Smart key system, on-vehicle device, smart key, and control method of smart key system

Abstract

To provide a smart key system, an on-vehicle device, a smart key, and a control method of the smart key system capable of preventing a vehicle door from being unlocked illegally.SOLUTION: A smart key system according to an aspect of the embodiment includes: an on-vehicle device mounted on a vehicle; and a smart key that can communicate with the on-vehicle device. The on-vehicle device unlocks a vehicle door when a key side authentication code included in an unlock signal sent from the smart key is identical to an on-vehicle side authentication code the on-vehicle device has. And, the on-vehicle device updates the on-vehicle side authentication code at timing based on door-lock. The smart key updates the key side authentication code at timing based on detection of user's intention getting on the vehicle.SELECTED DRAWING: Figure 1D

Description

[Technical Field]

[0001] The disclosed embodiments relate to a smart key system, an in-vehicle device, a smart key, and a control method for a smart key system. [Background technology]

[0002] Conventionally, smart key systems have been known that allow users to lock and unlock vehicle doors and start the vehicle without inserting the key into the vehicle cylinder (see, for example, Patent Document 1). The smart key constantly emits weak encrypted radio waves, and when the user approaches the vehicle within a predetermined distance, the smart key automatically recognizes the vehicle and the user. For example, when the user touches the vehicle door handle in this state, the vehicle door is unlocked. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 7308568 Summary of the Invention [Problem to be solved by the invention]

[0004] However, in recent years, a new method of crime known as a relay attack has emerged, in which a special process is used to illegally unlock the vehicle door even when the smart key is located more than a predetermined distance away from the vehicle.

[0005] A relay attack is a method in which a malicious third party receives and amplifies weak radio waves emitted by a smart key located far from the vehicle using a highly sensitive transceiver, and then relays and transmits them to the vehicle, simulating a situation in which the smart key is near the vehicle and fraudulently unlocking the door.

[0006] One aspect of the embodiment has been made in consideration of the above, and aims to provide a smart key system, an in-vehicle device, a smart key, and a control method for a smart key system that can prevent unauthorized unlocking of vehicle doors. [Means for solving the problem]

[0007] To solve the above problems and achieve the object, in one aspect of the embodiment, a smart key system includes an onboard device mounted in a vehicle and a smart key capable of communicating with the onboard device. The onboard device unlocks the vehicle doors when a key-side authentication code included in an unlocking signal transmitted from the smart key matches an onboard authentication code stored in the onboard device. The onboard device also updates the onboard authentication code based on locking of the doors. The smart key updates the key-side authentication code based on detection of a user's intention to enter the vehicle while the vehicle is parked. [Effects of the Invention]

[0008] In one aspect of the embodiment, the in-vehicle device updates the in-vehicle authentication code based on the timing of door locking. Meanwhile, the smart key updates the key authentication code based on the timing of detecting the user's intention to enter the vehicle while the vehicle is parked. As a result, the in-vehicle authentication code and the key authentication code do not match after the doors are locked until the user's intention to enter the vehicle is detected. Therefore, even if a relay attack is performed, for example, by amplifying weak radio waves emitted from a smart key located away from the vehicle and transmitting them to the vehicle, the vehicle doors will not be unlocked because the in-vehicle authentication code and the key authentication code will not match. This prevents unauthorized unlocking of the vehicle doors. [Brief explanation of the drawings]

[0009] [Figure 1A] FIG. 1A is a diagram showing an overview of a control method executed in a smart key system according to an embodiment. [Figure 1B] FIG. 1B is a diagram showing an overview of a control method executed in the smart key system according to the embodiment. [Figure 1C] FIG. 1C is a diagram illustrating an overview of a control method executed in the smart key system according to the embodiment. [Figure 1D] FIG. 1D is a diagram illustrating an overview of a control method executed in the smart key system according to the embodiment. [Figure 1E] FIG. 1E is a diagram illustrating an overview of a control method executed in the smart key system according to the embodiment. [Figure 2] FIG. 2 is a block diagram showing an example of the configuration of a smart key system according to the embodiment. [Figure 3] FIG. 3 is a block diagram showing an example of the configuration of a vehicle equipped with an in-vehicle device according to the embodiment. [Figure 4] FIG. 4 is an explanatory diagram showing an example of the vehicle-mounted side authentication information. [Figure 5] FIG. 5 is an explanatory diagram showing an example of a comparative vehicle-mounted authentication code. [Figure 6] FIG. 6 is a block diagram showing an example of the configuration of a smart key according to the embodiment. [Figure 7] FIG. 7 is an explanatory diagram illustrating an example of key-side authentication information. [Figure 8] FIG. 8 is an explanatory diagram showing an example of the comparison key side authentication code. [Figure 9] FIG. 9 is a block diagram illustrating an example of the configuration of a management device according to the embodiment. [Figure 10A] FIG. 10A is a diagram illustrating an example of a processing sequence executed by the smart key system according to the embodiment. [Figure 10B] FIG. 10B is a diagram illustrating an example of a processing sequence executed by the smart key system according to the embodiment. [Figure 11] FIG. 11 is an explanatory diagram showing an example of vehicle-side authentication information held by an in-vehicle device according to a modified example. [Figure 12]FIG. 12 is an explanatory diagram showing an example of a comparative in-vehicle authentication code possessed by an in-vehicle device according to a modified example. [Figure 13] FIG. 13 is an explanatory diagram showing an example of key-side authentication information held by a smart key according to a modified example. [Figure 14] FIG. 14 is an explanatory diagram showing an example of a comparison key-side authentication code possessed by a smart key according to a modified example. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments of a smart key system, an in-vehicle device, a smart key, and a control method for a smart key system disclosed herein will be described in detail with reference to the accompanying drawings. Note that the present invention is not limited to the embodiments described below.

[0011] [Embodiment] First, an outline of a control method executed in a smart key system according to an embodiment will be described below with reference to Figures 1A to 1E. Figures 1A to 1E are diagrams illustrating an outline of a control method executed in a smart key system according to an embodiment.

[0012] The smart key system 1 is a system that enables wireless communication between the in-vehicle device 10 and the smart key 50, thereby enabling the doors of vehicle A to be locked, unlocked, opened and closed, and the vehicle A to be started without inserting the key into the key cylinder of vehicle A.

[0013] 1A to 1E show, in chronological order, the control method executed by the smart key system 1. Specifically, FIG. 1A shows a scene in which vehicle A is parked. FIG. 1B shows a scene in which the doors of the parked vehicle A are locked, and FIG. 1C shows a scene in which user B takes the smart key 50 back to home C after locking the vehicle. FIG. 1D shows a scene in which user B takes the smart key 50 out of home C and an intention to get into vehicle A is detected, and FIG. 1E shows a scene in which the doors of vehicle A are unlocked using the smart key 50 that has been taken out.

[0014] As shown in FIG. 1A, the smart key system 1 according to this embodiment includes an in-vehicle device 10, a smart key 50, and a management device 100.

[0015] The in-vehicle device 10 is mounted on a vehicle A. The in-vehicle device 10 controls, for example, the doors of the vehicle A, a drive source 12 (see FIG. 3) of the vehicle A, etc. The detailed configuration of the in-vehicle device 10 will be described later with reference to FIG. 3.

[0016] The smart key 50 is carried by a user B of the vehicle A. The smart key 50 and the in-vehicle device 10 are connected via wireless communication. The smart key 50 includes an operation unit 51 (see FIG. 6 ). The operation unit 51 accepts user operations that instruct the in-vehicle device 10 to execute various processes. For example, when the smart key 50 accepts a user operation to lock the doors of the vehicle A via the operation unit 51, the smart key 50 executes a process of transmitting a locking signal indicating a locking instruction to the in-vehicle device 10. Furthermore, when the smart key 50 accepts a user operation to unlock the doors of the vehicle A via the operation unit 51, the smart key 50 executes a process of transmitting an unlocking signal indicating an unlocking instruction to the in-vehicle device 10. Note that, although an example in which the smart key 50 transmits a door locking signal and an unlocking signal to the in-vehicle device 10 has been described above, the present invention is not limited to this. That is, the smart key 50 may receive other user operations, such as instructions to start the drive source of the vehicle A or to open or close the doors, via the operation unit 51, and transmit a signal indicating an instruction corresponding to the received user operation to the in-vehicle device 10. The detailed configuration of the smart key 50 will be described later with reference to FIG.

[0017] The management device 100 is a device that manages the smart key 50. The management device 100 is installed in a predetermined specific location. The specific location is a place where the smart key 50 is kept when user B is not in vehicle A, and in the example of FIG. 1A etc., it is user B's home C. Note that, although the example above shows that the specific location is home C, it is not limited to this and may be other locations such as a company.

[0018] The management device 100 and the smart key 50 are connected via wireless communication. The management device 100 can detect whether or not user B, who is at home C, intends to get into vehicle A, which will be described in detail later. The management device 100 can be, but is not limited to, a control device of a smart home system that manages home appliances, equipment, etc. in home C. The detailed configuration of the management device 100 will be described later with reference to FIG. 9.

[0019] In the smart key system 1 according to this embodiment, when the smart key 50 carried by user B approaches vehicle A within a predetermined distance (a distance within which communication is possible), authentication processing is performed between the in-vehicle device 10 of vehicle A and the smart key 50. Specifically, the in-vehicle device 10 communicates with the smart key 50 to determine whether the in-vehicle authentication information held by the in-vehicle device 10 matches the key authentication information held by the smart key 50, and if it is determined that they match, authenticates the smart key 50 as a legitimate key.

[0020] The vehicle-mounted authentication information and key-mounted authentication information include various types of information for generating an authentication code used in the authentication process to determine whether the smart key is genuine. Specifically, the authentication code generation data includes index information (hereinafter referred to as "index"; see FIG. 1A, etc.), whose data changes according to predetermined change rules when predetermined trigger conditions are met. For example, this change rule may increment the index by one (or reset it to 0 when it reaches its upper limit) if the index is a numeric value. The authentication code generation data also includes authentication code determination information that uniquely determines an authentication code for each index. In this embodiment, for example, this authentication code determination information is configured as a data table that associates multiple indexes with authentication codes. Alternatively, the authentication code determination information may be a function that calculates an authentication code using the index as a variable. The change rules and authentication code determination information are the same for the vehicle-mounted authentication information and the key-mounted authentication information, and the initial values ​​of the indexes are also the same. Hereinafter, the authentication code, index, and authentication code candidate in the vehicle-side authentication information will be referred to as the vehicle-side authentication code, vehicle-side index, and vehicle-side authentication code candidate, and the authentication code, index, and authentication code candidate in the key-side authentication information will be referred to as the key-side authentication code, key-side index, and key-side authentication code candidate. The key-side authentication code is included in the unlock signal and lock signal from the smart key 50 and transmitted to the in-vehicle device 10, but is not limited to this.

[0021] The in-vehicle device 10 compares the in-vehicle authentication code generated in the in-vehicle device 10 with the key authentication code generated in the smart key 50, and if they match, authenticates that the smart key 50 is a legitimate key.

[0022] If the vehicle-side index and authentication code determination information of the in-vehicle device 10 match the key-side index and authentication code determination information of the smart key 50, the authentication code of the in-vehicle device 10 will match the authentication code of the smart key 50. Conversely, if this condition is not met, there is a very high probability that the authentication code of the in-vehicle device 10 will not match the authentication code of the smart key 50. Note that in this embodiment, a common system code (a different system code for each smart key system 1) is assigned to the in-vehicle device 10 and smart key 50 of a legitimate combination (same smart key system 1), and the authentication code of the in-vehicle device 10 and the authentication code of the smart key 50 are formatted to include this common system code, thereby preventing the authentication codes of the in-vehicle device 10 and smart key 50 of an illegible combination (different smart key systems 1) from accidentally matching.

[0023] After authenticating that the smart key 50 is a legitimate key, the in-vehicle device 10 locks the doors of vehicle A when, for example, user B touches a door handle or the like of the vehicle, or when a locking signal indicating a locking instruction is transmitted by a user operation on the smart key 50. Furthermore, after authenticating that the smart key 50 is a legitimate key, the in-vehicle device 10 unlocks the doors of vehicle A when, for example, user B touches a door handle or the like of the vehicle, or when a unlocking signal indicating an unlocking instruction is transmitted by a user operation on the smart key 50. In this way, the in-vehicle device 10 unlocks the doors of vehicle A when the key-side authentication code included in the unlocking signal transmitted from the smart key 50 matches the in-vehicle authentication code stored in the in-vehicle device 10.

[0024] The smart key system 1 according to this embodiment is configured to prevent unauthorized unlocking of the doors of the vehicle A.

[0025] Specifically, as shown in Figure 1A, vehicle A is parked in the parking lot of home C, and user B gets out of the parked vehicle A. In this situation, the vehicle-side index and the key-side index are the same, and in this explanation, both the vehicle-side index and the key-side index are assumed to be "1." In addition, the authentication code generated based on index x is represented as F(x).

[0026] Next, as shown in FIG. 1B, a locking signal indicating an instruction to lock the doors of vehicle A is transmitted from the smart key 50. When the in-vehicle device 10 receives the signal, the in-vehicle device 10 executes a locking process (step S1). Specifically, the in-vehicle device 10 first performs an authentication process by communicating with the smart key 50. At this point, the vehicle-side index and the key-side index are both the same, "1," so the in-vehicle authentication code and the key-side authentication code generated based on these indexes are the same, F(1). Therefore, the vehicle-side authentication code F(1) and the key-side authentication code F(1) match, so the in-vehicle device 10 authenticates the smart key 50 present near vehicle A as a legitimate key. After authenticating the smart key 50, the in-vehicle device 10 locks the doors of vehicle A upon receiving a locking signal indicating a locking instruction.

[0027] Next, the in-vehicle device 10 updates the in-vehicle index when the doors are locked after the vehicle A is parked (step S2). Specifically, the in-vehicle device 10 updates the in-vehicle index in accordance with a predetermined index update rule. In the example of the index update rule described above (adding 1), the in-vehicle device 10 updates the in-vehicle index from "1" to "2."

[0028] From this point onwards (until the next index update), the vehicle-side index is "2" and the key-side index is "1." Therefore, the vehicle-side authentication code F(2) and the key-side authentication code F(1), which are generated based on the respective indexes, are different. In this way, the in-vehicle device 10 updates the vehicle-side authentication code at a timing based on the door locking in response to a locking signal from the smart key 50. Because the vehicle-side authentication code F(2) and the key-side authentication code F(1) are different as a result of the update, the in-vehicle device 10 no longer authenticates the smart key 50 as a legitimate key (a state will arise in which unlocking, etc. cannot be performed even with a signal from the legitimate smart key 50).

[0029] After locking the doors, user B takes the smart key 50 back to his home C, as shown in FIG. 1C. In this state, both indexes have not changed, the vehicle-side authentication code is F(2), and the key-side authentication code is F(1). Therefore, in the event of a fraudulent relay attack, the key-side authentication code of the data transmitted from the legitimate smart key 50 is F(1), and therefore the key-side authentication code received by the in-vehicle device 10 due to the relaying act of a suspicious individual is F(1). Therefore, the key-side authentication code F(1) received by the in-vehicle device 10 does not match the in-vehicle-side authentication code F(2) in the in-vehicle device 10, and therefore, a fraudulent unlocking operation or the like is not performed.

[0030] Next, as shown in FIG. 1D, when user B's intention to enter vehicle A (including his / her intention to perform various vehicle operations, such as loading and unloading luggage) is detected (step S3), the smart key 50 updates the key-side index in accordance with a predetermined index update rule (step S4). In the example index update rule described above (adding 1), the smart key 50 updates the key-side index from "1" to "2." Therefore, from this point onward, the key-side authentication code F(2) and the in-vehicle authentication code F(2) in the in-vehicle device 10 match, enabling operations such as unlocking using the smart key 50. In this way, while vehicle A is parked, the smart key 50 updates the key-side authentication code at a timing based on the detection of user B's intention to enter vehicle A, thereby matching the in-vehicle authentication code.

[0031] At this point, it becomes possible to perform a fraudulent relay attack to unlock the vehicle, but since user B will soon arrive near vehicle A (user B is in the process of getting into vehicle A), it becomes virtually impossible to perform any fraudulent acts. Here, several examples of methods for determining (detecting) user B's intention to get into vehicle A will be explained.

[0032] <Method 1> An operation switch for user B to indicate his / her intention to board vehicle A is provided on the smart key 50, and when the operation switch is operated, the smart key 50 determines that it has detected user B's intention to board vehicle A. In this way, the smart key 50 detects the intention to board vehicle A based on the operation of the smart key 50 (here, the switch operation).

[0033] <Second method> An administration device 100 is installed at user B's home C, which outputs radio waves strong enough to communicate with the smart key 50 within an appropriate range (preferably, communication is possible within the house, but not near vehicle A (the home parking lot)). The smart key 50 determines that the user has an intention to board when communication with the administration device 100 is lost (radio waves are not detected) and communication with the in-vehicle device 10 becomes possible. Note that communication with the in-vehicle device 10 can be achieved by simply detecting radio waves (carrier waves) without authentication using an authentication code or the like, but security can be improved by authenticating the system code. In this way, the administration device 100 transmits a boarding intention determination signal (e.g., radio waves) whose reception status changes within a range set to determine the user's intention to board vehicle A. The smart key 50 then detects the user's intention to board vehicle A based on the reception status of the boarding intention determination signal. For example, the smart key 50 detects the user's intention to board vehicle A when reception conditions cause communication with the administration device 100 to be lost.

[0034] <3rd method> An administration device 100 is installed at user B's home C. The administration device 100 communicates with the smart key 50 and transmits a key-side index update command (boarding intention information). The administration device 100 determines whether user B intends to board a vehicle. If the administration device 100 determines that user B intends to board a vehicle, it transmits the update command (boarding intention information) to the smart key 50. The smart key 50 updates the key-side index based on the update command (boarding intention information). For example, the administration device 100 includes a microphone 101 (see FIG. 9 ) and uses the microphone 101 to collect voice information uttered by user B at home C. The administration device 100 analyzes the collected voice information of user B to detect the intention to board a vehicle. For example, if the collected voice information contains information that suggests the intention to board vehicle A, such as "I'm going by car" or "I'm going for a drive," the administration device 100 determines that user B intends to board vehicle A. In this way, the administration device 100 determines the intention to board vehicle A based on user B's state (here, the voice uttered by user B). Then, the management device 100 transmits riding intention information based on the determination to the smart key 50. Specifically, when the management device 100 detects an intention to ride in vehicle A, it transmits riding intention information indicating that an intention to ride has been detected to the smart key 50.

[0035] <4th method> The management device 100 detects the intention of user B (or smart key 50) to board vehicle A based on information indicating the movement of user B (or smart key 50) to vehicle A. Specifically, the management device 100 is equipped with a camera 102 (see FIG. 9 ) and captures an image of user B at home C. When the management device 100 estimates, through image analysis processing of the captured image, that user B is moving from home C to vehicle A, it determines that user B has the intention to board vehicle A.

[0036] Furthermore, for example, the management device 100 measures the distance to the smart key 50 by communicating with the smart key 50. As an example, the management device 100 communicates with the smart key 50 using UWB (Ultra Wide Band) wireless communication. The UWB wireless communication is a communication method that enables communication devices to measure the distance between each other with high accuracy. When the measured distance to the smart key 50 changes in such a way that it is inferred that user B, who possesses the smart key 50, has left home C and is moving toward vehicle A, the management device 100 determines that user B has an intention to ride vehicle A. In this way, the management device 100 detects the intention to ride based on information indicating the movement of the smart key 50 from home C to vehicle A. In this way, the management device 100 determines whether user B intends to ride vehicle A based on the state of user B (here, user B's movement) and transmits riding intention information based on this determination to the smart key 50. Specifically, when the management device 100 detects an intention to board the vehicle A, the management device 100 transmits to the smart key 50 boarding intention information indicating that an intention to board has been detected.

[0037] Next, as shown in FIG. 1E, user B carrying the smart key 50 moves to vehicle A. When the in-vehicle device 10 receives, for example, an unlock signal from the smart key 50 indicating an instruction to unlock the doors of vehicle A, it executes an unlocking process (step S5). Specifically, the in-vehicle device 10 first performs an authentication process by communicating with the smart key 50. At this point, the in-vehicle index and the key-side index are both the same, "2," so the in-vehicle authentication code and the key-side authentication code generated based on these indexes are the same, F(2). Therefore, since the in-vehicle authentication code F(2) and the key-side authentication code F(2) match, the in-vehicle device 10 authenticates the smart key 50 carried by user B near vehicle A as a legitimate key. When the in-vehicle device 10 receives an unlocking signal after authenticating the smart key 50, it unlocks the doors of vehicle A.

[0038] Next, the configuration of the smart key system 1 according to the embodiment will be described with reference to Fig. 2. Fig. 2 is a block diagram showing an example of the configuration of the smart key system 1 according to the embodiment. Note that the block diagrams such as Fig. 2 show only the components necessary to explain the features of the embodiment, and general components are omitted.

[0039] As shown in FIG. 2, the smart key system 1 includes the above-described in-vehicle device 10, smart key 50, and management device 100. The in-vehicle device 10 and smart key 50 are connected via short-range wireless communication (communication within a communication range within which the owner of the smart key 50 can monitor the vehicle (for unauthorized operation)). The smart key 50 and management device 100 are connected via short-range wireless communication (a communication range within which the smart key 50 and management device 100 can cooperate to communicate to determine whether user B intends to enter vehicle A). Various communication methods such as NFC (Near Field Communication), Bluetooth (registered trademark), Wi-Fi (registered trademark), and UWB wireless communication can be used as the short-range wireless communication method. Note that using the same communication method between the in-vehicle device 10 and smart key 50 and between the smart key 50 and management device 100 has the advantage that the communication hardware and software of the smart key 50 can be shared.

[0040] Next, a configuration example of a vehicle A equipped with the on-vehicle device 10 according to the embodiment will be described with reference to Fig. 3. Fig. 3 is a block diagram showing a configuration example of a vehicle A equipped with the on-vehicle device 10 according to the embodiment.

[0041] As shown in FIG. 3, a vehicle A includes an in-vehicle device 10, a door lock unit 11, a drive source 12, and a GPS (Global Positioning System) sensor 13.

[0042] The door lock unit 11 is a lock mechanism that locks or unlocks the doors of vehicle A. The drive source 12 is a mechanism that outputs a driving force to drive vehicle A, such as an engine or an electric motor. The GPS sensor 13 receives radio waves transmitted from GPS satellites and acquires location information of vehicle A based on the received radio waves. The GPS sensor 13 outputs the acquired location information to the in-vehicle device 10.

[0043] The in-vehicle device 10 includes an in-vehicle controller (control unit) 20, a storage unit 30, and a communication unit 40. The storage unit 30 is realized by a storage device such as a ROM (Read Only Memory), a RAM (Random Access Memory), or a flash memory. The storage unit 30 stores in-vehicle authentication information 31, a comparative in-vehicle authentication code 33, various data, various programs, and the like. The in-vehicle authentication information 31 and the comparative in-vehicle authentication code 33 will now be described with reference to FIGS. 4 and 5. FIG. 4 is an explanatory diagram showing an example of the in-vehicle authentication information 31. FIG. 5 is an explanatory diagram showing an example of the comparative in-vehicle authentication code 33.

[0044] 4, the in-vehicle authentication information 31 is made up of a plurality of data groups including data items of "index" and "authentication code candidate," and in this example, it is made up of five data groups. The "index" is information used as a parameter for determining the authentication code, and in this example, consecutive integers from 1 to 5 are set (stored) in accordance with the authentication code selection processing method (increment processing).

[0045] The authentication code candidate is a code determined by the index, and basically, different authentication code candidates are set depending on the index. Note that it is preferable for the authentication code candidate (authentication code) to include data that identifies the vehicle, since this allows vehicle authentication to be performed during authentication. Also, instead of the authentication code candidate (authentication code) being the value itself, a mathematical formula using the index as a variable may be set (registered), and the authentication code candidate (authentication code) may be calculated using this mathematical formula during the authentication process. In the example of Figure 4, the authentication code candidate (authentication code) is shown as a symbol, but in reality, data such as "324356" is stored.

[0046] 5, the comparative vehicle-side authentication code 33 is selected from the authentication code candidates stored in the vehicle-side authentication information 31 based on an index set by the in-vehicle device 10 in accordance with a predetermined index setting rule to be used in the authenticity determination process, and the selected authentication code is stored as the in-vehicle-side authentication code. In this example, the index setting rule is to increment the previous index (add 1; if it exceeds the maximum value (becomes 6), set it to 1). In this example, there is one comparative vehicle-side authentication code 33, but if multiple authentication codes are used in the determination process, multiple comparative vehicle-side authentication codes 33 will be stored.

[0047] Returning to the explanation of FIG. 3, the communication unit 40 is a communication interface that transmits and receives information to and from the smart key 50 and the like. The in-vehicle controller 20 corresponds to a so-called processor. The in-vehicle controller 20 is realized by a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphical Processing Unit), etc. The in-vehicle controller 20 executes a program according to an embodiment (not shown) that is stored in the storage unit 30, using RAM as a working area. Note that the in-vehicle controller 20 may be partially or entirely configured by hardware such as an ASIC (Application Specific Integrated Circuit) or an FPGA (Field Programmable Gate Array).

[0048] The in-vehicle controller 20 controls the door lock unit 11. For example, when the in-vehicle controller 20 receives a door lock signal for the vehicle A from the smart key 50 via the communication unit 40, the in-vehicle controller 20 controls the door lock unit 11 to lock the door. When the in-vehicle controller 20 receives a door unlock signal for the vehicle A from the smart key 50 via the communication unit 40, the in-vehicle controller 20 controls the door lock unit 11 to unlock the door. The in-vehicle controller 20 controls the drive source 12. For example, when the in-vehicle controller 20 receives a start instruction signal for the vehicle A from the smart key 50 via the communication unit 40, the in-vehicle controller 20 controls the start of the drive source 12 to make the vehicle A ready to travel. The in-vehicle controller 20 acquires location information of the vehicle A from the GPS sensor 13. The in-vehicle controller 20 detects that the vehicle A has been parked in the parking lot of the home C based on the location information acquired from the GPS sensor 13 and pre-stored location data of the parking lot of the home C. The vehicle controller 20 performs vehicle authentication processing for the smart key 50, which will be described later together with key authentication processing in the smart key 50.

[0049] Next, a configuration example of the smart key 50 according to the embodiment will be described with reference to Fig. 6. Fig. 6 is a block diagram showing a configuration example of the smart key 50 according to the embodiment. As shown in Fig. 6, the smart key 50 includes a key-side controller (control unit) 60, a storage unit 70, and a communication unit 80.

[0050] The storage unit 70 is realized by a storage device such as a ROM, RAM, or flash memory. The storage unit 70 stores key-side authentication information 71, a comparison key-side authentication code 73, increment status information 75, smart key identification information 77, which is data for identifying the smart key 50, as well as various data and programs. The key-side authentication information 71 and the comparison key-side authentication code 73 will now be described with reference to FIGS. 7 and 8. FIG. 7 is an explanatory diagram showing an example of the key-side authentication information 71. FIG. 8 is an explanatory diagram showing an example of the comparison key-side authentication code 73.

[0051] 7, the key-side authentication information 71 is made up of multiple data groups including data for the items "index" and "authentication code candidate," and in this example, it is made up of five data groups. The "index" is information used as a parameter for determining the authentication code, and in this example, consecutive integers from 1 to 5 are set (stored) in accordance with the authentication code selection processing method (increment processing).

[0052] The authentication code candidate is a code determined by the index, and basically, different authentication code candidates are set depending on the index. Note that it is preferable for the authentication code candidate (authentication code) to include data that identifies the vehicle it is paired with, since this allows vehicle authentication to be performed during authentication. Also, instead of the authentication code candidate (authentication code) being the value itself, a mathematical formula using the index as a variable may be set (registered), and the authentication code candidate (authentication code) may be calculated using this mathematical formula during the authentication process. In the example of Figure 7, the authentication code candidate (authentication code) is shown as a symbol, but in reality, data such as "324356" is stored.

[0053] As shown in Fig. 8, the comparison key-side authentication code 73 is obtained by selecting an authentication code candidate to be used in the authenticity determination process from the authentication code candidates stored in the key-side authentication information 71 based on an index set by the smart key 50 in accordance with a predetermined index setting rule, and storing the selected authentication code as the key-side authentication code. In this example, the index setting rule increments the previous index (adding 1; if it exceeds the maximum value (becoming 6), incrementing it by 1). Note that in this example, there is one comparison key-side authentication code 73, but if multiple authentication codes are used in the determination process, multiple comparison key-side authentication codes 73 will be stored.

[0054] The vehicle-side authentication information 31 and the key-side authentication information 71, as well as the comparison vehicle-side authentication code 33 and the comparison key-side authentication code 73, have the same data structure and contain the same data. The index setting rules for the vehicle-side device 10 and the smart key 50 are the same.

[0055] Returning to the explanation of Fig. 6, the increment status information 75 of the storage unit 70 is information indicating whether or not an increment process corresponding to an index increment process in the in-vehicle device 10 has been performed in the smart key 50 (increment process is performed when the doors of vehicle A are locked using the smart key 50 after vehicle A is parked). If the recognition process between the in-vehicle device 10 and the smart key 50 is not completed by being recognized as a legitimate smart key, for example, if the doors of vehicle A are not unlocked, the index and key-side authentication code in the smart key 50 are returned to the previous data, and the increment status information 75 indicates that increment has not been performed.

[0056] The communication unit 80 is a communication interface that transmits and receives information to and from the in-vehicle device 10, the management device 100, etc. The key-side controller 60 corresponds to a so-called processor. The key-side controller 60 is realized by a CPU, MPU, GPU, etc. The key-side controller 60 executes a program according to an embodiment (not shown) that is stored in the storage unit 70, using RAM as a work area. Note that the key-side controller 60 may be configured partly or entirely with hardware such as an ASIC or FPGA.

[0057] The key-side controller 60 performs various processes, such as communication with the in-vehicle device 10 and transmitting locking and unlocking signals based on user operation of the operation unit 51. The key-side controller 60 also performs in-vehicle authentication processing for the smart key 50, the details of which will be described later together with the key authentication processing in the smart key 50.

[0058] Next, a configuration example of the management device 100 according to the embodiment will be described with reference to Fig. 9. Fig. 9 is a block diagram showing a configuration example of the management device 100 according to the embodiment. This example is a configuration example for detecting user B's intention to ride using the third method described above.

[0059] As shown in FIG. 9, the management device 100 includes a microphone 101, a camera 102, a management controller (control unit) 110, a storage unit 120, and a communication unit 130. The microphone 101 is installed at an appropriate position in home C and collects information about the voice uttered by user B at home C. The microphone 101 outputs the collected voice information of user B to the management controller 110. The camera 102 is installed at an appropriate position in home C and captures an image of user B at home C. The camera 102 outputs the captured image to the management controller 110.

[0060] The storage unit 120 is realized by a storage device such as a ROM, RAM, or flash memory. Various data and programs are stored in the storage unit 120. The storage unit 120 stores smart key identification information 121 for identifying the smart key 50. This smart key identification information 121 is stored based on a user operation or the like when a new smart key 50 is registered. The smart key identification information 121 is added to communication data in communication between the management device 100 and the smart key 50, and is used by the management device 100 and the smart key 50 to identify the communication partner. The smart key identification information 121 is also stored in the storage unit 70 of the smart key 50 (see "smart key identification information 77" in FIG. 6).

[0061] The communication unit 130 is a communication interface that transmits and receives information to and from the smart key 50 and the like. The management controller 110 corresponds to a so-called processor. The management controller 110 is realized by a CPU, MPU, GPU, or the like. The management controller 110 executes a program according to an embodiment (not shown) that is stored in the storage unit 120, using RAM as a work area. Note that the management controller 110 may be configured partly or entirely with hardware such as an ASIC or FPGA.

[0062] The management controller 110 detects user B's intention to board vehicle A at home C and notifies the smart key 50 of the intention to board. Specifically, the management controller 110 detects the intention to board based on user B's voice information collected by the microphone 101. For example, a voice recognition AI (Artificial Intelligence) is stored in the storage unit 120, and the management controller 110 uses the voice recognition AI to detect user B's intention to board from spoken voice information. For example, the management controller 110 detects user B's intention to board vehicle A when the voice information includes information that suggests boarding vehicle A, such as "I'm going by car" or "I'm going for a drive." Specifically, the voice recognition AI is an artificial intelligence model trained with learning data that uses spoken voice as input data and the presence or absence of the intention to board (presence or absence of boarding behavior) at the time of the voice utterance as correct answer data.

[0063] Similarly to the detection based on audio information described above, the management controller 110 may also detect the intention to board based on the video captured by the camera 102. The management controller 110 may also detect the intention to board based on information indicating the movement of the smart key 50 to vehicle A.

[0064] When the management controller 110 detects user B's intention to board vehicle A, it sends information (boarding intention information) to the smart key 50 via the communication unit 130 indicating that the intention to board has been detected (an instruction to update the key side authentication code), along with smart key identification information 121 (so that the smart key 50 recognizes that the information is for itself).

[0065] Next, processing executed by the smart key system 1 according to the embodiment will be described with reference to FIGS. 10A and 10B. FIGS. 10A and 10B show an example of a processing sequence executed by the smart key system 1 according to the embodiment. FIGS. 10A and 10B are composed of a flowchart showing processing executed by the in-vehicle device 10 (in-vehicle controller 20), a flowchart showing processing executed by the smart key 50 (key controller 60), a diagram showing the state of the comparison in-vehicle authentication code 33 that changes in accordance with processing by the in-vehicle controller 20, and a diagram showing the state of the comparison key authentication code 73 and the increment status information 75 that changes in accordance with processing by the key controller 60. Note that the processing of each flowchart shown in FIGS. 10A and 10B starts from the parked state after initialization processing at the first startup (setting each index of the comparison in-vehicle authentication code 33 and the comparison key authentication code 73 to its initial value (both indexes to the same value (e.g., 1)) and setting each authentication code to a code corresponding to each index (e.g., CS1)). Thereafter, the processing continues continuously unless power is turned off, a reset operation, or the like is performed. In order to make the explanation of operation easier to understand, the explanation will begin with the user being in the vehicle, and the explanation will proceed using the example of the state in which the indexes of the comparison vehicle-mounted authentication code 33 and the comparison key-side authentication code 73 are 1.

[0066] As shown in FIG. 10A, the in-vehicle controller 20 (in-vehicle device 10) performs vehicle occupancy state processing (step S100). In step S100, the in-vehicle controller 20 detects, for example, the presence of the smart key 50 in vehicle A (determined by, for example, the reception status of a signal from the smart key 50), and performs processing such as permitting the driving of the drive source 12 to maintain a running state. Next, the in-vehicle controller 20 determines whether vehicle A is in a parked state (step S101). The in-vehicle controller 20 determines the parked state of vehicle A based on the stopped state of the drive source 12 (detected by, for example, the presence or absence of an engine stop operation), and if vehicle A is in a parked state (step S101, Yes), the process proceeds to step S102. If vehicle A is not in a parked state (step S101, No), the process proceeds to step S100.

[0067] On the smart key 50 side, the key-side controller 60 (smart key 50) performs vehicle occupancy status processing (step S200). In step S200, the key-side controller 60 performs processing such as outputting a signal periodically (at a period that allows the in-vehicle controller 20 to appropriately detect the presence of the smart key 50 in vehicle A). Next, the key-side controller 60 determines whether a locking operation has been performed by the user (step S201). If a locking operation has been performed (step S201, Yes), the key-side controller 60 proceeds to step S202; if a locking operation has not been performed (step S201, No), the key-side controller 60 proceeds to step S200. In step S202, the key-side controller 60 transmits a locking signal (to the in-vehicle device 10) and proceeds to step S203.

[0068] In step S102, the in-vehicle controller 20 of the in-vehicle device 10 determines whether or not a locking signal has been received from the key controller 60. If a locking signal has been received (if the locking signal transmitted in step S202 is detected; step S102, Yes), the in-vehicle controller 20 proceeds to step S103. If a locking signal has not been received (step S102, No), the in-vehicle controller 20 proceeds to step S100. Note that in step S102, the in-vehicle controller 20 compares the in-vehicle authentication code of the comparative in-vehicle authentication code 33 with the key authentication code of the comparative key authentication code 73. Only if they match does the in-vehicle controller 20 determine that a legitimate locking signal has been received, and proceeds to the next process (step S103). In step S103, the in-vehicle controller 20 performs locking processing, specifically, outputs a locking signal to the door lock unit 11, and proceeds to step S104. In step S104, the in-vehicle controller 20 transmits a locking completion signal (to the smart key 50) and proceeds to step S105. From the perspective of the in-vehicle device 10's processing, vehicle A is now in a parked (no occupants) state. In step S105, the in-vehicle controller 20 updates the comparison in-vehicle authentication code 33. Specifically, it increments the index and sets the in-vehicle authentication code to the authentication code (searched from the in-vehicle authentication information 31) corresponding to the incremented index, and proceeds to step S106. The in-vehicle controller 20 performs the in-vehicle authentication code update process in step S105 after a predetermined waiting time (e.g., an appropriate time determined based on experiments, etc.) following locking (step S103). If the in-vehicle controller 20 receives an unlocking signal from the smart key 50 during this waiting time, it performs the unlocking process without updating the comparison in-vehicle authentication code 33 and proceeds to step S100.

[0069] In step S203, the key-side controller 60 of the smart key 50 determines whether or not a locking completion signal has been received from the in-vehicle device 10. If the key-side controller 60 has received the locking completion signal (Yes in step S203), the process proceeds to step S204. If the key-side controller 60 has not received the locking completion signal (No in step S203), the process proceeds to step S202. That is, the key-side controller 60 repeatedly transmits the locking signal until the in-vehicle device 10 receives the locking signal (until reception of the locking signal by the in-vehicle device 10 is confirmed). In step S204, the key-side controller 60 updates the increment status information 75 to data (“Not Incremented”) indicating that the index in the comparison key-side authentication code 73 has not been updated (incremented), and then proceeds to step S205 shown in FIG. 10B. From this point on, vehicle A enters a parked (no occupants) state from the perspective of the smart key 50 processing.

[0070] In step S205, the key-side controller 60 determines whether the user intends to board vehicle A using a method such as the above-described <First Method>. If the key-side controller 60 detects (senses) the intention to board (Yes in step S205), the process proceeds to step S206. If the key-side controller 60 does not detect (sense) the intention to board (No in step S205), the process repeats step S205. In step S206, the key-side controller 60 updates the comparison key-side authentication code 73, specifically, increments the index, sets the key-side authentication code to a code corresponding to the incremented index, and then proceeds to step S207. In the example shown in FIG. 10B, the index of the comparison key-side authentication code 73 is 2, and the key-side authentication code is CS2. In step S207, the key-side controller 60 updates the increment status information 75 to data (“Incremented”) indicating that the index in the comparison key-side authentication code 73 has been updated (incremented), and then proceeds to step S208.

[0071] In step S208, the key-side controller 60 determines whether or not the user has performed an unlocking operation. If the user has performed an unlocking operation (step S208, Yes), the process proceeds to step S212. If the user has not performed an unlocking operation (step S208, No), the process proceeds to step S209. In step S209, the key-side controller 60 determines whether or not the time elapsed since the user's intention to board (step S205) has exceeded a validity period threshold for the intention to board (a value set by a developer or the like based on experiments or the like) (step S209). If the elapsed time has exceeded the validity period threshold for the intention to board (step S209, Yes), the key-side controller 60 proceeds to step S210. If the elapsed time has not exceeded the validity period threshold for the intention to board (step S209, No), the key-side controller 60 proceeds to step S208. In step S210, the key-side controller 60 updates the comparison key-side authentication code 73 (returning it to the state before step S206), specifically, decrements the index, sets the key-side authentication code to a code corresponding to the decremented index, and proceeds to step S211. 10B, the index of the comparison key-side authentication code 73 at this point is 1, and the key-side authentication code is CS1. Next, the key-side controller 60 performs processing to cancel the update of the increment status information 75 performed in step S207 (step S211). Specifically, the key-side controller 60 updates the increment status information 75 to data (“not incremented”) indicating that the index in the comparison key-side authentication code 73 has not been updated (incremented), and then proceeds to step S205.

[0072] In step S212, the key-side controller 60 transmits an unlock signal (to the in-vehicle device 10) and proceeds to step S213. In step S213, the key-side controller 60 determines whether or not an unlock completion signal has been received from the in-vehicle device 10. If the key-side controller 60 has not received an unlock completion signal (step S213, No), it proceeds to step S212. If the key-side controller 60 has received an unlock completion signal (step S213, Yes), it proceeds to step S214 (same as S200) and repeats the above-described process. That is, the key-side controller 60 repeatedly transmits the unlock signal until the in-vehicle device 10 receives the unlock signal (until reception of the unlock signal by the in-vehicle device 10 is confirmed). Note that in the example shown in FIG. 10B, the index of the comparison key-side authentication code 73 at this point is 2, and the key-side authentication code is CS2.

[0073] In step S106, the in-vehicle controller 20 of the in-vehicle device 10 determines whether or not an unlocking signal has been received from the key-side controller 60. If an unlocking signal has been received (if the locking signal transmitted in step S212 is detected; step S106, Yes), the in-vehicle controller 20 proceeds to step S107. If an unlocking signal has not been received (step S106, No), the in-vehicle controller 20 repeats the process of step S106. Note that in step S106, the in-vehicle controller 20 compares the in-vehicle authentication code of the comparative in-vehicle authentication code 33 with the key-side authentication code of the comparative key-side authentication code 73. Only if they match does the in-vehicle controller 20 determine that a legitimate unlocking signal has been received, and proceeds to the next process (step S107). In step S107, the in-vehicle controller 20 performs unlocking processing, specifically, outputs an unlocking signal to the door lock unit 11, and proceeds to step S108. In step S108, the in-vehicle controller 20 transmits an unlock completion signal (to the smart key 50), and proceeds to step S109 (same as S100). In the example shown in Fig. 10B, the index of the comparison in-vehicle authentication code 33 at this point is 2, the key authentication code is CS2, and the data of the comparison in-vehicle authentication code 33 and the comparison key authentication code 73 when the driver is inside the vehicle are the same.

[0074] By the above-described processing, the authentication code on the in-vehicle device 10 side and the authentication code on the smart key 50 side do not match during the period between step S105 and step S206 (the period immediately before step S105 and step S212, excluding the short period between step S208 and step S210), thereby preventing unlocking and other fraudulent acts such as relay attacks while the vehicle is parked. Furthermore, at the time of comparison processing (step S106) between the authentication code on the in-vehicle device 10 side and the authentication code on the smart key 50 side, these two authentication codes match, so normal operation (unlocking, etc.) is performed without hindrance when the legitimate smart key 50 is operated (unlocking operation, etc.).

[0075] Furthermore, in the processes of steps S208 to S211, if the unlocking operation is not performed within a predetermined time from the detection of the intention to board, the comparison key authentication code 73 is restored to the data before the update, and is set to a state in which it does not match the comparison vehicle authentication code 33. This allows the security of the smart key system 1 to be maintained even if the user's behavior (intention) changes and they no longer board the vehicle.

[0076] As described above, in the smart key system 1 according to the embodiment, the in-vehicle device 10 updates the in-vehicle authentication code based on the timing of door locking. Meanwhile, the smart key 50 updates the key authentication code based on the timing of detection of the user's intention to enter vehicle A while vehicle A is parked. As a result, the in-vehicle authentication code and the key authentication code do not match from the time the doors are locked until the user's intention to enter vehicle A is detected (see FIG. 1C ). Therefore, even if a relay attack is performed, for example, by amplifying weak radio waves emitted from the smart key 50 located at a location away from vehicle A (e.g., home C) and transmitting the amplified signal to vehicle A, the in-vehicle authentication code and the key authentication code do not match, and the doors of vehicle A will not be unlocked. This prevents unauthorized unlocking of the doors of vehicle A.

[0077] Furthermore, the in-vehicle device 10 updates the in-vehicle authentication code after a standby time has elapsed since the doors were locked. In other words, the in-vehicle device 10 does not update the in-vehicle authentication code before the standby time has elapsed (for example, immediately after the doors are locked). This improves the convenience of the smart key system 1. For example, after locking the doors and leaving vehicle A, user B may realize that he or she left something behind in the vehicle before arriving at home C and immediately return to vehicle A. If the in-vehicle authentication code has been updated, user B may not be able to unlock the doors with the smart key 50, which may reduce the convenience of the smart key system 1. In this embodiment, even if user B returns to vehicle A immediately, user B can unlock the doors with the smart key 50 because the in-vehicle authentication code has not been updated. As a result, the convenience of the smart key system 1 is improved.

[0078] After detecting an intention to enter vehicle A, if the validity period has expired and no unlocking operation has been performed, the smart key 50 restores the key-side authentication code to the key-side authentication code before it was updated. In this embodiment, for example, if an intention to enter vehicle A is detected, but the user subsequently changes their behavior (intention) and decides not to enter the vehicle, and the smart key 50 is returned to their home, a discrepancy will occur between the vehicle-side index and the key-side index, resulting in a mismatch between the vehicle-side authentication code and the key-side authentication code. Therefore, restoring the key-side authentication code (key-side index) to its state before it was updated can prevent this discrepancy from occurring.

[0079] Furthermore, the smart key 50 detects the intention to board the vehicle A based on the operation of the smart key 50. This makes it possible to determine whether or not the user B intends to board the vehicle A based on the user's operation of the smart key 50, thereby enabling the intention to board to be detected with high accuracy.

[0080] The smart key system 1 also includes a management device 100 that transmits a boarding intention determination signal whose reception status changes in a range set to determine whether or not a user B intends to board vehicle A. The smart key 50 detects the intention to board vehicle A based on the reception status of the boarding intention determination signal. This makes it possible to determine whether or not user B intends to board vehicle A based on the reception status of the boarding intention determination signal transmitted from the management device 100, thereby enabling accurate detection of the intention to board.

[0081] The smart key system 1 also includes a management device 100 that determines whether user B intends to board vehicle A based on their state (e.g., user B's voice, user B's movement) and transmits boarding intention information based on this determination to the smart key 50. The smart key 50 detects the intention to board vehicle A based on the boarding intention information received from the management device 100. This makes it possible to determine whether user B intends to board vehicle A based on the boarding intention information received from the management device 100, thereby enabling accurate detection of the intention to board.

[0082] [Variations] Next, a modified example of the smart key system 1 according to the embodiment will be described. The smart key system 1 according to the modified example is a system that allows multiple smart keys 50 to be used with the same vehicle A. To accommodate multiple smart keys 50, an independent authentication process is performed for each of the multiple smart keys 50, and if the smart key 50 is authenticated in each authentication process, various operations based on the smart key 50 can be performed regardless of the authentication process.

[0083] Here, a specific method for realizing a modified example of the smart key system 1 will be described with reference to Figures 11 to 14. Figure 11 is an explanatory diagram showing an example of the vehicle-side authentication information 31 stored in the in-vehicle device 10 according to the modified example, and Figure 12 is an explanatory diagram showing an example of the comparative vehicle-side authentication code 33 stored in the in-vehicle device 10 according to the modified example. Figure 13 is an explanatory diagram showing an example of the key-side authentication information 71 stored in the smart key 50 according to the modified example, and Figure 14 is an explanatory diagram showing an example of the comparative key-side authentication code 73 stored in the smart key 50 according to the modified example. Note that, although this modified example will be described assuming a smart key system 1 in which three smart keys can be used for vehicle A, the same can be achieved with other numbers of smart keys 50, such as two or four, by increasing or decreasing the number of data items according to the number of smart keys 50.

[0084] 11, the in-vehicle authentication information 31 includes information items such as "index," "key 1 authentication code candidate," "key 2 authentication code candidate," and "key 3 authentication code candidate." The "index" is information used as a parameter for determining the authentication code, and in this example, consecutive integers from 1 to 5 are set (stored) in accordance with the authentication code selection processing method (increment processing).

[0085] The "Key 1 authentication code candidate," "Key 2 authentication code candidate," and "Key 3 authentication code candidate" are codes determined by the index for each of the three smart keys, and basically, different authentication code candidates are set depending on the index. Note that it is preferable for each authentication code candidate (authentication code) to contain data that identifies the vehicle, since this allows vehicle authentication to be performed during authentication. Also, instead of the authentication code candidate (authentication code) being the actual value, a mathematical formula using the index as a variable may be set (registered), and the authentication code candidate (authentication code) may be calculated using this mathematical formula during the authentication process. In the example of Figure 11, each authentication code candidate (authentication code) is shown with a symbol, but in reality, data such as "324356" is stored.

[0086] 12, the comparative vehicle authentication code 33 is obtained by selecting an authentication code candidate to be used in the authenticity determination process from the authentication code candidates stored in the vehicle authentication information 31 based on an index set by the in-vehicle device 10 in accordance with a predetermined index setting rule, and storing the selected authentication code as the in-vehicle authentication code. Therefore, the data table configuration of the comparative vehicle authentication code 33 includes data items for "key ID," "index," and "vehicle authentication code," which are the identification codes of the smart key 50. In other words, the comparative vehicle authentication code 33 is data for the index and "vehicle authentication code" for each smart key 50.

[0087] In addition, the index setting rule in this example is that the previous index is incremented (1 is added; if it exceeds the maximum value (becomes 6), it is set to 1). In this example, the authentication code selected based on each index for each of the three smart keys 50 (the key 1 authentication code, key 2 authentication code, and key 3 authentication code selected from the key 1 authentication code candidate, key 2 authentication code candidate, and key 3 authentication code candidate) is stored as the comparison in-vehicle authentication code 33.

[0088] As shown in Fig. 13, key-side authentication information 71 is the same information as key-side authentication information 71 described in Fig. 7, and is stored as unique data in each smart key 50. Also, as shown in Fig. 14, comparison key-side authentication code 73 is the same information as comparison key-side authentication code 73 described in Fig. 8, and is stored as unique data in each smart key 50.

[0089] The in-vehicle device 10 (in-vehicle controller 20) and each smart key 50 (key-side controller 60) then include the smart key 50's identification data in each communication to determine which smart key 50 the information in each communication is for. Then, they perform authentication processing for the identified smart key 50 and various controls (locking processing, unlocking processing, etc.) based on the information transmitted from the smart key 50. The smart key 50 (key-side controller 60) performs processing (authentication processing, etc.) similar to that in the example of a single smart key 50 described above.

[0090] In this way, the in-vehicle device 10 according to the modified example has an in-vehicle authentication code associated with each of the multiple smart keys 50 (see FIG. 12). The in-vehicle device 10 then performs various processes, such as an update process, on the in-vehicle authentication code corresponding to the operated smart key 50.

[0091] Furthermore, the in-vehicle device 10 (in-vehicle controller 20) basically performs the same processing as in the example of a single smart key 50 described above, but based on the identification information (included in the communication information) of the smart key 50 that is the communication partner (the subject of authentication), it selects data to be used in the in-vehicle authentication information 31 (selecting from among the key 1 authentication code candidate, key 2 authentication code candidate, and key 3 authentication code candidate based on the smart key identification information), and also selects data to be used in the comparison in-vehicle authentication code 33 (determining a key ID based on the smart key identification information, and selecting an index and in-vehicle authentication code corresponding to the determined key ID), and performs processing.

[0092] With this configuration, the in-vehicle device 10 is configured to perform independent recognition processing for each smart key 50 with which it communicates (the smart key 50 that sent the unlock command signal, etc.), and identifies the smart key 50 with which it communicates and performs recognition processing for the identified smart key 50. Therefore, the in-vehicle device 10 performs authentication operations for each smart key 50 in the same way as the smart key system 1 consisting of a single smart key 50 described above. As a result, even in a smart key system 1 having multiple smart keys 50, unauthorized operations such as unlocking can be prevented even if unauthorized operations such as relay attacks are performed.

[0093] In the above description, a key ID is assigned to each of the multiple smart keys 50, and the in-vehicle device 10 updates the comparison vehicle-side authentication code 33 using the key ID. However, this is not limiting. For example, the data for the key 1 authentication code candidate, key 2 authentication code candidate, and key 3 authentication code candidate in the in-vehicle device 10's in-vehicle authentication information 31 are all different data. When updating the comparison vehicle-side authentication code 33 during the recognition process, the in-vehicle device 10 determines which of the key 1 authentication code candidate, key 2 authentication code candidate, and key 3 authentication code candidate should be used to update the comparison vehicle-side authentication code 33 based on the in-vehicle authentication code used in the recognition process (used for data comparison). Specifically, the in-vehicle authentication code candidate group including the in-vehicle authentication code used in the recognition process is selected from the key 1 authentication code candidate, key 2 authentication code candidate, and key 3 authentication code candidate, and the in-vehicle authentication code candidate is updated with the in-vehicle authentication code in the selected authentication code candidate group that is next (corresponding to the next index) to the in-vehicle authentication code used in the recognition process.

[0094] Further advantages and modifications will readily occur to those skilled in the art. Therefore, the invention in its broader aspects is not limited to the specific details and representative embodiments shown and described above. Accordingly, various modifications may be made without departing from the spirit or scope of the general inventive concept as defined by the appended claims and their equivalents. [Explanation of symbols]

[0095] 1 Smart Key System 10 Onboard equipment 50 Smart Key 100 Management device

Claims

1. A smart key system including an on-board device mounted in a vehicle and a smart key capable of communicating with the on-board device, The in-vehicle device If the key authentication code included in the unlocking signal transmitted from the smart key matches the vehicle authentication code stored in the vehicle-mounted device, the vehicle doors are unlocked. updating the vehicle-mounted authentication code at a timing based on the locking of the door; The smart key is updating the key-side authentication code at a timing based on detection of a user's intention to get into the vehicle while the vehicle is parked; Smart key system.

2. The in-vehicle device updating the in-vehicle authentication code after a waiting time has elapsed since the door was locked; The smart key system of claim 1 .

3. The smart key is If an unlocking operation is not performed after a valid period has elapsed after detecting an intention to get into the vehicle, the key-side authentication code is restored to the key-side authentication code before the update. The smart key system of claim 1 .

4. There are multiple smart keys, The in-vehicle device The vehicle authentication code is associated with each of the plurality of smart keys, performing an update process on the vehicle-mounted authentication code corresponding to the operated smart key; The smart key system according to any one of claims 1 to 3.

5. The smart key is Detecting an intention to get into the vehicle based on an operation on the smart key; The smart key system of claim 1 .

6. The vehicle management system further includes a management device that transmits a boarding intention determination signal whose reception state changes in a region set for determining whether the passenger intends to board the vehicle, The smart key is Detecting the intention to board the vehicle based on a reception status of the boarding intention determination signal; The smart key system of claim 1 .

7. a management device that determines whether the user intends to ride the vehicle based on the user's state and transmits riding intention information based on the determination to the smart key; The smart key is detecting an intention to board the vehicle based on the boarding intention information received from the management device; The smart key system of claim 1 .

8. A key-side authentication code is sent to determine whether the operation is legitimate. a smart key that updates the key-side authentication code at a timing based on detection of a user's intention to get into a vehicle that is a target of operation while the vehicle is parked; an on-board device mounted on a vehicle; An in-vehicle device in a smart key system including: If the key authentication code included in the unlocking signal transmitted from the smart key matches the stored vehicle authentication code, the vehicle doors are unlocked. updating the in-vehicle authentication code at a timing based on the locking of the door; In-vehicle device.

9. Smart key and If the key authentication code included in the unlocking signal transmitted from the smart key matches the stored vehicle authentication code, the vehicle doors are unlocked. an in-vehicle device that updates the in-vehicle authentication code at a timing based on the locking of the door; A smart key in a smart key system including: updating the key-side authentication code at a timing based on detection of a user's intention to get into the vehicle while the vehicle is parked; Smart key.

10. A control method for a smart key system including an on-board device mounted in a vehicle and a smart key capable of communicating with the on-board device, comprising: The in-vehicle device If the key authentication code included in the unlocking signal transmitted from the smart key matches the vehicle authentication code stored in the vehicle-mounted device, the vehicle doors are unlocked. updating the vehicle-mounted authentication code at a timing based on the locking of the door; The smart key is updating the key-side authentication code at a timing based on detection of a user's intention to get into the vehicle while the vehicle is parked; A method for controlling a smart key system.

Images