JP7457540B2 - Fare collection system - Google Patents

Description

TECHNICAL FIELD The present invention relates to a fare collection system for collecting a fare for a shared vehicle from a user of the vehicle. Note that the shared vehicles include shared buses such as route buses, streetcars, and trolleybuses, and trains.

The technology that allows people to enter and exit through automatic ticket gates at train stations by holding a mobile information terminal device such as a smartphone over a ticket gate instead of a train ticket, that is, the technology related to digital tickets, is described below. It is disclosed in Patent Document 1. A digital ticket is a computerized form of certain rights such as an admission ticket or an exchange ticket, and is sometimes called an electronic ticket.

Japanese Patent Application Publication No. 2018-147270

A typical example of a digital ticket is an encoded code (e.g., QR code (registered trademark) or barcode) printed on paper or displayed on the screen of a mobile information terminal device such as a smartphone. By reading the code with a reader for that code, certain rights such as admission tickets and exchange tickets can be confirmed. When this is applied to automatic ticket gates at railway stations, it is necessary to provide the ticket gate itself with a reader function, as in the type α automatic ticket gate of the transportation system disclosed in Patent Document 1 ( Patent Document 1; paragraph 0011, etc.). Therefore, there is a possibility that equipment costs at the time of system introduction etc. will increase.

Further, the transportation system of Patent Document 1 relates to an automatic ticket gate at a railway station, and the automatic ticket gate is provided within the station premises. Therefore, it is relatively easy to connect via wired communication lines between the automatic ticket gate provided at the entry station and the center server device, and between the automatic ticket gate provided at the exit station and the payment server device. However, when attempting to introduce such transportation system technology into the fare collection system of route buses, the fare box installed on the route bus and the center server device and payment server device must be connected via wireless communication lines. I don't get it. This is because the on-vehicle fare box itself moves. Wireless communication lines are orders of magnitude more expensive to use than wired communication lines, and operational costs are more likely to become an obstacle to system introduction than equipment costs.

The present invention has been made in order to solve the above-mentioned problems, and aims to provide a fare collection system that can enable payment using digital tickets while suppressing increases in equipment costs and operational costs. .

In order to achieve the above object, the fare collection system recited in claim 1 is a fare collection system that collects the fare for use of a shared vehicle from the user of the vehicle, and a boarding information providing device provided near the exit; an alighting information providing device provided near the exit in the vehicle; and information corresponding to the stop at which the vehicle stopped, which is different for each stop. a control device that outputs information to the boarding information providing device and the getting off information providing device each time the vehicle stops; a payment server device that is installed outside the vehicle and performs information processing regarding electronic payment for collecting the fare; a portable information terminal device that is carried by a user and is capable of acquiring the stop information output from the boarding information providing device and the getting off information providing device, and is capable of communicating information to the payment server device via a wireless communication line; , the portable information terminal device acquires the stop information at the time of boarding (hereinafter referred to as "boarding stop information" in claims 1 to 5) output from the boarding information providing device when the user boards the board. , acquires the stop information at the time of alighting (hereinafter referred to as "alighting stop information" in claims 1 to 5) output from the alighting information providing device when the user alights, and acquires the alighting stop information included in the boarding stop information. transmitting usage fare information regarding the usage fare obtained based on the numbered ticket number corresponding to the stop at the time of boarding and fare data corresponding to the numbered ticket number included in the alighting stop information to the payment server device; A technical feature of the payment server device is that the payment server device performs information processing regarding the electronic payment based on the usage fare information transmitted from the mobile information terminal device.

In the invention of the fare collection system according to claim 1, the boarding information providing device, the alighting information providing device, the control device, the payment server device, and the portable information terminal device constitute the system. The mobile information terminal device acquires the boarding stop information output from the boarding information providing device when the user gets on the train, acquires the alighting stop information output from the boarding information providing device when the user gets off, and uses the boarding stop information as the boarding stop information. The usage fare information regarding the usage fare obtained based on the numbered ticket number corresponding to the included boarding stop and the fare data corresponding to this numbered ticket number included in the alighting stop information is sent to the payment server device, and the payment is made. The server device performs information processing regarding electronic payment based on usage fare information transmitted from the mobile information terminal device. Typically, the control device is a control device constituting on-vehicle equipment such as a fare box, a fare display, or an in-vehicle broadcasting device existing as existing equipment in a shared vehicle. Furthermore, existing equipment can be used as the payment server device. The portable information terminal device is owned by the user of the shared vehicle. Note that the control device itself may be provided alone.

Therefore, in configuring the fare collection system, what is newly required is a boarding information providing device and an alighting information providing device. Further, information processing for obtaining usage fare information regarding usage fares and communication processing with the payment server device are performed by a mobile information terminal device owned by the user. As a result, the control device, boarding information providing device, and alighting information providing device installed in the shared vehicle do not need to perform information processing to obtain usage fare information or perform communication processing with the payment server device. There is no need to provide these control devices with a microcomputer with high arithmetic processing capacity or a memory with a large storage capacity. Also, there is no increase in communication costs.

Furthermore, it is exclusively the mobile information terminal device that communicates information with the payment server device via the wireless communication line, and the boarding information providing device, the alighting information providing device, and the control device installed in the shared vehicle are connected to the payment server device. Do not communicate information directly with the device. In other words, businesses operating shared vehicles do not need to use a wireless communication line with the payment server device when operating the fare collection system. As a result, communication costs are significantly reduced compared to the case where the in-vehicle boarding information providing device, the alighting information providing device, and the control device use wireless communication lines.

The fare collection system described in claim 2 of the present patent application has a technical feature in that, in the fare collection system described in claim 1, the boarding stop information output from the boarding information providing device and the alighting stop information output from the alighting information providing device each change over time and include at least time information on the output time.

In the invention of the fare collection system according to claim 2, the boarding stop information and the alighting stop information change over time, and include at least time information of the time when these stop information was output. By comparing the time information of this output time and the time information at the time of acquisition of these stop information, for example, the acquired boarding stop information and alighting stop information can be transmitted from the boarding information providing device or the alighting information providing device to the boarding and alighting information. It becomes possible to determine whether the output was output in the past before that time. Note that the time information at the time of acquiring the stop information is obtained, for example, from the clock function of the mobile information terminal device, or from the clock function of the boarding information providing device or the getting off information providing device.

As a result, if the acquired boarding stop information and alighting stop information are from the previous day, for example, the boarding stop information and alighting stop information that should have been acquired at the time of boarding or alighting will be changed. Since there is a high probability that the user intentionally acquired the old boarding stop information and alighting stop information prepared in advance with the mobile information terminal device, it is possible to determine whether such unauthorized use has occurred.

Further, in the fare collection system according to claim 1 or 2, the fare collection system according to claim 3 provides the boarding stop information and the alighting information output from the boarding information providing device. The alighting stop information output from the device is encrypted, and the portable information terminal device decodes the encrypted boarding stop information and the alighting stop information using a predetermined encryption key to obtain the ticket number. The technical feature is to obtain the above-mentioned fare data .

In the invention of the fare collection system according to claim 3, since the boarding stop information outputted from the boarding information providing device and the alighting stop information outputted from the boarding information providing device are encrypted, boarding stop information and alighting stop information output from the boarding information providing device are encrypted. This makes it possible to prevent stop information from being generated illegally. The portable information terminal device decrypts the encrypted boarding stop information and alighting stop information using a predetermined encryption key to obtain a ticket number and fare data. As a result, even if boarding stop information and alighting stop information are encrypted, the mobile information terminal device can obtain the ticket number and fare data from this information and obtain usage fare information regarding the usage fare. .

The fare collection system described in claim 4 of the claims has a technical feature that, in the fare collection system described in any one of claims 1 to 3, the mobile information terminal device outputs predetermined incomplete information so as to be notified to the driver of the vehicle when the transmission of the fare information to the payment server device has not been completed or the information processing related to the electronic payment cannot be completed based on the alighting stop information and the boarding stop information, or outputs predetermined completion information so as to be notified to the driver of the vehicle when the transmission of the fare information to the payment server device has been completed or the information processing related to the electronic payment can be completed.

In the invention of the fare collection system according to claim 4, the mobile information terminal device determines whether the transmission of the usage fare information to the payment server device is not completed based on the alighting stop information and the boarding stop information, or when the electronic payment is completed. If the information processing cannot be performed, predetermined incomplete information is outputted so as to be notified to the vehicle crew. This allows the crew to know that the fare has not been collected for the user in question, allowing them to respond appropriately to the passenger, such as explaining to the user that post-payment processing is required. become. Further, when the transmission of the fare information to the payment server device is completed or when the information processing regarding the electronic payment can be performed, predetermined completion information is outputted so as to be notified to the crew of the vehicle. This allows the crew member to know that the user's fare has been collected, so that the crew member can understand that there is no need to explain the post-payment process, etc. to the user.

Further, in the fare collection system according to claim 5, in the fare collection system according to any one of claims 1 to 4, the mobile information terminal device , if the mobile information terminal device is set not to communicate information via the wireless communication line, technical regulations require that predetermined communication failure information be outputted in a manner that can be notified to the crew of the vehicle. Features.

In the invention of the fare collection system according to claim 5, when the portable information terminal device is set so as not to perform information communication via the wireless communication line when the user gets off the train, (For example, when the mobile information terminal device is set to "in-flight mode"), predetermined communication failure information is outputted so as to be notified to the vehicle crew. As a result, the crew member cannot allow the mobile information terminal device to send fare information to the payment server device or send boarding stop information or alighting stop information to other server devices, etc. via the wireless communication line. Since the current status can be recognized, it becomes possible, for example, to prompt the user to cancel airplane mode. Therefore, it is possible to prevent incomplete transmission of fare information from the mobile information terminal device to the payment server device due to the in-flight mode.

In the fare collection system of the present invention, the control device, boarding information providing device, and disembarking information providing device installed in the public vehicle do not need to perform information processing to obtain fare information related to the fare used, or communication processing with the payment server device, so there is no need to provide these control devices with microcomputers with high computing power or large-capacity memories. There is also no increase in communication costs. Therefore, it is possible to enable payment using digital tickets while suppressing increases in equipment costs.

1 is an explanatory diagram showing a configuration example of a fare collection system according to an embodiment of the present invention. FIG. 2 is a perspective view showing an example of the external appearance of a boarding display terminal and a getting off board display terminal that constitute the fare collection system of the present embodiment. It is an explanatory view showing an example of triangular fare table data stored in a data cassette. It is a flowchart which shows the flow of the stop information etc. transmission process performed by the control unit of the host device which comprises the fare collection system of this embodiment. It is a flowchart which shows the flow of the code output process performed by the control unit of a boarding display terminal and alighting display terminal. 10 is a flowchart showing the flow of the fare settlement process executed by the control unit of the smartphone constituting the fare collection system of this embodiment. 7 is a flowchart showing the flow of the code acquisition process shown in FIG. 6. 8 is a flowchart showing the flow of the wireless transmission process shown in FIG. 7. It is a flowchart which shows the flow of the stop information etc. recording process performed by the management server which comprises the fare collection system of this embodiment. It is a flowchart showing the flow of fare payment processing executed by the payment server configuring the fare collection system of this embodiment. FIG. 2 is a sequence diagram showing a series of processes executed by the host device, the boarding display terminal, the alighting display terminal, the smartphone, the management server, and the payment server from when the user gets on the bus to when the user gets off the bus. . These are examples of screen displays of a smartphone, with FIG. 12(A) showing a display example in the selection menu display process, and FIG. 12(B) showing a display example in the code information importing process. These are examples of smartphone screen displays. Figure 13(A) shows an example of the display when it is determined that the airplane mode is in the code acquisition process when getting on the train, and Figure 13(B) shows the display when getting off the train. This is a display example when it is determined that the airplane mode is present in the code acquisition process. FIG. 4 is an explanatory diagram showing how a fare is calculated based on the fare triangular table data shown in FIG. 3 . These are examples of screen displays on a smartphone. Figure 14(A) shows an example of a payment completion display in the processing result notification process, and Figure 14(B) shows an example of a payment incomplete display in the processing result notification process. It is something.

Hereinafter, embodiments of the fare collection system of the present invention will be described with reference to the drawings.

One embodiment of the fare collection system of the present invention is a fare collection system 10 that collects fares from passengers (hereinafter referred to as "users") who use a route bus (hereinafter referred to as "bus") 90. This assumes that a smartphone 50 is possessed as a portable information terminal device. An application program for fare settlement (hereinafter referred to as "fare settlement application"), which will be described later, is installed on the user's smartphone 50.

As shown in FIG. 1, the bus 90 of this embodiment is a one-man operation system, in which the user gets on the bus from the rear entrance 91 and then pays the fare when getting off from the front exit 93. The train uses a pay-before-boarding, deferred-pay method. The ``post-boarding, pre-disembarking, deferred payment system'' is a form of deferred fare payment system, and typically adopts a fare system in which the amount increases depending on the distance. Therefore, to obtain the usage fare, for example, triangular fare table data, which will be described later, is used.

The bus 90 is provided with a fare box near the exit 93 where passengers can pay their fares with cash or IC cards. In this embodiment, the fare box serves as the host device 40. In addition to such a fare box, the host device 40 may be any device mounted on the bus 90, such as an on-board device such as a fare display that displays to passengers the fare corresponding to the boarding section, an on-board public address device that broadcasts the name of the next stop, etc., inside the vehicle, or a destination display device control panel that displays the destination of the bus 90, etc., to the outside of the vehicle.

The fare collection system 10 includes a boarding display terminal 20, an alighting display terminal 30, a host device 40, a smartphone 50, a management server 60, a payment server 70, and the like. Of these, the boarding display terminal 20, the alighting display terminal 30, and the host device 40 are mounted on the bus 90, and the smartphone 50 is carried by the user. The management server 60 and the payment server 70 are housed, for example, within the company premises of the bus 90 operating company. These servers 60 and 70 may use rental servers managed by other businesses.

The management server 60 and the payment server 70 are connected to the Internet N via, for example, an unillustrated Internet service provider (ISP). Furthermore, the smartphone 50 is connected to the Internet N via a base station 80 or the like managed by a mobile network operator (MNO). The Internet N is an example of an information communication network that transmits data, and is a computer network that interconnects computers using Internet protocols. Note that any information communication network other than the Internet N may be used as long as data communication is possible between the smartphone 50 and the management server 60 and between the smartphone 50 and the payment server 70.

As shown in FIGS. 1 and 2, the boarding display terminal 20 mainly includes a control unit 21, a display unit 23, a lighting unit 25, a communication unit 27, and the like. It is attached to a grip bar P provided near the entrance 91 of the vehicle. The appearance of the ride display terminal 20 is composed of, for example, a rectangular box-shaped housing that houses the control unit 21 and the like, and a rectangular liquid crystal display panel of the display unit 23 provided on the front surface of the housing.

The control unit 21 is a controller composed of an MPU, a memory (DRAM, ROM), an interface, etc., almost like the control unit 41 of the host device 40 described later. , a communication unit 27, etc. are connected thereto. The ROM of the memory stores a predetermined system program that allows the MPU to control the display unit 23, lighting unit 25, and communication unit 27, and a code output program that allows the MPU to execute code output processing 200, which will be described later. etc. are stored.

The display unit 23 is a display device equipped with a liquid crystal display panel or electronic paper as a display device, and is connected to the control unit 21 by, for example, a liquid crystal video parallel interface, an LVDS (Low voltage differential signaling) interface, or an SPI (Serial Peripheral Interface). ) etc. The screen size is set to be large enough to display the two-dimensional code DC described later, for example, in the case of a square type with an aspect ratio of 4:3, the screen size is set to 5 to 6 inches, and if the aspect ratio is 16 :9 wide type is set to 6 to 7 inches.

The lighting unit 25 is a lighting device that can emit surface light to illuminate the display unit 23, and the light source is, for example, an LED, an organic EL, or the like. The lighting unit 25 is connected to the control unit 21 via a serial interface or a GPIO (General-purpose input/output) interface, and is configured such that the control unit 21 can control the on/off of light emission and the brightness. For example, when the display device of the display unit 23 is a liquid crystal display panel, the lighting unit 25 is provided on the back side of the display unit 23. Further, when the display device is electronic paper, the lighting unit 25 is provided on the front side of the display unit 23.

In this embodiment, the boarding display terminal 20 is equipped with an illumination unit 25 that illuminates the display unit 23. Therefore, even if the boarding display terminal 20 is surrounded by a dark environment, such as at night, the illumination unit 25 can illuminate the two-dimensional code DC displayed on the display unit 23. This makes it possible to increase the success rate of capturing an image of the two-dimensional code DC by the camera 55 when the two-dimensional code DC is captured by the smartphone 50.

The communication unit 27 is a serial communication device that allows the control unit 21 to communicate data with the host device 40 via the wired communication line 15. In this embodiment, an RS-458 compliant device is used that allows multi-drop connection between the host device 40, the boarding display terminal 20, the boarding display terminal 30, etc. When making PP (Point to Point) connections between the host device 40 and the alighting display terminal 30, for example, current loop or RS-422 compliant devices may be used. Further, the host device 40, the boarding display terminal 20, the disembarking display terminal 30, etc. may be connected using an Ethernet-compliant LAN.

In this embodiment, the host device 40 sends control commands related to display and lighting, stop information, etc. to be described later, to the boarding display terminal 20 via the communication unit 27 and the wired communication line 15. A boarding door opening signal is also sent. The boarding door opening signal is a signal sent from another vehicle-mounted device (not shown) at the timing when the boarding door of the bus 90 is opened, and is a signal that instructs the boarding door opening/closing device (not shown) to open the boarding door. Further, in order to close the boarding door of the bus 90, a boarding door close signal that is sent from another vehicle-mounted device to the boarding door opening/closing device and instructing the boarding door to close may be sent to the boarding display terminal 20.

The dashed line reference number 17 denotes a stop-send signal that is output from a manually operated push button (hereinafter referred to as the "stop-send button") each time the crew member (driver) of the bus 90 operates the button, and is sometimes called a proceeding signal. The stop-send signal 17 is a trigger signal that advances the control of on-board equipment such as the fare display, on-board public address system, and fare box in accordance with the next stop (hereinafter referred to as the "next stop") at which the bus 90 is scheduled to stop as it travels. The information obtained by the stop-send signal 17 is referred to as "stop-send information."

In addition, instead of such a stop sending button that is manually operated by a crew member (driver), there is a button that uses GPS (Global Positioning System) to grasp the running position of the bus 90 and automatically outputs the stop sending information. May be used. This prevents the output of the stop sending information from being omitted due to the crew member (driver) forgetting to operate the stop sending button, thereby preventing a situation in which the two-dimensional code DC described later is not displayed on the boarding display terminal 20 or the getting off display terminal 30. becomes possible.

The control unit 21, display unit 23, lighting unit 25, and communication unit 27 are each supplied with driving power from a power supply unit (not shown) provided within the housing. Therefore, although not shown in FIG. 2, a wire harness for the wired communication line 15 and the power supply line is connected to the boarding display terminal 20. The wired communication line 15 may be replaced with a wireless communication line that complies with wireless standards such as Bluetooth (registered trademark) or ZigBee (registered trademark). In this case, the communication unit 27 needs to be replaced with one that is compatible with Bluetooth (registered trademark), ZigBee (registered trademark), or the like.

The disembarking display terminal 30 is attached, for example, to a grip P provided near the disembarking entrance 93 of the bus 90, and has the same hardware configuration as the boarding display terminal 20. In other words, the disembarking display terminal 30 is mainly composed of a control unit 31, a display unit 33, a lighting unit 35, a communication unit 37, etc., which correspond to the control unit 21, display unit 23, lighting unit 25, and communication unit 27 of the boarding display terminal 20 described above, respectively. Therefore, a description of the configuration and connection relationships of the control unit 31, etc. will be omitted here.

Note that since the alighting display terminal 30 is provided near the alighting gate 93 of the bus 90, an alighting door signal is sent from another vehicle-mounted device (not shown) at the timing when the alighting door of the bus 90 is opened. The exit door signal is a signal that instructs the exit door opening/closing device to open the door. Further, if a small display that the user can see is provided in the fare box near the exit 93, this small display may be used in place of the exit display terminal 30. In this case, the hardware of the alighting display terminal 30 can be reduced, making it possible to further reduce equipment costs.

In this embodiment, the host device 40 corresponds to a fare box. Therefore, the control unit 41 serves as a control unit for the fare box, and the communication unit 47 serves as a communication unit for the fare box. Note that the host device 40 may be newly installed independently without using an existing fare box or the like as described above, regardless of the existing fare box or the like.

The control unit 41 controls various units 46 such as a drive unit of the fare collection mechanism provided in the fare box, a data cassette in which fare triangular table data, etc. are written, an IC card reader/writer, a display, a communication unit 47, etc. The controller is composed of an MPU 42, a memory 43, an input/output interface 44, a clock unit (not shown), and the like. The MPU 42 is an arithmetic processing unit that controls various units 46 and the like, and is connected to the memory 43, the input/output interface 44, and the like via the system bus 45 and the like.

The memory 43 is a semiconductor storage device, and constitutes a main storage space used by the MPU 42. In this embodiment, it is configured by a ROM that serves as a program area and a DRAM that is allocated to a work area and a data area. In this embodiment, the ROM stores various control programs such as a system program for controlling the various units 46 and a stop information etc. sending program that enables the stop information etc. sending process 100 described later.

In addition, in addition to the fare triangular table data, the data cassette memory has its system number, operator name, business office name, vehicle number, etc., so, for example, if the route of bus 90 is changed. Each time, it is replaced with one that corresponds to that route. An example of fare triangular table data is illustrated in FIG.

The input/output interface 44 is an input/output interface device that mediates the exchange of serial and parallel data with peripheral devices of the control unit 41. In this embodiment, it is configured to be connectable to various units 46, a communication unit 47, etc. The input/output interface 44 may also be equipped with a driver circuit that drives the various units 46.

The communication unit 47 is a serial communication device that allows the control unit 41 to communicate data with the boarding display terminal 20 and the disembarking display terminal 30 via the wired communication line 15. It functions as a host for the host. In this embodiment, a device based on RS-458 is used, and a multi-drop connection is made between the host device 40, the boarding display terminal 20, the getting off display terminal 30, etc. using the wired communication line 15. A communication protocol is used that allows the boarding display terminal 20, the boarding display terminal 30, etc. connected to the wired communication line 15, including the host device 40, to be identified by ID.

The smartphone 50 is a portable information terminal device owned (possessed) by a user, and is sometimes called a "portable information terminal" or a "mobile terminal." The smartphone 50 is generally commercially available and is composed of a control unit 51 (MPU, memory, etc.), a wireless unit 52, a display unit 53, a camera 55, a memory card, a battery, etc., and is approximately several millimeters thick. It is housed in a thin plate-like case.

Note that instead of such a smartphone 50, the user may have a tablet-type personal computer (hereinafter referred to as a "tablet") that has a display unit with a screen size of 8 to 10 inches and is capable of data communication. Further, instead of a smartphone or a tablet, the user may have a generally commercially available mobile phone device with a camera (mobile phone with a camera) as a mobile information terminal device.

In the present embodiment, the smartphone 50 has a control unit 51 running on an OS (basic software) such as Android (registered trademark) or iOS (registered trademark), and performs fare settlement processing 300 to be described later. Applications are also configured to be able to run on these OSs. The OS of the smartphone 50 may be one other than Android (registered trademark) or iOS (registered trademark), but in that case, the fare adjustment application must also be adapted to operate on that OS. The wireless unit 52 is configured to be capable of data communication and voice communication via a wireless communication line 85 of a mobile network operator (MNO).

The camera 55 is equipped with a solid-state imaging element such as a CCD or CMOS, has a lens on the back of the smartphone 50, and is configured to be able to capture an image of the two-dimensional code DC displayed on the boarding display terminal 20 or the disembarking display terminal 30. The image data captured by the camera 55 can be processed by the control unit 51, and in this embodiment, the information embedded in the two-dimensional code DC can be obtained by decoding it using the fare adjustment app. Note that in the case of a tablet, the configuration is almost the same as the smartphone 50, except for the screen size of the display unit.

Both the management server 60 and the payment server 70 are file servers mainly composed of a control device, a database device, network equipment, and the like. The control device is an information processing device that is connected to and controls a database device and network equipment, and corresponds to, for example, a server computer. A database device is a large-capacity information storage medium with a storage capacity of several hundred TB (terabytes). The network device is connected to the Internet N, for example.

The differences in the hardware between the management server 60 and the payment server 70 are, for example, the processing speed of the control device and the storage capacity of the database device, but basically the hardware of both servers 60, 70 is configured in almost the same way. In terms of software, in the case of the management server 60, for example, a bus stop information recording program that enables the control device to execute the bus stop information recording process described below is stored in the hard disk drive of the control device. Also, in the case of the payment server 70, for example, a fare payment program that enables the control device to execute the fare payment process described below is stored in the hard disk drive of the control device.

Therefore, in this embodiment, the management server 60 and the payment server 70 are configured separately, but these servers 60 and 70 may be configured as the same server. That is, the management server 60 may have the function of the payment server 70, or the payment server 70 may have the function of the management server 60. In this case, a stop information recording program and a fare payment program are stored in a hard disk device or the like of a control device provided in a single server.

By configuring the boarding display terminal 20, the disembarking display terminal 30, the host device 40, the smartphone 50, the management server 60, and the payment server 70 in this manner, the fare collection system 10 of this embodiment performs various processes such as bus stop information sending process 100, code output process 200, and fare settlement process 300 from the time user M boards the bus 90 until he disembarks, as shown in the sequence diagram in Figure 11.

In addition, as a preliminary preparation for using the fare collection system 10, the user M may, for example, install a fare settlement application that can execute the fare settlement process 300 on the user M's smartphone 50 by using the operator of the bus 90 or the smartphone. It is necessary to download the application program (smartphone application) from a website operated by a vendor or the like and install it (implementation) on the smartphone 50.

After starting the fare adjustment app on the smartphone 50, it is necessary to set personal information such as the name, date of birth, sex, address, telephone number, and occupation of the user M in the smartphone 50 and the management server 60 as an initial setting task, and to register payment information such as credit card information in the smartphone 50. When performing secure information management, personal information and payment information are registered only in the management server 60. The smartphone 50 can be uniquely identified by its MAC address or device ID. It can also be identified by the IMSI (International Mobile Subscriber Identity) stored in the SIM card of the smartphone 50. This identifies the owner of the smartphone 50 as user M, making it possible to associate IS such as bus stop information described below with user M.

[Stop information etc. sending process 100]
As shown in FIG. 11, in the fare collection system 10 of this embodiment, the host device 40 of the bus 90 first starts the stop information etc. sending process 100. That is, in the host device 40, as described above, the ROM of the memory 43 of the control unit 41 stores a program for transmitting stop information, etc. Therefore, when the power is turned on to the host device 40 before the start of operation of the bus 90, the MPU 42 executes a program for transmitting stop information, etc., which is loaded into the DRAM of the memory 43 immediately after, and the stop information shown in FIG. etc. sending processing 100 is started. Note that the MPU 42 may be configured to directly execute a program for transmitting stop information, etc., which is stored in the ROM instead of being developed in the DRAM.

As shown in FIG. 4, in the process 100 for sending bus stop information, etc., a predetermined initialization process is first performed in step S101. In this process, for example, the work area and flags for this process in the memory 43 of the control unit 41 are cleared, and control commands for initial setting are sent to the boarding display terminal 20 and the disembarking display terminal 30, which are started at approximately the same time. In the following step S102, a route number input process is performed in which the driver inputs the route number on which the bus 90 runs.

In the next step S103, a process of reading the first train stop information, etc. is performed. The first stop information, etc. is information regarding the first stop BSa of the bus 90, and is, for example, the information (1) to (8) listed below. Among these, (1) to (4) change while the bus 90 is running, and (5) to (8) are fixed.
(1) Numbered ticket number
(2) Fare data corresponding to each ticket number
(3) Stop name
(4) Stop serial number
(5) System number
(6) Business name
(7) Office name
(8) Vehicle number

At the first stop, BSa, the ticket number in (1) is "4" and the fare data in (2) is only 200 yen, which corresponds to ticket number 4. Further, the stop name in (3) is, for example, "ABC Station", and the stop serial number in (4) is, for example, "0". Each of these pieces of information is changed for each stop BS. On the other hand, each information (5) to (8) is information that does not change even if the stop BS advances. For example, the system number in (5) is "01", the business name in (6) is "XYZ Transportation", the office name in (7) is "○×△ office", and the vehicle number in (8) is " 123'' etc. In this embodiment, each of these pieces of information is stored, for example, in the memory of a data cassette connected to the host device 40, and is read from there to obtain each piece of information (1) to (8) above. (See Figure 3).

In the next step S105, processing for transmitting first train stop information, etc. is performed. At the first stop BSa before the start of service, when the on-board equipment such as the fare display is turned on, the fare display and in-board public address system will notify the bus even if the stop sending signal 17 is not output from the push button. Guidance information such as system number and destination of 90 is automatically provided, and predetermined control processing of fare boxes and the like is also started. Therefore, the host device 40 also generates and sends stop information ISa such as the first stop BSa to the boarding display terminal 20 and the getting off display terminal 30 (see FIG. 11).

In addition to each of the information in (1) to (8) above, the display update date and time in (9) is added to the first train stop information, etc. ISa that is sent out. That is, the host device 40 generates the stop information ISa by adding the time information of the year, month, day, hour, minute, and second immediately before transmitting the stop information ISa as the display update date and time in (9). For example, add binary data representing 17:46 on September 25, 2019. In this embodiment, the stop information ISa is, for example, the above (1), (2), (4), (5), (8), (9) as binary data, (3), (6), ( 7) is generated as a text data representation. Note that all of these (1) to (9) may be generated as text data.

As a result, the boarding display terminal 20 and the disembarking display terminal 30 can obtain stop information, etc. ISa (S203) by the code output process 200 shown in FIG. 5, as described below, and output the two-dimensional code DC, etc. to the display unit 23, 33 (S213, S215, S217). The contents of the code output process 200 executed by the control units 21, 31 of these display terminals 20, 30 will be described in detail later.

In the next step S107, a stop transfer information acquisition process is performed. As described above, the stop sending information is information obtained from the stop sending signal 17 that is output every time the crew member (driver) operates an unillustrated push button. The presence or absence of input of this stop sending information can be obtained by, for example, the presence or absence of predetermined interrupt processing or the on/off of a predetermined flag. If the stop transfer information is obtained, the crew member has given an instruction to proceed with the control of on-board equipment such as the fare display, in-car public address system, and fare box in accordance with the next stop.

Therefore, in the subsequent step S109, it is determined whether or not the stop sending information has been acquired, and if it has been acquired (S109; Yes), the process advances to the next step S111, and it cannot be determined that the stop sending information has been acquired. If (not acquired) (S109; No), the process returns to step S107 and the stop sending information acquisition process is performed again. That is, steps S107 and S109 are repeated until the stop sending information is acquired.

In step S111, next stop information etc. reading processing is performed. In this process, the next stop information etc. described in (1) to (8) above are read out from the data cassette of the host device 40 as information regarding the next stop BSb. If the read next stop information, etc. is not the information in (1) to (8) above, but is end information indicating that the next stop does not exist, the determination process in step S113 determines that there is no next stop. In other words, it is determined that the previous stop is the final stop (S113; Yes), and the present stop information etc. sending process 100 is ended.

If the next stop information etc. read in step S111 is each of the information (1) to (8) above, it is determined that the next stop BSb exists (S113; No), and the process moves to the subsequent step S115. In step S115, a process for transmitting stop information, etc. is performed. This process, similar to the above-mentioned first stop information etc. sending process (S105), adds the (9) display update date and time information immediately before sending to generate the stop information etc. ISb and displays it on the boarding display terminal 20 and getting off. It is sent to the terminal 30.

The ISb such as the stop information sent here is changed in the above (1) to (4) and (9). For example, in the case of the triangular fare table data shown in Figure 3, the stop information ISb for stop BSb is such that the ticket number in (1) is "3" and the fare data in (2) corresponds to ticket number 3. 200 yen and 200 yen corresponding to numbered ticket number 4. The name of the stop in (3) will be changed to ``○×△1-chome,'' and the serial number of the stop in (4) will be changed to ``1.'' Furthermore, the display update date and time in (9) is changed to, for example, September 25, 2019, 17:52.

When the process of sending bus stop information, etc. in step S115 is completed, the process returns to step S107 and the process of acquiring bus stop sending information is performed. Then, each time bus stop sending information is acquired (S107, S109: Yes), the next stop information, etc. is read (S111), and bus stop information, etc. IS is generated and sent to the boarding display terminal 20 and the disembarking display terminal 30 (S115). This makes it possible for the boarding display terminal 20 and the disembarking display terminal 30 to display on the display units 23 and 33 different two-dimensional codes DCa, DCb, ..., DCd for each bus stop BSa, BSb, ..., BSd (see Figure 11).

[Code output processing 200]
Next, the code output process 200 executed by the boarding display terminal 20 and the disembarking display terminal 30 will be explained. These display terminals 20 and 30 also have a code output program stored in the memory of the control units 21 and 31, as described above. Therefore, when power is turned on to the display terminals 20, 30 together with the host device 40 before the bus 90 starts operating, the MPUs of the control units 21, 31 execute the code output program that is loaded into the DRAM of the memory immediately after. By doing so, the code output processing 200 shown in FIG. 5 is started. Note that the MPU may be configured to directly execute a code output program stored in the ROM instead of the one developed in the DRAM.

In the code output processing 200 executed by the boarding display terminal 20 and the getting off display terminal 30, since the information processing is performed in the same way on both of these display terminals 20 and 30, the code output processing 200 of the boarding display terminal 20 will be explained here. I will represent and explain. In the case of the exit display terminal 30, the control unit 21 is replaced with the control unit 31, the display unit 23 is replaced with the display unit 33, the boarding door of the boarding entrance 91 is replaced with the boarding door of the boarding gate 93, and the boarding door is opened. The process can be understood by replacing the door signal with the exit door opening signal.

As shown in FIG. 5, in the code output process 200, a predetermined initialization process is first performed in step S201. In this process, for example, the work area of the memory (DRAM or SRAM) of the control unit 21, timer counters, and flags are cleared, and the initialization is performed based on a control command sent from the host device 40 that is started at approximately the same time. Settings etc. are performed.

In the next step S203, stop information etc. acquisition processing is performed. As described above, the host device 40 before the start of operation after the power is turned on sends out the stop information ISa such as the first stop BSa (see FIG. 11), so in this process, the information stored in the input buffer of the control unit 21 is Obtain ISa such as stop information. If it has been acquired (S205; Yes), encoding processing is performed in the subsequent step S207, and if it has not been acquired (S205; No), steps S203 and S205 are repeated until it is acquired.

In the encoding process of step S207, the two-dimensional code DC is generated after encrypting the stop information ISa acquired in step S203. In this embodiment, IS such as stop information is not directly converted into a two-dimensional code, but is encrypted and converted into a two-dimensional code DC, making it possible to prevent the two-dimensional code DC from being generated illegally. ing.

In this embodiment, the two-dimensional code DC is, for example, a QR code. Note that QR code is a registered trademark (the same applies below). In this embodiment, the bus stop information ISa is, for example, the following information (1) to (9), of which (1), (2), (4), (5), (8), and (9) are represented as binary data, and (3), (6), and (7) are represented as text data and are not encrypted (plain data). Note that all of these (1) to (9) may be generated as text data.
(1) Ticket number
(2) Fare data corresponding to each ticket number
(3) Bus stop name
(4) Bus stop serial number
(5) Route number
(6) Name of business operator
(7) Name of business office
(8) Vehicle number
(9) Display update date and time

Therefore, in step S207, such plaintext data is encrypted with a predetermined encryption key and converted (encrypted) into cryptographic data, and then image information of the two-dimensional code DC is generated. In this embodiment, the encryption key is a common key, and for example, the encryption key is written into the memory (ROM or SRAM) of the control unit 21 when the ride display terminal 20 is manufactured. In this embodiment, the two-dimensional code DC is, for example, a type 1 (model number 1) QR code with a size of 21 x 21 modules, but if the data capacity is insufficient, it may be a type 2 (model number 1) with a size of 25 x 25 modules. A QR code of type 2) or a QR code of type 3 (model number 3) or higher may be used.

In the next step S209, a door-opening signal acquisition process is performed. In this embodiment, when the boarding door of the boarding entrance 91 is opened, a boarding door-opening signal is sent from another in-vehicle device (not shown) to the boarding display terminal 20 via the wired communication line 15. The presence or absence of a boarding door-opening signal can be obtained, for example, by the presence or absence of a predetermined interrupt process or the on/off state of a predetermined flag, so in this process, information on the boarding door-opening signal (door-opening information) is obtained by the presence or absence of a predetermined interrupt process or the state of the flag. Then, if it is determined that a boarding door-opening signal has been acquired (S211; Yes), image information of the two-dimensional code DC is output to the display unit 23 by the code output start process in the next step S213.

If it is determined that the boarding door opening signal has not been acquired (S211; No), steps S209 and S211 are repeated until the boarding door opening signal is acquired. In this embodiment, the code output start process in step S213 is performed for a predetermined period of time after the boarding door opening signal is acquired (S211; Yes) and after the boarding door opening signal cannot be acquired (S215; No). The process continues until a period of time (for example, 30 seconds or 1 minute, etc.) has elapsed (S216; No). Thereby, the two-dimensional code DC is displayed on the boarding display terminal 20 and the disembarking display terminal 30 while the boarding door is open and until a predetermined time (for example, 30 seconds) has elapsed after the boarding door is closed. Therefore, a user who gets on the train just before the door closes or a user who forgets to get the two-dimensional code DC when getting on the vehicle and immediately realizes it can also get the two-dimensional code DC. Further, while the bus 90 is running, the two-dimensional code DC is not displayed on the boarding display terminal 20 or the alighting display terminal 30, so it is possible to prevent unauthorized acquisition of the two-dimensional code DC.

That is, based on the value of the timer counter that starts counting immediately after it is determined that the boarding door opening signal cannot be acquired (S215; No) in the door opening signal acquisition process (S214) executed during the door opening period, In step S216, it is determined whether a predetermined time has elapsed. If it is determined that the predetermined time has elapsed (S216; Yes), the output of the image information of the two-dimensional code DC to the display unit 23 is ended by the code output end process in the subsequent step S217, and the above-mentioned stop information etc. acquisition process is performed. The process returns to (S203).

As a result, as shown in FIG. 11, for example, when the boarding door opens at the first stop BSa (door opening →), the boarding display terminal 20 starts displaying the two-dimensional code DCa on the display unit 23 at that timing. The display ends after a predetermined period of time has elapsed since the boarding door was closed (closed door→). Also, at the next stop BSb, when the boarding door opens (open door →), the boarding display terminal 20 starts displaying the two-dimensional code DCb, and after the boarding door closes (closed door →), the two-dimensional code DCb is displayed after a predetermined period of time has elapsed. When the exit door is opened (open →), the exit display terminal 30 starts displaying the two-dimensional code DCb and ends the display after a predetermined time has elapsed.

Similarly, at bus stop BSd, when the boarding door opens (door open →), the boarding display terminal 20 starts displaying the two-dimensional code DCd, and when the alighting door opens (door open →), the alighting display terminal 30 starts displaying the two-dimensional code DCd. Then, after each door closes (door closed →), when a predetermined time has elapsed, the display units 23 and 33 stop displaying the two-dimensional code DCd.

Therefore, while the bus 90 is running, the two-dimensional code DC is not displayed on the boarding display terminal 20 or the alighting display terminal 30. Therefore, for example, when boarding the bus, the two-dimensional code DCb displayed on the boarding display terminal 20 is displayed on the smartphone 50. It is possible to prevent unauthorized acquisition of the two-dimensional code DC, such as acquiring the two-dimensional code DCd displayed after the two-dimensional code DCb in response to another stop after boarding the vehicle without acquiring the two-dimensional code DC. Become.

[Fare settlement processing 300]
Next, the fare settlement process 300 executed by the smartphone 50 will be explained. Note that here, a fare settlement application that can execute the fare settlement process 300 is installed on the smartphone 50, and user M's personal information and payment information such as credit card are registered in the management server 60 and payment server 70. It is assumed that there is.

As shown in FIG. 11, before boarding the bus 90, the user M operates the smartphone 50 to start the fare adjustment application. Thereby, the control unit 51 of the smartphone 50 starts the fare settlement process 300 shown in FIG.

As shown in FIG. 6, in the fare settlement process 300, a predetermined initialization process is first performed in step S301. In this process, for example, the work area and flags for this process in the memory (DRAM) of the control unit 51 are cleared. In the next step S303, a selection menu display process is performed.

In this embodiment, for example, a selection menu screen as shown in FIG. 12(A) is displayed on the display unit 53 of the smartphone 50 (S303). On the screen of the display unit 53, buttons such as "get on", "get off", "end", and "help" are displayed, and the user M selects each function by touching these buttons.

For example, "Board" is a button that selects a function to obtain the two-dimensional code DC displayed on the boarding display terminal 20 at the boarding entrance 91, and is configured to be selectable only before user M selects the "Disembark" button. Typically, user M selects this before boarding the bus 90. Also, "Disembark" is a button that selects a function to obtain the two-dimensional code DC displayed on the disembarking display terminal 30 at the disembarking entrance 93, and is configured to be selectable only after user M selects the "Board" button. Typically, user M selects this before boarding the bus 90.

"Help" is a button that user M selects when he/she wishes to know how to use the fare adjustment app. "Exit" is a button that user M selects when he/she wishes to terminate the fare adjustment app. The "Help" button and "Exit" button can be selected at any time as long as the selection menu screen is displayed. Although not shown, in this embodiment, unselectable buttons are displayed in a weak (pale) color to indicate that they cannot be visually selected.

Although not shown, if the fare payment app has a "Usage History" button that allows you to display and check your usage history, or a function that can only be used for a predetermined period such as a free pass or commuter pass, etc. On the selection menu screen of the smartphone 50, an "expiration date" button or the like is displayed that allows you to display and check the expiration date.

In step S305, it is determined whether or not there is a selection input by user M, and the process waits until there is an input (S305; No). When there is a selection input, if the selection is "Ride" (S305; Yes: Ride), the process moves to the following step S307, and if it is "End" (S305; Yes: End). , completes the fare adjustment process 300 and exits the fare adjustment application.

Note that since user M cannot select the "get off" button before selecting the "get on" button in the fare adjustment application, the input determination of the "get off" button is not performed in step S305. Furthermore, when the "Help" button is selected and input, a help screen or the like is displayed in another task (thread, program), not shown.

If the selection input by user M is "ride", code acquisition processing is performed in the subsequent step S307. The flow of this process is shown in FIG. 7 as a subroutine, so the description will be made with reference to FIG. 7 from here on.

[Code Acquisition Process 400]
7, in the code acquisition process 400, a predetermined initialization process is performed in step S401 to clear a work area and flags used for decoding, and then a two-dimensional code DC is acquired in a code information acquisition process in step S403. In this embodiment, the two-dimensional code DC is acquired by taking an image of the two-dimensional code DC with the camera 55.

In this process, for example, as shown in FIG. 12(B), by clearly indicating the position and range of the subject using a guide frame whose four corners are surrounded by "", the two-dimensional code DC is placed within this guide frame. The operation of the smartphone 50 by the user M is guided. The camera 55 of the smartphone 50 has an automatic adjustment function that appropriately sets focal length, exposure, shutter speed, and shutter timing. Therefore, when the entire two-dimensional code DC falls within the guide frame, the camera 55 automatically takes a picture.

As described above, the two-dimensional code DCa continues to be displayed on the boarding display terminal 20 at the boarding entrance 91 for a predetermined period (for example, 30 seconds) even after the boarding door of the bus 90 is opened and closed. Therefore, the user M photographs the two-dimensional code DCa with the camera 55 of the smartphone 50 when boarding the vehicle from the boarding gate 91. The two-dimensional code DCa photographed when boarding the vehicle (at the time of boarding) is stored in the work area of the memory of the control unit 51 as boarding stop information (see FIG. 11).

If the two-dimensional code DC has been photographed, it is determined that the two-dimensional code DC has been acquired through the determination process in step S405 (S405; Yes), and the decoding process in the next step S407 is performed. If the two-dimensional code DC cannot be photographed (S405; No), the code information acquisition process (S403) is performed until the two-dimensional code DC can be photographed. Note that, if the two-dimensional code DC cannot be photographed even after a predetermined period of time has elapsed, the process flow is configured such that the main code acquisition process 400 is forcibly terminated and the process returns to the selection menu display process (S303). It's okay.

In step S407, the acquired two-dimensional code DC is decoded. In this embodiment, since the two-dimensional code DC is a QR code, it is analyzed according to a predetermined algorithm, and the acquired encrypted data is decrypted with a predetermined encryption key to return it to plain text data. This encryption key is a common key, and is acquired by the smartphone 50 when the fare adjustment app is downloaded from the website and installed. The plain text data includes the above-mentioned information (1) to (9) as the bus stop information, etc. IS. In other words, the bus stop information, etc. IS is extracted from the two-dimensional code DC. Note that in order to increase security, it is desirable to update (download) the encryption key not only during the initial installation, but also periodically.

In the next step S409, processing for storing stop information, etc. is performed. In this process, IS (boarding stop information) such as decoded and extracted stop information is stored in the work area of the memory of the control unit 51. In the following step S411, mode information acquisition processing is performed. In this process, operation mode information of the wireless unit 52 of the smartphone 50 is acquired, and based on the acquired operation mode information, it is determined in step S413 whether or not the in-flight mode, which is not available, is set.

If the smartphone 50 is set to the airplane mode in which the wireless unit 52 cannot be used, that is, not to communicate information via the wireless communication line (S413; Yes), the IS such as the stop information is transferred to the management server 60. Since it is not possible to send the message to the destination, an airplane mode display process is performed in step S415. In this process, for example, a message "Please cancel airplane mode" as shown in FIG. The background color of this message is set to red, and the text color is set to white or yellow, for example. This makes it possible to display a message that can have a color impact on the user M.

In the example of the screen shown in FIG. 13(A), "ABC Station" is displayed as the name of the stop at which the train boarded, and "4" is also displayed as the ticket number. This is information such as (1) the numbered ticket number and (3) the stop name among the information obtained from ISa such as the stop information decoded in step S407. In addition, the fare data for (2) is "200 yen corresponding to numbered ticket number 4", the stop serial number for (4) is "0", the system number for (5) is "01", and the operator for (6) The name is "XYZ Transportation", the office name for (7) is "○×△ office", the vehicle number for (8) is "123", and the display update date and time for (9) is "September 25, 2019 17 46 minutes" is obtained.

The display of such a message in step S415 continues until the airplane mode is canceled (S413; Yes→S411). If the smartphone 50 is not originally set to airplane mode or if airplane mode is canceled (S413; No), wireless transmission processing is performed in step S417. This wireless transmission process is a transmission process to the management server 60, and the flow thereof is illustrated as a subroutine in FIG. 8, so the description will be made with reference to FIG. 8 from here on.

[Wireless transmission processing 500]
As shown in FIG. 8, in the wireless transmission processing 500, the work area used for the transmission buffer, retry counter, flag, etc. are cleared by a predetermined initialization processing in step S501, and then the transmission buffer set processing in step S503 is performed. be exposed. The transmission buffer is provided to make the data format (transmission format) wirelessly transmitted by the wireless unit 52 conform to a predetermined communication protocol. Therefore, in this process, IP address information of the management server 60 is set as destination information, and ISa such as IP address information and stop information of the smartphone 50 is set as source information in the transmission buffer.

In the next step S505, a transmission process is performed. As a result, the bus stop information ISa (boarding stop information) set in the transmission buffer is transmitted as transmission data TXa transmitted by the wireless unit 52, for example, to the nearest base station 80 (see FIG. 11). The transmission data TXa may be divided into multiple packet data and transmitted to the base station 80. When the base station 80 receives such transmission data TXa, it converts it into a specified data format and then transmits it to the management server 60 connected to the Internet N.

When the management server 60 receives the bus stop information ISa (boarding stop information) etc. as described below, it sends the reception result information back to the smartphone 50. Therefore, after the wireless unit 52 of the smartphone 50 sends the bus stop information ISa in step S505, it receives the reception result information RXa sent from the management server 60. Therefore, in the following step S507, it is determined whether the transmission is complete based on this reception result information RXa.

If the transmission is completed (S507; Yes), transmission completion information is set in the transmission result flag in step S508, the wireless transmission process 500 is ended, and the process returns to the code acquisition process 400 in FIG. On the other hand, if the transmission is not completed or the reception result information RXa cannot be received (S507; No), the retry counter is incremented (added) in step S509, and then the counter value, that is, the number of retries is set to the predetermined number of times ( For example, it is determined in step S511 whether or not the number of times exceeds three times.

If the number of retries does not exceed the predetermined number (S511; No), the transmission process in step S505 is repeated until the number of retries exceeds the predetermined number (S511; Yes) or the transmission is completed (S507; Yes). . If the number of retries exceeds the predetermined number (S511; Yes), the wireless transmission process 500 is terminated by setting transmission incomplete information in the transmission result flag in step S513, and the code acquisition process of FIG. The process returns to 400.

When the process returns to step S417 of the code acquisition process 400 in FIG. 7, the code acquisition process 400 is ended and the process returns to step S309 of the fare adjustment process 300 in FIG. In this embodiment, even if the transmission incomplete information is set in the transmission result flag, that is, even if ISa (boarding stop information) such as stop information cannot be transmitted to the management server 60, the Tolerate without rejecting. As a result, even if, for example, the radio wave conditions around the user M are using the smartphone 50 are not good and there is a communication failure in the wireless communication line 85, the user M can board the vehicle without any problems. can do.

Although not shown in FIG. 6, if the transmission incomplete information is set in the transmission result flag, for example, another task (thread, program), not shown, may send stop information to the management server 60. The process flow may be configured to perform a process (retransmission process) of retransmitting ISa (boarding stop information) multiple times. This makes it possible to send ISa such as stop information to the management server 60 after the user M gets on or off the bus, so that the user M can use the bus 90 (common vehicle) from where to where. It is possible to increase the rate of collection of information on the number of passengers (so-called OD data (Origin: origin, destination)) . It is also possible to prevent or suppress attempts to intentionally cause communication failures to ride for free.

[Continuation of Fare Settlement Processing 300]
6, after the code acquisition process in step S307 is completed, a selection menu display process is performed in step S309. The code acquisition process (S307) is executed when the user M acquires, with the smartphone 50, the two-dimensional code DC displayed on the boarding display terminal 20 at the boarding gate 91 when the user M boards the bus 90. Therefore, it is highly likely that the user M is on the bus 90 at the time when the code acquisition process (S307) is completed.

For this reason, in step S309, a selection menu display process is executed to clearly indicate to the user M that the two-dimensional code DC must be obtained using the smartphone 50 even when getting off the vehicle. For example, a selection menu screen such as that shown in FIG. 12(A) is displayed on the display unit 53 of the smartphone 50.

Here, user M has already acquired the two-dimensional code DC of the boarding display terminal 20 when boarding the bus 90, and therefore cannot select either the "Board" button or the "Exit" button. Therefore, user M is only allowed to select either the "Disembark" button or the "Help" button. If the "Help" button is selected and input, a help screen or the like is displayed in another task (thread, program) not shown. Note that instead of such a screen, for example, the "boarding date and time," "boarding stop name," "route name," etc. may be displayed on the display unit 53 of the smartphone 50. This makes it clear at a glance that the user has already boarded the bus.

If it is determined in the determination process of step S311 that the selection input by the user M is "getting off" (S311; Yes: getting off the vehicle), a code acquisition process is performed in the subsequent step S313. Since this process has already been explained with reference to FIG. 7, the explanation of the code acquisition process (S313) will be omitted here, and an outline of the process will be explained with reference to FIG.

For example, when the user M gets off at bus stop BSd, after the exit door of the bus 90 is opened and even after the exit door is closed, the exit display terminal 30 at the exit 93 is displayed for a predetermined period (for example, 30 seconds). The two-dimensional code DCd continues to be displayed. Therefore, the user M photographs the two-dimensional code DCd with the camera 55 of the smartphone 50 before getting off the vehicle from the exit 93 (or when getting off the vehicle) (S403). The photographed two-dimensional code DCd is stored as alighting stop information in the work area of the memory of the control unit 51, and then decoded to extract ISd (alighting stop information) such as stop information (S407).

The bus stop information ISd corresponds to the bus stop BSd. That is, for example, the following can be obtained: (1) the numbered ticket number is "2", (2) the fare data is "200 yen corresponding to numbered ticket number 2, 220 yen corresponding to numbered ticket number 3, and 220 yen corresponding to numbered ticket number 4", (3) the bus stop name is "XX Park North", (4) the bus stop serial number is "4", (5) the route number is "01", (6) the business operator name is "XYZ Transportation", (7) the business office name is "XX△ Business Office", (8) the vehicle number is "123", and (9) the display update date and time is "September 25, 2019, 18:03" (see FIG. 3).

If the smartphone 50 is in the airplane mode (S413; Yes), the airplane mode is displayed in a color that can give an impact to the user M on the screen of the display unit 53 of the smartphone 50, as shown in FIG. 13(B). A message asking you to cancel airplane mode will be displayed: ``Please cancel airplane mode.'' In the example of the screen shown in FIG. 13(B), in addition to the name of the stop "ABC Station" where the user boarded the vehicle, "○○ Koen Kita" in (3) above is displayed as the name of the stop where the user alights.

ISd (get-off stop information) such as stop information extracted from the two-dimensional code DCd is transmitted as transmission data TXb transmitted by the wireless unit 52 of the smartphone 50 to the nearest base station 80, and transmitted to the base station 80 and the Internet. It reaches the management server 60 via N. When the management server 60 receives ISd (get-off stop information) such as stop information, it sends the reception result information back to the smartphone 50. The wireless unit 52 of the smartphone 50 receives the reception result information RXb transmitted from the management server 60 after transmitting the ISd such as the stop information.

In this embodiment, even if ISd (alighting stop information) such as stop information cannot be transmitted to the management server 60, the payment processing that the user M plans to perform when getting off the train is not rejected but is allowed. As a result, even if, for example, the radio wave conditions around the user M using the smartphone 50 are not good and there is a communication failure in the wireless communication line 85, it is possible to process the payment for the user M without any delay. It can be done.

Although not shown in FIG. 6, in such a case, for example, the process flow may be configured so that in another task (thread, program) not shown in the figure, a process (resend process) is performed to resend bus stop information, etc. ISd (alight stop information) to the management server 60 multiple times. This makes it possible to transmit bus stop information, etc. ISd to the management server 60 after the user M has alighted, thereby increasing the OD data collection rate. It is also possible to intentionally cause communication failures to prevent or suppress attempts to ride without paying.

When the code acquisition process in step S313 is completed, the smartphone 50 of the user M stores ISa (boarding stop information) such as the stop information of the stop BSa where the user got on the train, and ISd (alighting stop information) such as the stop information of the stop BSd where the user gets off the train. is retained (memorized). Therefore, the usage fare acquisition process is performed in the next step S315. In this embodiment, the fare used includes, for example, (1) the ticket number included in the IS, such as the stop information of the stop BS where you got on the train, and (2) fare data included in the IS, such as the stop information of the stop BS where you got off. Find it by

In the example shown in FIG. 11, the smartphone 50 stores the numbered ticket number "4" in (1) as the stop information ISa (boarding stop information), and the fare data "4" in (2) as the stop information ISd (disembarking stop information). 200 yen corresponding to numbered ticket number 2, 220 yen corresponding to numbered ticket number 3, and 220 yen corresponding to numbered ticket number 4". Therefore, the fare data in (2) included in ISd (disembarking stop information) such as stop information is ``200 yen corresponding to numbered ticket number 2, 220 yen corresponding to numbered ticket number 3, and 220 yen corresponding to numbered ticket number 4. By selecting "220 yen" corresponding to numbered ticket number "4" in (1) of ISa (boarding stop information) such as stop information, the usage fare "220 yen" (usage fare information) will be (see Figure 14).

When user M's usage fare information is obtained in step S315, it is necessary to transmit the usage fare information and payment information to the payment server 70 in order to perform information processing regarding electronic payment in the payment server 70. Therefore, in the next step S317, the current fare information (usage fare information) and the payment information of user M are transmitted to the payment server 70 by wireless transmission processing. Note that the wireless transmission process has already been described with reference to FIG. 8, so the description of the wireless transmission process (S317) will be omitted here, and the outline of the process will be described with reference to FIG. 11.

User M's payment information (credit card information (name, card number, expiration date, security code, etc.)) is registered in the smartphone 50 when the fare adjustment app is initially set up (when secure information management is performed, the payment information is registered in the management server 60). Therefore, in the wireless transmission process 500, in addition to this payment information and fare information (220 yen in the previous example), the IP address information of the payment server 70 is set as destination information and the IP address information of the smartphone 50 as source information in the transmission buffer (S503), and then the data is transmitted as transmission data TXc to, for example, the nearest base station 80 (if the payment information is registered only in the management server 60, the smartphone 50 does not send the payment information, so the payment server 70 obtains the payment information from the management server 60).

When the payment server 70 receives usage fare information and the like as described later, it sends the reception result information back to the smartphone 50. In this embodiment, if the usage fare information etc. cannot be sent to the payment server 70, the payment processing by the payment server 70 is not completed, that is, the payment result flag is set to "payment not completed". The same process as in the case is performed in the process result notification process in step S323.

Further, the payment server 70 performs payment processing and transmits the result of the payment processing to the smartphone 50. Therefore, as shown in FIG. 6, in the fare adjustment process 300 using the smartphone 50, the payment result information RXc transmitted from the payment server 70 is received by the payment result receiving process in step S319. Then, after storing the received payment result information RXc in the memory (DRAM) of the control unit 51 in step S321, processing result notification processing is performed based on the payment result information RXc in step S323.

That is, if the payment process is completed by the fare payment process 700 by the payment server 70, the payment result flag set to payment complete is included in the payment result information RXc, indicating that the payment process is not completed. In this case, the payment result information RXc includes a payment result flag that is set to indicate that the payment has not been completed.

For this reason, in the processing result notification process of step S323, if the payment is completed based on the information of the payment result flag, a large and eye-catching blue "○" mark, the boarding stop name, the disembarking stop name, the numbered ticket number, and the fare are displayed on the screen of display unit 53 as shown in FIG. 15(A). The background color is set to light blue, for example. In this example, the boarding stop name [BOARD] ABC Station, the disembarking stop name [DISPLIT] XX Koen Kita, the numbered ticket number "4", the fare: 220 yen, and the message "Thank you" to convey gratitude are displayed on the screen of display unit 53.

In addition, when the payment is completed, in addition to the screen display by the display unit 53, a synthesized voice message such as "ping-dong" or "thank you for using the service" is uttered from the speaker of the smartphone 50. The processing result notification processing in step S323 may be configured to be outputtable. Note that even if the smartphone 50 is set to a manner mode or a silent mode in which the sound output is limited, this function is used to enable auditory notifications to the crew (driver) and the user M. Regardless of the settings of the smartphone 50, the processing result notification process in step S323 may be configured to forcibly output a message or the like using a synthesized voice.

On the other hand, if the payment is not completed based on the information of the payment result flag or if the usage fare information etc. cannot be sent to the payment server 70, the process shown in FIG. 15 ( As shown in A), although a large and conspicuous blue "○" mark, boarding stop name, alighting stop name, numbered ticket number, and usage fare are displayed on the screen of the display unit 53, the background color is set to, for example, yellow. At the same time, a warning message "Payment processing could not be completed" is displayed on the screen of the display unit 53 instead of the "Thank you" message. Further, the process result notification process in step S323 may be configured to allow audible output of a synthesized voice message saying "Payment processing failed" from the speaker of the smartphone 50. This makes it possible to notify the user M and the crew member (driver) that payment processing will be performed after the fact. Even in this case, the processing result notification process in step S323 may be configured to forcibly output a message or the like using synthesized voice.

The screen display of the display unit 53 shown in FIG. 15(B) is performed, for example, when there is a high probability of fraudulent use, and a large, conspicuous red "X" mark or a warning message saying "Use is restricted" is displayed on the screen of the display unit 53, or a message is output from the speaker of the smartphone 50 in a synthetic voice uttering "beep beep" or "Use is restricted." Even in such a case, the name of the boarding stop, the name of the disembarking stop, the numbered ticket number, and the fare are displayed on the screen of the display unit 53 so that the details of the use can be clearly indicated to the crew (driver) and the user M. Even in this case, a forced synthetic voice message, etc. may be displayed.

In addition, by managing the history data of unauthorized use for each user, for example, if the frequency of unauthorized use by a particular user is high, the use of the fare collection system 10 by that user is suspended (rejected). It becomes possible to take measures to Management of such history data of unauthorized use can be performed, for example, using IS such as stop information stored in the management server 60 and personal information associated therewith.

Furthermore, in this embodiment, the display update date and time of (9) above is embedded in the two-dimensional code DC. Therefore, based on time information Therefore, it becomes possible to determine whether or not the two-dimensional code DC is being used illegally from the difference between the two times (time difference).

For example, if the time information Originally, it should be new, but since the time relationship is reversed (old), it can be determined that there is a high probability that the two-dimensional code DC has been illegally generated or copied.

Furthermore, even if the time information X of the smartphone 50 is newer (larger) than the time information Y embedded in the two-dimensional code DC, if the difference (time difference) between the two times is greater than the predetermined time N, Since the time interval is large, it can be determined that there is a high probability that the two-dimensional code DC has been illegally generated or copied. In this case, the predetermined time N may be set to, for example, the time actually required for the bus 90 to travel between stops or a shorter time, or may be set to a time based on inter-stop travel time information held by a system that manages the bus schedule. It can be set to a variable time length in conjunction with the service schedule.

[Processing for recording bus stop information, etc. 600]
Next, the bus stop information recording process 600 executed by the management server 60 will be described. In the management server 60, a bus stop information recording program capable of executing the bus stop information recording process 600 is stored in a hard disk device or the like of a server computer serving as a control device. In the bus stop information recording process 600 executed in the server computer, a predetermined initialization process is first completed in step S601, and then a bus stop information receiving process is performed in step S603, in which the bus stop information IS transmitted as transmission data TXa, TXb from the smartphone 50 via the base station 80 or the Internet N is received.

Then, in step S605, it is determined whether or not IS such as stop information has been received, and if it has been received (S605; Yes), the process moves to the next step S607, and if it has not been received (S605 ;No), the process returns to step S603 again to perform the process of receiving stop information, etc. In step S607, a process of transmitting the reception result information to the smartphone 50 is performed. If the reception is successful, normal reception information will be sent, but if part of the IS, such as the received stop information, is missing or damaged, the abnormal reception information will be sent as it is not received normally. Send.

In the following step S609, a process (accumulation process) is performed to store and accumulate the normal IS such as stop information received in step S603 in the database device. When this process is finished, the process returns to step S603 to perform the process of receiving stop information, etc. This allows the management server 60 to sequentially store received IS such as stop information in the database device.

[Fare payment processing 700]
Next, the fare payment process 700 executed by the payment server 70 will be explained. In the payment server 70, a fare payment program capable of executing the fare payment process 700 is stored in a hard disk device or the like of a server computer serving as a control device. In the fare payment process 700 executed in the server computer, first a predetermined initialization process is performed in step S701, and once that is completed, the usage fare sent as transmission data TXc from the smartphone 50 via the base station 80 and the Internet N. The processing for receiving information and payment information (such as usage fare information) is performed in step S703 (if the payment information is registered only in the management server 60, the payment server 70 (obtained from the management server 60).

Then, it is determined in step S705 whether or not the usage fare information, etc. has been received, and if it has been received (S705; Yes), the process moves to the next step S707, and if it has not been received (S705 ;No), the process returns to step S703 to perform the process of receiving usage fare information, etc. In step S707, a process of transmitting the reception result information to the smartphone 50 is performed. If the reception is successful, normal reception information will be sent, but if part of the received fare information is missing or damaged, the abnormal reception information will be sent as it is not received normally. Send.

In the next step S709, a payment process is performed based on the fare information, etc. That is, in step S709, the fare for user M's use of bus 90 (in the example of FIG. 11, the fare is 220 yen) is collected by electronic payment. In other words, this is a fare collection process by electronic payment. User M's payment information is, for example, credit card information (user M's name, card number, expiration date, security code, etc.).

In the following step S711, it is determined whether the payment processing in step S709 has been completed. If there is no problem with the credit card information such as an error or expiration of the expiration date, the payment process is completed (S711; Yes), and the payment result flag is set to complete payment in step S713. On the other hand, if there is a problem with the credit card information, for example, the card number or security code is incorrect or the expiration date has passed, the payment process will not be completed (S711; No) and the step In step S715, the payment result flag is set to indicate that the payment has not been completed.

Then, in the next step S717, a process of transmitting payment result information, that is, a payment result flag, to the smartphone 50 is performed. If the payment process is completed, a payment result flag with payment complete set is sent, and if the payment process is not completed, a payment result flag is sent with payment incomplete set. When this process is finished, the process returns to step S703 to perform the process of receiving usage fare information, etc. This makes it possible for the payment server 70 to electronically pay the received usage fare information and the like one by one.

As described above, in the fare collection system 10 of this embodiment, the smartphone 50 acquires the two-dimensional code DCa output from the boarding display terminal 20 when the user M boards the bus, acquires the two-dimensional code DCd output from the disembarking display terminal 30 when the user M disembarks, and transmits to the payment server 70 the fare information regarding the fare obtained based on the bus stop information ISa decoded from the two-dimensional code DCa and the bus stop information ISd decoded from the two-dimensional code DCd. The payment server 70 then performs information processing regarding electronic payment based on the fare information transmitted from the smartphone 50 by the fare payment processing 700. The host device 40 is typically a control device that constitutes on-board equipment such as a fare box, a fare display, and an in-car broadcasting device that exist as existing equipment in the bus 90. The payment server 70 can also be an existing equipment. The smartphone 50 is owned by the user M of the bus 90.

Therefore, in configuring the fare collection system 10, the boarding display terminal 20 and the alighting display terminal 30 are newly required. Further, the information processing for obtaining usage fare information regarding the usage fare and the communication processing with the payment server 70 are performed by the smartphone 50 owned by the user M. As a result, the host device 40, the boarding display terminal 20, and the disembarking display terminal 30 mounted on the bus 90 do not need to perform information processing to obtain usage fare information or perform communication processing with the payment server 70. There is no need to provide these host devices 40 and the like with a microcomputer with a high arithmetic processing capacity, a memory with a large storage capacity, or the like. There is also no increase in communication costs. Therefore, it is possible to suppress increases in equipment costs while enabling payment using digital tickets.

In addition, in the fare collection system 10 of this embodiment, the two-dimensional code DC output by the boarding display terminal 20 and the two-dimensional code DC output by the disembarking display terminal 30 are not only different for each bus stop, but also contain at least time information about the time when the two-dimensional code DC was output so that they change over time (display update date and time information in (9) above). Therefore, for example, even if the vehicle, route, and stop are the same, a different two-dimensional code DC will be generated if the date and time are different, making it extremely difficult to illegally generate or copy a two-dimensional code DC. Furthermore, by comparing this display update date and time information with the time information when these two-dimensional codes DC were obtained (obtained from the clock function of the smartphone 50), it is possible to determine whether or not a two-dimensional code DC has been obtained illegally.

For example, by determining whether the image data of the two-dimensional code DC captured by the camera 55 of the smartphone 50 was output from the boarding display terminal 20 or the disembarking display terminal 30 in the past before the time of boarding or disembarking, if the image data of the acquired two-dimensional code DC is from before the date of boarding or disembarking, there is a high probability that the image data of the old two-dimensional code DC that the user M prepared in advance was intentionally acquired by the smartphone 50, making it possible to determine whether such fraudulent acquisition has occurred.

In addition, in the fare collection system 10 of the present embodiment, the smartphone 50 transmits IS such as stop information obtained from the two-dimensional code DC to the management server 60 and payment server 70 provided outside the vehicle. 60 and 70, it becomes possible to accumulate information (so-called OD data) on how far the user M has used the bus 90. For example, the association between IS such as stop information and user M may be based on user M's personal information (user M's name, date of birth, gender, address, telephone number, occupation) registered in the smartphone 50 or management server 60. etc.) and the smartphone 50 is owned by the user M. This makes it possible to ascertain the number of users for each combination of origin and destination when using Bus 90, which can be used to improve transportation efficiency or provide related services, for example. It becomes possible to collect high OD data.

In addition, in the fare collection system 10 of this embodiment, if the smartphone 50 does not complete the transmission of the fare information to the payment server 70 or if the information processing related to the electronic payment cannot be performed, the background color of the screen of the smartphone 50 may be changed to, for example, yellow, or a warning message stating "Payment processing has not been completed" may be displayed on the screen. The processing result notification process of step S323 may be configured to output a synthetic voice message stating "Payment processing has not been completed" from the speaker of the smartphone 50. This makes it possible to inform the user M or the crew (driver) that the payment processing will be performed later, and the crew can know that the fare collection for the user M has not been completed, making it possible to appropriately handle the passenger, such as explaining to the user M that post-payment processing is required.

On the other hand, when the transmission of the fare information to the management server 60 is completed or when the information processing related to electronic payment can be performed, a large conspicuous blue "○" mark or "Thank you" will be displayed. A message is displayed on the screen of the smartphone 50 (FIG. 15(A)). Further, the process result notification process in step S323 may be configured to output a message using a synthesized voice such as "ping-dong" or "thank you for using the service" from the speaker of the smartphone 50. This allows the flight attendant to know that the fare has been collected for the user M, and therefore to understand that there is no need to explain the post-payment process, etc. to the user M. .

Further, in the fare collection system 10 of the present embodiment, when the smartphone 50 is set not to communicate information via the wireless communication line 85 when the user M gets off the train (for example, "in-flight" For example, if the background color is red and the text color is white or yellow) is displayed on the screen of the display unit 53 of the smartphone 50.

This makes it possible to display a message that can have a color impact on the user M. In addition, since the flight attendant is also set to "in-flight mode," the smartphone 50 is in a state where it is unable to send fare information to the payment server 70 or IS such as stop information to the management server 60. For example, it becomes possible to prompt the user M to cancel airplane mode. Therefore, it is possible to prevent incomplete transmission of fare information from the smartphone 50 to the payment server 70 due to the airplane mode.

In addition, in the fare collection system 10 of this embodiment, since the boarding display terminal 20 and the getting off display terminal 30 have the same hardware and software configuration, compared to a case where they have different hardware and software configurations, It becomes possible to suppress development costs, manufacturing costs, and maintenance costs. Additionally, mass production is expected to result in lower costs, which will further reduce product costs and make it possible to further reduce equipment installation costs.

Note that in Patent Document 1 (JP Patent Publication No. 2018-147270) mentioned in the [Prior Art Documents] section, in addition to the Type α automated ticket gate, a Type β automated ticket gate is also disclosed (Patent Document 1; paragraph 0020, etc.). This Type β automated ticket gate is configured to display a QR code, but automated ticket gates at railway stations are generally fixed inside the station.

For this reason, when using a type β automatic ticket gate, it is easy to obtain a relatively stable communication status with a smartphone or mobile phone, whereas when using a route bus, the smartphone or mobile phone cannot be used while the bus is running. They may be used in environments where communication conditions are unstable, as they may be moved along with traffic or moved to a stop in an area where infrastructure such as mobile base stations is not sufficiently established. In such a case, the payment server may become unable to make payments due to unstable communication conditions, and the present invention solves this problem with the above-described configuration.

In the embodiment described above, the display units 23 and 33 are provided in the boarding display terminal 20 and the disembarking display terminal 30 so that codes such as the two-dimensional code DC can be displayed, and the two-dimensional code DC is displayed by the camera 55 of the smartphone 50. It is possible to capture the two-dimensional code DC, etc. by taking images such as the following. However, the application of the present invention is not limited to this, and for example, instead of the display units 23 and 33 (or in addition to the display units 23 and 33), an RFID (Radio A wireless unit capable of near field communication (NFC) such as Frequency IDentification (IDentification) and its antenna may be provided.

As a result, a smartphone equipped with a short-range wireless communication function such as RFID can acquire the boarding stop information and the alighting stop information outputted from the boarding display terminal 20 and the alighting display terminal 30 by short-range wireless communication. This makes it possible to quickly acquire boarding stop information and alighting stop information compared to the case where the two-dimensional code DC is photographed and acquired using the camera 55 of the smartphone 50 or the like. Therefore, users M (passengers) are less likely to get stuck at the boarding gate 91 and the exit gate 93 of the bus 90, so boarding and alighting from the bus 90 becomes smoother even at times or at bus stops where there are many passengers. .

Further, in the above-described embodiment, the case where the fare triangular table data stored in the memory of the data cassette is used is exemplified and explained, but the application of the present invention is not limited to this, and for example, Fare triangular table data sent from in-vehicle equipment such as an in-vehicle broadcasting device via the wired communication line 15 may also be used.

Furthermore, in the embodiment described above, the case where the smartphone 50 obtains the time information X at the time when the two-dimensional code DC is obtained from the clock unit of the smartphone 50 is illustrated, but the application of the present invention is limited to this. For example, the smartphone 50 may be configured to obtain the time information X from the boarding display terminal 20 or the disembarking display terminal 30.

In addition, in the above-mentioned embodiment, the case where a QR code is used as a two-dimensional code was illustrated and explained, but the application of the present invention is not limited to this, and for example, as a matrix-type two-dimensional code, DataMatrix, VeriCode, Aztec or MaxCode may also be used. Furthermore, PDF471 or CODE49 may be used as a stacked two-dimensional code. Furthermore, if the amount of data to be encoded is small, a one-dimensional code such as a barcode may be used.

In addition, in the above-described embodiment, the two-dimensional code DC output from the boarding display terminal 20 and the two-dimensional code DC output from the disembarking display terminal 30 are codes with the same data content (the same code), but they may be configured to output codes with different data content (different codes). This increases the likelihood that fraudulent generation of a two-dimensional code DC will be discovered, making it possible to suppress fraudulent generation and duplication of two-dimensional codes DC.

Furthermore, in the embodiment described above, the boarding display terminal 20 and the disembarking display terminal 30 are configured with the same hardware and software, but they may be configured with different hardware and software. This makes it possible to respond to various customer needs.

Furthermore, in-vehicle equipment for buses having a display device capable of displaying the two-dimensional code DC may be used in place of the boarding display terminal 20 and the alighting display terminal 30. This eliminates the need to separately provide the boarding display terminal 20 and the disembarking display terminal 30, making it possible to further reduce the cost of introducing equipment.

Further, in the above-described embodiment, the case where the fare collection system of the present invention is applied to fare collection of the bus 90 (route bus) has been described as an example, but the application of the present invention is not limited to this. , as long as the system collects fares for shared vehicles, for example, it can also be applied to those that collect fares for shared vehicles such as streetcars, trolleybuses, and one-man operated railways, and in these cases. It is also possible to obtain the same effects and effects as when applied to route buses.

Although specific examples of the present invention have been described in detail above, these are merely illustrative and do not limit the scope of the claims. The techniques described in the claims include various modifications or changes to the specific examples described above. Further, the technical elements described in this specification or the drawings exhibit technical usefulness singly or in various combinations, and are not limited to the combinations described in the claims as filed. Furthermore, the techniques illustrated in this specification or the drawings simultaneously achieve a plurality of objectives, and achieving one of the objectives has technical utility in itself. Note that the descriptions in parentheses in the [Explanation of symbols] column can clarify the correspondence between the terms used in each of the embodiments described above and the terms described in the claims.

10...Fare collection system 20...Ride display terminal (ride information providing device)
30...Getting off display terminal (getting off information providing device)
40...Host device (control device)
50...Smartphone (portable information terminal device)
51...control unit
52...Wireless unit
53...Display unit 55... Camera
60...Management server
70...Payment server (payment server device)
80...Base station 85...Wireless communication line 90...Route bus (passenger vehicle)
91...Boarding entrance 93...Getting off exit 100...Stop information etc. sending process 200...Code output process 300...Fare payment process 400...Code acquisition process 500...Wireless transmission process 600...Stop information etc. recording process 700...Fare payment process BS, BSa , BSb, BSd...Stop DC, DCa, DCb, DCd...Two-dimensional code (boarding stop information, getting off stop information)
IS, ISa, ISb, ISd...Stop information, etc. (boarding stop information, getting off stop information)
M...User N...Internet TXa, TXb, TXc...Transmission data RXa, RXb...Reception result information

Claims (5)

A fare collection system that collects a fare for a shared vehicle from a user of the vehicle,
a boarding information providing device provided near a boarding entrance in the vehicle;
an alighting information providing device provided near the alighting entrance in the vehicle;
a control device that causes the boarding information providing device and the getting off information providing device to output stop information corresponding to the stop at which the vehicle stopped, which is different for each stop, each time the vehicle stops;
a payment server device installed outside the vehicle and processing information regarding electronic payment for collecting the usage fare;
a portable information terminal device that is carried by the user and is capable of acquiring the stop information output from the boarding information providing device and the getting off information providing device, and is capable of communicating information to the payment server device via a wireless communication line; , including;
The mobile information terminal device includes:
Obtaining the stop information at the time of boarding (hereinafter referred to as "boarding stop information" in claims 1 to 5) output from the boarding information providing device when the user boards the board;
acquiring the stop information at the time of alighting (hereinafter referred to as "alighting stop information" in claims 1 to 5) output from the alighting information providing device when the user alights;
Use fare information regarding the use fare obtained based on the numbered ticket number corresponding to the stop at the time of boarding included in the boarding stop information and the fare data corresponding to the numbered ticket number included in the alighting stop information. transmitting it to the payment server device;
The fare collection system is characterized in that the payment server device performs information processing regarding the electronic payment based on the usage fare information transmitted from the mobile information terminal device. The boarding stop information output from the boarding information providing device and the alighting stop information outputting from the boarding information providing device each change over time and include at least time information of an output time. The fare collection system according to claim 1, characterized in that: The boarding stop information output from the boarding information providing device and the getting off stop information output from the boarding information providing device are encrypted,
2. The portable information terminal device decrypts the encrypted boarding stop information and the alighting stop information using a predetermined encryption key to obtain the ticket number and the fare data. The fare collection system described in . The mobile information terminal device includes:
If the transmission of the fare information to the payment server device is not completed based on the alighting stop information and the boarding stop information, or if the information processing regarding the electronic payment cannot be performed, a predetermined Output uncompleted information to the crew of the vehicle in a manner that can be notified to the crew member of the vehicle,
Alternatively, when the transmission of the usage fare information to the payment server device is completed or when the information processing regarding the electronic payment can be performed, predetermined completion information is outputted so as to be notified to the crew of the vehicle. ,
The fare collection system according to any one of claims 1 to 3, characterized in that: If the mobile information terminal device is set not to communicate information via the wireless communication line when the user gets off the train, the mobile information terminal device transmits predetermined communication disabling information to the user. The fare collection system according to any one of claims 1 to 4, characterized in that the fare collection system is outputted so as to be able to notify the crew of the vehicle.

Images