Express bus system, express bus processing method, and express bus processing program, as well as transportation reservation system, transportation reservation method, and transportation reservation program

Abstract

We aim to streamline reservation processing for express bus services and improve the efficiency of reservation processing for jointly operated routes. [Solution] In an express bus system equipped with a server 1 and each reservation system storing management information required for reservations for a plurality of routes operated by a plurality of operators, server 1 is equipped with a management information storage means 190 storing the management information stored in the reservation systems, a reservation reception means 191 receiving reservations for the routes, and a reservation means 192 which, when a reservation for the route is received by the reservation reception means 191, executes a reservation for the route based on the management information stored in the management information storage means 190.

Description

[Technical field]

[0001] The present invention relates to an express bus system, an express bus processing method, and an express bus processing program that can effectively perform route searches, reservations, payments, etc. for connecting routes in express bus services, 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 multiple types of transportation such as buses, airplanes, ferries, taxis, rental cars, and rental bicycles at once and provides search results (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2019-211960 A Summary of the Invention [Problem to be solved by the invention]

[0004] When using this type of system to actually use a plurality of transportation means searched for, after using a first transportation means, a transfer is required to use a second transportation means. Transfers occur not only when multiple types of transportation are used, but also when a single type of transportation is used. For example, express bus routes are established nationwide 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 (e.g., eastern Japan), then if a user wants to travel by highway bus within region A (e.g., Tokyo to Nagoya), they must use highway bus A. In addition, 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), he or she 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. For this reason, when using an express bus to travel between region A and region B (for example, Tokyo → Okayama), it is necessary to travel on route A by express bus A, then transfer to express 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 route A on express bus A (for example, Tokyo → Osaka), and to access counter B to make a reservation and payment for route B on express bus B (for example, Osaka → Okayama). In other words, in addition to transferring, passengers had to visit multiple counters and complete procedures at each one. There are also expected benefits, such as the effective expansion of 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] In response to these issues, computerization of procedures can be effective to a certain extent, but problems are likely to occur in the linking process via communication with existing reservation systems, and other problems that arise from this need to be addressed (see Figure 24). In addition, in express bus services, one route (one bus) may be jointly operated by multiple bus companies, posing the following challenges in terms of 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 the 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 the rear seats. This resulted in an unreasonable problem in that if all the front seats were reserved, a user making a reservation through reservation system A could not reserve a rear seat, even if there was one available, because the rear seat was under the control of reservation system B. In joint operation, the total revenue from the route is distributed to each bus operator in a set ratio, but this type of operation can also be problematic in preventing increased revenue. In the past, these problems were addressed by having staff from bus company A and staff from bus company B communicate via telephone or other means and transfer some of the back seats managed by reservation system B to bus company A. However, because this was a manual process, 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 has an object to provide an express bus system, an express bus processing method, and an express bus processing program that make transfers and the associated procedures easy and useful. Another object of the present invention is to provide an express bus system, an express bus reservation method, and an express bus reservation program that enable smoother reservation processing and more efficient seat reservations on jointly operated routes. [Means for solving the problem]

[0007] In view of the above problems, an express bus system according to one embodiment of the present invention is an express bus system comprising: reservation systems each storing management information required for reservations for a plurality of routes operated by a plurality of operators; and a server; wherein the server comprises a management information storage means for storing the management information stored in the reservation systems; a reservation reception means for accepting reservations for the routes; and a reservation means for, when a reservation for a route is accepted by the reservation reception means, executing a reservation for the route based on the management information stored in the management information storage means.

[0008] In addition, an expressway bus reservation method according to another aspect of the present invention uses a server and each reservation system, each of which stores management information required for reservations for a plurality of routes operated by a plurality of operators, and includes a first step of storing the management information stored in the reservation systems, 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 a reservation for the route based on the management information stored in the first step.

[0009] In addition, an express bus reservation program according to another aspect of the present invention causes a computer connected to each reservation system, which respectively stores management information necessary for making reservations for a plurality of routes operated by a plurality of operators, to function as a management information storage means for storing the management information stored in the reservation systems, a reservation reception means for accepting reservations for a route, and a reservation means for, when a reservation for a route is accepted by the reservation reception means, executing a reservation for the route based on the management information stored in the management information storage means. Effect of the Invention

[0010] According to the present invention, it is possible to realize a highly useful express bus service, such as a series of long-distance buses, with simplified transfer procedures. In areas lacking direct routes, rail, 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 to improve the efficiency of reservation processing for jointly operated routes. [Brief description 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; [Diagram 2] FIG. 2 is a diagram illustrating a hardware configuration of a server. [Diagram 3] FIG. 2 is a hardware configuration diagram of a user terminal. [Figure 4] FIG. 2 is a functional configuration diagram of a server. [Diagram 5] 11 is a table showing an example of grouping information. [Figure 6] FIG. 11 is an explanatory diagram of a route search based on grouping. [Figure 7] FIG. 1 is an explanatory diagram of a special transfer route. [Figure 8] 11 is a sequence chart showing a processing procedure of a route search. [Figure 9] FIG. 13 is a diagram showing an example of a route search screen. [Figure 10] FIG. 13 is a diagram illustrating an example of a search result screen. [Figure 11] FIG. 13 is a diagram showing an example of a flight candidate display / selection screen. [Figure 12] 1 is a sequence chart showing a procedure for processing reservations and payments. [Figure 13] FIG. 13 is a diagram showing an example of a fee information display screen. [Figure 14] FIG. 13 illustrates an example of a reservation screen. [Figure 15] FIG. 13 is a diagram showing an example of a reservation result screen. [Figure 16] FIG. 13 illustrates an example of a payment execution screen. [Figure 17] 13 is a sequence chart showing a procedure for changing a reservation. [Figure 18] 13 is a sequence chart showing a procedure for canceling a reservation. [Figure 19] FIG. 13 is a diagram illustrating an example of a recommendation display screen. [Figure 20] FIG. 11 is a diagram showing another example (part 1) of the display screen. [Figure 21] FIG. 13 is a diagram showing another example (part 2) of the display screen. [Figure 22] FIG. 11 is a diagram showing another example (part 3) of the display screen. [Figure 23] FIG. 1 is an explanatory diagram of reservation system cooperation (reservation cooperation). [Figure 24] This is a diagram for explaining problems that may occur in reservation linkage. (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. [Diagram 25] FIG. 11 is a functional configuration diagram of a server according to another embodiment. [Figure 26] FIG. 11 is an explanatory diagram of a high-speed bus system according to another embodiment. [Figure 27] FIG. 13 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. 13 is a diagram showing seat information (A3) after sales (reservations) have begun. [Diagram 30] This figure shows the addition and deletion (A4) of seats for sale after sales (reservations) have begun. [Diagram 31] FIG. 13 is a diagram showing the acquisition of vacant seat information (B1). [Diagram 32] This is a diagram showing a request for a seat (B2). [Diagram 33] FIG. 13 is a diagram showing the execution of seat taking (B3). [Diagram 34] This is a diagram showing the automation of seat support (B4). DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] A preferred embodiment of the high-speed 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 to be able to execute reservation processing, which will be described later, 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 a payment process, which will be described later, substantially by the operation of the payment server 4. The devices are connected to each other via the Internet 9 so as to be able to 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 includes a CPU (Central Processing Unit). The memory 102 is a computer-readable storage medium, and is configured from a RAM (Random Access Memory), a ROM (Read Only Memory), or the like. The storage 103 is a computer-readable storage medium, and is configured by a solid state drive (SSD), 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, a tablet terminal, or a 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 a RAM (Random Access Memory), a ROM (Read Only Memory), or the like. The storage 203 is a computer-readable storage medium, and is configured from a solid state drive (SSD), 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 a mouse in a personal computer, or a touch panel in a smartphone or a tablet terminal. The display unit 205 displays various screens and information received from the server 1 (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 a reservation server 3A managed by bus company A which operates express bus A on a first route, and a reservation server 3B managed by bus company B which operates express bus B on a second route. The reservation server 3A has conventionally operated reservation site A for express bus A and route 1. For this reason, it is 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 conventionally operated reservation site B for express bus B and the second route. For this reason, it is 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 . It should be noted that 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 reserved and processed by the server 1. The payment server 4 of this embodiment is operated by a credit card company and enables credit card payments. In addition, other payment methods (bank transfer, electronic money payment, convenience store payment, etc.) can be used instead of or in addition to credit card payment. 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 pre-stores (stores) route information for currently existing express buses throughout the country. The route information is common to the route information managed by the reservation server 3. For this reason, it is sufficient to acquire and store in the storage means 11 the route information managed by each reservation server 3. 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 at appropriate times 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 route information for express buses. Specifically, the route information is configured to enable identification of 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, the operating bus company, etc., 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 begins 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 involves memorizing two lines in series when the area or stop at which one line ends is the same as the area or stop at which another line begins. The explanation of these two routes is just an example, and three or more routes can be grouped by linking them in series.

[0021] FIG. 5 is a diagram illustrating an example of grouping information. The grouping information will be explained using the first line 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 is the same as the starting region of the "Osaka → Okayama" route and the "Osaka → Hiroshima" route. Note that "XX → □□" indicates the name of the route, XX indicates the name of the area where the route starts, and □□ indicates the name of the area where the route ends. This allows the setting (registration) of a transfer route such as traveling on a highway bus from Tokyo to Osaka, getting off in Osaka and changing to another highway bus to head to Okayama, or traveling on a highway bus from Tokyo to Osaka, getting off in Osaka and changing to another highway bus to head to Hiroshima. The setting and registration (storage) of the transfer route may be performed automatically by a computer or manually, by following the above-mentioned rules. By doing this manually, it is possible to set only the transfer routes that are deemed necessary. In the case of computer processing, it is possible that a large number of unnecessary transfer routes will be set, but the number of unnecessary transfer routes can be reduced by combining the methods described below (such as limiting the number of transfers) or by thinning them out artificially. 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 available to the user (hereinafter also referred to as “available routes”) from the track information stored in the storage means 11, based on the information inputted 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 following route (second route). Because it is "multiple routes," it is not limited to transfers between two routes, but includes transfers between three or more routes. In other words, the 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 "Tokyo → Okayama" as a search condition. 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 is able to set search conditions based on the search condition information.

[0024] When the search condition is "Tokyo → Okayama," first, the control unit 101 (extraction unit 12) refers to the route information (including grouping information) stored in the memory means 11 and extracts a 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 end area of ​​the extracted route is the same as the starting area will be excluded. In this way, a rule that excludes an extracted route if the area at the end of the route is the same as the area at the starting point is called the "first rule." In addition, since there are no routes among the above first routes that fall under the first rule, no routes are excluded based on the first rule. Also, 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. Route search for subordinate routes of the route extracted as an available route is not performed and the process ends. In this way, if the area at the end of an extracted route is "the same as the destination," the route is extracted as a usable route, and the rule that ends the route search at that point is called the "second rule." Among the first route, the route that falls under the second rule is "Tokyo → Okayama." Therefore, the extraction means 12 extracts the direct route of the "Tokyo → Okayama" line as the available route, and ends the process without executing the route search below "Tokyo → Okayama".

[0025] Next, the control unit 101 (extraction unit 12) extracts a route (second route) that starts from the end area of ​​the first route. 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, since the end area is "Osaka", 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 end area of ​​the extracted route is the same as the starting area. In the case of the "Tokyo → Kobe" route, since the end area is "Kobe", 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 end area of ​​the extracted route is the same as the starting point. As a result, the route "Osaka → Okayama" and the route "Kobe → Okayama" 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. Then, the route search for each line is terminated.

[0026] Next, the control unit 101 (extraction unit 12) extracts a route (third route) that starts from the end area of ​​the second route. In other words, the control unit 101 extracts a route (third route) following the preceding route "Osaka → Hiroshima". In the case of the "Osaka → Hiroshima" route, the end region is "Hiroshima", so we extract the route with "Hiroshima" as the start 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 ends 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 performs a process of extracting usable 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 routes: "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 one groups combinations of routes 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 a large number of such combinations, so there is a problem that simply extracting available routes through computer processing may result in a large number of useless available routes being extracted. This problem can be addressed by limiting the number of transfers to a certain number. That is, the extraction means 12 extracts a transit route with a specific number of transits or less as an available route, and does not extract a transit route with a specific number of transits or more as an available route. In that case, if the "specific number = 2" is set, 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 the number of transfers is "3."

[0028] Note that the available routes can be limited by other methods as well as by restricting the number of transfers. For example, the grouping information is set manually. As an example, a combination (grouping) of routes for which a demand for transfers is expected from the viewpoints of bus operators, travel agents, and users is detected manually, 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 a popular destination, and "Okayama" is the departure and arrival point, then "Hiroshima," which is one bus stop away from "Okayama" (a nearby area), 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 who lives in Tokyo and has his / her parents' home in Hiroshima needs to go to Okayama for business purposes, he / she can first return to Hiroshima and then make a business trip to Okayama. It is possible to adjust the time until the transfer or even set the transfer to 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 would remain hidden. For this reason, previous users probably felt some frustration at not being able to return home despite having traveled so far to get close to their parents' homes, but were discouraged from doing so by regulatory notions and common sense. According to the express bus system of this embodiment, a new service can be realized that provides a connecting route that allows travel to an area farther than the destination before arriving at the destination, thereby resolving potential problems in 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 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 is sufficient 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 called "Tokyo Station → Okayama Interchange" and "Tokyo Station → Okayama Station," it is possible to specify "Tokyo Station" as the departure point and "Okayama Interchange" or "Okayama Station" as the destination.

[0033] For this reason, in route information, the names of bus stops and the names of areas are stored in association with each other. For example, since there are bus stops called "OCAT" and "Umeda Tower" in "Osaka," "Osaka" (area name) is linked to "OCAT" and "Umeda Tower" (bus stop names) and stored in the route information. Similarly, since there are bus stops called "Okayama Station" and "Okayama Interchange" in "Okayama," "Okayama" (area name), "Okayama Interchange" (stop name), and "Okayama" are stored in association with each other in the route information. Similarly, since there are bus stops called "Kobe Sannomiya" and "Kobe Station" in "Kobe," "Kobe" (area name) is linked to "Kobe Sannomiya" and "Kobe Station" (stop name) and stored in the route information. It is assumed that only one bus stop, "Tokyo Station," exists in "Tokyo," and only one bus stop, "Hiroshima Station," exists in "Hiroshima." For this reason, "Tokyo" (area name) and "Tokyo Station" (bus stop name), and "Hiroshima" (area name) and "Hiroshima Station" (bus 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 exists 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 with the search condition "Tokyo Station to Okayama Station," the same process as the route search based on the area name described above is executed. In addition, the "first rule" is to be interpreted as "a rule that excludes a line if the stop is the same as the last stop of the extracted line." In addition, the "second rule" is to be interpreted and applied as "a rule that extracts an extracted route as an available route if the last stop of the 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) by the Web browser provided in the user terminal 2. The display control means 13 can, for example, cause the information on the available routes extracted by the extraction means 12 to be displayed on the user terminal 2. In this case, the server 1 (the communication unit 104) transmits information on the extracted available routes to the user terminal 2. The user terminal 2 displays the information on the available routes transmitted from the server 1 on the display unit 205 (see FIG. 10).

[0037] The reservation means 14 executes reservation processing for an available route in response to an operation of the user terminal 2. The reservation means 14 can collectively execute reservation processing for a plurality of routes constituting a connecting route in response to an operation of the user terminal 2. This "collective reservation processing" is performed in cooperation with multiple reservation servers 3 each responsible for processing reservations for multiple routes. Specifically, server 1 cooperates 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, and therefore sends reservation request information to reservation server 3A for processing reservations for the "Tokyo Station → OCAT" route, and sends reservation request information to reservation server 3B for processing reservations for the "OCAT → Okayama Station" route. 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 server 3 executes the reservation processing. 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, which is responsible for reservation processing for direct routes, to request 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 collectively in response to an operation of the user terminal 2. This "lump-sum payment processing" is realized by the cooperation between server 1 and 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, the server 1 receives information necessary for payment (user's name, amount, card number, expiration date, security code, etc.) from the user terminal 2, and sends payment request information including that information to the payment server 4 to request payment processing, and the payment processing is then executed by the payment server 4. The express bus system of this embodiment includes one payment server 4. However, if a payment system exists for each credit company, cooperation with each payment server 4 included in each payment system is required. For example, if payment for the fare (first fare) of express bus A or the first route can only be made with credit card A and the payment process can be performed by payment server 4A, and payment for the fare (second fare) of express bus B or the second route can only be made with credit card B and the payment process can be performed by payment server 4B, server 1 will send payment request information to payment server 4A for the payment process of the first fare, and will send payment request information to payment server 4B for the payment process of 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 collectively in response to an operation of the user terminal 2. The reservation cancellation means 17 can execute reservation cancellation processing in response to an operation of the user terminal 2. The reservation cancellation means 17 can execute cancellation processing for multiple reserved routes collectively in response to an operation of 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 transfer route. In particular, the benefit granting means 18 can grant a larger benefit to a user of a transit route in which the number of transfers is a second number, which is greater than the first number, when using the transit route, than to a user of a transit route in which the number of transfers is a first number. Specifically, the discount rate may be set higher the more transfers there are, such as setting the discount rate for one transfer at X%, the discount rate for two transfers at Y% (≧X%), and the discount rate for three transfers at Z% (≧Y%). The discount amount may vary depending on the circumstances at the time of reservation (for example, the discount rate may be higher in the off-season than in the peak season, or the discount rate may be higher when there are many vacant seats). A special transit route may be discounted more than a normal transit route, in which case the discount may be increased as the overlapping distance between the preceding route and the following route increases. 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 transfer routes at low cost, and will increase the value of express buses through an increase in users.

[0041] The functions of the reservation server 3 will not be described in detail since a known express bus reservation system is utilized. The functions of the payment server 4 will not be described in detail since 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, "route search," "reservation and payment," "reservation change," and "reservation cancellation" will be explained in that order.

[0043] (Route search) The route search process will now be described. FIG. 8 is a sequence chart showing the procedure of a route search process. 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 specific URL (Uniform Resource Locator) into the Web browser of the user terminal 2. On the route search screen, the user enters the search condition 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 selection, and when a region is selected, the name of a bus stop in that region by selection (d1, d2 in FIG. 9). The departure point and destination can also be entered by selecting (clicking or tapping) the bus stop mark displayed on the map (d5 in Figure 9) (d4 in Figure 9). The departure date can be entered via a 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. In addition, other information (for example, departure time, arrival date, arrival time, stopovers, whether or not there is a connection, number of people, etc.) may be entered as search conditions. The user terminal 2 (communication unit 206) transmits the input search condition information (start point, 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 transfer routes, and (4) is a direct route. The explanation of route search has already been given, so it will be omitted. 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 described above in (1) to (4) 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 and can be selected: (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 the transfer route (1) "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 connecting route information 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 the departure date is transmitted to the reservation server 3A, and flight confirmation information including the second route information and the departure date is transmitted to the reservation server 3B. This is because the first route, "Tokyo Station → OCAT", has traditionally been managed by reservation server 3A, and the second route, "OCAT → Okayama Station", has traditionally been managed by reservation server 3B. 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 the route is selected 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 of the first route from the reservation server 3A, the server 1 includes the arrival time of the first route contained in the flight information in the 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 regarding the first route and transmits the flight information as the search result to the server 1 (S107), and the reservation server 3B searches for flight information regarding the second route and transmits 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 regarding 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. In other words, "2024 / 2 / 1_22:10-06:44_7,800 yen_6 seats remaining" is sent as flight information for the first route, and "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 sent as flight information for the second route.

[0050] The user terminal 2 displays the flight information received from the server 1 on the display unit 205 (S110). In other words, 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 regarding the first flight (d21) and also displays flight candidate information regarding the second flight (d22). Specifically, the following flight candidate information is displayed: 1st flight_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); 2nd flight_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 process 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, a flight is selected (S201). Specifically, the user selects a desired flight from among the flight candidates displayed on the flight candidate display / selection screen (Fig. 11). As shown in FIG. 11, the flight candidate display / selection screen has check boxes for each flight candidate that can be used to select the flight candidate, so the user can select the flight candidate by selecting the check box for the desired flight candidate. In this processing procedure, the first flight selected is flight candidate 1, which departs at "Tokyo Station_22:10" and arrives at "OCAT_6:44", and the second flight selected is flight candidate 2, which departs at "OCAT_10:30" and arrives at "Okayama Station_13:30" (Figure 11). The user terminal 2 transmits the selected flight information (boarding flight information) to the server 1. Specifically, the boarding information transmitted will be [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 the discount rate is Y% (≧X%), for three transfers the discount rate is Z% (≧Y%), etc., 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 or amounts during off-season and peak seasons, or to apply discount rates or amounts based on available seats. Passengers on special transfer routes may be eligible for higher discount rates or amounts than those on regular transfer routes. In this processing procedure, the standard fee is 10,800 yen in total, consisting of 7,800 yen for the first flight and 3,000 yen for the second flight, and a discount amount of 200 yen is applied, 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 is 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), and can also display 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 transitions 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 reservations via login. For example, by selecting the SNS login button (d42) displayed on the reservation screen, it is possible to automatically log in and make a reservation via SNS integration. 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 to OCAT") is sent to reservation server 3A, and reservation request information regarding the second route ("OCAT to 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." In other words, since the server 1 is not currently processing reservations, it transmits 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 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, reservation processing for the first route can be performed by a reservation server 3A (first device) operated by a first operator, and reservation processing 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 processing for the first route to be performed by the reservation server 3A (first device) and the reservation processing for the second route to be performed by the reservation server 3B (second device), thereby making it possible to perform reservation processing for a connecting route consisting of the first route and the second route in a single operation.

[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 combination of 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 linked to the reservation number and managed.

[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 input into the user terminal 2 (S212). Payment information can be entered via a 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 includes a display of the fee (d61) as payment information, and an input field (d62) for credit card information (card number, expiration date, security code). In addition, 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 is entered: "Card number: 1234-5678-9021, expiration date: 5 / 2 / 2026, security code: ***" (Figure 16). The user terminal 2 transmits the input 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 series following 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 carried out in a single operation.

[0065] (Reservation change) The procedure for changing a reservation will now be described. FIG. 17 is a sequence chart showing a procedure for changing a reservation. As shown in the figure, reservation changes can be made in a state where the reservation information received from the server 1 is displayed on the display unit 205. For example, the reservation result screen (Figure 15) displaying 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 for specifying the flight information to be changed (i.e., the old flight information), and when 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 which 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 executes a new flight search based on the departure and arrival points and departure date of the flight to be changed that is included in the original flight information, and transmits the search results to the server 1 as candidate flight information for change. 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 flight information candidates 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 the reservation change screen 2 as well.

[0071] Next, reservation change operation 2 is performed (S307). Specifically, reservation change operation 2 is an operation for specifying 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 fee information such as the standard fee, the discount amount, and the deduction amount to the user terminal 2. 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 changed destination information and fee information.

[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 transmitted from the server 1, it executes reservation change processing (S312). Specifically, the source flight information "2024 / 2 / 2_9:30-12:30" will be 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] When the payment server 4 receives the payment request information transmitted from the server 1, it 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 contents to the user terminal 2 (S315). When the user terminal 2 receives the result of the change transmitted from the server 1, it displays the result of the change on the display unit 205 (S316). The result of the change is not shown in the figure.

[0079] (Reservation cancellation) The procedure for canceling a reservation will now be described. FIG. 18 is a sequence chart showing a procedure for canceling a reservation. As shown in the figure, reservation cancellation can be performed in a state where the 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 (reserved boarding information for the first 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]). 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 is cancelled (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 transmitted 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 transmitted from the server 1, it executes the reservation cancellation process (S405). The reservation server 3A transmits 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 commission calculated in S403.

[0083] When the payment server 4 receives the payment request information transmitted from the server 1, it 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 payment result transmitted from the payment server 4, it transmits the cancellation result including the cancellation content 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 figure.

[0085] In this manner, 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 the reservation, previously you would have to visit multiple counters and go through the cancellation process for each one individually, but with the bus system of this embodiment, you can complete the process all at once.

[0086] (Recommendation information display) The display process of the recommendation information will be described. In the express bus system of this embodiment, various pieces of recommended information are provided to users of express buses. 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 that is likely to interest the member through analysis of the history information, and notifies the member 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 when the member is logged in, and when the member is not logged in, recommended information is sent to a pre-registered email address.

[0087] FIG. 19 is a diagram showing an example of a recommendation display screen. Figure 19 shows 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 connecting point of "Osaka." The recommendation information shown in the figure suggests that Yamada has booked a connecting route and that the recommendation information corresponds to the time when Yamada will transfer at the transfer 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 the 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 is during the night of the previous day, 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 an express bus" is information that encourages members to make reservations for an express bus by pairing recommended spots, etc. with the nearest bus stop, and notifying the user terminal 2 by e-mail, etc. by generating such information on the server 1. 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, since the user's current location can be identified from the time and the GPS information of the user terminal 2, various information corresponding to the current location (for example, while moving 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 a member to make a reservation next time immediately after using an express bus, and notify the user terminal 2 via chat or the like.

[0089] Another display example 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 is allowed to select either "travel time" or "fare." 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. Additionally, you can narrow down flight information by selecting either "with transfer" or "without transfer." For example, users who prefer or can tolerate transfers can select "with transfers," while users who do not prefer or can tolerate 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 possible to select either "in order of most number of transfers" or "in order of least 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, when "order by 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. In other words, the display control means 13 causes a connecting route with a second number of transfers, which is greater than the first number, to be displayed higher on the user terminal 2 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. Additionally, the transfer discount for a transfer route with a large number of transfers can be greater than the transfer discount for a transfer route with a small number of transfers. In other words, a transfer discount for a transfer route with a large number of transfers will be displayed with a relatively large discount amount applied.

[0092] This will make it possible to display information that caters to users who prefer to transfer, or who want to use express buses at a cheaper 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 situation were to occur, there is a preconceived notion that "transfers = inconvenience," so displaying the number of transfers in order was not anticipated. According to the express bus system of this embodiment, the convenience of transfers is improved, thereby eliminating the notion that "transfers = inconvenience." In addition, the display modes shown in Figures 20 to 22 can further improve convenience for users who wish to actively make use of 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: storage means 11 for storing route information of existing express buses; extraction means 12 for extracting from the route information available routes which are routes available to the user based on information input by the user terminal 2; display control means 13 for displaying information of the extracted available routes on the user terminal 2; and reservation means 14 capable of executing reservation processing of the available routes in response to operation of the user terminal 2, wherein the extraction means 12 is capable of extracting a transfer route involving transfers between multiple routes including a first route and a second route as the available route, and the reservation means 14 is capable of simultaneously executing reservation processing of multiple routes constituting the transfer route in response to operation of the user terminal 2. In other words, the reservation process for the connecting route is executed in a lump sum in response to operations via a single website, and further, following the reservation process, the payment process is executed in a series and lump sum. This will make reservations and payment 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 between bus operators, and through such cooperation the entire bus business can flourish. It will also help resolve the actual vehicle mileage restrictions and so-called 2024 problems faced by bus operators. Furthermore, in areas lacking direct routes or other means of transportation such as rail and 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 transportation and travel. In contrast, in the past, there was the hassle of procedures 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 needed to transfer, you had to make reservations at multiple counters, but with the express bus system of this embodiment, all of the reservations can be processed together, and payments can be made all at once. In addition, 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, the reservation of an express bus is performed 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 three or more reservation systems are integrated.

[0095] FIG. 23 is an explanatory diagram of reservation linkage. Specifically, Fig. 23 is a diagram showing a typical process of making a reservation for a connecting route that involves three lines through reservation cooperation. For this reason, Fig. 23 assumes cooperation with three reservation systems. That is, FIG. 23 assumes that a user operates user terminal 2 to make a reservation for a connecting route consisting of a first route (bus A), a second route (bus B), and a third route (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) is capable of making 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 seats on the first route are requested to reservation system A, reservations for seats on the second route are requested to reservation system B, and reservations for seats on the third route are requested to 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 give rise to 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 link between reservation system A and reservation system B was processed without any problems, but a problem occurred in the link with reservation system C, causing the route or seat reservation to fail. In this case, the user will have to perform the reservation operation again, which reduces convenience, and the successful reservations in reservation systems A and B will have to be deleted, resulting in other problems. FIG. 24(b) shows problems that occur when changing the number of people or canceling a reservation after it 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 "success", but it is necessary to cancel (delete) the reservation in reservation system B. In other words, unless the cancellation in reservation system B is somehow executed, the reservation cancellation as a whole will not be completed, so the problem arises that a management mechanism for the cancellation of reservation system B is required. When changing the number of people in a reservation, the system cancels the original number of people and then stores the correct number of people, so the same problems arise as when canceling a reservation. 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., with the 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 reservation means 14 described above, that is, reserving routes, 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 the server 1 to accept and execute reservations alone. Furthermore, since the configuration of the reservation system remains the same, reservations can be accepted and made 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 line, the reservation means 192 of the server 1 executes the reservation for the line 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 required for reserving a seat (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 receiving means 193 of the server 1 receives seat reservations. When a seat reservation is accepted by the seat reservation accepting means 193 , 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 a first seat, the seat reservation means 194 of the server 1 executes 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 a second seat, the seat reservation means 194 executes 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 server 1 acquires (prestores) management information required for reserving routes and seats in advance, so that reservations can be made by the server 1 alone. The server 1 is communicatively connected to each reservation system (reservation server), and receives and acquires management information (including seat information capable of identifying 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 of the user terminal 2 . For example, when server 1 receives a reservation for a connecting route and a 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 pre-stored management information of each reservation system, 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 makes it possible to prevent problems associated with reservation coordination regarding seat reservations.

[0102] Each reservation server has a configuration similar to that of the above-mentioned server 1 (not shown). In other words, in the reservation server, means corresponding to management information storage means 190 stores information necessary for making reservations for routes under the management of the system, means corresponding to reservation reception means 191 accepts reservations for routes under the management of the system, means corresponding to reservation means 192 can reserve the accepted route, means corresponding to seat reservation reception means 193 accepts seat reservations, and means corresponding to seat reservation means 194 can reserve the accepted seat. As a result, the reservation server has traditionally been equipped with a configuration that allows it to make reservations for routes and seats that are managed by its own system.

[0103] (Management and reservation of seats on jointly operated routes) A "jointly operated route" refers to a route that is 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, it is envisaged that 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 rear 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 performed centrally by server 1, but rather the reservations of seats allocated to each operator are performed 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 were handled individually and manually by each reservation system. Furthermore, by being equipped with 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 according to the other embodiments are only for managing and reserving "seats" on jointly operated routes, and do not include managing and reserving "jointly operated routes." These functions may be performed individually by each reservation system.

[0104] (Seat management for jointly operated routes) As described above, seats on express buses operated on jointly operated routes are managed by multiple operators, so 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, for seats for which specific information is set in the seat information (setting: meaning stored in correspondence), the seat reservation control means 196 controls the reservation means 192 provided in the server 1 to be inoperable, 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) in server 1 or reservation system A, but can be sold (reserved) in reservation system B. Although the above description is for a case where there are two joint operators, it can also be applied to a case where there are three or more. For example, if there are three joint operators, the seat information managed (stored) by the reservation system C is acquired, and the seat information is associated with the information of the operator C and stored.

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

[0106] FIG. 27 is a diagram showing acquisition of seat information before sales (A1). As shown in FIG. 27, before seats are sold (before reservations are accepted), the server 1 acquires and stores the seat information managed by each reservation system (each operator), i.e., each reservation server, in advance (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). Furthermore, the server 1 is communicably connected to each reservation server via the Internet or the like, and can obtain seat information via the communications. Therefore, 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 operator information that sells seats, operator information that does not sell seats may be used, and "available for sale" information or "not available for sale" information may be associated with the operator information that sells seats or the operator information that does not sell seats and stored. The seat information includes seat availability information indicating whether a seat is reserved or vacant. For this reason, the server 1 stores the 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 that can be reserved (seats for sale) through each reservation system. For example, a unique account is provided for each operator, and when the server 1 confirms (authenticates) the input of pre-set account information (user ID, etc.), it causes the seat map of that operator to be displayed on the web on the management terminal. The management terminal is assumed to be a management terminal for server 1 or a management terminal for a reservation system that can be connected to server 1 via the Web.

[0108] FIG. 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 the 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 show a schematic representation of the transmission and reception of information between the server 1 and each reservation server. The seat map shown in Figure 27(a) distinguishes between sold seats (seats that can be sold by Operator A) and non-sold seats (seats that cannot be sold by Operator A) in reservation system A. For convenience, sold seats are shown in "light ink" and non-sold seats 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 sold seats (seats available for sale by operator B) and non-sold seats (seats not available for sale by operator B) in reservation system B. For convenience, sold seats are shown with "shading" and non-sold seats are shown with "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 ink) 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, and 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 through D·1 through 4 are for sale and seats A through D·5 through 11 are not for sale (Figure 27(a)), and can further recognize that these not for sale seats are for sale by Operator B (Figure 27(c)). In addition, Operator B can recognize that seats A through D·5 through 11 are seats for sale and seats A through D·1 through 4 are seats not for sale (Figure 27(b)), and can further recognize that the seats not for sale are seats for sale by Operator A (Figure 27(c)). In addition, 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. For this reason, 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 a state in which the server 1 (the express bus system) cannot sell (reserve) even one seat. 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 the server administrator as a third operator, thereby enabling third operators to accept and execute seat reservations on server 1. The method for adding an administrator (third operator) of a server terminal will be described below.

[0112] FIG. 28 is a diagram showing the setting (A2) of seat information before the sale. Specifically, this figure shows a setting method for adding seats for sale by a third operator after acquiring seat information (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 only diagrammatically 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 of moving the seat for sale from the reservation system to a third operator by setting the seat information of the seat for sale in the reservation system to "not for sale" information or setting information indicating that the seat information is for a third operator. For example, by operating the management terminal, the server 1 associates the "not for sale" information or "server administrator information" with the seat numbers A to D, 3 to 4 (dashed line portion) of the seats for sale in the reservation system A stored in the server 1 and stores them. As a result, server 1 executes the process of adding (setting) seats A through D, 3, and 4 as seats for sale by the server administrator, and sends information to reservation system A (reservation server A) that seats A through D, 3, and 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 line area) of the seats for sale in reservation system B that it has stored, and stores them. As a result, server 1 executes the process of adding (setting) seats A through D, 5 and 6 as seats for sale by the server administrator, and sends information to reservation system B (reservation server B) that seats A through D, 5 and 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 only diagrammatically 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 (x), and as shown in FIG. 29(c), A to D·3 to 4 are displayed as sale 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), seats A to D·5 to 6 are displayed as non-sale seats (x), and as shown in FIG. 29(c), seats A to D·5 to 6 are displayed as sale seats (blank). In other words, 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) of 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 to which the specific information is associated.

[0114] FIG. 30 is a diagram showing 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 carried out. 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 only diagrammatically 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 may be added or deleted only if they are vacant. The reason for limiting the scope to "vacant seats" is to solve the existing problem that in joint operations, even if there are vacant seats it is not possible to make a reservation. Since the latest "vacant seat information" is managed (stored) in the reservation system, the server 1 causes the reservation system to transmit the "vacant seat information" as necessary. 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 vacancy status, such as whether the seats for sale are vacant or reserved. For example, Figures 30(a) and (c) show that seats C through D and 1 through 2 are available for sale by reservation system A (light ink) and are vacant. Also, Figures 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 seat not for sale, and the seat corresponding to the server administrator can be changed 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 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), when server 1 stores information indicating that seats D·1-2 are sold by the server administrator in association with seat numbers D·1-2 of seats sold by reservation system A, server 1 becomes able to recognize that seats D·1-2 are sold by the server administrator, and reservation server A also becomes 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-2 as sales seats. In other words, the change means 197 of the server 1 can change information indicating a seat managed by operator A (one operator) to a seat managed by a third operator (another operator) by correlating the information with specified specific information (information indicating that the seat is managed by another operator) and storing the information. As a result, the server administrator is able to 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 the seats for sale (vacant seats) to seats not for sale, and change the seats associated with the reservation system from seats not for sale to seats for sale. Specifically, in response to an operation of the management terminal, the server 1 sets information indicating that the seat is a seat for sale in the reservation system to the seat number of the seat for sale (vacant seat) of 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), when server 1 stores information indicating that seats D·5-6 are sold by reservation system B in association with seat numbers D·5-6 of the seats sold by the server administrator, server 1 becomes able to recognize that seats D·5-6 are not sold by the server administrator, and reservation server B also becomes able to recognize that seats D·5-6 are sold by reservation system B. This allows the server administrator to remove D·5-6 from the sales seats. In other words, the change means 197 of the server 1 can change information indicating a seat managed by one operator to a seat managed by another operator by correlating the information with specified specific information and storing the information. As a result, the server administrator will be unable to accept or execute reservations for seats D·5-6 via server 1. In this way, seats that have remained vacant and not sold (reserved) under the management of one operator can be made available for sale by other operators (including third operators). This solves the existing problem of not being able to reserve seats even when there are vacant seats in joint operations.

[0117] 31 to 34 show 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 show a schematic representation of 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 the server 1 can obtain (receive) "vacant seat information" from the reservation system as necessary and store it in association with the seat number (similar to Figure 30). This allows the server 1 to grasp the seat vacancy status, such as whether the seats for sale are vacant or reserved. The server 1 only needs to obtain vacant seat information, and does not need to obtain reservation information. For example, as shown in Figures 31(a) and (c), vacant seat information indicating that seats C through D and 1 through 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 through D, 5 through 6 and 9 through 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 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 existing problem of not being able to reserve seats even if they are available 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 for sale in one reservation system to a seat for sale 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 understand that seats C through D and 1 through 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 makes a request to reservation system A for the seats (vacant seats) C to D·1 to 2 that are for sale. In this case, the 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 sold seats C to D·1 to 2) is output from the management terminal to the server 1. The server 1 inputs the request information output from the management terminal, and thereby accepts the request for a seat. Based on the input request information, the server 1 recognizes that a seat reservation request from the reservation system B to the reservation system A has been accepted. 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 causes it to be displayed. This allows the administrator of reservation system A to grasp the contents of the request information (a request to get seats for sale seats C to D·1 to 2) via the management terminal. In addition, the dashed line related to "Request for seat reservation" in Figure 32 is an image diagram to make the actual flow of the seat reservation request easier to understand, and does not represent the actual flow of information processing. The same applies to the dashed lines related to "Approval / Rejection".

[0119] The administrator of reservation system A, who has seen 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 administration 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 a seat grab" will be described with reference to FIG.

[0120] FIG. 33 is a diagram showing the execution of seat taking (B3). Specifically, the seat reservation is performed by storing the seat numbers C to D·1 and 2 in the server 1 in association with the operator B information. That is, the change means 197 of the server 1 changes a seat managed by an operator A (one operator) to a seat managed by an operator B (another operator) by storing specified specific information for the seat. As a result, the sold seats C~D·1~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 not been sold (reserved) and remain vacant through reservation system A (operator A) can now be sold (reserved) through reservation system B (operator B). This solves the existing problem of not being able to reserve seats even when there are vacant seats in joint operations.

[0121] FIG. 34 is a diagram showing the automation of seat support (B4). The above-mentioned seating arrangement (FIG. 33, etc.) is partially executed manually, but the seating arrangement 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 specified 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 for sale (vacant seats) in reservation system B is 2 (a certain number or less) and that the number of seats for sale (vacant seats) in reservation system A is 8 (a certain number or more), so it can select the four seats for sale (vacant seats) in the front: C to D·1 to 2, and change the reservation system from A to B. Specifically, similarly to the case shown in FIG. 33, the server 1 may store the operator B information in association with the seat numbers C to D·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 available seats to be moved may be x% (e.g. 30%) of the available seats (vacant seats) in the reservation system from which the seats are moved, or may be determined based on a relationship between a "fixed number" and a "predetermined number." This will efficiently solve the previous problem of not being able to reserve seats 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 a 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 be provided in external devices including the user terminal 2, the reservation server 3, and the payment server 4. Also, a part 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 capable of communicating with the server 1. Furthermore, the server 1 may have some of the functions of the reservation server 3 and the payment server 4. In addition, 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 a part of the reservation servers 3 may be devices operated by the same business operator.

[0123] Although the special transfer route has been described based on the area names for the sake of convenience, it may be realized based on the bus stops. In that case, the area names may be replaced with the bus stop names. Furthermore, the server 1 may manage flight information (including seat availability and prices) 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 reservation processing by itself.

[0124] Furthermore, while the above embodiment is a system relating to transfers on express buses, the present invention can be expanded to a system relating to transfers between other means of transportation such as airplanes, bullet trains, etc. In another embodiment, seat association 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 joint operators has been described as an example, but the present invention can also be applied to a case where there are three or more joint operators. It can also be applied to routes jointly operated by an operator who runs one reservation system and a third operator (server administrator). In addition, automation of seat collecting may be performed using AI (Artificial Intelligence). For example, a model (program) can be generated that learns (through machine learning or deep learning, etc.) from the past performance of the number of seats sold and the number of seats given to reservation systems A and B, and that can output the number of seats given to one system when the number of seats sold in one system reaches a specific number, and the number of seats sold or the number of seats remaining for sale in one system or both systems can 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: privilege 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. In an express bus system, the system includes a server and reservation systems each storing management information necessary for reservations on a plurality of routes operated by a plurality of operators, The server, a management information storage means for storing management information stored in the reservation system; A reservation acceptance means for accepting reservations for the route; a reservation means for executing a reservation for the line based on the management information stored in the management information storage means when the reservation acceptance means accepts a reservation for the line, The management information includes seat information necessary for reserving seats on express buses, A seat reservation receiving means for receiving a seat reservation; a seat reservation means for executing a seat reservation based on the seat information stored in the management information storage means when a seat reservation is accepted by the seat reservation acceptance means, The route includes a jointly operated route on which a plurality of operators, including a first operator and a second operator, jointly operate an express bus; A specific information storage means for storing information indicating a seat on an express bus operated on the jointly operated route in association with specific information indicating that the seat is managed by a specific operator; a seat reservation control means for allowing the specific operator to make a reservation for the seat associated with the specific information and restricting the reservation by the seat reservation means; A high-speed bus system.

2. The route includes a jointly operated route jointly operated by multiple operators including a third operator, The specific information storage means includes: storing specific information indicating that the seat is managed by the third operator in association with information indicating the seat; The seat reservation control means The seat reservation means executes a reservation for the seat to which the specific information is associated.

2. The high-speed bus system according to claim 1.

3. The specific information storage means is provided with a change means for changing a seat managed by one operator to a seat managed by another operator by storing specific information indicating that the seat is managed by another operator in association with the seat managed by one operator.

3. The express bus system according to claim 1 or 2.

4. The change means is Execute when the number of seats managed by the one operator reaches a predetermined number.

4. The express bus system according to claim 3.

5. The route includes a transfer route that transfers between a plurality of routes including a first route and a second route.

2. The express bus system according to claim 1.

6. A method for making reservations for express buses using a server and reservation systems each storing management information necessary for making reservations for a plurality of routes operated by a plurality of operators, comprising: a first step of storing management information stored in the reservation system; A second step of accepting route reservations; a third step of executing a reservation for the line based on the management information stored in the first step when the reservation for the line is accepted in the second step, The management information includes seat information necessary for reserving seats on express buses, A fourth step of accepting seat reservations; a fifth step of executing the seat reservation based on the seat information stored in the management information when the seat reservation is accepted in the fourth step, The route includes a jointly operated route on which a plurality of operators, including a first operator and a second operator, jointly operate an express bus; A sixth step of storing information indicating a seat on an express bus operated on the jointly operated route in association with specific information indicating that the seat is managed by a specific operator; a seventh step of allowing the specific operator to make a reservation for the seat associated with the specific information and restricting the reservation made in the fifth step; A method for making reservations for express buses.

7. A computer connected to each reservation system, each of which stores management information necessary for reservations for a plurality of routes operated by a plurality of operators, a management information storage means for storing management information stored in the reservation system; A reservation acceptance means for accepting reservations for the route; when a reservation for a line is accepted by the reservation accepting means, the reservation accepting means functions as a reservation means for executing a reservation for the line based on the management information stored in the management information storage means; The management information includes seat information necessary for reserving seats on express buses, A seat reservation acceptance means for accepting seat reservations; when a seat reservation is accepted by the seat reservation accepting means, the seat reservation accepting means executes the seat reservation based on the seat information stored in the management information storage means; The route includes a jointly operated route on which a plurality of operators, including a first operator and a second operator, jointly operate an express bus; a specific information storage means for storing information indicating a seat on an express bus operated on the jointly operated route in association with specific information indicating that the seat is managed by a specific operator; a seat reservation control means for allowing the specific operator to make a reservation for the seat associated with the specific information and restricting the reservation by the seat reservation means. The express bus reservation program is characterized by the above.

8. A transportation reservation system comprising a server and reservation systems each storing management information necessary for reservations for a plurality of routes operated by a plurality of operators, The server, a management information storage means for storing management information stored in the reservation system; A reservation receiving means for receiving reservations for the route; a reservation means for executing a reservation for the route based on the management information stored in the management information storage means when the reservation acceptance means accepts a reservation for the route, The management information includes seat information necessary for reserving seats on the means of transportation; A seat reservation receiving means for receiving a seat reservation; a seat reservation means for executing a seat reservation based on the seat information stored in the management information storage means when a seat reservation is accepted by the seat reservation acceptance means, The route includes a joint operation route in which a plurality of operators, including a first operator and a second operator, jointly operate a transportation means; a specific information storage means for storing information indicating a seat on a transportation means operated on the jointly operated route in association with specific information indicating that the seat is managed by a specific operator; a seat reservation control means for allowing the specific operator to make a reservation for the seat associated with the specific information and restricting the reservation by the seat reservation means; A transportation reservation system comprising:

9. A transportation reservation method using a server and each reservation system that stores management information required for reservations for a plurality of routes operated by a plurality of operators, comprising: a first step of storing management information stored in the reservation system; A second step of accepting reservations for 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, The management information includes seat information necessary for reserving seats on the means of transportation; A fourth step of accepting seat reservations; a fifth step of executing the seat reservation based on the seat information stored in the management information when the seat reservation is accepted in the fourth step, The route includes a joint operation route in which a plurality of operators, including a first operator and a second operator, jointly operate a transportation means; A sixth step of storing information indicating a seat of a transportation means operated on the joint operation route in association with specific information indicating that the seat is managed by a specific operator; a seventh step of allowing the specific operator to make a reservation for the seat associated with the specific information and restricting the reservation made in the fifth step; A transportation reservation method comprising:

10. A computer connected to each reservation system, each of which stores management information necessary for reservations for a plurality of routes operated by a plurality of operators, a management information storage means for storing management information stored in the reservation system; A reservation acceptance means for accepting reservations for the route; when a reservation for a route is accepted by the reservation accepting means, the reservation accepting means functions as a reservation means for executing a reservation for the route based on the management information stored in the management information storage means; The management information includes seat information necessary for reserving seats on the means of transportation; A seat reservation acceptance means for accepting seat reservations; when a seat reservation is accepted by the seat reservation accepting means, the seat reservation accepting means executes the seat reservation based on the seat information stored in the management information storage means; The route includes a joint operation route in which a plurality of operators, including a first operator and a second operator, jointly operate a transportation means; a specific information storage means for storing information indicating a seat of a transportation means operated on the jointly operated route in association with specific information indicating that the seat is managed by a specific operator; a seat reservation control means for allowing the specific operator to make a reservation for the seat associated with the specific information and restricting the reservation by the seat reservation means. A transportation reservation program comprising:

Images