In-vehicle communication system and vehicle information provision system

Abstract

To achieve both of the speed, quality, and rich content of a service and security against unauthorized access or the like by preventing connections and login from access sources that are not authorized.SOLUTION: An in-vehicle communication system mounted on a vehicle includes an information processing unit and a first communication unit for communicating between the information processing unit and the outside. The information processing unit receives schedule information for changing the address of the in-vehicle communication system via the first communication unit, transmits the received schedule information to a client device via a second communication unit that communicates using a protocol different from that of the first communication unit, and changes the address according to the received schedule information.SELECTED DRAWING: Figure 2

Description

Technical Field

[0001] The present invention relates to an in-vehicle communication system mounted on a vehicle such as an automobile and a vehicle information providing system using the same.

Background Art

[0002] Conventionally, there is a system for providing information of a vehicle such as an automobile to the outside of the vehicle. For example, Patent Document 1 describes a vehicle equipped with an embedded server supplied with power by a backup power source. According to Patent Document 1, the state data of the system can be accumulated by the embedded server and transmitted based on a request from outside the system.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the configuration of the vehicle described in Patent Document 1, the communication terminal accesses the embedded server to request the accumulated state data, and the embedded server transmits the state data to the requester in response to the request. At that time, information such as the device of the access source and the access code are registered in the embedded server in advance and collated, and after determining that it is a permitted access, the output of the state data is enabled. However, according to this configuration, although unauthorized access to the state data is restricted, it is difficult to restrict the connection to the embedded server. For example, when the access code (URL or global IP address) is known to a malicious third party, the embedded server of Patent Document 1 may be targeted by an attack from a malicious third party.

[0005] The present invention has been made in view of the above-described conventional examples, and an object thereof is to provide an in-vehicle communication system and a vehicle information providing system with improved safety.

Means for Solving the Problems

[0006] Therefore, the following configuration is proposed. According to one aspect of the present invention, there is provided an in-vehicle communication system (200) mounted on a vehicle (101), an information processing unit (201), a first communication unit (202) for communicating between the information processing unit and the outside, and a second communication unit for communicating between the information processing unit and the outside using a protocol different from that of the first communication unit, wherein the information processing unit (201) receives schedule information for changing the address for communication of the in-vehicle communication system (200) via the first communication unit (202), transmits the received schedule information to the client device (102), changes the address according to the received schedule information, and the information processing unit (201) transmits the received schedule information to the client device (102) via the second communication unit (204). An in-vehicle communication system is provided, which is characterized by the above.

[0007] According to another aspect of the present invention, there is provided a vehicle information providing system including the in-vehicle communication system (200) and a client device (102), wherein the client device (102) accesses the information processing device (201) using an address according to the schedule information received from the information processing unit (201) of the in-vehicle communication system (200) as a destination. A vehicle information providing system is provided, which is characterized by the above.

Effects of the Invention

[0008] According to the above configuration, for example, when the IP address of the server changes, a malicious third party will not be able to know the IP address of the target server. Also, if the transmission of schedule information to the client device is performed by P2P communication such as BT, the user of the vehicle can securely obtain the IP schedule information. Therefore, by preventing connections and logins from unauthorized access sources, it is possible to provide a more secure in-vehicle communication system and vehicle information providing system.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Mode for Carrying Out the Invention

[0010] Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. Note that the following embodiments do not limit the invention according to the claims, and not all combinations of the features described in the embodiments are essential for the invention. Two or more of the plurality of features described in the embodiments may be arbitrarily combined. Also, the same or similar configurations are given the same reference numerals, and duplicate descriptions are omitted.

[0011] [First Embodiment] ● Configuration of Vehicle Information Providing System FIG. 1 shows an example of the configuration of the vehicle information providing system of the present embodiment. In FIG. 1, solid arrows indicate HTTPS communication, broken arrows indicate manual input by the user, one-dot chain arrows indicate encrypted Bluetooth (BT) (registered trademark) communication, and dotted arrows indicate offline input, such as barcode reading. Also in the figure, BT is Bluetooth (registered trademark) communication, Conne is Connected, D Conne is Directly Connected, V Drive is Virtual Drive, App is Application, and IP is an abbreviation for Internet Protocol. The use of abbreviations is the same for other figures such as FIG. 12 other than FIG. 1. Here, Directly Connected is the name of a system or function including the vehicle and terminal according to the present embodiment. Also, Virtual Drive is a service or function that distributes information such as video from a camera mounted on a vehicle to a terminal in real time as described in the present embodiment.

[0012] In FIG. 1, the vehicle 101 is a battery EV or a plug-in hybrid EV capable of electric driving as shown in FIG. 12, and is equipped with a large-capacity storage battery that serves as the power source for the drive motor. The vehicle information system 200 provided in the vehicle 101 can operate with the electricity stepped down by a high-voltage DC / DC converter from this storage battery even when the ignition is off (power-off state) during parking. The vehicle 101 is equipped with an in-vehicle communication system 200 including a server 201, is connected to the outside through a wide-area communication network such as the Internet, and can further communicate with the owner terminal 102, the IP scheduler 103, and the guest terminal 104 through a communication network such as a wide-area communication network. Here, "outside" includes communication nodes such as servers not included in the in-vehicle communication system 200. The in-vehicle communication system 200 is connected to the wide-area communication network using TCP / IP. The vehicle 101, the owner terminal 102, the IP scheduler 103, and the guest terminal 104 may be connected to the wide-area communication network via a mobile communication network such as 4G (LTE) or 5G (NR). Also, the IP scheduler 103 may be provided by, for example, the manufacturer of the vehicle 101 or may be provided by the operator of the mobile communication network. Furthermore, the in-vehicle communication system 200 of the vehicle 101 has a peer-to-peer (P2P) communication function for directly communicating with the owner terminal 102 using a protocol different from TCP / IP. In this embodiment, since the communication partner by this P2P communication is assumed to be the owner terminal possessed by an occupant such as the owner of the vehicle riding in the vehicle 101, the P2P communication area may cover the entire vehicle 101 and may be limited. In addition, the in-vehicle communication system 200 of the vehicle 101 may be equipped with devices to be operated by direct connection, such as a GPS receiver, a mobile communication device, a microphone, a speaker, a camera, and a door lock device, as shown in FIG. 12. These devices are connected by a controller area network (CAN).

[0013] The owner terminal 102, the IP scheduler 103, and the guest terminal 104 may all be information processing devices, having a processor (CPU) and a memory, and performing processing by executing a program stored in the memory by the processor. Then, a predetermined function is realized by the processing. They also have a communication device for directly or indirectly connecting to a wide area communication network. The owner terminal 102 and the guest terminal 104 are user devices such as smartphones, for example, equipped with a user interface such as a touch panel, and a web browser is installed. Furthermore, an application program (also called an app) having a specific function can be additionally installed. In this embodiment, a direct connection app (also abbreviated as a D-connect app in the drawings) is installed. The user terminal 102 and the guest terminal 104 function as client devices that can access the server 201 of the in-vehicle communication system 200 to obtain information and play back the obtained information on the web browser through the user interface.

[0014] ●IP address scheduling The IP scheduler 103 in FIG. 1 creates an IP address schedule for changing the IP address of the wide area side port of the in-vehicle communication system 200 using a plurality of pre-reserved IP addresses (also referred to as an IP address pool). The IP address schedule may also be simply referred to as a schedule or schedule information. The IP addresses to be pooled are global IP addresses in this embodiment. The IP scheduler 103 transmits the created IP address schedule to the in-vehicle communication system 200 to cause the setting of the IP address according to the schedule. Also, the IP address schedule is transmitted from the in-vehicle communication system 200 to the owner terminal 102 and shared between the owner terminal 102 and the in-vehicle communication system 200. The owner terminal 102 and the in-vehicle communication system 200 change the IP address of the wide area side port of the in-vehicle communication system 200 in synchronization with each other according to the IP address schedule. That is, the in-vehicle communication system 200 changes the IP address of its own wide area side port, and the owner terminal 102 changes the IP address of the in-vehicle communication system 200 held as a destination.

[0015] The IP address schedule may be information that associates, for example, the time of IP address change and the IP address (the IP address after change) to be changed at that time of change. The time of IP address change may be regular or random. Even in the case of being random, the average interval from the time of change to the next time of change may be constant. Table 1 shows an example of an IPv4 IP address schedule. Note that actual numbers from 0 to 255 are assigned to abc.klm.xyz in Table 1. The operation by the IP scheduler 103 will be described in various sequences shown after FIG. 4. Also, the schedule may be a schedule for a predetermined period, for example, 30 days. Also, when using IPv6, an IPv6 IP address may be used instead of the IPv4 IP address.

[0016]

Table 1

[0017] In Table 1, the change time is specified up to the time, but only the date may be specified and the time may be determined in advance. Also, in the example of Table 1, a schedule for 30 days is set, but the schedule period may be determined as appropriate. Instead of determining the period, the number of times to change the IP address may be determined. For example, in accordance with the number of pooled IP addresses, a schedule may be generated to change the IP address the number of times corresponding to the number of those IP addresses. In this case, the interval for changing the IP address may be determined in advance. Further, only the IP address after the change may be determined, and the timing of the change may be determined in advance, for example, at a predetermined time every day. Also, the pooled IP addresses may be used repeatedly. Among the created schedules, one IP address may be used multiple times.

[0018] ● Configuration of In-vehicle Communication System FIG. 2 shows an example of the configuration of a vehicle communication system 200 mounted on a vehicle 101. A controller area network (CAN) 208 is connected to a group of devices 206 to be remotely operated via the CAN and an ECU / sensor group 207 including ECUs and sensors. Note that devices and sensors may also be connected to the CAN 208 via an ECU, and the device group 206 and the ECU / sensor group 207 also include those. Also, the device group 206 may include those controlled by the connected ECU. The device group includes various subsystems such as an air conditioner and a door lock, and the sensor group includes a sensor for detecting / estimating the state of charge (SoC) of the vehicle's battery and sensors for detecting the state of the vehicle such as its attitude, speed, and acceleration.

[0019] In addition to the other devices, user interface devices 205 such as in-vehicle and out-vehicle cameras, microphones, and speakers are also connected to CAN208. The in-vehicle camera and the out-vehicle camera are attached, for example, to the upper part of the front window of the vehicle 101, and photograph the in-vehicle and out-vehicle landscapes respectively. In particular, it is desirable that the in-vehicle camera be provided at a location where it is easy to photograph the faces of the front-seat and rear-seat passengers respectively. Also, the speaker may be required to be the speaker of an audio device such as a radio. The microphone may be provided at an appropriate location inside the vehicle, such as on the dashboard or the center of the ceiling, where it is easy to pick up the in-vehicle sound. Photographing and voice input may be performed according to an instruction from the server 201 or the like, and the photographed video and the input voice are recorded in the server 201.

[0020] ● Server Furthermore, a server 201 which is an information processing unit, a global navigation satellite system (GNSS) receiver 203 such as GPS, a mobile communication device 202 which is a communication unit, etc. are also connected to CAN208. Note that the server 201 and the mobile communication device 202 are not directly connected to CAN208, and may be connected to a local area network (LAN) connected via a gateway to CAN208. The server 201 and the mobile communication device 202 may be provided integrally. Also, the server 201 is provided with a P2P communication device 204 such as Bluetooth (registered trademark). Thereby, the server 201 can be connected to a wide area communication network via the mobile communication device 202, and can communicate with the owner terminal 102 via P2P communication. Note that the server 201 and the Bluetooth (registered trademark) chip 204 as the P2P communication device are provided integrally.

[0021] Note that in the configuration of FIG. 2, the mobile communication device 202 is connected to the communication interface of the server 201. The server 201 and the mobile communication device 202 may be configured integrally. For this reason in this example, in order to access the in-vehicle communication system 200 from the wide area communication network, the IP address of the wide area side port of the mobile communication device 202 is specified as the destination. That IP address is a global IP address in this embodiment, and is changed according to the IP address schedule.

[0022] Server 201 includes a web server (communications are secure encrypted communications over HTTPS) and responds to an HTTP request from the web browser of the owner terminal 102 or guest terminal 104 with the specified page. Also, sensor data (status information) indicating the state of the vehicle 101 obtained from the ECU / sensor group 207, as well as image data and video data obtained by in-vehicle / outside-vehicle cameras / microphones, are collected and stored in the server 201. The targets of the HTTP request may include video (moving images) and audio. In that case, when the server 201 transmits video or audio to the owner terminal 102 or guest terminal 104, the data transmitted by each terminal is played back.

[0023] Fig. 3 shows an example of the hardware configuration of the information processing apparatus. Each device is connected by a bus 307, and the CPU 301 executes a program stored in the memory 303 to obtain data from devices such as sensors connected via the CAN connector 305 and send data to devices such as actuators. Alternatively, information is received from a communication partner on a wide area communication network or a P2P connection via the communication interface 302, or information is transmitted to them. Further, the information input via the I / O interface 305 or the communication interface 302 is stored as a file or data on a DBMS (database management system) in the file storage 304. Furthermore, the information processing apparatus includes an operation unit 306 for realizing a user interface. The operation unit 306 of the server 201 is provided on the dashboard of the vehicle or the like, and the user can directly perform input / output operations on the server 201. Note that the hardware configurations of the owner terminal 102 and guest terminal 104 are also generally the same as that shown in Fig. 3.

[0024] ● Owner registration procedure From Figure 4 onwards, the procedure for the owner terminal 102 to receive information from the server 201 in the vehicle information providing system will be sequentially described. Note that in the owner terminal 102, the procedures described are realized when the direct connection app is executed. Therefore, when executing the procedures from Figure 4 onwards, the user needs to execute the direct connection app on the owner terminal 102. Also, each device operating in the sequence of Figures 4 to 10 performs the illustrated processing by the CPU included in each device executing a program. In Figures 4 to 10, the dashed arrows indicate manual operations by the user or the presentation of information to the user, the dash-dotted line indicates encrypted BT communication, and the solid arrows indicate HTTPS or CAN communication.

[0025] Figure 4 shows an example of a procedure / sequence diagram for registering the owner terminal 102 with the server 201. A user such as the owner of the vehicle unlocks the vehicle door (step 401, hereinafter steps are abbreviated as S) for owner registration with the server 201, gets in the vehicle (S402), and turns on the main power (S403). Thereafter, the user performs an owner registration operation in a predetermined procedure via the operation unit 306 provided in the vehicle (S404). In response, the server 201 requests an IP address schedule from the IP scheduler (S405). The IP scheduler 103 creates an IP address schedule in response (S406) and transmits the created IP address schedule to the server 201 (S407). If the server 201 receives the IP address schedule, it outputs to the operation unit 306 a notification of the success of owner registration, such as by display, to notify the owner (S408). Note that for initial communication, an initial value of the IP address is assigned to the communication port on the wide area communication network side of the mobile communication device, and the communication in steps S405 and S407 may be performed using this. Here, when referring to the IP address of the server 201, it refers to the IP address on the wide area communication network side of the mobile communication device 202.

[0026] After the owner registration is completed, the user performs a registration (pairing) operation for Bluetooth (registered trademark, hereinafter sometimes referred to as BT) communication through the owner terminal 102 (S409). Here, BT communication refers to encrypted BT communication. For this purpose, the P2P communication functions such as BT possessed by the owner terminal 102 and the server 201 are enabled. In response to that operation, the owner terminal 102 requests BT registration from the server 201 (S410). When the server 102 performs BT registration and it is successful, the server 102 sends a BT registration success response to the owner terminal 102 (S411). Before and after S410 and S411, the server 201 is displayed on the owner terminal 102 as a pairing partner. When the user selects it, an authentication code for pairing is displayed on the operation unit. When the code is input into the owner terminal 102, the registration is completed and communication via BT becomes effective. After that, the owner terminal 102 acquires an IP address schedule from the server 201 by the enabled BT communication (S412), and saves it in the storage area of the direct connection application, etc. (S413). The owner terminal 102 notifies the server 201 via BT communication that the saving of the IP address schedule has been completed (S414). The server 201 that has received it saves that it is shared with the owner terminal 102 together with the IP address schedule (S415). After the saving, the server 201 sends a message via BT communication to the owner terminal 102 that the preparation for the change according to the IP address schedule has been completed (S416). In response to that, the owner terminal 102 notifies the user by performing a screen display indicating that the preparation has been completed (S420).

[0027] Also, when the IP address schedule is saved in the owner terminal 102, the server 201 notifies the IP scheduler 103 of this as well (S417). In response, the IP scheduler 103 saves information indicating that the schedule has been shared between the server 201 and the owner terminal 102, in association with the created IP address schedule (S418). That is, the schedule created in step S406 etc. is finalized (for example, the created schedule is saved in the DBMS). The server 201 and the owner terminal 102 each change the IP address according to the IP address schedule (S419). In the server 201, the address on the wide area communication network side of the mobile communication device 202 is the target of change, and in the owner terminal 102, the address of the server 201 that is the information transmission destination is the target of change.

[0028] After that, when an operation to log in to the server 201 is performed on the owner terminal 102 using the direct connection application (S421), the owner terminal 102 sets the IP address of the server 201 according to the IP address schedule as the transmission destination (S422). Then, it transmits a login request to the server 201 with that address as the transmission destination (S423). When the login requested at the server 102 is successful, the response is transmitted to the owner terminal 102 (S424). When the owner terminal 102 receives a login success message, it displays the initial screen (S425).

[0029] Through the above procedure, communication using TCP / IP can be started between the owner terminal 102 and the server 201. Also, by changing the IP address of the server 201 according to the schedule and sharing it between the server 201 and the owner terminal 102, communication can be ensured and the security against unauthorized access to the server can be further improved.

[0030] ● Information provision procedure FIG. 5 shows an example of a procedure for referring to vehicle information or operating a vehicle subsystem by the direct connection application of the owner terminal 102. The vehicle information includes static vehicle information and dynamic vehicle information. Static vehicle information is vehicle information whose value basically does not change from when the user gets out of the vehicle until the next time the vehicle is driven. Examples of static vehicle information include the values of the ODO and trip meter, and the values of the fuel system. On the other hand, dynamic information is vehicle information whose value changes due to the passage of time, changes in the environment, etc. even when the vehicle is parked after the user gets out of the vehicle. That is, vehicle information that can change even when the vehicle is not in an operating state is dynamic vehicle information. Examples of dynamic vehicle information include the SoC of the battery, the temperature inside the vehicle, the states of various remotely operable subsystems such as locks and air conditioners. Depending on the type of vehicle information selected by the user interface of the owner terminal 102, either static vehicle information or dynamic vehicle information is referred to. It may also be configured such that the user can select and request either one from the user interface.

[0031] When the user designates the reference of vehicle information by the direct connection application of the owner terminal 102 and it is a static reference (S501), a request for static vehicle information is sent to the server 201 (S502). In response to the request, the server 201 reads the requested information held by the server 201 and transmits the requested vehicle information to the owner terminal 102 as a response (S503). The owner terminal 102 displays the received vehicle information in a format corresponding to the information (S504).

[0032] If the operation on one side is a dynamic reference (S505), the direct connection app requests dynamic vehicle information from the server 201 (S506). In response to the request, the server 201 refers to the information requested for the vehicle (S507), and accordingly, the vehicle 101 transmits vehicle information to the server 201 (S508). The server 201 saves the acquired information (S509). The vehicle information is transmitted to the owner terminal 102 as a response to the reference request in S506 (S510). If the information already saved when the server 201 updates the vehicle information, it is overwritten and saved with the newly acquired vehicle information in S509. In response to the reception of the vehicle information, the owner terminal 102 indicates that the operation is completed and displays the received information (S511).

[0033] If the operation performed by the user is an operation related to a remote operation involving an operation of the vehicle (S512), a remote operation is requested from the server 201 (S513). In response to the request, the server 201 instructs the vehicle to perform the requested operation (S514), and the vehicle performs the operation according to the instruction and transmits to the server 201 that the operation is completed (S515). In response to the notification of the completion of the operation, the server 201 updates the vehicle information (S516), and transmits to the owner terminal 102 that the operation is completed (S517). The owner terminal 102 displays information indicating that the operation is completed (S518).

[0034] Through the above procedures, the vehicle information can be referred to using the direct connection app of the owner terminal 102, and the vehicle can be remotely operated. The remote operation may target, for example, locking and unlocking of the vehicle doors, starting and stopping of the engine, starting and stopping of the air conditioner, opening and closing of the windows, etc.

[0035] ● Procedure for setting the IP address schedule FIG. 6 shows a process for updating the IP address schedule, which is executed when the server 201 and the owner terminal 102 hold the IP address schedule for a predetermined period. The procedure in FIG. 6 starts when the user starts the direct connection app on the owner terminal 102 and logs in to the server 201.

[0036] When the user (owner) performs a login operation on the owner terminal 102 (S601), the owner terminal 102 sets the IP address of the server 201 according to the IP schedule (S602), and attempts to log in to the server 201 according to the operation (S603). If the server 201 permits the login, it responds with a login success to the owner terminal 102 (S604). In response to the response, the owner terminal 102 displays the initial screen (S605).

[0037] The owner terminal 102 determines whether the IP address schedule for a predetermined period has been determined and retained. If it has been retained, the process ends as it is (S606-1). If the IP address schedule for the predetermined period has not been retained, it is determined that the IP address schedule needs to be updated (S606-2).

[0038] In that case, the owner terminal 102 sends an update request for the IP address schedule to the server 201 (S607). The target of the request only needs to be the part where the schedule is not yet determined. The update request is transferred from the server 201 to the IP scheduler 103 (S608). The IP scheduler 103 receives the request and generates the requested IP address schedule (S609), and sends it to the server 201 (S610). The server 201 sends the received IP address schedule to the owner terminal 102 (S611). On the owner terminal 102, the received IP address schedule and the currently retained IP address schedule are merged (or additionally) and saved (S612). Thereby, the IP address schedule is updated. When the saving is completed, the owner terminal 102 sends a notification indicating completion to the server 201 (S613). The server 201 that has received the completion notification merges and saves the IP address schedule in the same way as the owner terminal (S614), and further sends a saving completion notification to the IP scheduler 103 (S615). When the IP scheduler 103 receives the notification, it merges and saves the generated IP address schedule with the saved IP address schedule (S616).

[0039] By the above procedure, the IP address schedule is updated, and the updated IP address schedule is shared between the server 201 and the owner terminal 102. Then, the IP address of the server 201 is updated according to the updated IP address schedule, and for example, remote vehicle information reference, vehicle operation, etc. are performed according to the procedure of FIG. 5.

[0040] ● Procedure for Reacquiring IP Address FIG. 7 shows an example of the procedure for the server 201 and the owner terminal 102 to reacquire the IP address schedule. This procedure is executed, for example, when the user gets into the vehicle. The user, such as the owner of the vehicle, unlocks the vehicle door (S701), gets into the vehicle (S702), and turns on the main power (S703) for owner registration with the server 201.

[0041] Triggered by the main power of the vehicle being turned on, the server 201 determines whether the remaining period of the IP address schedule is less than or equal to a predetermined update period (S704). If it is determined that the remaining period is less than or equal to the update period and the direct connection app is not running, the server 201 displays a message on its operation unit 306 prompting the activation of the direct connection app (reacquisition of the IP address schedule), and also prompts the activation of the app audibly from the speaker 205 (S705). The user who receives the message activates the direct connection app on the owner terminal 102 (S706). The owner terminal 102 establishes a BT connection with the server 201 (S707) and transmits a completion response to the owner terminal 102 (S708).

[0042] Then, the server 201 sends an update request for the IP address schedule to the IP scheduler 103 (S709). The request only needs to target the undetermined part of the schedule. The IP scheduler 103 receives the request, generates the requested IP address schedule (S710), and sends it to the server 201 (S711). The server 201 sends the received IP address schedule to the owner terminal 102 via the BT connection (i.e., in BT communication) (S712). At the owner terminal 102, the received IP address schedule is merged with the currently held IP address schedule and saved (S713). Thereby, the IP address schedule is updated. When the saving is completed, the owner terminal 102 sends a completion indication notification to the server 201 via BT communication (S714). Upon receiving the completion notification, the server 201 merges and saves the IP address schedule in the same way as the owner terminal (S715), and further sends a saving completion notification to the IP scheduler 103 (S717). When the IP scheduler 103 receives the notification, it merges and saves the generated IP address schedule with the saved IP address schedule (S718). The server 201 sets the IP address of the server 201 according to the IP address schedule if necessary (S719), and outputs the completion of the re-acquisition of the IP address schedule to the operation unit 306 by voice or on the screen (S720).

[0043] The IP address schedule is also updated according to the procedure in FIG. 7, and the updated IP address schedule is shared between the server 201 and the owner terminal 102. Then, afterwards, the IP address of the server 201 is updated according to the advanced IP address schedule, and for example, remote vehicle information reference and vehicle operation are performed according to the procedure in FIG. 5. Thereby, the owner can seamlessly update the IP address in the ordinary lifestyle of using an automobile while carrying an owner terminal such as a smartphone.

[0044] ●Procedure for changing the IP address schedule FIG. 8 shows an example of a procedure for changing an IP address schedule. The change of the IP address schedule is executed in response to a user's operation, for example, when the user feels uneasy for some reason and wants to change the IP address schedule at any timing. In the procedure of FIG. 8, when the user (owner) performs a login operation on the owner terminal 102 (S801), the owner terminal 102 sets the IP address of the server 201 according to the IP schedule (S802), and attempts to log in to the server 201 according to the operation (S803). If the server 201 permits the login, it responds with a login success to the owner terminal 102 (S804). In response to the response, the owner terminal 102 displays an initial screen (S605). Next, the user performs a predetermined operation for changing the IP address schedule on the screen of the direct connection application of the owner terminal 102 (S806). In response, the owner terminal 102 sends a change request for the IP address schedule (hereinafter simply referred to as a change request) to the server 201 (S807). The server 201 that has received it sends the change request to the IP scheduler 103 (S808). The IP scheduler 103 receives the request and generates a new IP address schedule (S809), and sends it to the server 201 (S810). The generated IP address schedule may cover a predetermined holding period from the current time. The server 201 sends the received IP address schedule to the owner terminal 102 (S811). On the owner terminal 102, the currently held IP address schedule is overwritten and saved with the received IP address schedule (S812). Thereby, the IP address schedule is changed. When the saving is completed, the owner terminal 102 sends a notification indicating completion to the server 201 (S813). The server 201 that has received the completion notification overwrites and saves the IP address schedule in the same way as the owner terminal (S814), and further sends a notification of saving completion to the IP scheduler 103 (S816). When the IP scheduler 103 receives the notification, it overwrites and saves the IP address schedule saved with the generated IP address schedule (step 17).

[0045] On the other hand, the owner terminal 102 that has saved the changed IP address schedule notifies the user by displaying on the operation unit or the like that the schedule change has been completed (S815). As a result, on the owner terminal 102 and the server 201 that have shared the changed IP address schedule, the server 201 changes the IP address according to the new schedule (S818), and the owner terminal 102 changes the IP address according to the new schedule (S819).

[0046] By the above procedure, the IP address schedule can be changed according to the user's operation, and the changed IP address schedule can be shared between the server 201 and the owner terminal 102. Thereby, any uneasiness of the user due to some reason can be eliminated.

[0047] ● Procedure for issuing guest accounts FIG. 9 shows an example of a procedure for setting a guest account for a guest user other than the owner and newly registering the guest user in the server 201 to allow access. The procedure in FIG. 9 also starts with the direct connection application being activated on the owner terminal. The operation of the guest terminal 104 is also realized by the direct connection application installed and executed on the guest terminal 104.

[0048] First, the user directly operates through the operation unit 306 or the like to register a guest user with the server 201 (S901). Then, the server 201 performs guest user registration according to the operation and returns a response to the owner terminal 102 (S902). When the user who is the owner performs an operation to obtain a QR code (registered trademark) with the direct connection application (S903), the owner terminal 102 sends a QR code (registered trademark) acquisition request to the server 201 through P2P communication such as encrypted BT communication (S904). After receiving it, the server 201 encrypts the user information registered in S901 and S902 using the common key of the direct connection application, and generates a QR code (registered trademark) based on the information (S905). The generated code is also login data (guest user ID, initial password, etc.) used for guest user login, but it has an expiration date, and the server 201 rejects the first login by a guest user after the expiration date has passed. The server 201 sends the generated QR code (registered trademark) to the owner terminal 102 through BT communication (S906). The owner terminal 102 displays information indicating that it has received it (S907).

[0049] The owner terminal 102 that has obtained the user information of the guest user in the form of a QR code (registered trademark) in this way displays the obtained QR code (registered trademark) in response to the user's login operation (S909). On the other hand, the guest user performs a login operation for the guest user to log in on the guest terminal 104 (S908). The guest terminal 104 reads the QR code (registered trademark) displayed on the owner terminal 102 by the camera of the guest terminal 104 according to the operation (S910), and the guest terminal 104 receives the data of the read QR code (registered trademark) (S911). The guest terminal 104 decrypts the encrypted data in the QR code (registered trademark) using the common key of the direct connection application (S912).

[0050] The guest terminal 104 attempts to log in by sending the decrypted user information to the server 201 together with a login request (S913). If the login is successful, the server 201 sends a notification indicating successful login to the guest terminal 104 (step 14). Subsequently, the server 102 generates a password, a common key, a public key, and a private key for the guest user who logs in for the first time (S915), encrypts these generated data using the common key that the direct connection application has, and sends them to the guest terminal 104 (S916). The guest terminal 104 saves the received password, common key, and private key for subsequent use (S917). Thereafter, the data exchanged between the server 201 and the guest terminal 104 is encrypted by the common key generated in S915. Also, the password received here is used as the password (included in the user information) for subsequent logins. The guest terminal 104 sends a notification to the server 201 indicating that it has saved the received information (S918). Also, the guest terminal 104 displays an initial screen for the guest user (S919). The server 201 saves the password, public key, and common key excluding the private key among the data generated in S915 (S920).

[0051] Through the above procedure, a guest account can be assigned to the guest user, and user information for logging in can be provided to the guest terminal 104. From the guest terminal 104, it is possible to log in to the server 201 using the user information to obtain information, for example, to receive the virtual drive service executed in the procedure of FIG. 10.

[0052] Although the procedure of encrypted communication using the common key method was described in the procedure of FIG. 9, encrypted communication using the public key method may also be performed. Even in that case, encryption using the common key that the direct connection application has may be used up to step 12. Then, in step 15, a private key and a public key are generated, the private key is sent to the guest terminal 104, and it may be used to decrypt the data encrypted with the public key received from the server 201.

[0053] ● Procedure for issuing virtual drive tickets FIG. 10 shows an example of a procedure for issuing a virtual drive (referred to as a V drive in FIG. 10) ticket to a guest user. The guest terminal 104 of the guest user can receive and play back video and audio from the server 201 using the virtual drive ticket. Also, the guest terminal 104 can transmit video and audio to the server 201 and play it back through the display unit and speaker of the vehicle 101.

[0054] The user directly operates the server 201 to input a request for issuing a virtual drive ticket (S1001). This issuance request includes the guest user's username and the scheduled date of the virtual drive, etc., which are input by the user. The server 201 issues a virtual drive ticket in response to the request and registers the issued virtual drive ticket in the database (S1002). The registered virtual drive ticket is encrypted with the public key generated in S915 and saved in S920. The server 201 transmits the encrypted virtual drive ticket to the owner terminal 102 (S1003). The owner terminal 102 indicates that it has acquired the virtual drive ticket by display or the like (S1004). Here, the virtual drive ticket includes, in addition to the guest user's username and the scheduled date of the virtual drive, the IP address change schedule of the server 201 on the scheduled date of the virtual drive, the ID of the virtual drive ticket, etc., and is ticket information that does not include a password. The password is set to match the password in the guest terminal 104. When the scheduled date spans multiple days, the IP address change schedule for those multiple days is included. Note that if the scheduled date includes a date outside the period of the IP address change schedule, the server 201 may reject the issuance of the virtual drive ticket. In that case, the reason for the rejection is transmitted to the owner terminal 102 and the user is notified to that effect. Note that if it is possible to create the IP address change schedule for the scheduled date of the virtual drive by updating the IP address change schedule, it may branch to step 5 of FIG. 7. Thereby, using the updated IP address change schedule, the IP address change schedule on the scheduled date of the virtual drive can be included in the virtual drive ticket.

[0055] The owner terminal sends a virtual drive ticket to the guest terminal 104 according to the user's operation (S1005). This transmission may be performed, for example, by attaching it to a previous mail application, messenger application, etc. The guest terminal 104 receives the received virtual drive ticket, decrypts it with the private key received from the server 201 in S916 (S1006), and stores it (S1007). Then, it notifies the guest user by, for example, displaying on the screen that the virtual drive ticket has been received (S1008).

[0056] On the day of the virtual drive, the owner drives with the vehicle 101 (S1009). During that time, the scenery photographed by the in-vehicle camera and the out-vehicle camera is stored in the server 201, and the audio recorded by the microphone is also stored in the server 201 together with the video. The guest user performs an operation to participate in the virtual drive by operating, such as tapping the icon of the virtual drive ticket (S1010).

[0057] In response, the guest terminal 104 sends a login request to the server 201 and also sends a request to participate in the virtual drive (S1011). At this time, the IP address of the server 201 is set as the destination according to the IP address schedule.

[0058] The server 201 that has received the login request and the request to participate in the virtual drive sends a message waiting for permission to the guest terminal 104 (S1012), and also displays on its operation unit 306, etc., a message for confirming the guest's permission to participate in the virtual drive (S1013), and waits for permission. If the participation permission is input (S1014), the server 201 sends the participation permission to the guest terminal 104. Note that the message in step 12 may not be sent, and the guest terminal 104 may perform a display indicating waiting after the login request. At the same time, the server 201 starts providing the video and audio accumulated during driving, and they are played and output (S1015).

[0059] Also, from the guest terminal 104, according to the camera operation by the guest user (S1016), it is also possible to request a camera operation to the server 201 (S1017). The server 201 transmits a camera operation in response to the request (S1018, S1019). Also, by operating the emotion sensor (S1020), the acquired video or the like can be distributed to the guest terminal 104 for playback (S1021, 22). Here, the emotion sensor does not refer to a specific sensor. For example, when the vehicle in front opens (by the ADAS sensor), when an acceleration or deceleration above a threshold value is detected, when a laughing voice is detected, when the position of the vehicle specified by GNSS is a tourist spot, when the sun, sunset, or weather change is detected in the video, etc. It refers to the process of specifying such times. In such cases, the type of the detected event may be associated with the video and audio and saved.

[0060] FIG. 11 shows an example of a UI (user interface) and a video (image) displayed on the direct connection app of the guest terminal 104. Screen 1101 is an example of a video taken by an external camera. In this example, the scenery in front of the vehicle is displayed. Image 1102 is an example of a video taken by an in-company camera. Which one to display can be selected by the guest user by operating the guest terminal 104. Also, the guest user can operate the camera to adjust the shooting direction, zoom in, zoom out, etc. On any screen, a message "Virtual Drive" indicating that it is in the virtual drive, the name of the guest participating in the virtual drive "Guest A", and the name of the owner of the vehicle 101 "Owner" are displayed. Further, an operation section for operations such as fast-forwarding and rewinding the video is provided at the bottom of the screen. Also, an icon for selecting a camera is displayed in the lower left. The guest user can select a desired camera and display its video.

[0061] As described above, according to the vehicle communication system of the present embodiment, the server and the terminal can share the address for message transmission to the server, and moreover, the shared address can be changed according to the schedule. Thereby, the security of the server is improved. Also, since there is no need to register the address in the directory, it is possible to suppress the disclosure of the address to those other than those who attempt to access the server, and thus the security is improved in this regard. Furthermore, since the server is mounted on the vehicle, a shorter response time can be expected compared to the case of transmitting information to an external server and accessing it. Also, according to the vehicle information providing system using the in-vehicle communication system of the present embodiment, a guest user can receive the provision of video etc. by the vehicle and enjoy a virtual drive service as if driving together with the vehicle occupants.

[0062] ● Summary of the embodiment Summarizing the above embodiment, the following inventions are included.

[0063] (Item 1) An in-vehicle communication system (200) mounted on a vehicle (101), an information processing unit (201), a first communication unit (202) for communicating between the information processing unit and the outside, and a second communication unit for communicating between the information processing unit and the outside using a protocol different from that of the first communication unit, wherein the information processing unit (201) receives schedule information for changing the address for communication of the in-vehicle communication system (200) via the first communication unit (202), transmits the received schedule information to a client device (102), changes the address according to the received schedule information, and the information processing unit (201) transmits the received schedule information to the client device (102) via the second communication unit (204). An in-vehicle communication system characterized by the above. With the above configuration, by transmitting the schedule information to the client device via the second communication unit, the security of the in-vehicle communication system can be further improved.

[0064] (Item 2) The in-vehicle communication system (200) according to Item 1, wherein the information processing unit (201) periodically acquires the schedule information and transmits the schedule information to the client device (102). An in-vehicle communication system characterized by the above. With the above configuration, the schedule information shared by the client device and the information processing unit can be periodically updated, and the security of the in-vehicle communication system can be further improved.

[0065] (Item 3) The in-vehicle communication system (200) according to Item 1 or 2, wherein the information processing unit (201) acquires the schedule information and transmits the schedule information to the client device in response to a request from the client device (102). An in-vehicle communication system characterized by the above. With the above configuration, the schedule information shared by the client device and the information processing unit can be updated in response to a user's request, and the security of the in-vehicle communication system can be further improved.

[0066] (Item 4) The in-vehicle communication system (200) according to any one of Items 1 to 3, wherein when the power of the vehicle is turned on, if the remaining period of the schedule information is equal to or less than a predetermined period, the information processing unit (201) prompts the user to acquire the schedule information. An in-vehicle communication system characterized by the above. With the above configuration, the user can be prompted to update the schedule information at an appropriate timing, and the security of the in-vehicle communication system can be further improved. In addition, the owner can seamlessly update the IP address in their daily lifestyle of using the vehicle while carrying an owner terminal such as a smartphone.

[0067] (Item 5) The in-vehicle communication system (200) according to any one of Items 1 to 4, wherein the schedule information includes the time to change the address and the address after the change. An in-vehicle communication system characterized by this. With the above configuration, since it can be changed to the address set at the time set in the schedule, the security of the in-vehicle communication system can be further improved.

[0068] (Item 6) The in-vehicle communication system (200) according to any one of Items 1 to 5, wherein the first communication unit (202) communicates using TCP / IP, and the address is a global IP address. An in-vehicle communication system characterized by this. With the above configuration, communication via the Internet becomes possible, improving the convenience of communication.

[0069] (Item 7) The in-vehicle communication system (200) according to any one of Items 1 to 6, wherein the information processing unit (201) collects dynamic vehicle information that can change even when the vehicle (101) is not in an operating state, obtained from a sensor (207) of the vehicle. An in-vehicle communication system characterized by this. With the above configuration, it is possible to access vehicle sensor data from a client device, improving convenience.

[0070] (Item 8) The in-vehicle communication system (200) according to Item 8, Further includes a camera (205), and the information processing unit (201) collects image data captured by the camera (205). An in-vehicle communication system characterized by the above. With the above configuration, it is possible to access the video captured by the vehicle from the client device.

[0071] (Item 9) The in-vehicle communication system (200) according to any one of Items 1 to 8, The information processing unit (201) issues ticket information including the schedule information for accessing the information processing unit (201) to a second client device (104) different from the client device in response to a request from the client device (102). An in-vehicle communication system characterized by the above. With the above configuration, by issuing ticket information including schedule information, it is possible to access the in-vehicle communication system by the ticket issuer, and both security and convenience can be achieved.

[0072] (Item 10) The in-vehicle communication system (200) according to any one of Items 1 to 9, and A client device (102), including The client device (102) accesses the information processing unit (201) using the address according to the schedule information received from the information processing unit (201) of the in-vehicle communication system (200) as the destination. A vehicle information providing system characterized by the above. With the above configuration, the security of the in-vehicle communication system is improved, and access by the client device can be permitted.

[0073] (Item 11) The vehicle information providing system (200) according to Item 10, The vehicle information providing system further includes a scheduler device (103) that creates the schedule information and transmits the created schedule information to the information processing unit (201) of the in-vehicle communication system (200). A vehicle information providing system characterized by the above. With the above configuration, a schedule for changing the address can be created.

[0074] (Item 12) The in-vehicle communication system (200) according to Item 9, the client device (102), and the second client device (104), and when the second client device (104) receives the ticket information, it accesses the information processing unit (201) at the address according to the schedule information included in the ticket information. A vehicle information providing system characterized by the above. With the above configuration, by including schedule information in the ticket information and issuing it, access to the in-vehicle communication system by the second client device can be enabled, and both security and convenience can be achieved.

[0075] The present invention is not limited to the above embodiments, and various modifications and changes are possible within the scope of the gist of the invention.

Explanation of Reference Numerals

[0076] 101 Vehicle, 200 In-vehicle communication system, 102 Owner terminal, 103 IP scheduler, 104 Guest terminal

Claims

1. An in-vehicle communication system mounted on a vehicle, comprising: an information processing unit; a first communication unit for communicating between the information processing unit and the outside; a second communication unit for communicating between the information processing unit and the outside using a protocol different from that of the first communication unit; The information processing unit: receives schedule information for changing the address for communication of the in-vehicle communication system via the first communication unit; transmits the received schedule information to a client device; changes the address according to the received schedule information; The information processing unit transmits the received schedule information to the client device via the second communication unit. An in-vehicle communication system characterized by the above.

2. The in-vehicle communication system according to Claim 1, wherein: the information processing unit periodically acquires the schedule information and transmits the schedule information to the client device. An in-vehicle communication system characterized by the above.

3. The in-vehicle communication system according to Claim 1, wherein: the information processing unit acquires the schedule information and transmits the schedule information to the client device in response to a request from the client device. An in-vehicle communication system characterized by the above.

4. The in-vehicle communication system according to Claim 1, wherein: when the power of the vehicle is turned on, if the remaining period of the schedule information is equal to or less than a predetermined period, the information processing unit prompts the user to acquire the schedule information. An in-vehicle communication system characterized by the above.

5. The in-vehicle communication system according to Claim 1, wherein: the schedule information includes the time to change the address and the address after the change. An in-vehicle communication system characterized by the above.

6. The in-vehicle communication system according to Claim 1, wherein: the first communication unit communicates using TCP / IP, and the address is a global IP address. An in-vehicle communication system characterized by the above.

7. The in-vehicle communication system according to Claim 1, wherein: the information processing unit collects dynamic vehicle information that can change even when the vehicle is not in an operating state, acquired from sensors of the vehicle. An in-vehicle communication system characterized by the above.

8. The in-vehicle communication system according to Claim 7, further comprising: a camera, and the information processing unit collects image data captured by the camera. An in-vehicle communication system characterized by the above.

9. The in-vehicle communication system according to claim 1, wherein in response to a request from the client device, the information processing unit issues ticket information including the schedule information for accessing the information processing unit to a second client device different from the client device. The in-vehicle communication system is characterized by the above.

10. An in-vehicle communication system according to any one of claims 1 to 9, and a client device, wherein the client device accesses the information processing unit using an address according to the schedule information received from the information processing unit of the in-vehicle communication system as a destination. The vehicle information providing system is characterized by the above.

11. The vehicle information providing system according to claim 10, wherein the vehicle information providing system further includes a scheduler device that creates the schedule information and transmits the created schedule information to the information processing unit of the in-vehicle communication system. The vehicle information providing system is characterized by the above.

12. The in-vehicle communication system according to claim 9, and the client device, and the second client device, wherein when receiving the ticket information, the second client device accesses the information processing unit using an address according to the schedule information included in the ticket information. The vehicle information providing system is characterized by the above.

Images