JP2023131019A - Operation management system, method, and program - Google Patents

Abstract

To provide a technique that can achieve both securing benefit for a transportation company and convenience for a user.SOLUTION: An operation management system manages a vehicle that is available in common for a plurality of users paying a charge for using the vehicle in a demand-responsive manner, and the operation management system has: a receiving unit that receives, from each of the users, a request specifying a specified time width during which the user desires to use the vehicle; a state calculation unit that specifies a cluster constituted by overlapping the specified time widths of the plurality of requests, and operates the vehicle for the cluster to calculate benefit estimated from the charge for using the vehicle; and an operation determination unit that, when the benefit is equal to or larger than a predetermined benefit threshold, determines to operate the vehicle for the cluster.SELECTED DRAWING: Figure 3

Description

The present disclosure relates to technology for realizing mobility services that operate on demand.

Mobility-as-a-Service (MaaS) is a service that centrally manages various means of transportation using Information Technology (IT) and realizes planning, reservation, and payment for user movement from origin to destination. It is. MaaS makes it possible to provide a flexible and highly real-time means of transportation by using an information system realized in the cloud or the like from a smartphone. The means of transportation provided by MaaS include not only vehicles used by individuals such as taxis and car sharing, but also public transportation vehicles such as trains and buses that are shared by multiple users.

It is assumed that there will be fewer users of transportation in areas that are far from stations and urban areas, and in rural areas with low population density. In such remote and rural areas, demand-responsive bus services that allow multiple users to ride on a bus that operates on demand are attracting attention (see Patent Document 1).

The following three types of demand-responsive bus services are considered.

(1) Fixed route type: The operating route from the starting point to the ending point of the bus is fixed, and the user specifies his or her boarding point and alighting point on the operating route.

(2) Variable route type: The starting and ending points of the bus are fixed, but the operating route between them can be changed to a certain extent. The user can specify the pick-up and drop-off points within the variable range of the operating route.

(3) Free route type: The bus route, including the starting point and ending point, is flexibly set according to the user's request.

Japanese Patent Application Publication No. 2017-182137

The demand-based operation system of Patent Document 1 is intended to improve convenience for users without increasing the burden on transportation companies that provide public transportation such as buses. However, the demand-based operation system of Patent Document 1 does not take into account the profitability of the transport company, and cannot necessarily be said to be able to secure profits for the transport company.

One objective included in the present disclosure is to provide a technology that enables both securing profits for transportation companies and convenience for users.

An operation management system according to one aspect included in the present disclosure is an operation management system that manages the operation of a vehicle that can be jointly used by a plurality of users in a demand-responsive manner by paying a usage fee. A reception unit that accepts a request specifying a desired specified time width, a cluster in which multiple requests are configured with overlapping specified time widths, and operating the vehicle for the cluster to collect the usage fee according to the usage fee. a state calculation unit that calculates expected revenue; and an operation determination unit that determines to operate the vehicle for the cluster when the revenue is equal to or greater than a predetermined revenue threshold;

has.

According to one aspect included in the present disclosure, it is possible to both secure profits for transportation companies and provide convenience for users.

1 is a block diagram of a traffic management system. FIG. 2 is a block diagram showing the logical configuration of a traffic management server. It is a block diagram showing the hardware configuration of an operation management server. FIG. 2 is a block diagram showing the logical configuration of a user terminal. 3 is a flowchart showing the operation of the traffic management system. FIG. 2 is a diagram showing an example of a screen of a transport operator portal site. FIG. 3 is a diagram showing an application screen of a user terminal. It is a figure which shows the other application screen of a user terminal. It is a figure which shows yet another application screen of a user terminal. It is a time chart showing the status of a request. FIG. 2 is a conceptual diagram for explaining how a mobility service is used.

Embodiments of the present invention will be described below with reference to the drawings.

FIG. 1 is a block diagram of the traffic management system. The operation management system 10 is an information system that realizes a mobility service that provides demand-responsive operation of buses, which are vehicles that can be used jointly by users, by paying usage fees. The mobility service of this embodiment is a fixed route type in which the bus route from the starting point to the final destination is fixed, and the user specifies his/her desired pick-up and drop-off points on the bus route.

The traffic management system 10 includes a user terminal 301, a traffic management server 401, and a transportation company terminal 601.

The user terminal 301 is a terminal device used by each user to utilize mobility services. In this embodiment, the user terminal 301 is a user's own smartphone on which an application dedicated to mobility services is installed. From the user terminal 301, the user can request bus service and check the status of other users' requests, bus service schedules, and the like.

The operation management server 401 is a server device that coordinates this mobility service and determines bus operations in response to requests from users. The traffic management server 401 of this embodiment may be constructed on a cloud. The operation management server 401 determines the operation of buses so as to ensure both the transportation company's profits and the user's convenience. Details of the processing executed by the traffic management server 401 will be described later.

The transportation company terminal 601 is a terminal device used by a transportation company that operates buses in this mobility service. The transport operator performs settings and operations necessary for the mobility service on the transport operator terminal 601 from the portal provided by the operation management server 401. Further, the transportation company receives a request for bus operation from the operation management server 401 on the transportation company terminal 601, and operates the actual bus according to the request.

FIG. 2 is a block diagram showing the logical configuration of the traffic management server.

The operation management server 401 includes a reception section 402, a state calculation section 403, and an operation determination section 404.

The reception unit 402 receives a request from a user via the user terminal 301 to use the bus. In the request, in addition to the pick-up and drop-off locations desired by the user, the pick-up time is specified within a range of times. This time will be referred to as a designated time width. The status calculation unit 403 identifies a cluster in which requests from multiple users overlap in specified time widths, and operates a bus for that cluster, thereby providing a fee to the transportation company based on the usage fee paid by the user. Calculate expected revenue. If the revenue is equal to or greater than a predetermined revenue threshold, the operation determining unit 404 determines that the profitability of the transportation company is secured, and determines to operate a bus for that cluster. This enables demand-responsive mobility services for users to both secure revenue for transport operators and provide convenience for users.

FIG. 3 is a block diagram showing the hardware configuration of the traffic management server. The traffic management server 401 of this embodiment is a server device that can be connected from a personal computer, a smart phone, etc. via a communication network such as the Internet.

The traffic management server 401 has a processor 411, a main memory 412, a storage device 413, a communication device 414, an input device 415, and a display device 416 as hardware, and these are connected to a bus 417.

The storage device 413 is a device that stores data in a writable and readable manner. The storage device 413 stores software programs and data used for processing the software programs. The processor 411 reads the software program stored in the storage device 413 to the main memory 412 and uses the main memory 412 to execute processing of the software program. When the processor 411 executes the software program, the receiving section 402, the state calculating section 403, and the operation determining section 404 shown in FIG. 2 are realized. The communication device 414 transmits information processed by the processor 411 via a communication network including wired and/or wireless communication, and also transmits information received via the communication network to the processor 411. The received information is used for processing by the processor 411. The input device 415 is a device that accepts information inputted by an operator such as a keyboard or a mouse, and the input information is used for processing by the processor 411. The display device 416 is a device that displays image and text information on a display screen in accordance with processing by the processor 411. When the traffic management server 401 is a computer on the cloud, the processor 411, main memory 412, storage device 413, and communication device 414 are on the cloud, and the input device 415 and display device 416 are external and cannot be connected to the computer on the cloud. It may be something that connects.

FIG. 4 is a block diagram showing the logical configuration of the user terminal.

The user terminal 301 has an action section 302 and a guide section 303. The action unit 302 provides the user with a GUI (Graphical User Interface) for inputting each piece of request information and transmitting the request to the operation management server 401. The guide unit 303 provides the user with a GUI that presents a recommendation to change the specified time period if the bus does not operate within the specified time period set in the request because the transportation company's profitability cannot be ensured. .

FIG. 5 is a flowchart showing the operation of the traffic management system.

In step S101, the transport operator accesses the transport operator portal site provided by the operation management server 401 from the transport operator terminal 601 and sets various parameters.

FIG. 6 is a diagram showing an example of a screen of a transportation company portal site.

On the screen 611, a starting point & ending point upload button 612, a time frame & reception end time setting button 613, a profit threshold setting button 614, a discount rate setting button 615, and a schedule reception button 616 are arranged.

The starting point and ending point upload button 612 is a button that moves to a sub-screen where the starting point and ending point of a bus operated by a transportation company are registered. Information on the starting point and ending point set on the sub-screen is stored as parameters in the database (not shown) of the operation management server 401.

The time frame & acceptance end time setting button 613 is a sub-screen for setting the time frame that is the unit of time for aggregating requests from users, and the time at which the acceptance of requests for that time frame will end (reception end time). This is the button to move to. Information on the time frame and reception end time set on the sub-screen is stored as parameters in the database (not shown) of the operation management server 401.

The profit threshold setting button 614 sets a threshold (profit threshold) for determining how much profit is expected to be made by operating the bus when it is decided to operate the bus. This is a button to move to a sub-screen for. Information on the profit threshold set on the sub-screen is stored as a parameter in the database (not shown) of the operation management server 401.

The discount percentage setting button 615 is a sub-screen for setting the percentage of the discount amount to be presented to other users (discount percentage) with respect to the difference between the amount expressed by the user who wishes to use the bus and the basic price. This is a transition button. Information on the discount rate set on the sub-screen is stored as a parameter in the database (not shown) of the operation management server 401.

The operation plan reception button 616 is a button for the transportation company to manually acquire the bus operation plan from the operation management server 401. By pressing this button, the bus operation plan is downloaded from the operation management server 401 to the transportation company terminal 601 and displayed on the screen.

Returning to FIG. 5, in step S301, the user terminal 301 uses the action unit 302 to acquire information input by the user for requesting bus service.

FIG. 7 is a diagram showing an application screen of a user terminal. Screen 101 is a screen for the user to select a desired bus boarding location and alighting location. A plurality of selection buttons 102 are arranged on the screen 101. A selection button 102 is provided for each combination of pick-up and drop-off locations.

FIG. 8 is a diagram showing another application screen of the user terminal. Screen 103 is a screen for selecting a time frame in which the user wishes to use the bus.

A plurality of selection buttons 104 are arranged on the screen 103. A selection button 104 is provided for each time frame. For each time frame, the start time and end time 105 of the time frame, and the reception end time 106 are predetermined.

When the user selects a pick-up point and a drop-off point from screen 101 in FIG. 7 and a time frame from screen 103 in FIG. 8, the application on user terminal 301 displays a screen for generating a request and prompts the user. Prompt for information input.

FIG. 9 is a diagram showing still another application screen of the user terminal. Screen 107 is a screen for the user to input various information regarding the request. Three areas are arranged on the screen 107: a status display area 108, a guide display area 109, and an action display area 110.

The status display area 108 includes the remaining time until the reception end time of the target time frame, and the pick-up and drop-off locations selected by the user. The status display area 108 further includes a time chart showing the status of the request for the time frame. This time chart displays the request status calculated by the operation management server 401 by totaling the requests.

The action display area 110 shows a screen on which the user can input information for sending a request. In the action display area 304, in an initial state, the desired ride time tk, the ride time margin mk, and the proposed payment amount Pk that the user k has selected in a previously transmitted request are displayed.

The desired boarding time tk is the time range in which the user k desires to board the bus, that is, the start time of the designated time range. The boarding time margin mk is the specified time width desired by the user k. The proposed payment amount Pk is the amount that the user k proposes to pay as a bus usage fee. A basic price is set as the minimum necessary amount for bus usage fees. The proposed payment amount Pk can be set within the range of Pk≧P0. If any user presents a proposed payment amount Pk that is higher than the basic price P0, the difference is applied to discount the usage price for other users who use the time frame.

User k can send a request with the same desired boarding time tk, boarding time margin mk, and proposed payment amount Pk that are displayed in the initial state, or can change these values and send the request. You can also do it.

User k selects the pick-up and drop-off locations and time slots on the screens 101 and 103 of the mobile application of the user terminal 301, and enters the desired boarding time, boarding time margin, and proposed payment amount on the screen 107. When the user terminal 301 performs the operation of transmitting a request, the action unit 302 transmits the request to the operation management server 401 in step S302.

When the operation management server 401 receives the request in step S201, it starts batch processing to process the request in step S202.

In step S203, which is a batch processing stage, the operation management server 401 aggregates requests from multiple users, checks whether the specified time widths of the requests overlap, and classifies the parts where the specified time widths overlap into clusters of requests. Specify as.

Furthermore, in step S204, the operation management server 401 calculates potential revenue based on the degree of overlap of the specified time widths of requests in each cluster, and compares the value of the revenue with the revenue threshold. , it is determined whether a predetermined profit of the transport operator in the cluster is secured.

At this time, the operation management server 401 totals the amount of payment offered by each user who sent a request included in each identified cluster. If the proposed payment amount of a user included in a cluster is equal to the basic price P0, the minimum amount required to be paid in order to join the cluster and use the bus remains unchanged at the basic price. On the other hand, if some users in a cluster offer a higher payment amount than the base price, they can join that cluster and buy the bus by using the amount that their payment amount exceeds the base price. The minimum amount you need to pay for access will be lowered. For example, a user included in a cluster where the transportation operator's revenue does not reach a predetermined revenue threshold can invite other users to join that cluster by setting their own payment offer higher. . As described above, the ratio of the discount amount for other users to the additional payment amount for which the proposed payment amount exceeds the basic price is set in advance as a parameter.

FIG. 10 is a time chart showing the status of requests. A time chart 201 shows requests received from each user for a time frame from time T1 to time T2. Requests from each user are shown as rectangles over a specified time range, and clusters of requests are shown as hatched rectangles. Clusters in which a predetermined profit is expected to be secured are indicated by downward hatching to the right, and clusters in which a predetermined profit is expected to be secured are indicated by upward hatching to the right. Here, as an example, a cluster in which there are duplicate requests from three users who have presented the basic price as their proposed payment amount is expected to be profitable.

Returning to FIG. 5, in step S205, the operation management server 401 determines whether the reception end time D for the time frame has been reached. If the reception end time D has not been reached, the operation management server 401 saves the latest cluster state and notifies the user terminal 301 of the state information in step S206. Upon receiving the notification, the user terminal 301 uses the action unit 302 to acquire the latest cluster status and causes the status to be reflected in the status display area 108 on the screen 107 .

The time chart in the status display area 108 is a display equivalent to the display presented to the mobility service provider by the operation management server 401. A time period in which there is a request from a user but profitability for the transportation company is not ensured is shown as a time period hatched upward to the right on the time chart. If a user sets a proposed payment amount that exceeds the basic price in a request for such a time range, the difference between the proposed payment amount and the basic price, that is, the price with a discount according to the additional payment amount (post-discount price) ) will be displayed. This discount serves as an incentive to induce requests from other users for a time period in which a predetermined profitability of the transport company is not secured.

Further, in the user terminal 301, the guide unit 303 displays a guide message indicating a proposal to the user in the guide display area 109 as appropriate.

The message in the guide display area 109 illustrated in FIG. 9 indicates that the request of the user k is not currently in the cluster that satisfies the profitability of the transportation company, but if the boarding time margin is increased by m', the transportation business will It has been announced that you can join the cluster that meets the profitability of your company.

Returning to FIG. 5, in step S303, the action unit 302 of the user terminal 301 periodically checks whether the reception end time has been reached. If the acceptance end time has been reached, in step S304, the user terminal 301 causes the action unit 302 to determine whether the revenue of the transportation company has reached a predetermined revenue threshold in the cluster that includes the user's request. That is, it is determined whether or not it is possible to operate a bus to the cluster.

If the revenue of the transportation company in the cluster that includes the user's request has reached the predetermined revenue threshold, the action unit 302 of the user terminal 301 reserves the bus for the user in step S305. The user is prompted to confirm the reservation, and when the user performs the confirmation operation, the reservation is confirmed.

In step S304, if the transportation business operator's revenue has not reached the predetermined revenue threshold in the cluster that includes the user's request, the action unit 302 causes the transportation business operator's revenue to reach the predetermined revenue threshold for the user. Offer to join clusters that have reached a revenue threshold. If the user accepts the proposal and desires to change to a certain cluster, the action unit 302 sends a changed request to the traffic management server 401 to use a bus operated for that cluster.

When the operation management server 401 receives a changed request from the user terminal 301 after the acceptance end deadline has been reached in step S205, the operation management server 401 additionally registers the user in a desired cluster according to the request in step S207. . At this time, the time width and price of the cluster do not change. The operation management server 401 further requests the transport operator terminal 601 to set bus operation within the time range of the cluster in which the profitability of the transport operator is ensured.

FIG. 11 is a conceptual diagram for explaining how the mobility service is used. A mobility service is provided that operates demand-responsive buses between a remote or rural area 505 and a commercial area 504 near a station as shown in FIG. In this example, it is assumed that there is a time frame from 15:00 to 18:00, and the reception end time for that time frame is 14:30. Also assume a scenario in which multiple users 501, 502, 503 move from the same remote or rural area 505 to the same commercial area 504 near the station. It is assumed that the users 501, 502, and 503 move with some time margin. It is assumed that all three users 501, 502, and 503 can move to the same time frame.

In the example of FIG. 11, the user 501 sends a request in which the desired boarding time is 16:15 and the boarding time margin is 30 minutes. The user 502 sends a request in which the desired boarding time is 16:05 and the boarding time margin is 15 minutes. The user 503 sends a request in which the desired boarding time is 16:15 and the boarding time margin is 10 minutes. It is assumed that all the users 501, 502, and 503 have presented the basic price as the proposed payment amount.

In this example, a cluster including requests from three people is configured in the time range from 16:15 to 16:20. The total amount of payments offered by the three persons shall cause the transportation operator's revenue to exceed a predetermined revenue threshold. Therefore, three users 501, 502, and 503 can travel to commercial area 504 by jointly using one bus. If the service provided by the traffic management system 10 of this embodiment were not provided, the users 501, 502, and 503 might have to pay a fee individually to travel by taxi or shared car.

The embodiments described above are illustrative examples of the present invention, and are not intended to limit the scope of the present invention only to those embodiments. Those skilled in the art can implement the invention in various other ways without departing from the scope of the invention.

The embodiment described above includes the following items. However, the matters included in this embodiment are not limited to only those shown below.

(Item 1)
A traffic management system that manages the operation of a vehicle that can be jointly used by multiple users by paying a usage fee in a demand-responsive manner has a reception unit that accepts requests from users specifying a specified time range in which they wish to use the ride, and a multiple a state calculation unit that identifies clusters in which the requests are configured with overlapping specified time widths, and calculates the revenue expected from the usage fee by operating the vehicle for the cluster; and an operation determining unit that determines to operate the vehicle for the cluster when the revenue is equal to or greater than a revenue threshold.
According to this, in providing a demand-responsive means of transportation to users, it is possible to both secure profits for transportation companies and provide convenience for users.

(Matter 2)
The operation management system according to item 1 changes a request to a user included in a cluster whose revenue does not reach the revenue threshold so that the user is included in a cluster whose revenue is equal to or higher than the revenue threshold. The operation determining unit further includes a guide unit that presents a recommendation proposing that the cluster is selected, and when the user accepts the recommendation and changes the specified time range and the revenue exceeds the revenue threshold, the operation determining unit A decision is made to operate the vehicle.
According to this, even if the transport operator's profitability is not secured according to the user's initial request, the user is suggested to change the specified time range in a way that will ensure profitability, so that the transport operator's profits can be secured. User convenience can be further improved.

(Item 3)
In the operation management system described in Item 2, a basic price is set in advance as the minimum necessary amount of the usage fee, and the reception unit is configured to accept an amount equal to or higher than the basic price in the request. The state calculating unit calculates the revenue in the cluster based on the proposed payment amount in the request included in the cluster, and the operation determining unit determines that the revenue is within the revenue threshold A user who intends to use the vehicle is presented with a discount from the basic price for the usage fee of a cluster in which there is a user who has submitted a payment offer amount higher than the basic price.
According to this, if the user's original request is unlikely to ensure the profitability of the transport operator, by giving the user the means to solicit other users by paying an additional fee, the transport operator can It is possible to secure profits and improve user convenience.

(Item 4)
In the traffic management system according to Item 1, the reception unit allows the user to specify a desired boarding time, which is a time at which the user wishes to board the board, and a boarding time margin, which is a time range in which a change in the desired boarding time is allowed. accepts the designation of the designated time width.
According to this, the user can intuitively specify the specified time range by specifying the desired time and the time that can be changed.

10...Operation management system, 101...Screen, 102...Selection button, 103...Screen, 104...Selection button, 105...End time, 106...Reception end time, 107...Screen, 108...Status display area, 109...Guide display area , 110... action display area, 301... user terminal, 302... action section, 303... guide section, 304... action display area, 401... operation management server, 402... reception section, 403... state calculation section, 404... operation determination section , 411... Processor, 412... Main memory, 413... Storage device, 414... Communication device, 415... Input device, 416... Display device, 417... Bus, 501... User, 502... User, 503... User, 504... Commercial area , 505...Remote area or rural area, 601...Transport operator terminal, 611...Screen, 612...Start point & destination point upload button, 613...Time frame & acceptance end time setting button, 614...Value setting button, 615...Ratio Setting button, 616...Operation plan reception button

Claims (10)

An operation management system that manages the operation of a vehicle that multiple users can jointly use in a demand-responsive manner by paying a usage fee,
a reception department that accepts requests from users specifying a specified time range in which they wish to use a vehicle;
a state calculation unit that identifies a cluster in which a plurality of requests are configured with overlapping specified time widths, and calculates expected revenue from the usage fee by operating the vehicle for the cluster;
an operation determining unit that determines to operate the vehicle for the cluster when the revenue is equal to or greater than a predetermined revenue threshold;
A traffic management system with a guide unit that presents a recommendation to a user included in a cluster where the revenue does not reach the revenue threshold, suggesting that the user change the request so that the user is included in a cluster where the revenue is equal to or greater than the revenue threshold; It further has
The operation determining unit determines to operate the vehicle for the cluster when the user accepts the recommendation, changes the specified time range, and the revenue becomes equal to or higher than the revenue threshold.
The traffic management system according to claim 1. A basic price is set in advance as the minimum necessary amount of the usage fee,
The reception unit accepts a proposed payment amount equal to or higher than the base price in the request;
The state calculation unit calculates the revenue in the cluster based on the payment amount proposed in the request included in the cluster,
The operation determining unit may reduce the usage fee from the base price of a cluster in which there is a user whose revenue has not reached the revenue threshold and who has submitted a payment offer amount higher than the base price. Presented to users who intend to use the vehicle,
The traffic management system according to claim 2. The reception unit accepts the designation of the specified time range by having the user specify a desired boarding time, which is the time when the user wishes to board the board, and a boarding time margin, which is a time range that allows for a change in the desired boarding time. ,
The traffic management system according to claim 1. An operation management method for managing the operation of a vehicle that can be jointly used by multiple users in a demand-responsive manner by paying a usage fee, the method comprising:
Accepts requests from users specifying the specified time range in which they wish to use the vehicle,
Identifying a cluster in which multiple requests overlap in specified time widths, calculating expected revenue from the usage fee by operating the vehicle for the cluster,
determining to operate the vehicle to the cluster if the revenue is greater than or equal to a predetermined revenue threshold;
An operation management method in which a computer performs the operations. presenting a recommendation to a user included in a cluster where the revenue does not reach the revenue threshold, suggesting that the user change the request so that the user is included in a cluster where the revenue is equal to or greater than the revenue threshold;
If the user accepts the recommendation and changes the specified time range and the revenue becomes equal to or greater than the revenue threshold, determining to operate the vehicle for the cluster;
A computer performs
The operation management method according to claim 5. A basic price is set in advance as the minimum necessary amount of the usage fee,
accepting a proposed payment amount equal to or higher than the base price in the request;
Calculating the revenue in the cluster based on the payment amount offered in the request included in the cluster,
In order to reduce the usage fee from the base price of a cluster in which there is a user whose revenue has not reached the revenue threshold and who has submitted a payment offer higher than the base price, the user attempts to use the vehicle. to present to the user,
A computer performs
The operation management method according to claim 6. An operation management program for managing the operation of a vehicle that can be jointly used by multiple users in a demand-responsive manner by paying a usage fee,
Accepts requests from users specifying the specified time range in which they wish to use the vehicle,
Identifying a cluster in which multiple requests overlap in specified time widths, calculating expected revenue from the usage fee by operating the vehicle for the cluster,
determining to operate the vehicle to the cluster if the revenue is greater than or equal to a predetermined revenue threshold;
An operation management program that makes a computer perform certain tasks. presenting a recommendation to a user included in a cluster where the revenue does not reach the revenue threshold, suggesting that the user change the request so that the user is included in a cluster where the revenue is equal to or greater than the revenue threshold;
If the user accepts the recommendation and changes the specified time range and the revenue becomes equal to or greater than the revenue threshold, determining to operate the vehicle for the cluster;
make a computer do something
The operation management program according to claim 8. A basic price is set in advance as the minimum necessary amount of the usage fee,
accepting a proposed payment amount equal to or higher than the base price in the request;
Calculating the revenue in the cluster based on the payment amount offered in the request included in the cluster,
In order to reduce the usage fee from the base price of a cluster in which there is a user whose revenue has not reached the revenue threshold and who has submitted a payment offer higher than the base price, the user attempts to use the vehicle. to present to the user,
make a computer do something
The operation management program according to claim 9.

Images