JP7414470B2 - Server equipment, programs, user terminal equipment, and systems - Google Patents

Description

The present invention relates to a server device, a program, a user terminal device, and a system.

It is desirable for organizations such as companies to efficiently collect and aggregate information on taxi fares used for business purposes. For example, when paper taxi tickets are used, it takes a lot of effort (manpower) to manage the distribution of the taxi tickets and to convert and total the taxi fare amount written on the paper into data. Therefore, it is conceivable to make these data processing more efficient by using information equipment and communication.

For example, in paragraph 0002 (background technology column) of Patent Document 1, it is stated that "taxi ticket information such as taxi ticket identification information is transmitted from a management system that manages taxi tickets to a portable device such as a mobile phone or an IC card. A taxi ticket processing method in which a taxi device installed in a taxi reads out taxi ticket information stored in a portable device carried by a taxi user and settles the taxi usage fee, and a taxi ticket payment method. System” is described.

Further, in the column of embodiments of Patent Document 1, a taxi ticket processing system is described.

Specifically, in paragraph 0030, the ticket generation system receives ticket application information from the ticket application server and accepts a taxi ticket generation request (S210), and the taxi company selection unit stores the ticket application information in the taxi company information DB. The mobile phone selects a taxi company based on the taxi company information and ticket application information (S230), receives this e-mail (S310), and connects to the URL included in the e-mail (S310). S320), transmitting authentication information, and requesting download of a taxi ticket application (S330) are described.

Paragraph 0031 also states that a user who has downloaded a taxi ticket application onto a mobile phone must launch the application and display ticket data and taxi company information on the display; The user selects one of the taxi companies offered by the taxi company, the mobile phone calls the number, and the user requests a ride. Near field communication (infrared etc.) and transmitting the ticket data to the taxi device (S410), and the taxi device receives this ticket data (S510) and determines whether it can be used (S520). ing. In other words, if the taxi device can confirm the validity of the ticket data based on the electronic signature and confirm that the current location, time, etc. satisfy the restrictions on usage restriction information, the ticket data can be used. It is stated that it is determined that there is.

Paragraph 0025 also states that a taxi device is a device installed in a taxi that calculates and settles taxi charges, and includes a mobile phone, a data management server of a taxi company, a ticket payment server of a payment agency, etc. The taxi equipment installed in each taxi has a data management server, a communication device that controls communication with the ticket payment server, and a short-range wireless communication device that controls short-range wireless communication with mobile phones. It is stated that it is equipped with communication equipment, etc.

Paragraph 0027 also states that the data management server is a server that can communicate with taxi devices, ticket payment servers, etc. via a communication line, and manages data processing at the taxi company; The management server receives the usage record information from the taxi device, stores and manages it for each taxi ID, and the data management server stores the usage fee for which the payment process was performed based on the ticket data in the stored usage record information. It states that the tickets are to be aggregated periodically, the aggregated results are sent to the payment agency's ticket settlement server, and payment of this fee is requested.

Japanese Patent Application Publication No. 2007-018304

However, various problems remain with the technique described in Patent Document 1.

For example, in a method in which the taxi device installed in the taxi reads out the taxi ticket information stored in the portable device carried by the taxi user and settles the taxi fare, Communication with the taxi device is required, and the cost of the device itself and the cost of increasing the scale of the software become excessive.

In addition, the method in which the taxi company selection unit 33 (on the server side) selects a taxi company based on the taxi company information and ticket application information stored in the taxi company information DB 36 is difficult for the user to select a taxi company. This is inconvenient in that the degree of freedom is reduced, and the burden of processing such as selecting a taxi company is placed on the server side before boarding the taxi.

Furthermore, the method in which the mobile phone 40 requests the download of a taxi ticket application based on the received e-mail is inconvenient for the user because it requires the user to download (and install) the application more than necessary. be.

Further, the process of exchanging ticket data between the mobile phone 40 and the taxi device 50 through communication such as short-range wireless communication (infrared rays, etc.) is a complicated procedure, and it is desirable to avoid this process if possible.

Further, in the system described in Patent Document 1, it is difficult to incorporate an approval process regarding taxi use on the side of an organization such as a company.

The present invention was made based on the above-mentioned recognition of the problem, and does not require any additional communication means on the taxi side (transportation vehicle side), and uses a low-cost device to provide a simple method. The present invention aims to provide a server device, a program, a user terminal device, and a system that can realize cashless payment of fares for taxis, etc.

[1] In order to solve the above problems, a server device according to one aspect of the present invention transmits transport operator identification information for identifying a transport operator that provides a transport service and the amount of transport charges from a user's terminal device. a user function unit that receives usage record data including information on the transportation service; a data storage unit that stores the received usage record data; a decision maker function unit that executes a process of approving at least one of the previous or subsequent data, and adds information indicating that the data has been approved to the approved usage record data; and a terminal device of the transportation business operator. , and a transportation company functional department that provides the usage record data sorted by transportation company.

[2] Further, in one aspect of the present invention, in the above-mentioned server device, the transport operator identification information may be optically attached to a transport means owned by the transport operator and used for the transport service. The code information is obtained by the user's terminal device reading code information provided in a visually readable format.

[3] Further, in one aspect of the present invention, in the above server device, the user's terminal device reads the code information at the time of starting the transportation service, and the user function unit reads the code information. The transport operator identification information based on code information is received from the user's terminal device as part of a service start record.

[4] Further, in one aspect of the present invention, in the above server device, the user's terminal device determines the transportation fee amount for the transportation service at the end of the transportation service. The user function unit receives information on the amount of the transportation fee from the user's terminal device as part of the service termination record.

[5] Moreover, one aspect of the present invention is that in the above server device, the user's terminal device acquires information on the amount of the transportation fee by manual input by the user.

[6] Further, in one aspect of the present invention, in the above-mentioned server device, the transport company functional unit, when providing the usage record data for the transport company to a terminal device of the transport company, , in the unit of implementation of the transportation service, also transmitting information indicating whether or not the usage record data has been confirmed by the transportation business operator, and instructing from the terminal device of the transportation business operator that it has been confirmed; Regarding the usage record data that has been confirmed, information indicating that it has been confirmed is added.

[7] Further, in one aspect of the present invention, in the above-mentioned server device, the transport company functional unit, when providing the usage record data for the transport company to a terminal device of the transport company, , information indicating whether or not the transportation business operator has already billed for the usage record data in units of implementation of the transportation service, and has been billed from the terminal device of the transportation business operator; For the usage record data for which the instruction is given, information indicating that the fee has been charged is added.

[8] Further, in one aspect of the present invention, the above server device further includes a usage record confirmation unit that checks the content of the usage record data, and the user function unit is configured to confirm the content of the usage record data at the time of starting the transportation service. , receives from the terminal device of the user information on the time at which the transport service starts and information on the position at the start of the transport service, and when the transport service ends, the time at the end of the transport service; and information on the position at the end of the transportation service from the terminal device of the user, and the data storage unit receives information on the time at the start of the transportation service as part of the usage record data. , information on the position at the time the transportation service starts, information on the time at the end of the transportation service, and information on the location at the time the transportation service ends, and the usage record confirmation unit stores the information on the location at the time the transportation service ends. By referring to the attendance data representing the user's attendance status, the attendance data, information on the start time of the transportation service, information on the position at the start of the transportation service, and information on the end time of the transportation service are obtained. It is determined whether or not the time information and the position information at the end of the transportation service match predetermined alert conditions, and if the alert conditions are met, the usage history is It is something that generates alerts about data.

[9] In addition, one aspect of the present invention provides usage record data that includes transport operator identification information for identifying the transport operator that provides the transport service and information on the amount of the transport fee, from the user's terminal device. a data storage unit that accumulates the received usage record data; and a data storage unit that stores the received usage record data; and approves the use of the transportation service by the user at least either before or after the transportation service is implemented. a decision maker function unit that executes the processing to indicate that the usage record data has been approved and adds information indicating that it has been approved to the usage record data that has been approved; This is a program that allows a computer to function as a server device that includes a transport company functional department that provides usage record data.

[10] Further, one aspect of the present invention provides a method for identifying a transportation business operator that provides a transportation service by reading code information provided in an optically readable form on a transportation means used for the transportation service. obtains the transportation business operator identification information , acquires information on the transportation fee amount, and transmits usage record data including the transportation company identification information and the transportation fee amount information to the server device. This is a user terminal device.

[11] Further, in one aspect of the present invention, in the above user terminal device, the user terminal device includes the transportation operator identification information by reading the code information at the time of starting the transportation service. After transmitting the usage record data to the server device and determining the amount of the transportation fee, information on the amount of the transportation fee is obtained manually by the user, and the usage includes information on the amount of the transportation fee. transmitting the performance data to the server device, displaying a confirmation screen including information on the amount of the transportation fee, and finalizing the usage performance data when a "Register" button included in the confirmation screen is operated; A confirmation notification, which is a notification of the above, is sent to the server device.

[12] Further, in one aspect of the present invention, in the above user terminal device, application data for using the transportation service is transmitted to the server device, and after transmitting the confirmation notification to the server device, , the ticket number assigned by the server device is displayed on the screen in association with the application data.

[13] Further, one aspect of the present invention is to obtain usage record data including transport operator identification information for identifying the transport operator that provides the transport service and information on the amount of the transport fee, from the user's terminal device. a data storage unit that accumulates the received usage record data; and a data storage unit that stores the received usage record data; and approves the use of the transportation service by the user at least either before or after the transportation service is implemented. a decision maker function unit that executes the processing to indicate that the usage record data has been approved and adds information indicating that it has been approved to the usage record data that has been approved; a server device comprising: a transportation company functional department that provides usage record data; acquiring user identification information, acquiring information on the amount of the transportation fee, and transmitting usage record data including the transportation company identification information and the information on the amount of the transportation fee to a server device; This system includes a user terminal device.

According to the present invention, it is possible to realize payment of fares for taxis, etc., by a simple means, without requiring an additional communication means on the transportation vehicle side, and by using a low-cost device.

1 is a block diagram showing a configuration example of a taxi usage support system according to a first embodiment of the present invention. FIG. FIG. 2 is a block diagram showing in more detail the configuration of the taxi usage support system (including the schematic configuration of the communication network) according to the same embodiment. FIG. 2 is a block diagram showing a schematic functional configuration within the server device according to the same embodiment. FIG. 2 is a sequence diagram showing a typical processing procedure (prior approval by a decision maker and taxi usage) of the taxi usage support system according to the embodiment. FIG. 3 is a sequence diagram showing a typical processing procedure (post-approval by a decision maker) of the taxi usage support system according to the embodiment. FIG. 2 is a schematic diagram showing an example of code information (two-dimensional code) for specifying a taxi company, etc. (operator) to be used in the same embodiment. FIG. 2 is a schematic diagram showing an example of a screen displayed on a user mobile terminal device when the taxi usage support system according to the embodiment is in operation (before getting into a taxi). FIG. 2 is a schematic diagram showing an example of a screen displayed on the user mobile terminal device when the taxi usage support system according to the embodiment is in operation (immediately after boarding confirmation is completed). FIG. 2 is a schematic diagram showing an example of a screen displayed on a user mobile terminal device when the taxi usage support system according to the embodiment is in operation (entering amount, etc. when getting off the taxi); FIG. It is a schematic diagram showing an example of a screen displayed on a user mobile terminal device when the taxi usage support system according to the embodiment is in operation (when confirming getting off the taxi). It is a schematic diagram showing an example of a screen displayed on a user mobile terminal device when the taxi usage support system according to the embodiment is in operation (at the time of completion of registration in the latter case). FIG. 2 is a schematic diagram illustrating data generated at each stage of getting into a taxi, stopping at a stopover, and getting off the taxi, and the flow thereof, in the same embodiment. FIG. 2 is a schematic diagram illustrating the configuration of a table that is part of the data managed by the server device according to the embodiment and holds information for identifying taxi companies and automobiles. FIG. 2 is a schematic diagram illustrating the configuration of a table that is part of the data managed by the server device according to the embodiment and holds information about users of the system. It is a part of the data managed by the server device according to the same embodiment, and is a schematic diagram showing the structure of a table for accumulating individual taxi usage status. FIG. 2 is a block diagram showing a schematic functional configuration within a first user function section according to the same embodiment. FIG. 3 is a block diagram showing a schematic functional configuration within a second user function unit according to the same embodiment. FIG. 2 is a block diagram illustrating a schematic functional configuration of a decider function unit according to the same embodiment. FIG. 2 is a block diagram showing a schematic functional configuration within a taxi company functional unit according to the same embodiment. FIG. 2 is a block diagram showing a schematic functional configuration within an administrator function unit according to the same embodiment. FIG. 3 is a block diagram showing a schematic functional configuration of a first user functional unit in a taxi usage support system according to a second embodiment.

[First embodiment]
Next, one embodiment of the present invention will be described with reference to the drawings. The taxi usage support system 1 according to the present embodiment uses, for example, a mobile terminal device, when a user belonging to an organization (such as a company) uses a taxi, to collect at least information identifying the taxi company and information such as the taxi fare. This is to record amount information. Such records are called taxi usage records. The user may obtain approval from a decision maker (for example, the user's superior) before using the taxi or after using the taxi. The taxi usage record is accumulated in a database on the server device 10 side. The data stored in the database can be accessed by users, decision-makers, administrators of the taxi usage support system 1 (including accounting personnel), and taxi company personnel, depending on their respective access privileges. You can view or check it. Since information identifying the taxi company is included in the usage record, the server device 10 can compile fees and the like for each taxi company. In addition, the taxi company representative can process the billing process based on the usage history data for the taxi company. By using the taxi usage support system 1, usage records can be accumulated and aggregated without using paper taxi tickets (paper tickets) in principle, and the effort of paper handling etc. can be reduced. be able to. Further, if the taxi usage support system 1 includes a function regarding the approval process, it becomes possible to consistently execute the approval process, the taxi usage process, and the subsequent payment process. Furthermore, by importing data on the user's work status, the taxi usage support system 1 can automatically check the relationship between the work status and the taxi usage record.

In this embodiment, paid transportation services such as taxis, hire cars, shared taxis, buses, and car services are typically referred to as "taxi." When this embodiment is applied to transportation means other than taxis, "taxi" may be read as appropriate. Furthermore, in this embodiment, a "taxi company" is a business operator (a company, an individual, etc.) that provides transportation services such as the above-mentioned taxis. In other words, a "taxi company" does not necessarily have to be a company. Further, the "organization" that operates the taxi usage support system 1 of this embodiment is a corporation such as a company, a public institution, or various business entities. Furthermore, in this embodiment, the taxi usage support system 1 provides information processing functions for users, decision makers, and managers in the above-mentioned "organization." Here, the "user" is a person who uses a taxi for business purposes or the like. The "decision maker" is a person (usually the user's organizational superior) who has the authority to approve the use of a taxi by the user. Further, the "administrator" is a person who manages the operation of the taxi usage support system 1. The administrator is typically a person in charge of general affairs or human resources at a company or the like. Further, in this embodiment, the administrator may include an accounting person at a company or the like.

FIG. 1 is a block diagram showing a configuration example of a taxi usage support system according to this embodiment. As illustrated, the taxi usage support system 1 includes a server device 10, an internal terminal device 20, a user mobile terminal device 30, and a taxi company terminal device 40. The server device 10 can communicate with an in-house terminal device 20, a user mobile terminal device 30, and a taxi company terminal device 40 via a communication network. Note that this figure does not show the physical configuration of the communication network in the system. Also, here, one server device 10, one in-house terminal device 20, one user mobile terminal device 30, and one taxi company terminal device 40 are shown, but the number of these devices is Optional.

The server device 10 is a device for storing data necessary for this system and processing the data. The server device is realized using, for example, a server type computer. Further, the server device 10 may be physically realized using a plurality of server type computers.

The intra-organizational terminal device 20 is a terminal device used within the organization. The internal terminal device 20 functions as a client for the server device 10 described above. The intra-organizational terminal device 20 is realized using, for example, a PC (personal computer), a tablet terminal, a smartphone, or the like. The internal terminal device 20 can run a web browser and various applications (application programs). The internal terminal device 20 is used by users, decision makers, and administrators.

The user mobile terminal device 30 is a terminal device that a user of this system (a person riding in a taxi) can use while moving. The user mobile terminal device 30 is also simply referred to as a "user terminal device." The user mobile terminal device 30 functions as a client for the server device 10 described above. The user mobile terminal device 30 may have a function of authenticating users. Specifically, the authentication function of the user mobile terminal device 30 authenticates the user by using a password, passcode, fingerprint, face, voiceprint, etc. of the user. By performing such personal authentication, it is guaranteed that the user mobile terminal device 30 is being operated by the intended user. Furthermore, the user mobile terminal device may perform authentication using a user code issued by the server device 10. The user code is code information issued by the user code issuing function unit 1220 or the like on the server device 10 side, as described later. The user mobile terminal device 30 internally stores the user code issued by the server device 10 side. When the user mobile terminal device 30 accesses the server device 10, the user mobile terminal device 30 reads out the user code stored inside and transmits it to the server device 10. The server device 10 verifies the validity of the user code received from the user mobile terminal device 30 (such as whether it is a legitimately issued user code), and verifies the validity of the user code received from the user mobile terminal device 30. Accept only valid accesses. For example, if the user mobile terminal device 30 transmits a user code that has already been deleted on the server device 10 side or a user code that has not been legitimately issued, the server device 10 will refuse access. do. Furthermore, even when a user code is updated (reissued) for a certain user, the server device 10 rejects access using the past (pre-update) user code. In this way, by using the user code, the validity of the access from the user mobile terminal device 30 to the server device 10 is verified. Note that the user mobile terminal device 30 is realized using, for example, a smartphone, a wearable terminal device, a tablet terminal, a PC, or the like. The user mobile terminal device 30 can run a web browser and various applications.

The taxi company terminal device 40 is a terminal device used on the taxi company side. The taxi company terminal device 40 functions as a client for the server device 10 described above. The taxi company terminal device 40 is realized using, for example, a PC, a tablet terminal, or the like. The taxi company terminal device 40 can run a web browser and various applications.

Note that the functions executed on the in-house terminal device 20, the user mobile terminal device 30, and the taxi company terminal device 40 may be applications that run on a web browser, or may be run without using a web browser. It may be an application in the form of

FIG. 2 is a block diagram showing the configuration of the taxi usage support system 1 shown in FIG. 1 in more detail. FIG. 2 also shows a schematic configuration of the communication network. In the configuration shown here, the taxi usage support system 1 is realized using a device group connected to an external network 61 and a device group connected to an intra-organizational network 62. As illustrated, the taxi usage support system 1 includes a server device 10, an internal terminal device 20, a user mobile terminal device 30, a taxi company terminal device 40, a relay device 50, and an external network 61. , and an intra-organizational network 62.

As illustrated, in this embodiment, the server device 10 includes a cloud server device 11 and an in-house server device 12. In other words, the cloud server device 11 and the in-house server device 12 share functions. The cloud server device 11 and the in-house server device 12 are each connected to different communication networks. The cloud server device 11 is connected to an external network 61. Further, the intra-organizational server device 12 is connected to an intra-organizational network 62. Here, the external network 61 is an open network provided outside the organization. For example, the Internet can be used as the external network 61. Further, the intra-organizational network 62 is a network closed within the organization.

The cloud server device 11 can communicate with the user mobile terminal device 30 and the taxi company terminal device 40 via the external network 61.
Further, the intra-organizational server device 12 can communicate with the intra-organizational terminal device 20 via the intra-organizational network 62. Further, the relay device 50 performs relay between the external network 61 and the intra-organizational network 62. The cloud server device 11 and the in-house server device 12 can communicate with each other via the relay device 50. Thereby, data updates can be synchronized between the data held by the cloud server device 11 and the in-house server device 12, respectively.

Note that the user mobile terminal device 30 has a GPS (global positioning system) function. By receiving the GPS signal from the GPS satellite 71, the user mobile terminal device 30 can obtain information about its own location, for example, in the form of latitude and longitude.

FIG. 3 is a block diagram showing a schematic functional configuration within the server device 10. As shown in FIG. As already mentioned, the server device 10 can be realized using the cloud server device 11 and the in-house server device 12. Note that the in-house server device 12 itself may be implemented in a so-called cloud configuration. As illustrated, the cloud server device 11 includes a first data storage section 110, a first user function section 111, and a taxi company function section 112. In addition, the in-house server device 12 includes a second data storage section 120, a second user function section 121, a decider function section 122, an administrator function section 123, and a usage record confirmation section 124. be done. Each of these functional units can be realized by, for example, a computer and a program. Furthermore, each functional section has a storage means, if necessary. The storage means is, for example, variables on the program or memory allocated by executing the program. Furthermore, if necessary, non-volatile storage means such as a magnetic hard disk device or a solid state drive (SSD) may be used. Furthermore, at least some of the functions of each functional unit may be realized as a dedicated electronic circuit instead of a program. The functions of each part are outlined below.

The first data storage unit 110 stores data used by the cloud server device 11. Data in the first data storage unit 110 can be read and written from within the cloud server device 11. Details of the data stored in the first data storage unit 110 will be explained later with reference to other drawings.

The first user function unit 111 provides necessary data to the user mobile terminal device 30 and acquires data from the user mobile terminal device 30 side.

The taxi company function unit 112 provides necessary data to the taxi company terminal device 40 and acquires data from the taxi company terminal device 40 side.

The second data storage unit 120 stores data used by the in-house server device 12. The data in the second data storage unit 120 can be read and written from within the in-house server device 12 . Details of the data stored in the second data storage unit 120 will be explained later with reference to other drawings.

Note that some data contents may overlap between the first data storage section 110 and the second data storage section 120. As mentioned above, the cloud server device 11 and the in-house server device 12 can communicate with each other, and data is periodically synchronized between the first data storage unit 110 and the second data storage unit 120. . For example, so-called master data is mainly maintained and updated on the in-house server device 12 side, but necessary data is also passed to the cloud server device 11 side. Furthermore, data representing transaction results (taxi usage results) is first acquired primarily on the cloud server device 11 side, and is also passed to the in-house server device 12 side in a timely manner.

The second user function unit 121 presents data to the user and obtains data from the user via the internal terminal device 20. Further, the second user function section 121 writes data to the second data storage section 120 as appropriate.

The decision maker function unit 122 presents data to the decision maker and acquires data from the decision maker via the internal terminal device 20 . Further, the decider function unit 122 writes data to the second data storage unit 120 as appropriate.

The administrator function unit 123 presents data to the administrator and obtains data from the administrator via the internal terminal device 20. The administrator function unit 123 also writes data to the second data storage unit 120 as appropriate.

The usage record confirmation unit 124 confirms the contents of the taxi usage record data stored in the second data storage unit 120. Specifically, the usage record confirmation unit 124 generates an alert (turns on an alert flag) regarding data that matches a predetermined alert condition among data on individual taxi usage records. Note that the usage record confirmation unit 124 may import and refer to the attendance data of users (employees of the organization) from an external source (for example, an attendance management system) in order to confirm usage records. The attendance data includes information on the user's work status (starting time, clocking out time, holidays, vacation, etc.) for each day. Specific alert conditions will be described later.

More specific functions provided by the cloud server device 11 and the in-house server device 12 will be further explained later.

FIG. 4 is a sequence diagram showing a typical processing procedure (prior approval by a decision maker and taxi usage) of the taxi usage support system 1. The operation of the taxi usage support system 1 when a user uses a taxi will be described below with reference to this sequence diagram.

The procedures from steps S1 to S4 are for a user to apply for use in advance and a decision maker to approve the application. This pre-approval is not mandatory for taxi use. Post-approval may be performed by a decision maker as described below.

In step S1, the in-house terminal device 20 for the user transmits usage application data to the in-house server device 12 based on the user's operation. Information regarding this usage application is stored within the server device 10.

In step S2, based on the decision-maker's operation, the in-house server device 12 transmits the data of the utilization application list to the in-organization terminal device 20 for the decision-maker. The intra-organizational terminal device 20 for decision makers displays the information of the usage application list on the screen.

In step S3, based on the operation of the decider who has viewed the usage application information, the in-house terminal device 20 for the decider sends usage application approval data to the in-house server device 12. In response to this, the in-house server device 12 updates the status of the application to "approved."

In step S4, based on the user's operation, the in-house server device 12 transmits the data of the utilization application list to the in-house terminal device 20 for the user of the application. The in-house terminal device 20 for users displays the information of the application list on the screen. This allows the user to know whether or not the application he/she filed has been approved. Note that the user may be able to refer to the information in the usage application list using the user mobile terminal device 30.

The procedures from steps S5 to S7 are the processes of the taxi usage support system 1 from when the user actually gets into the taxi until when the user gets off the taxi. Note that the procedures from steps S5 to S7 can be executed regardless of whether or not a usage application has been made in advance, and regardless of whether or not the usage application has been approved in advance.

In step S5, the user mobile terminal device 30 transmits ride registration data to the cloud server device 11 via the Internet or the like. The process of this step is performed by the user operating the user mobile terminal device 30 when the user gets in the taxi. The ride registration data sent at this time includes a user code to identify the user, code information to identify the taxi company (and in some cases, the taxi car number), and boarding position information ( latitude and longitude) and date and time. Note that the user code is held in advance by the user mobile terminal device 30. Code information for identifying the taxi company (and, in some cases, the taxi number) is obtained by the user mobile terminal device 30 optically reading two-dimensional code information provided in the taxi. . Information on the riding position is acquired based on the GPS signal that the user mobile terminal device 30 receives from the GPS satellite 71.

In step S6, the user mobile terminal device 30 transmits the data for registering the waypoint to the cloud server device 11 via the Internet or the like. The process of this step is performed by the user operating the user mobile terminal device 30 when the taxi stops at a stopover point. The boarding registration data sent at this time includes a user code to identify the user, code information to identify the taxi company (and in some cases, the taxi number), and information about the transit point ( latitude and longitude).

In step S7, the user mobile terminal device 30 transmits the alighting registration data to the cloud server device 11 via the Internet or the like. The process of this step is performed by operating the user mobile terminal device 30 when the user gets off the vehicle. The boarding registration data sent at this time includes a user code to identify the user, code information to identify the taxi company (and in some cases, the taxi number), and information about the alighting location ( latitude and longitude), fees (for example, taxi meter fees and toll road fees other than meters), and date and time.

FIG. 5 is a sequence diagram showing the processing procedure (post-approval by the decision maker) in the taxi usage support system 1. The procedure from step S8 to S11 is the process of the taxi usage support system 1 when the decision maker approves the taxi after the user uses the taxi. Note that if approval has been given in advance by the decision maker, this post-approval is not essential.

In step S8, based on the user's operation, the in-house server device 12 transmits the usage history list data to the in-house terminal device 20 for that user. The in-house terminal device 20 for users displays the information of the usage record list on the screen. This allows the user to check information on usage history. Furthermore, if there is a usage record that requires complementary input, the user can perform complementary input from the in-house terminal device 20 for users.

In step S9, based on the user's operation, the intra-organizational terminal device 20 for the user transmits complementary data to the intra-organizational server device 12. This complementary data includes data inputted by the user.

In step S10, based on the decision-making person's operation, the in-house server device 12 transmits the usage history list data to the in-house terminal device 20 for that decision-making person. The intra-organizational terminal device 20 for decision makers displays the information of the usage record list on the screen. Thereby, the decision maker can approve the usage record information.

In step S11, based on the decision-maker's operation, the intra-organizational terminal device 20 for the decision-maker transmits usage record approval data to the intra-organizational server device 12. In response to this, the in-house server device 12 updates the status of its usage record to "approved."

FIG. 6 is a schematic diagram showing an example of code information for specifying the company (operator) of the taxi used, its branch, etc. This code information is printed on a medium such as paper, and is optically readable by the user mobile terminal device 30. In the illustrated example, the code information is a two-dimensional code. An example of a two-dimensional code is a QR code (registered trademark). However, the code information may be expressed by a method other than a two-dimensional code (for example, a bar code, characters, etc.). Also, the code information may be expressed by a method other than a two-dimensional code (for example, a bar code, characters, etc.). The terminal device 30 may be configured to be able to read code information using a wireless signal (radio wave).This code information is, for example, provided or placed inside a taxi.

This code information includes at least information that uniquely identifies a taxi company (operator). Further, the code information may further include information identifying a branch office, branch office, department, etc. of the taxi company. Furthermore, the code information may include information (vehicle number) for identifying individual taxi vehicles. That is, a two-dimensional code is generated based on information that identifies a taxi company and information that identifies a vehicle. When a user uses a taxi, by reading this code information using the user mobile terminal device 30, the user mobile terminal device 30 acquires at least information specifying the taxi company that operates the taxi. Further, the user mobile terminal device 30 can transmit at least information identifying a taxi company to the server device 10 side.

Note that, as shown in the figure, the taxi company identification information "0001" and the taxi company name "〇〇Taxi" may be printed in text along with the two-dimensional code.

Next, the user interface displayed on the user mobile terminal device 30 will be explained. 7 to 11 are schematic diagrams showing examples of user interfaces (screens) displayed on the user mobile terminal device 30 when the user uses a taxi in the taxi usage support system 1.

FIG. 7 is a schematic diagram showing a screen displayed on the user mobile terminal device 30 before boarding registration. As shown in the figure, this screen includes three buttons: "boarding record", "way point record", and "disembarking record". By selecting one of the buttons (operation such as tapping), the user can execute the function corresponding to each button.

In the screen shown in FIG. 7, when the user selects "ride record", the user mobile terminal device 30 causes the user mobile terminal device 30 to execute a function for registering the ride record. Specifically, the user mobile terminal device 30 acquires the current position (boarding position) by GPS, and reads the code information (FIG. 6) provided in the taxi. Further, the user mobile terminal device 30 stores in advance a user code for identifying the user. Further, the user mobile terminal device 30 acquires the current date and time (boarding date and time) from an internal clock. The user mobile terminal device 30 then records the ride record including the current position (boarding position) information, the code information read from the taxi, the user code, and the current date and time (boarding date and time). The data is sent to the cloud server device 11 and registered. Note that the user mobile terminal device 30 may register the ride record by associating the information (ticket number) of the usage application made by the user in advance.

FIG. 8 is a schematic diagram showing a screen displayed on the user mobile terminal device 30 after boarding registration. As shown in the figure, this screen includes two buttons: "Record of waypoints" and "Record of disembarkation." By selecting one of the buttons (operation such as tapping), the user can execute the function corresponding to each button.

In the screen shown in FIG. 8, when the user selects "Record waypoint", the user mobile terminal device 30 executes a function for registering waypoint record. Specifically, the user mobile terminal device 30 acquires the current location (transit location) using GPS. Further, the user mobile terminal device 30 stores in advance a user code for identifying the user. Further, the user mobile terminal device 30 acquires the current date and time (transit date and time) from an internal clock. Then, the user mobile terminal device 30 transmits the data of the transit point record including the information of the current location (transit location), the user code, and the current date and time (transit date and time) to the cloud server device 11. ,register. In particular, if there is no waypoint, that is, if the taxi goes directly from the boarding position to the alighting position, there is no need to register this waypoint.

In the screen shown in FIG. 8, when the user selects "alighting record", the user mobile terminal device 30 causes the user's mobile terminal device 30 to execute a function for registering the alighting record. The screens for this are shown in the following FIGS. 9, 10, and 11.

FIG. 9 shows a screen for the user to input the amount, etc. when getting off the taxi. As shown in the figure, this screen is provided with columns for inputting the reason for use, the fare, and the toll road fee. The reason for use is a column for the user to input the reason for using this taxi. For example, it may be a user interface that allows the reason for use to be selected from several options. Further, the reason for use selected by the user at the time of application may be displayed as a default on this screen. In addition, numerical values can be entered in the fields for travel fees and toll road fees. This screen also includes a button called "Confirm Getting Off". After inputting information such as the fare, the user can press (for example, tap) this "confirm getting off" button. When the "Confirm getting off" button is pressed, the user mobile terminal device 30 transmits the input data to the cloud server device 11. In addition, the user mobile terminal device 30 also stores the current position (alighting position) acquired by GPS, the user code stored in advance, and the current date and time (alighting date and time) acquired from the internal clock on the cloud server. The information is transmitted to the device 11.

FIG. 10 is a confirmation screen for getting off the vehicle. This alighting confirmation screen is displayed on the user mobile terminal device 30 after the "Getting off Confirmation" button is pressed on the screen shown in FIG. The alighting confirmation screen in FIG. 10 is displayed on the user mobile terminal device 30 by the cloud server device 11, and includes items such as the taxi company, car number, boarding fee, toll road fee, total, boarding date and time, and alighting date and time. Contains data.

The taxi company and car number displayed on the screen in FIG. 10 are based on data sent from the user mobile terminal device 30 to the cloud server device 11 side. The cloud server device 11 obtains taxi company name information from the taxi company identification information by referring to master data (described later). Note that the car number may not be specified, in which case it will not be displayed. Further, the fare and toll road fee are based on the values input on the screen shown in FIG. Further, the total is the sum of the ride fee and the toll road fee, and is a value calculated on the cloud server device 11 side based on the value input on the screen of FIG. The boarding date and time and the alighting date and time are data transmitted from the user mobile terminal device 30 to the cloud server device 11 at the time of boarding and alighting, respectively.

Note that information regarding the transit points may be further displayed on the above-mentioned disembarkation confirmation screen.

The alighting confirmation screen includes a button for "determine/register boarding information" and a button for "modify". When the user presses the "Confirm/boarding information registration" button (operation such as tapping), the information to register is transmitted to the cloud server device 11 side, and the data displayed on the alighting confirmation screen is transferred to the cloud server. The device 11 is confirmed. Further, when the user presses the "modify" button, the display returns to the screen shown in FIG. 9, for example, and the user can perform an operation to modify the data. Note that when confirming the data, the user may show the screen to the taxi service provider (driver, etc.) and confirm the information with each other.

FIG. 11 shows the exit recording completion screen. After the "determination/boarding information registration" button is pressed on the alighting confirmation screen in FIG. 10, the display moves to the alighting record completion screen in FIG. 11. This alighting record completion screen is also displayed by the cloud server device 11 on the user's mobile terminal device 30, and includes the taxi company, car number, boarding fee, toll road fee, total, boarding date and time. , date and time of disembarkation, and ticket number. This alighting record completion screen is for checking the data determined on the server side. The user may show this alighting record completion screen to the taxi service provider (driver, etc.) and mutually confirm the contents. Additionally, since the ticket number is displayed on the user mobile terminal device 30 for the first time at the alighting record completion screen, the taxi service provider (driver, etc.) must confirm that the data has been confirmed on the server side. Can be done. Furthermore, by recording the ticket number in the passenger record or other documents, the taxi service provider can easily refer to the usage record data later.

FIG. 12 is a schematic diagram summarizing data generated at each stage of taxi boarding, transit points, and alighting, and the flow thereof. As shown in the figure, when riding in a taxi, the user mobile terminal device 30 transmits and registers the ride record to the server device 10. The ride record includes data such as a user code, ticket number, boarding date and time, boarding position, and taxi company code information. On the server device 10 side, upon receiving the ride record, the data is written into the storage means. Furthermore, when the taxi passes through a transit point, the user mobile terminal device 30 transmits and registers the transit point record to the server device 10. The transit point record includes data such as user code, ticket number, transit date and time, and transit location. On the server device 10 side, upon receiving the route point record, the data is written into the storage means. Note that the waypoint record can be registered, for example, from 0 times to N times (N is a non-negative integer, and as an example, N=10) for each time a taxi gets on and off. As shown in the figure, when getting off the taxi, the user mobile terminal device 30 transmits and registers the alighting record to the server device 10. The alighting record includes data such as the user code, ticket number, date and time of alighting, alighting location, fare (metered fare), toll road toll, and reason for use. On the server device 10 side, upon receiving the alighting record, the data is written into the storage means. Note that the fee information may be manually input by the user on the screen of the terminal device.

FIG. 13 is a schematic diagram showing the configuration of a table (taxi master) that is part of the data managed by the server device 10 and holds information for identifying taxi companies, their branches, etc., and individual cars. . This table is configured as two-dimensional tabular data, and has data items such as a taxi company code, taxi company name, branch code, branch name, and car number. The taxi company code is a code assigned to each business operator for the taxi usage support system 1. In the illustrated example, codes such as 0001 and 0002 are assigned. The taxi company name is the name of the company. In the illustrated example, the name of the company whose taxi company code is 0001 is "〇〇 Taxi." Further, the name of the company whose taxi company code is 0002 is "△△Automobile". The branch code is a code for identifying a branch, a branch office, a branch office, a department, a branch office, or the like of a taxi company. Further, the branch code may be a code for identifying another taxi company (or individual) that has a business alliance with the taxi company. For example, if multiple taxi companies form a union and a taxi company code is assigned to the union itself or to the taxi company representing the union (also called a "ticket handling company", etc.), the union Branch codes may be assigned to member taxi companies, etc. The "association" mentioned here is an association of business operators that jointly bill charges. The branches, branch offices, sub-offices, sub-offices, business partner companies, etc. mentioned here may be referred to as "branches" or "branches, etc.". The branch name is the name of the branch, etc. mentioned above. In the illustrated example, for a company with a taxi company code of 0001, a Yoyogi branch with a branch code of 0321 and a Shinagawa branch with a branch code of 0322 are registered. A company with a taxi company code of 0002 does not use a branch code. Furthermore, the car number is a number given to identify each vehicle. In the illustrated example, a taxi company code of 0001 does not use a car number. Furthermore, taxi companies with a taxi company code of 0002 are assigned and used vehicle numbers from 0001 to 0500. The two-dimensional code illustrated in FIG. 6 is created by a predetermined calculation procedure based on, for example, a combination of a taxi company code and a car number. If you read the two-dimensional code, you will get the taxi company code, branch code, and car number. Furthermore, if the data shown in FIG. 13 is searched using a taxi company code or branch code as a key, information on the taxi company name or branch name can be obtained, respectively.

FIG. 14 is a schematic diagram showing the configuration of a table (user master) that is part of the data managed by the server device 10 and holds information regarding users of the system. As shown in the figure, this table includes data items such as a user code, name, department code, home address, and home latitude and longitude. Note that the data items of home address and home latitude and longitude may be held only in the table on the in-house server device 12 side, and not in the table on the cloud server device 11 side. The user code is code information given for the taxi usage support system 1 and used to identify each user individually. The name is the user's name. The department code is code information for identifying the department to which the user belongs within the organization. The home address is the user's home address. The home latitude and longitude is information representing the location of the user's home in terms of latitude and longitude. Note that it is possible to convert an address into latitude and longitude by searching a database. Note that for the process of generating an alert, which will be described later, the taxi usage support system 1 may refer to the home address and its latitude/longitude information. Further, access to the home address and its latitude/longitude information is controlled so that only a limited number of people (for example, the user himself/herself) can refer to the information.

FIG. 15 is a schematic diagram showing the structure of a table that is part of the data managed by the server device 10 and is used to accumulate the usage status of individual taxis. Each row of this table corresponds to one taxi ride. As shown in the figure, this table includes data items such as confirmation date and time, ticket number, taxi company code, car number, user code, boarding date and time, alighting date and time, riding section, reason for use, boarding fee, and toll road fee.

The meaning of the data for each item is as follows. The confirmation date and time is the date and time when the data at the time of getting off the vehicle was finally confirmed. The ticket number is a number corresponding to one use of a taxi. The ticket number is issued, for example, when a usage application is made or when a ride record is registered without a usage application. The taxi company code and car number are as described with reference to FIG. 13. The user code is as described with reference to FIG. 14. The ride date and time is the date and time when the process of registering the ride record was performed. The date and time of getting off the vehicle is the date and time when the process of registering the record of getting off the vehicle was performed. The riding section is data that is constructed based on the position information at the time of registration of the ride record and the position information at the time of registration of the alighting record. Each of the boarding position and the disembarking position may be represented by latitude and longitude, or may be represented by a place name, facility name, etc. determined based on latitude and longitude. The reason for use, boarding fee, and toll road fee are data registered at the time of getting off the vehicle. Note that the above-mentioned confirmation date and time, boarding date and time, and disembarkation date and time are expressed, for example, in the format of "YYYY/MM/DD hh:mm" (year/month/day, hour/minute).

Note that the taxi usage status of all users is accumulated in a single table having the structure shown in FIG. 15.

Next, the internal functional configuration of each functional unit will be described with reference to the figures from FIG. 16 to FIG. 20.

FIG. 16 is a block diagram showing a schematic functional configuration within the first user function section 111. As shown in FIG. As illustrated, the first user function section 111 includes a boarding registration function section 1111, a waypoint registration function section 1112, and an alighting registration function section 1113.

The ride registration function unit 1111 registers in the database that the user has taken a taxi. Note that the ride registration function unit 1111 acquires the taxi code information (including at least information identifying the taxi company) read by the user mobile terminal device 30. The boarding registration function unit 1111 also acquires other data collected during boarding from the user mobile terminal device 30. The data items that the ride registration function unit 1111 acquires when riding are as described with reference to FIG. 12 and the like.

The waypoint registration function unit 1112 registers in the database that the user has passed through the waypoint. The waypoint registration function unit 1112 acquires and stores the data of the waypoint record, as described with reference to FIG. 12 and the like.

The alighting registration function unit 1113 registers in the database that the user has alighted from the vehicle. The alighting registration function unit 1113 acquires and stores the alighting record data, as described with reference to FIG. 12 and the like.

FIG. 17 is a block diagram showing a schematic functional configuration within the second user function section 121. As shown in FIG. As shown in the figure, the second user function unit 121 includes a home registration function unit 1212, a usage application function unit 1213, a usage application list function unit 1214, a usage history list function unit 1215, and an alert response function unit 1216. , and a complementary function unit 1217.

The home registration function unit 1212 has a function of registering the user's home address. The home registration function unit 1212 writes the home address input by the user into the table shown in FIG. 14, for example, based on the user's operation. In addition, the home registration function unit 1212 calculates the latitude and longitude of the user's home by referring to geographic data (not shown) based on the registered home address, and calculates the latitude and longitude of the user's home, and calculates the latitude and longitude of the user's home based on the registered home address. write to.

The usage application function unit 1213 processes a taxi usage application by a user. The usage application function unit 1213 sends the user's in-house terminal device 20 the scheduled boarding date, the scheduled boarding section (the place name of the boarding position, the place name of the alighting position, and the place name of the stopover point if necessary), Displays a screen for entering information such as the reason for use and the person who should approve the application (some items are selected from options). When the user inputs data for those items (selects some items) and presses the "apply" button, the usage application function unit 1213 registers the application. Further, the usage application function unit 1213 allows an appropriate decision maker to approve the usage application. A usage application list function section 1214, which will be described later, displays information indicating whether or not the application has been approved. Further, when a user gets in a taxi, the user can associate the ride with a usage application (for example, the user can select an application when getting in the taxi).

Note that if the decision maker who should approve the application is absent (for example, temporarily out of the office), the usage application function unit 1213 is configured so that the usage application can be registered in the absence of the decision maker. You can. Further, the usage application function unit 1213 may accept the application with some of the data items to be input at the time of application left blank. When an application is made in the absence of a decision maker or an application is made with some items blank, a supplementary function unit 1217, which will be described later, provides a function to supplement these deficiencies.

Further, the usage application function unit 1213 may provide a user interface that allows multiple usage applications to be made at once. For example, in cases where the user repeatedly uses a particular section of travel every day, it is convenient to have a function that allows the user to apply for multiple rides at once (allowing the user to apply for multiple ticket numbers at once).

The usage application list function unit 1214 causes the in-organization terminal device 20 for users to display list information of taxi usage applications of a specific user (logged-in user). This allows the user to grasp the status of the usage application (for example, whether it has already been approved or not) at once. The usage application list function unit 1214 may accept search conditions for narrowing down usage applications to be displayed. The search conditions may include, for example, the user name, the status of the usage application (whether it has already been approved or not), the period for narrowing down the application date, and other conditions related to free words.

The usage record list function unit 1215 has a function of displaying information on the user's internal terminal device 20 that allows the user to view usage records. The usage record list function unit 1215 may accept search conditions for narrowing down the usage records to be displayed. Search conditions include, for example, the user name, the period for narrowing down the date of use, the condition indicating whether or not supplementary input is required, the reason for use, the existence or type of alert, and other free words ( For example, conditions related to search terms related to riding sections, etc.) may be included. When search conditions are specified by the user, the usage record list function unit 1215 displays a list of only usage records that match the specified search conditions.

The alert response function unit 1216 has a function that allows the user to take action in response to an alert regarding usage history when the alert occurs. For example, if there is a usage record that includes an alert, the alert support function unit 1216 displays a supplementary explanation column to allow the user to input supplementary explanation regarding the alert. The supplementary explanation can be accepted as free text, for example. The alert support function unit 1216 stores the supplementary explanation input by the user in a form associated with the usage record. Further, the alert support function unit 1216 allows the decision maker to display supplementary explanations when viewing the user's usage history. This allows the decision maker to decide whether to approve the usage record based on the supplementary explanation input by the user.

The complementation support function unit 1217 has a function for the user to input complementation regarding usage records that require complementation. Complementary support is required, for example, in the following cases. As mentioned above, when applying for use, a user can apply without a decision maker or leave some items blank. Regarding these incomplete applications and usage records based on the applications, the complementation support function unit 1217 displays a message indicating that "complementary input is required." Then, the complementation support function unit 1217 displays a supplementary explanation column for the application that is "complementary input required" and allows the user to input a supplementary explanation. Supplementary explanations are accepted as text. The complementation support function unit 1217 stores the supplementary explanation input by the user in a form associated with the application. Further, the supplement support function unit 1217 allows a supplementary explanation to be displayed together with the supplementary input application (or usage history based on such application) when the decision maker views the application. This allows the decision maker to decide whether to approve the usage record based on the content (supplementary explanation, etc.) supplemented by the user.

In addition to the above cases (partially blank or no decision maker is present), depending on the class to which the user belongs, the complementation support function unit 1217 may similarly indicate "Complementation required" for applications for specific reasons for use. It may be treated as "input". As an example, if a user belonging to a specific class uses a reason for use other than "emergency," "nighttime," or "morning drive," the complementation support function unit 1217 may mark the application as "complementary input required." handle.

FIG. 18 is a block diagram showing a schematic functional configuration within the decider function section 122. As shown in the figure, the decider function unit 122 includes a user code issuing function unit 1220, a usage application approval function unit 1221, a usage application list function unit 1222, a usage history list function unit 1223, and an alert response function unit 1224. and a complementation support function section 1225.

The user code issuing function unit 1220 issues a user code to the user. The user code is code information within the taxi usage support system 1. For example, the user code issuing function unit 1220 displays a list of people (employees, etc.) who may become users, and allows the decision maker to select the person to whom the user code is to be issued using a check box or the like. Make it. The user code issuing function unit 1220 issues a new user code to the selected user based on the operation of such a decider. The user code is determined, for example, by using sequential numbers so as not to be duplicated with other users. The user code issuing function unit 1220 writes the issued user code into the user code column of the table shown in FIG.

After the user code issuance is completed, the user code issuing function unit 1220 sends the issued user code to the user. For example, the user code issuing function unit 1220 embeds an encrypted user code or a plaintext user code in a character string of a URL (uniform resource locator) in the text of an email. The user who receives this accesses the resource represented by the URL from the user mobile terminal device 30, for example. Then, the application running on the web browser in the user's mobile terminal device 30 writes the user code into the storage means in the user's mobile terminal device 30. Alternatively, the web browser itself writes the user code into a storage means (eg, the browser's management information storage). This allows the user mobile terminal device 30 to read the user code of the user from the storage means and use it when executing a function for the user.

The usage application approval function unit 1221 has a function for a decision maker to approve a usage application. Specifically, the usage application approval function unit 1221 causes the intra-organizational terminal device 20 for the decision maker to display a list of applications that require approval by the decision maker. Note that the usage application approval function unit 1221 may accept search conditions for narrowing down applications to be displayed as a list. In addition, the usage application approval function unit 1221 provides a means (for example, an "approve" or "reject" button) for selecting whether to approve the applications all at once or for each application individually. It is displayed on the in-house terminal device 20 for the decision-maker. Then, the usage application approval function unit 1221 performs a process of approving or denying those applications in accordance with the operation of the decision-maker. If the application is approved, the approved flag is updated to on in the application data. That is, when the application is approved, the usage application approval function unit 1221 adds information indicating that the application has been approved to the approved usage record data (usage application data).

The usage application list function unit 1222 has a function of displaying a list of usage applications on the in-house terminal device 20 for decision makers. The usage application list function unit 1222 may accept search conditions for narrowing down usage applications to be displayed. The search conditions may be, for example, the same conditions as those already described for the usage application list function section 1214.

The usage record list function unit 1223 has a function of displaying a list of taxi usage records on the in-house terminal device 20 for the decision maker. If the usage record includes an alert, the usage record list function unit 1223 also displays that there is an alert for the usage record. Note that the usage record list function unit 1223 may accept search conditions for narrowing down the usage records to be displayed. The search conditions may be, for example, user name, date, reason for use, or amount of money (travel fee, etc.). Further, the usage history list function unit 1223 has a function of approving the usage history data displayed in a list based on the operation by the decision maker.

The alert response function unit 1224 displays a column for the decision maker to input supplementary explanation when the data on the taxi usage record includes an alert. Additionally, the alert support function unit 1224 receives supplementary explanations (text) input by the decision maker. The alert support function unit 1224 stores the received supplementary explanation data in association with the usage record data. Further, the alert handling function unit 1224 has a function of approving usage history data that has an alert based on an operation by a decision maker.

The complementation support function unit 1225 displays a column for the decision maker to input supplementary explanation when the taxi usage application or usage record data is in the state of "complementary input required". The conditions for “complementary input required” have already been described. Further, the supplement support function unit 1225 receives supplementary explanations input by the decision maker. The complementation support function unit 1225 stores the received supplementary explanation data in association with the usage record data. Further, the complementation support function unit 1225 has a function of approving usage record data that is "required complementation input" based on the operation by the decision maker.

FIG. 19 is a block diagram showing a schematic functional configuration within the taxi company function section 112. As shown in the figure, the taxi company function section 112 includes a data confirmation function section 1121, a data editing function section 1122, a billing execution function section 1123, a billing statement outputting section 1125, a billing statement adding section 1126, and a paper It is configured to include a ticket details addition function section 1127. The taxi company function unit 112 provides the taxi company terminal device 40 with usage record data sorted by taxi company. Note that the taxi company function unit 112 provides only data related to the taxi company to the taxi company terminal device 40.

The data confirmation function unit 1121 has a function of confirming usage record data. Specifically, the data confirmation function unit 1121 causes the taxi company terminal device 40 to display a list of individual data of usage records (referred to as "details"). At this time, the data confirmation function unit 1121 displays the confirmed data and the unconfirmed data in different display methods (for example, in different display colors). The data confirmation function section 1121 has a function that allows a taxi company representative who sees this list to confirm the list by, for example, checking a checkbox. The data confirmation function unit 1121 updates the confirmation flag of the confirmed data (details) based on the operation of the taxi company representative.

The data editing function unit 1122 provides a function that allows a taxi company representative to edit usage record data. For example, a taxi company representative may need to edit (correct) data in the following cases.
a) When the cloud server device 11 is unable to obtain the riding record due to poor radio wave propagation conditions when getting on the vehicle (when getting off the vehicle, the riding record and the alighting record may be registered together).
b) If the date, time, or location of the boarding record, stopover record, or disembarkation record deviates from the actual date due to the timing of the user's operation being out of sync.
c) If the user enters the fare incorrectly and the taxi service provider (driver) fails to confirm the fare.

The billing execution function unit 1123 has a function for billing the taxi company to the organization (company, etc.) to which the user belongs. Specifically, the billing execution function unit 1123 searches for and presents confirmed and unbilled data from the taxi usage history based on, for example, the operation of a taxi company representative. The billing execution function unit 1123 presents an "OK" button on the screen so that the taxi company representative can execute the billing after confirming the billing data. When the "OK" button is pressed, the billing execution function unit 1123 assumes that the billing has been executed and updates the status of the data (details) to "billed." In addition, the billing execution function unit 1123 writes data on the billing date (the same day the billing is executed) to each item of detailed data.

The billing details output function section 1125 has a function of outputting billing details data regarding the above-mentioned billing. The billing details output function unit 1125 receives the designation of the billing date as a search condition from the taxi company terminal device 40. The billing details output function unit 1125 extracts data corresponding to the specified billing date by searching. The billing details output function unit 1125 prints out the data extracted according to the conditions as a form or outputs it as data for a spreadsheet. This makes it possible for taxi company personnel to send printed forms (collections of detailed data) and spreadsheet data attached to invoices to the organization to which the user belongs.

The billing statement addition function unit 1126 is a function that additionally creates billing statement data for usage records that have been omitted for some reason. The billing details addition function unit 1126 creates detailed data to be added based on the operation of the taxi company representative.

The paper ticket details addition function unit 1127 has a function of additionally creating billing detail data based on a paper taxi ticket (paper ticket). Paper tickets can be used when, for some reason, the taxi usage support system 1 is unable to create boarding and alighting records.

FIG. 20 is a block diagram showing a schematic functional configuration within the administrator function section 123. As shown in the figure, the administrator function section 123 includes a user registration function section 1231, a user change function section 1232, a user deletion function section 1233, an approved application discard function section 1234, and a user code issuing function. 1235 , a user code update function section 1236 , and an accounting-related function section 1239 .

The user registration function section 1231 has a function of registering users who use the taxi usage support system 1. The user registration function unit 1231 imports, for example, user (employee, etc.) data managed by another database management system (DBMS), spreadsheet data created by PC spreadsheet software, etc. Register the user by doing this. The data to be imported has at least some of the data items included in the table shown in FIG. The user registration function unit 1231 writes the imported data into the table shown in FIG. Alternatively, users may be registered by the administrator manually inputting the user's information.

The user change function unit 1232 changes user information. The user change function unit 1232 can change the user's name, department code, and other attribute information based on, for example, an administrator's operation.

The user deletion function unit 1233 deletes users registered in the taxi usage support system 1. For example, when a user who is an employee retires, the user deletion function unit 1233 deletes the registration of the user, for example, by an operation by the administrator. The user deletion function unit 1233 deletes the user from the table shown in FIG. 14, or updates equivalent data (for example, turns on the invalid flag). The deleted user will no longer be able to use the taxi usage support system 1.

The approved application disposal function unit 1234 has a function of discarding approved usage applications (applications for which the taxi has not yet been actually used) that meet predetermined conditions and the like. The approved application discard function unit 1234 causes the intra-organizational terminal device 20 for the administrator to display a field for inputting conditions for searching usage applications. This allows the administrator to set search conditions. As a specific example, the administrator inputs the name of a user (for example, an employee whose department has changed due to a personnel change or the like after the usage application was approved) as a search condition. The approved application discard function unit 1234 searches for usage applications according to specified search conditions, and displays usage applications that match the conditions on the screen. The administrator checks the display, performs operations such as selecting usage applications to be discarded as necessary, and presses the "discard" button. Based on this operation, the approved application discard function unit 1234 can discard the approved usage application.

The user code issuing function unit 1235 issues a user code to the user. The user code is code information within the taxi usage support system 1. The user code issuing function unit 1235 issues a new user code to a user selected based on an operation by the administrator, for example. The user code issuing function unit 1235 writes the issued user code into the user code column of the table shown in FIG.

The user code update function unit 1236 has a function of updating (changing) the user code. The user code update function unit 1236 issues a user code different from the conventional one to a user selected based on an operation by the administrator, for example. The user code update function unit 1236 updates the user code column of the table shown in FIG. 14 using the changed user code.

The accounting-related functional unit 1239 provides functions necessary from an accounting perspective regarding the use of taxis. For example, the accounting-related function unit 1239 allows the administrator (particularly the person in charge of accounting) to view usage record data and total fare data for each taxi company for a specified period. Furthermore, the accounting-related function unit 1239 has a function of checking whether the usage record data has been approved by the decision maker. Furthermore, the accounting-related function unit 1239 may have a function of checking whether the usage record data has been approved by the administrator. Furthermore, the accounting-related function unit 1239 has a function of updating a flag indicating whether or not the taxi company has already charged the fare on the usage record data. Furthermore, the accounting-related function unit 1239 displays usage records for which charges from taxi companies have been omitted in a way that makes them conspicuous on the screen (for example, by changing the color). Furthermore, the accounting-related function unit 1239 has a function of outputting data for settlement (data for invoicing from the taxi company, erasing unpaid amounts due to payment, etc.) for each taxi company. Furthermore, the accounting-related function unit 1239 has a function of additionally creating usage record data when there is no usage record data for some reason even though a taxi is actually used. In addition, if a taxi is used without using the mechanism of the taxi usage support system 1 (in this case, for example, a taxi ticket (paper ticket) printed on paper is used), the fare is The accounting-related functional unit 1239 has a function of reflecting data on settlements with taxi companies.

As described above, the taxi usage support system 1 can seamlessly exchange data with accounting systems of companies and the like.

Note that the alert conditions used by the usage record confirmation unit 124 described above to confirm data are, for example, as follows. However, alert conditions are not limited to those listed here. Alert conditions may be added or changed as appropriate. It should be noted that attendance data such as arrival time and leaving time can be referred to as described above.

(1) Excess time after leaving work: The taxi boarding time is more than a predetermined time from the user's leaving time.
(2) Exceeding time after getting off the taxi: The time when the user starts work is longer than the time when the user gets off the taxi.
(3) More than a predetermined amount per day: The total daily taxi fare for the same user is more than a predetermined amount.
(4) Late night/early morning: On days when the attendance data indicates that the user is working all night, the user uses a taxi for late night/early morning reasons.
(5) Late night/early morning/more than a specified distance: If you are using a taxi late at night or early in the morning, the pick-up or drop-off point (whichever is closer to your home) is more than the specified distance from your home location (latitude/longitude). is seperated.
(6) Late-night, early-morning, out-of-hours rides: If you are using a taxi late at night or early in the morning, you may use it outside of the available hours stipulated by your workplace (or department). There is.
(7) Riding near home: When using a taxi for reasons other than late at night and early morning, there is a boarding position near home (within a predetermined distance).
(8) Getting off near your home: When using a taxi for reasons other than late at night and early in the morning, there is a drop-off location near your home (within a predetermined distance).
(9) Holiday use: A taxi is used on a holiday or vacation day in the attendance data.
(10) Boarding and alighting outside of working hours: When using a taxi late at night or early in the morning for reasons other than the reason for use, the boarding or alighting time does not fall within working hours.

The usage history confirmation unit 124 verifies the usage history of the taxi based on the above-mentioned alert conditions, for example. That is, the usage record confirmation unit 124 determines whether or not a predetermined alert condition is met, and if the alert condition is met, generates an alert regarding the usage record data. Therefore, if there is a possibility that taxi usage is inappropriate, it is possible to request the user to input supplementary explanation.

Note that at least some of the functions in the taxi usage support system 1 in the embodiment described above can be realized by a computer. In that case, a program for realizing this function may be recorded on a computer-readable recording medium, and the program recorded on the recording medium may be read into a computer system and executed. Note that the "computer system" herein includes hardware such as an OS and peripheral devices. Furthermore, "computer-readable recording media" refers to portable media such as flexible disks, magneto-optical disks, ROM, CD-ROM, DVD-ROM, and USB memory, and storage devices such as hard disks built into computer systems. Say something. Furthermore, a "computer-readable recording medium" refers to a medium that temporarily and dynamically stores a program, such as a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line. In that case, it may also include something that retains a program for a certain period of time, such as a volatile memory inside a computer system that is a server or client. Further, the program may be one for realizing a part of the above-mentioned functions, or may be one that can realize the above-mentioned functions in combination with a program already recorded in the computer system.

The present embodiment is summarized as follows.

The server device includes at least a user function section, a data storage section, a decider function section, and a transportation company function section. The cloud server device 11 and the in-house server device 12 are server devices. The first user function section 111 and the second user function section 121 are user function sections. The first data storage section 110 and the second data storage section 120 are data storage sections. The taxi company functional department 112 is a transportation company functional department.
The user function unit receives usage record data including transport operator identification information for identifying the transport operator that provides the transport service and information on the amount of the transport fee from the user's terminal device. Note that the service in which taxis transport people is a transportation service. Taxi companies are transportation operators. The information identifying the taxi company is transportation company identification information.
The data storage unit stores and accumulates the received usage record data.
The decider function unit executes processing (pre-approval or post-approval) for approving the use of the transportation service by the user at least either before or after the implementation of the transportation service, and approves the use of the transportation service that has already been approved. Information indicating that it has been approved is added to the performance data.
Based on the approved usage record data, the transport company functional department provides the usage record data sorted by transport operator to the terminal device of the transport operator.

The transportation operator identification information (taxi company identification information) is optically readable on the transportation means (taxi vehicles, etc.) owned by the transportation operator (taxi company) and used for the transportation service. The code information is obtained by the user's terminal device reading code information provided in a suitable format.

The user's terminal device reads the code information at the time of starting the transportation service (when getting into the taxi).
The user function unit receives the transportation company identification information based on the code information from the user's terminal device as part of a service start record (boarding record).

After the user's terminal device determines (confirms) the transportation fee (meter fee, toll road fee, and their total) for the transportation service at the end of the transportation service (when getting off the taxi), This is to obtain information on the amount of the transportation fee.
The user function unit receives information on the amount of the transportation fee from the user's terminal device as part of the service end record (disembarkation record).

The user's terminal device acquires information on the amount of the transportation fee through manual input by the user. In other words, there is no need to provide means for receiving fare data from a taxi meter or the like.

When the transport company functional department provides the usage record data for the transport operator to the terminal device of the transport operator, the transport company functional department transmits the usage record data to the transport operator in units of implementation of the transport service. Information indicating whether or not the information has been confirmed is also transmitted, and information indicating that the usage record data is indicated as confirmed by the terminal device of the transport operator is added with information indicating that it has been confirmed. (Update confirmed flag).

When the transportation company functional department provides the usage record data for the transportation business operator to the terminal device of the transportation business operator, the transportation company functional department may provide the transportation business with respect to the usage record data in units of execution of the transportation service. The carrier also transmits information indicating whether or not charges have been made, and for the usage record data for which the transportation operator's terminal device indicates that charges have been made, the carrier shall indicate that charges have been made. Add representing information (update billed flag).

The server device further includes a usage record confirmation unit that checks the contents of the usage record data.
At the time of starting the transportation service (at the time of boarding), the user function unit transmits the information on the time at the time of the start of the transportation service (boarding time) and the information on the position at the time of the start of the transportation service (boarding position). In addition to being received from the user's terminal device, at the end of the transportation service (disembarkation time), information on the time at the end of the transportation service (disembarkation time) and the position at the end of the transportation service (disembarkation position) are received. information from the user's terminal device.
The data storage unit includes, as part of the usage record data, information on a time when the transportation service starts, information on a position when the transportation service starts, and information on a time when the transportation service ends; and information on the location at the end of the transportation service.
By referring to the attendance data representing the attendance status of the user, the usage record confirmation unit obtains the attendance data, information on the time at which the transportation service starts, and information on the location at the time the transportation service starts. , determine whether or not the information on the time when the transportation service ends and the information on the location when the transportation service ends match a predetermined alert condition, and if the alert condition is met. In this case, an alert regarding the usage record data is generated.

The user mobile terminal device 30 (user terminal device) identifies a transportation company that provides transportation services by reading code information provided in an optically readable form on the transportation means used for transportation services. Acquire transport operator identification information for identification, acquire information on the amount of the transport fee, and send usage record data including the transport operator identification information and information on the amount of the transport fee to the server device. Send to. Further, the user mobile terminal device 30 (user terminal device) transmits the usage record data including the transportation company identification information to the server device by reading the code information at the time of starting the transportation service. After determining the amount of the transportation fee, acquiring information on the amount of the transportation fee by manual input by the user and transmitting the usage record data including the information on the amount of the transportation fee to the server device; In addition to displaying a confirmation screen that includes information on the amount of the transportation fee, when the "Register" button included in the confirmation screen is operated, the server device sends a confirmation notification that is a notification that the usage record data is confirmed. Send to. Furthermore, after transmitting the confirmation notification to the server device, the user mobile terminal device 30 (user terminal device) displays the ticket number given by the server device on the screen.

As described above, according to the present embodiment, it is possible to settle fees without requiring an excessively large device (in particular, without providing an additional communication means on the vehicle such as a taxi). Further, according to the present embodiment, the user can use a taxi not only from a taxi company determined in advance on the server side. Further, according to the present embodiment, there is no need for the user's terminal device to download and install an application when using a taxi. Further, according to the present embodiment, the approval process within the user's organization, the taxi usage process, and the billing process from the taxi company can be seamlessly connected.

[Second embodiment]
Next, a second embodiment will be described with reference to the drawings. Note that description of matters already described in the previous embodiment may be omitted below. Here, matters specific to this embodiment will be mainly explained. The feature of this embodiment is the configuration of the functions that the cloud server device 11 has. The cloud server device 11 is configured to have a first user function section 211 in this embodiment instead of the first user function section 111 in the first embodiment.

FIG. 21 is a block diagram showing a schematic functional configuration of the first user function section 211 in this embodiment. As shown in the figure, the first user function section 211 includes a ride registration function section 2111, a waypoint registration function section 2112, an alighting registration function section 2113, a usage application function section 2118, and a usage application list function section 2119. It consists of: Of these, the boarding registration function part 2111, the waypoint registration function part 2112, and the alighting registration function part 2113 are respectively the boarding registration function part 1111, the waypoint registration function part 1112, and the alighting part in the first embodiment. It has the same function as the registration function section 1113. In other words, in this embodiment as well, the user can execute processes such as boarding registration, waypoint registration, and alighting registration by operating the user mobile terminal device 30. A feature of this embodiment is that the first user function section 211 also includes a usage application function section 2118 and a usage application list function section 2119.

The usage application function section 2118 has the same function as the usage application function section 1213 in the second user function section 121 in the first embodiment. As a result, in this embodiment, the user can apply for a taxi not only from the in-organization terminal device 20 but also from the user mobile terminal device 30. Specifically, the usage application function unit 2118 provides the user mobile terminal device 30 with a screen for inputting necessary items regarding the application (some items are selected from options), similar to the usage application function unit 1213. Display. Further, when the user inputs the data and operates (tap, etc.) the "application" button, the usage application function unit 1213 registers the application. This application data is also transferred from the cloud server device 11 side to the in-house server device 12 side at an appropriate timing. In other words, the application processed by the usage application function unit 2118 is treated in the same way as the application processed by the usage application function unit 1213 on the in-house server device 12 side. In other words, the appropriate decision maker will be able to approve the usage application.

The usage application function unit 2118 has the same functions as the usage application function unit 1213, including the functions whose description is omitted here.

Note that also in this embodiment, the second user function section 121 has the same function as the usage application function section 1213 in the first embodiment. In other words, whether the user uses the internal terminal device 20 or the user mobile terminal device 30, the user can equally perform the process related to applying for the use of a taxi.

In addition, when a user applies for the use of a taxi using either the usage application function unit 1213 or the usage application function unit 2118, a notification is sent by e-mail to the decision maker who should make a decision regarding the application. may also be sent. For example, a daemon that monitors new applications is always running in the in-house server device 12, and the daemon is configured to send e-mails to decision makers associated with new applications. do.

The usage application list function section 2119 has the same function as the usage application list function section 1214 in the second user function section 121 in the first embodiment. As a result, in this embodiment, the user can view the list of taxi usage applications not only from the in-organization terminal device 20 but also from the user mobile terminal device 30.

The usage application list function unit 2119 causes the user mobile terminal device 30 to display list information of taxi usage applications of a specific user (logged-in user). This allows the user to grasp the status of the usage application (for example, whether it has already been approved or not) at once. Regarding other functions, the usage application list function section 2119 is made to have the same functions as the usage application list function section 1214.

Note that, as described above, the user mobile terminal device 30 according to the present embodiment transmits application data for using a transportation service (taxi service) to the server device. Further, as described in the first embodiment, the user mobile terminal device 30 displays the alighting record completion screen when alighting is confirmed (after sending a confirmation notification to the server device). The ticket number is also displayed on this disembarkation confirmation completion screen. This ticket number is a number assigned by the server device in association with the above application data.

Although the first embodiment and the second embodiment have been described above, the present invention can be further implemented in the following modifications.
Modification 1: In the above embodiment, the system is configured by dividing the functions of the server device 10 into the cloud server device 11 and the in-house server device 12. As a first modification, the system may be configured as a single server device without separating these two devices. Further, the system may be configured by dividing the functions of the server device 10 into three or more devices.
Modification 2: In the above embodiment, when getting into the vehicle, the user mobile terminal device 30 reads two-dimensional code information (code information that at least identifies the taxi company) and transmits that information to the server side as a ride record. I made it. As a second modification, the user mobile terminal device 30 may read this two-dimensional code information at any time from the time of getting into the taxi to the time of getting off the taxi (while the transportation service is being performed). . Further, the user mobile terminal device 30 may transmit information identifying the taxi company to the server side at any time from the time the user gets into the taxi to the time the user gets off the taxi.
Further, a plurality of modifications may be implemented in combination.

Although multiple embodiments of this invention have been described above in detail with reference to the drawings, the specific configuration is not limited to these embodiments, and includes designs within the scope of the gist of this invention. .

The present invention can be used, for example, for the purpose of managing the use of transportation means by employees or related parties in organizations such as companies. However, the scope of use of the present invention is not limited to what is exemplified here.

1 Taxi usage support system 10 Server device 11 Cloud server device 12 In-house server device 20 In-house terminal device 30 User mobile terminal device (user terminal device)
40 Taxi company terminal device 50 Relay device 61 External network 62 Internal network 110 First data storage unit 111 First user function unit 112 Taxi company function unit 120 Second data storage unit 121 Second user function unit 122 Decidor Function unit 123 Administrator function unit 124 Usage record confirmation unit 211 First user function unit 1111 Boarding registration function unit 1112 Stopover registration function unit 1113 Alighting registration function unit 1212 Home registration function unit 1213 Usage application function unit 1214 Usage application list function Section 1215 Usage record list function part 1216 Alert support function part 1217 Complement support function part 1220 User code issuing function part 1221 Usage application approval function part 1222 Usage application list function part 1223 Usage record list function part 1224 Alert support function part 1225 Complement support Function unit 1121 Data confirmation function unit 1122 Data editing function unit 1123 Bill execution function unit 1125 Bill details output function unit 1126 Bill statement addition function unit 1127 Paper ticket statement addition function unit 1231 User registration function unit 1232 User change function unit 1233 Usage User deletion function section 1234 Approved application disposal function section 1235 User code issuing function section 1236 User code update function section 1239 Accounting related function section 2111 Boarding registration function section 2112 Stopover registration function section 2113 Alighting registration function section 2118 Usage application function Section 2119 Usage application list function section

Claims (10)

From the user's terminal device, usage record data including a user code for identifying the user, transportation operator identification information for identifying the transportation operator providing the transportation service, and information on the amount of transportation fee is received. a user function unit for receiving;
a data storage unit that stores the received usage record data;
A process of approving the use of the transportation service by the user at least either before or after implementation of the transportation service is executed, and information indicating that the usage has been approved is included in the approved usage record data. A decider function section to be added,
a decision maker function unit that adds information indicating that the transportation service has been approved to the approved usage record data based on the operation of a decision maker regarding the use of the transportation service by the user;
a transport company functional department that provides the usage record data sorted by transport operator to the transport operator's terminal device;
A server device equipped with. The transport operator identification information includes code information provided in an optically readable form on a transport means owned by the transport operator and used for the transport service by the user. is obtained by reading the terminal device,
The server device according to claim 1. The user's terminal device reads the code information at the time of starting the transportation service,
The user function unit receives the transport operator identification information based on the code information from the user's terminal device as part of a service start record.
The server device according to claim 2. The user's terminal device acquires information on the amount of the transportation fee after determining the amount of the transportation fee for the transportation service at the end of the transportation service,
The user function unit receives information on the amount of the transportation fee from the user's terminal device as part of a service termination record.
The server device according to any one of claims 1 to 3. The user's terminal device acquires information on the amount of the transportation fee by manual input by the user;
The server device according to claim 4. When the transport company functional department provides the usage record data for the transport operator to the terminal device of the transport operator, the transport company functional department transmits the usage record data to the transport business in units of execution of the transport service. information indicating whether the carrier has been confirmed or not is also transmitted, and for the usage record data that has been instructed to be confirmed by the transport operator's terminal device, information indicating that it has been confirmed is transmitted. add,
The server device according to any one of claims 1 to 5. When the transportation company functional department provides the usage record data for the transportation business operator to the terminal device of the transportation business operator, the transportation company functional department may provide the transportation business with respect to the usage record data in units of execution of the transportation service. The carrier also transmits information indicating whether or not charges have been made, and for the usage record data for which the transportation operator's terminal device indicates that charges have been made, the carrier shall indicate that charges have been made. Add information to represent
The server device according to claim 6. a usage record confirmation unit that checks the content of the usage record data;
further comprising;
At the time of starting the transportation service, the user function unit receives information on the time at the time the transportation service starts and information on the position at the time the transportation service starts from the terminal device of the user, and At the end of the service, receiving information on the time at the end of the transportation service and information on the location at the end of the transportation service from the user's terminal device;
The data storage unit stores, as part of the usage record data, information on a time when the transport service starts, information on a position when the transport service starts, and information on a time when the transport service ends. , information on the location at the end of the transportation service, and
The usage record confirmation unit refers to the attendance data representing the attendance status of the user, thereby obtaining the attendance data, information on the time at which the transportation service starts, and information on the location at the time the transportation service starts. and determining whether or not the information on the time at the end of the transportation service and the information on the location at the end of the transportation service match a predetermined alert condition, and match the alert condition. If so, generate an alert regarding the usage record data,
The server device according to any one of claims 1 to 7. From the user's terminal device, usage record data including a user code for identifying the user, transportation operator identification information for identifying the transportation operator providing the transportation service, and information on the amount of transportation fee is received. a user function unit for receiving;
a data storage unit that stores the received usage record data;
a decision maker function unit that adds information indicating that the transportation service has been approved to the approved usage record data based on the operation of a decision maker regarding the use of the transportation service by the user;
a transport company functional department that provides the usage record data sorted by transport operator to the transport operator's terminal device;
A program that allows a computer to function as a server device equipped with. From the user's terminal device, usage record data including a user code for identifying the user, transportation operator identification information for identifying the transportation operator providing the transportation service, and information on the amount of transportation fee is received. a user function unit for receiving;
a data storage unit that stores the received usage record data;
a decision maker function unit that adds information indicating that the transportation service has been approved to the approved usage record data based on the operation of a decision maker regarding the use of the transportation service by the user;
a transport company functional department that provides the usage record data sorted by transport operator to the transport operator's terminal device;
a server device comprising;
acquiring the transportation operator identification information by reading code information provided in an optically readable form on the transportation means used for the transportation service, and acquiring information on the amount of the transportation fee; a user terminal device that transmits usage record data including the transportation company identification information and the transportation fee amount information to a server device;
system containing.

Images