System and method for managing devices within a vehicle system

Abstract

The present disclosure provides methods, systems, and devices for managing one or more devices within a vehicle system. According to an embodiment, a method is implemented by at least one processor, the method comprising: acquiring a message from a first device, the message being a message for requesting a service from a second device, and the message containing identification information ID of the first device; determining whether the first device has been registered based on the ID of the first device; performing one or more operations for registering the first device based on the determination that the first device is not registered; determining whether the first device has been normally registered; determining whether the first device has been authenticated based on the determination that the first device has been registered or based on the determination that the first device has been normally registered; and providing access to the requested service to the first device based on the determination that the first device has been authenticated.

Description

Technical Field

[0001] Systems and methods integrated with embodiments as examples of the present disclosure are associated with vehicle systems and, in particular, relate to managing one or more devices within one or more vehicle systems. Background Art

[0002] Modern vehicles are equipped with various devices that form interconnected vehicle systems. These devices include, but are not limited to, electronic control units (ECUs), infotainment systems, sensors, actuators, telematics units, and communication modules. These devices interact with each other to provide necessary functions such as propulsion, safety, entertainment, connectivity, and advanced driver assistance. Moreover, a considerable number of devices are involved in the process of vehicle development and manufacturing. For example, various fleet devices or mobile hardware are involved in various stages of vehicle manufacturing, various static hardware such as servers are used to store and share information, and various testing hardware are involved to test the functions of the vehicle.

[0003] In this regard, most devices within a vehicle system need to communicate with each other and share information to ensure seamless operation and thus improve the user experience. However, managing these devices efficiently and securely presents significant problems. In particular, prior art systems and approaches for managing devices in vehicle systems lack comprehensive access management and information control capabilities in most cases, causing a variety of issues that should be addressed.

[0004] First, in particular, in situations where a device is accessed by different users with different roles or responsibilities, users from different teams, users from suppliers, users located in different geographical locations, etc., most of the systems and methods in the prior art lack robust mechanisms for identifying and authenticating devices. This may allow unauthorized devices or compromised devices to access the system, causing potential security violations or erroneous actions.

[0005] Furthermore, most prior art systems and methods lack centralized and comprehensive device information management. This can sometimes make it difficult to provide accurate information about all available devices when the number of available devices is large. For example, it can be difficult to fully and timely identify which devices are available, where each device is located, how each device is connected, what each device does, etc. The process for collecting and managing device information can become particularly complex when devices are located in geographically diverse locations.

[0006] Furthermore, prior art systems and methods often lack sophisticated access control mechanisms. As a result, it is difficult to provide users with appropriate information. For example, users may sometimes be provided with a considerable amount of information, which may be voluminous and inefficient for users to quickly grasp the desired information. Conversely, users may sometimes be provided with an inefficient amount of information, which may result in less information, and users may have to manually obtain additional information.

[0007] In view of at least the foregoing, there exists a need to provide improved systems, methods, devices, etc. for managing devices and associated information within a vehicle system. Summary of the invention

[0008] Exemplary embodiments of the present disclosure provide methods, systems, and apparatus for effectively and efficiently managing one or more devices within one or more vehicle systems.

[0009] According to an embodiment, a method is provided, which is a method for managing multiple devices within a vehicle system. The method can be implemented by at least one processor of the system, and the method may include: obtaining a message from a first device, the message being a message for requesting a service from a second device, and the message containing identification information (ID: identity) of the first device; determining whether the first device has been registered based on the ID of the first device; performing one or more operations for registering the first device based on the determination that the first device has not been registered; determining whether the first device has been registered normally; determining whether the first device has been authenticated based on the determination that the first device has been registered, or based on the determination that the first device has been registered normally; and providing the first device with access to the requested service based on the determination that the first device has been authenticated. The second device may include a vault, and the service may include pre-configuration of one or more information stored in the vault. The first device and the second device may be configured in geographically different locations.

[0010] According to an embodiment, determining whether the first device has been registered may include: determining, based on the ID of the first device, whether a public key associated with the first device can be used in one or more storage media of the system; determining that the first device has been registered based on the determination that the public key of the first device can be used; and determining that the first device has not been registered based on the determination that the public key of the first device cannot be used.

[0011] According to an embodiment, performing one or more operations for registering the first device may include: establishing an out-of-band (OOB) channel between the system and the first device; receiving information of a public key of the first device from the first device through the OOB channel; registering the first device based on the information of the public key; and sending a result of registering the first device to the first device. Registering the first device may include: verifying the public key; and generating a mapping of the verified public key and the ID of the first device.

[0012] According to an implementation, determining whether the first device has been authenticated may include: determining whether the first device has permission to utilize the requested service based on the ID of the first device; determining that the first device has been authenticated based on a determination that the first device has permission to utilize the requested service; and determining that the first device has not been authenticated based on a determination that the first device does not have permission to utilize the requested service.

[0013] According to an embodiment, at least a portion of the message is encrypted by the first device based on a private key, and determining whether the first device has the authority to utilize the requested service may include: obtaining the public key of the first device; decrypting the encrypted portion of the message to obtain information about the requested service; and determining whether the first device has the authority to utilize the requested service based on the information about the requested service and the ID of the first device.

[0014] According to an embodiment, providing access to a requested service to a first device may include: obtaining information associated with the requested service from a second device; encrypting the information of the requested service obtained from the second device based on a public key of the first device; and providing the encrypted information to the first device. The first device may include a trusted platform module (TPM), the TPM may be configured to manage a public key and a private key, and the first device may be configured to decrypt the encrypted information based on the private key.

[0015] According to an embodiment, a system is provided, which is a system for managing multiple devices in a vehicle system. The system may include: a storage storage storing computer executable instructions; and at least one processor coupled to the storage storage in a communicable manner. At least one processor may be configured to execute the following instructions, which are used to: obtain a message from a first device, the message is a message for requesting a service from a second device, and the message contains identification information (ID) of the first device; based on the ID of the first device, determine whether the first device has been registered; based on the determination that the first device has not been registered, perform one or more operations for registering the first device; determine whether the first device has been registered normally; based on the determination that the first device has been registered, or based on the determination that the first device has been registered normally, determine whether the first device has been authenticated; and based on the determination that the first device has been authenticated, provide the first device with access to the requested service. The second device may include a vault, and the service may include pre-configuration of one or more information stored in the vault. The first device and the second device may be configured in geographically different locations.

[0016] According to an embodiment, at least one processor may be configured to execute the following instructions, which are used to: determine, based on the ID of the first device, whether a public key associated with the first device can be used in one or more storage media of the system; determine, based on the determination that the public key of the first device can be used, that the first device has been registered; and determine, based on the determination that the public key of the first device cannot be used, that the first device has not been registered, thereby determining whether the first device has been registered.

[0017] According to an embodiment, at least one processor may be configured to execute the following instructions, which are used to: establish an OOB channel between the system and the first device, receive information about the public key of the first device from the first device through the OOB channel, register the first device based on the information about the public key, and send a result of registering the first device to the first device, thereby performing one or more operations for registering the first device. According to an embodiment, at least one processor may be configured to execute the following instructions, which are used to: verify the public key, generate a mapping between the verified public key and the ID of the first device, thereby registering the first device.

[0018] According to an embodiment, at least one processor may be configured to execute the following instructions, which are used to: determine whether the first device has permission to utilize the requested service based on the ID of the first device, determine that the first device has been authenticated based on the determination that the first device has permission to utilize the requested service, and determine that the first device has not been authenticated based on the determination that the first device does not have permission to utilize the requested service, thereby determining whether the first device has been authenticated.

[0019] According to an embodiment, at least a portion of the message may be encrypted by the first device based on a private key, and at least one processor may be configured to execute the following instructions, which are used to: obtain the public key of the first device, decrypt the encrypted portion of the message to obtain information about the requested service, and determine whether the first device has permission to utilize the requested service based on the information about the requested service and the ID of the first device, thereby determining whether the first device has permission to utilize the requested service.

[0020] According to an embodiment, at least one processor may be configured to execute the following instructions, which are used to: obtain information associated with the requested service from the second device, encrypt the information of the requested service obtained from the second device based on the public key of the first device, and provide the encrypted information to the first device, thereby providing the first device with access to the requested service. The first device may include a trusted platform module (TPM), the TPM may be configured to manage a public key and a private key, and the first device may be configured to decrypt the encrypted information based on the private key.

[0021] Additional aspects are described in part in the description that follows and may be apparent in part from the description, or may be achieved by practice of the presented embodiments of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Hereinafter, features, advantages, and significance of exemplary embodiments of the present disclosure will be described with reference to the accompanying drawings in which the same reference numerals represent the same elements.

[0023] Figure 1 is a block diagram of an exemplary system configuration for managing one or more devices within a vehicle system according to one or more embodiments.

[0024] Figure 2 is a block diagram of exemplary components of a device management system according to one or more implementations.

[0025] Figure 3 is a flow chart of an exemplary method for managing one or more devices within a vehicle system according to one or more implementations.

[0026] Figure 4 is a flow chart of an exemplary method for registering a device in a vehicle system according to one or more implementations.

[0027] Figure 5 is a diagram of a system configuration representing an exemplary use case for providing a device with access to a requested service in accordance with one or more embodiments.

[0028] Figure 6A diagram showing a system configuration for managing one or more remote sessions between one or more user equipment (UE) and one or more devices within a vehicle system in accordance with one or more embodiments.

[0029] Figure 7 is a flow chart of an exemplary method for managing device information in accordance with one or more implementations. DETAILED DESCRIPTION

[0030] The following detailed description of the exemplary embodiments refers to the accompanying drawings. The foregoing disclosure provides examples and descriptions, but is not intended to be exhaustive, and further, is not intended to limit the implementation form to the exact manner disclosed. In view of the above disclosure, modifications and variations are possible, or can be obtained through the practice of the implementation form. Moreover, one or more features or components of one or more embodiments may be embedded in another embodiment (or one or more features of another embodiment), or may be combined therewith. Additionally, it is understood that in the description of the operations provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed (at least partially) simultaneously, and the order of one or more operations may be switched.

[0031] Even if a particular combination of features is listed in the claims and / or disclosed in this specification, that combination is not intended to limit the disclosure of possible implementations. Indeed, many of the features may be combined in ways that are not specifically listed in the claims and / or disclosed in this specification. Each of the dependent claims listed below may be directly dependent on only one claim, but the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0032] As long as it is not so clearly stated, any element, operation or instruction used herein should not be interpreted as critical or essential. In addition, as used herein, the article "a" and "an" are intended to include one or more items and can be used interchangeably with "one or more". When only one item is meant, the term "one" or similar language is used. In addition, as used herein, the terms such as "have", "having", "include", "including", etc. are meant to be open terms that are not restricted. Moreover, as long as it is not clearly stated that it is not so, the phrase "based on" means "at least partially based on...". Moreover, such expressions as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include only A, only B, or both A and B.

[0033] References throughout this specification to "one embodiment," "an embodiment," "a non-limiting preferred embodiment," or similar terms mean that a particular feature, structure, or characteristic described in connection with the illustrated embodiment is included in at least one embodiment of the solution. Thus, the phrases "in one embodiment," "in an embodiment," "in a non-limiting preferred embodiment," and similar terms throughout this specification may all refer to the same embodiment, but need not.

[0034] Moreover, the features, advantages and characteristics of the present disclosure described may be combined in any suitable manner in one or more embodiments. In view of the description of this specification, those skilled in the art will recognize that the present disclosure may be implemented without using one or more of the specific features or advantages of a specific embodiment. In other examples, in a specific embodiment, additional features and advantages that are sometimes not present in all embodiments of the present disclosure may be recognized.

[0035] In addition, when the term "vehicle" is used in this specification, it can refer to any electric and / or mechanical machine that can carry or transport people and / or goods, such as a car, truck, motorcycle, bus, bicycle, or mobility scooter.

[0036] Exemplary embodiments consistent with the present disclosure provide methods, systems, and apparatus for managing one or more devices within one or more vehicle systems. Specifically, exemplary embodiments provide a device management system (and a method for utilizing the system) that can provide centralized management of devices within a vehicle system. Therefore, devices within a vehicle system, such as remote devices and user devices, can be effectively and efficiently managed without manual operation or physical access to the devices. Ultimately, exemplary embodiments of the present disclosure can achieve efficient and effective management of a considerable number of devices, thereby solving the problems in the prior art systems described above.

[0037] The features, advantages and importance of the exemplary embodiments described above are only part of the present disclosure and are not intended to be exhaustive or to limit the technical scope of the present disclosure. Further descriptions of the features, components, configurations, operations and implementations of the exemplary embodiments of the present disclosure and the advantages and importance of the associated technologies will be provided below.

[0038] Figure 1 1 is a block diagram of an exemplary system configuration 100 for managing one or more devices within a vehicle system according to one or more embodiments. Figure 1 As shown, the system configuration 100 may include a device management system 110, a plurality of user equipments (UE: user equipment) 120-1 to 120-N, a plurality of devices 130-1 to 130-N, a database 140, and a network 150. In this regard, it should be understood that the "one or more devices in the vehicle system" described in this specification may refer to one or more of the plurality of UEs 120-1 to 120-N, the plurality of devices 130-1 to 130-N, and the database 140.

[0039] Generally speaking, the device management system 110 can be coupled to multiple UEs 120-1 to UE 120-N, multiple devices 130-1 to devices 130-N, and a database 140 in a communicative manner via a network 150, and can be configured to manage the mutual operation between the devices. For example, the device management system 110 can be configured to manage the access of UE 120-1 to device 130-1 and / or database 140, and can be configured to aggregate and collect information of devices 130-1 to devices 130-N, etc. Figure 2 The components that may be included in the device management system 110 are described below with reference to Figures 3 to 7 Operations that can be performed by the device management system 110 are described.

[0040] Multiple UEs 120-1 to UE 120-N may include one or more systems, devices, and any other appropriate devices that can be used by one or more users associated with one or more of devices 130-1 to 130-N. The one or more users are not limited, but may include software developers for developing software / firmware associated with one or more of devices 130-1 to 130-N, managers of one or more of devices 130-1 to 130-N, device management systems 110 and / or databases 140, vehicle manufacturers or device providers of one or more of devices 130-1 to 130-N, and drivers / users of one or more of devices 130-1 to 130-N. One or more users may also be located in geographically different places from each other.

[0041] Multiple UE120-1~UE120-N can be used by more than one associated user to access the device management system 110 and use the device management system 110. Specifically, the user can access the device management system 110 via the associated UE to manage one or more devices in the vehicle system. For example, the user can use the device management system 110 via the associated UE to: search for one or more available devices, browse the information of one or more available devices, request information or services from one or more available devices, etc. In addition, the user can also use the device management system 110 to: register information associated with one or more devices, request access to one or more devices, update the roles of one or more users, etc.

[0042] According to an embodiment, one or more of the plurality of UE120-1 to UE120-N may include a computing device (e.g., a desktop computer, a laptop computer, a tablet computer, a handheld computer, a smart speaker, a server, etc.), a mobile device (e.g., a smart phone, etc.), a wearable device (e.g., smart glasses or a smart watch, etc.), a SIM (Subscriber Identity Module)-based device, or any other appropriate device that can establish an association with one or more users. In addition, the plurality of UE120-1 to UE120-N may also include, for example, a workstation, a test system, a software development system, etc.

[0043] According to an embodiment, at least a portion of the plurality of UEs 120-1 to UE 120-N may be located in geographically different places. For example, a first portion of the plurality of UEs 120-1 to UE 120-N may be used by a first user (e.g., a developer of software updates for a first device, etc.), and the first user and the associated UEs may be located in a first place, while a second portion of the plurality of UEs 120-1 to UE 120-N may be used by a second user (e.g., an administrator of the first device, etc.), and the second user and the associated UEs may be located in a second place different from the first place.

[0044] According to an embodiment, the device 130-1 to the device 130-N may include one or more remote devices associated with the vehicle system. In this regard, the remote device described in this specification may refer to an electronic component, subsystem and / or module that is interconnected (e.g., via the network 150) and can communicate with one or more systems (e.g., the device management system 110) and one or more devices (e.g., UE120-1 to UE120-N, database 140, etc.).

[0045] These devices may include the following devices, but are not limited to these devices.

[0046] ・Equipment related to control units in the vehicle, such as the Electronic Control Unit (ECU), Transmission Control Unit (TCU), and Body Control Module (BCM)

[0047] Equipment for vehicle infotainment systems and functions such as audio / video entertainment systems, navigation systems, connectivity functions, and user interfaces

[0048] Telematics equipment such as equipment or components responsible for vehicle communication and remote monitoring that enable services such as remote diagnosis, vehicle tracking, and emergency assistance

[0049] ・Sensor devices such as devices that collect data from various sensors, such as devices related to advanced driver assistance systems (ADAS) and environmental monitoring

[0050] Additionally or alternatively, the devices 130 - 1 to 130 -N may include a plurality of fleet devices or mobile hardware involved in various stages of vehicle manufacturing, a plurality of test hardware involved in testing vehicle functions, and the like.

[0051] Furthermore, one or more of the devices 130-1 to 130-N may be located in a geographically different place from the device management system 110, one or more of the plurality of UEs 120-1 to 120-N, and / or the database 140. Similarly, at least a portion of the devices 130-1 to 130-N may be located in a geographically different place from the other devices 130-1 to 130-N.

[0052] Further references Figure 1 The database 140 may include a server, a repository, or any suitable device that can be configured to store data or information associated with one or more devices in the vehicle system, such as information associated with one or more services provided by the device, information associated with one or more users of the device, location information of the device, schedule or availability information of the device, resource information of the device, etc. According to an embodiment, the database 140 can effectively utilize additional indexing and querying functionalities of a database (e.g., PostgreSQL, etc.) when storing and provisioning device information. Therefore, the database 140 can efficiently manage and retrieve device information based on various benchmarks such as device model, software / firmware information, location of the device, information of users with whom the device is associated, etc.

[0053] According to an embodiment, the database 140 may include a vault, which may include one or more repositories that function as secure storage for confidential or private information within the vehicle system. The vault may use one or more appropriate encryption algorithms and access control mechanisms to protect the information or data stored therein. For example, as described below with reference to Figure 5 As described above, the vault can be configured to interact with a Trusted Platform Module (TPM) corresponding device to securely provide information to the TPM corresponding device via the device management system 110. In addition to or in lieu of TPM technology, the vault can also be configured to interact with the device management system 110 when performing one or more role-based access control (RBAC) operations.

[0054] According to an embodiment, the database 140 (e.g., a safe, etc.) can operate as a centralized inventory database. For example, the database 140 can be configured to collect and store information of multiple devices 130-1 to 130-N, information of multiple UEs 120-1 to UE 120-N, and / or information of associated users, and can be configured to appropriately provide the collected information as needed. In this regard, the term "centralized" described in this specification sometimes refers to the nature of the database 140 when device information is collected and centrally managed regardless of the geographical location of the device.

[0055] Further references Figure 1 The network 150 may include one or more wired and / or wireless networks that may be configured to couple the device management system 110 , the plurality of UEs 120 - 1 ˜ UE 120 -N, the plurality of devices 130 - 1 ˜ 130 -N, and the database 140 to one another.

[0056] For example, the network 150 may include a cellular network (e.g., a fifth generation (5G) network, a long-term evolution (LTE) network, a third generation (3G) network, a code division multiple access (CDMA) network, etc.), a public land mobile communication network (PLMN: Public Land Mobile Network), a local area network (LAN: Local Area Network), a wide area network (WAN: Wide Area Network), a metropolitan area network (MAN: Metropolitan Area Network), a telephone line network (e.g., a public switched telephone network (PSTN: Public Switched Telephone Network)), a private network, an ad hoc network, an intranet, the Internet, a fiber-based network, the like, and / or a combination of these networks or other types of networks.

[0057] According to an embodiment, the network 150 may include a virtual network, which may include one or more physical network components (e.g., Ethernet (registered trademark), WiFi (Wireless Fidelity) module, electrical communication network hardware, etc.) that implement one or more virtual network functions (e.g., a Controller Area Network (CAN) bus, etc.).

[0058] According to an embodiment, one or more devices within the vehicle system may be interconnected via a network 150, and communication between these devices may be performed via OTA (Over-the-Air). For example, the device management system 110 may utilize OTA capabilities to manage the mutual use of one or more devices within the vehicle system, the database 140 may utilize OTA capabilities to collect information and provide it to one or more devices within the vehicle system, and multiple devices 130-1 to 130-N may utilize OTA capabilities to distribute one or more services (or information associated therewith) to other devices within the vehicle system. In this way, OTA communication between the device management system 110 and one or more devices within the vehicle system (e.g., UE120-1 to UE120-N, devices 130-1 to 130-N, and database 140) enables information or services to be communicated in the form of data packets, thereby enabling efficient, secure, and reliable communication and information exchange.

[0059] According to an embodiment, one or more devices within the vehicle system (e.g., one UE among the plurality of UEs 120-1 to UE 120-N, one device among the plurality of devices 130-1 to 130-N, database 140, etc.) may include a trusted platform module (TPM). The TPM may include at least one hardware-based security component such as a security chip, a microcontroller chip, etc., which is integrated into an associated device and is configured to provide a range of hardware-based security functions and features including storage of security information (e.g., security keys, digital certificates, etc.), encryption and / or decryption of data, etc.

[0060] According to an embodiment, the TPM of one or more devices may be configured to manage (e.g., generate, update, provide, etc.) a public-private key pair. A public-private key pair may include a pair of encryption keys used in asymmetric encryption (i.e., encryption using two separate keys, namely a public key and a private key, for encryption and decryption of data or information). For example, a public key may be used to encrypt information that can only be deciphered by a private key, and the public key may be freely shared with any appropriate device within a vehicle system. On the other hand, the private key is kept secret in the associated device and may be used to decipher data encrypted by the corresponding public key. According to an embodiment, the public key may be used to register the associated device in a device management system (hereinafter referred to as a device management system). Figure 4 The public key-private key pair can be accessed through the device management system (hereinafter referred to as Figure 5 Exploited by a device when it accesses services or information from another device.

[0061] It is understandable that, referring to Figure 1 The components and their configurations included in the above-mentioned system configuration 100 are merely exemplary implementations, and the system configuration may include more or fewer components than those described and / or the components included in the system configuration may be configured in any manner different from the method described without departing from the technical scope of the present disclosure. Figure 6 As shown, the system configuration may also include one or more fleet gateways, one or more network load balancers, and one or more virtual private networks (VPN).

[0062] Figure 2 is a block diagram of exemplary components of a device management system 200 of one or more embodiments. The device management system 200 may be used with Figure 1 The same as the device management system 110.

[0063] like Figure 2 As shown, the device management system 200 may include at least one communication interface 210, at least one storage 220, and at least one processor 230. According to an embodiment, the device management system 200 (or one or more components included therein) may be deployed on a server (e.g., a cloud server, a hybrid cloud server, a server cluster, etc.).

[0064] The communication interface 210 may include a transceiver-type component (e.g., a transceiver, a separate receiver and transmitter, a bus, etc.) that enables the device management system 200 (or one or more components included therein) to communicate with one or more components external to the device management system 200 via a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection.

[0065] For example, the communication interface 210 can couple the device management system 200 (or one or more components included therein) to a plurality of UEs (eg, Figure 1 UE120-1 to UE120-N, etc.), multiple devices (for example, Figure 1 Devices 130-1 to 130-N, etc.) and / or databases (e.g., Figure 1 As another example, the communication interface 210 may enable the components of the device management system 200 to communicate with each other. For example, the communication interface 210 may couple the storage 220 to the processor 230, thereby enabling them to communicate and interact with each other.

[0066] According to an embodiment, the communication interface 210 may include a bus interface, an Ethernet (registered trademark) interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, a software interface, or other hardware-based interfaces. According to an embodiment, the communication interface 210 may include at least one controller area network (CAN) bus, which may be configured to communicatively couple components of the device management system 200 (e.g., storage 220, processor 230, etc.) to multiple UEs (e.g., UE120-1 to UE120-N), multiple devices (e.g., devices 130-1 to devices 130-N), and / or a database (e.g., database 140). Additionally or alternatively, the communication interface 210 may include a software-based interface such as an application programming interface (API), a virtual network interface (e.g., a virtual CAN bus, etc.).

[0067] According to an embodiment, the communication interface 210 may be configured to receive information from one or more components external to the device management system 200, and provide the information to the processor 230 for further processing and / or provide the information to the storage 220 for storage. For example, the communication interface 210 may receive one or more information associated with multiple UEs, and may provide the information to the processor 230 and / or the storage 220. Similarly, the communication interface 210 may be configured to enable the processor 230 of the device management system 200 to provide one or more information to one or more components external to the device management system 200.

[0068] Further references Figure 2 , at least one storage 220 may include one or more storage media suitable for storing data, information and / or computer readable instructions / computer executable instructions. Depending on the implementation, the storage 220 may include a random access memory (RAM), a read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions for use by the processor 230.

[0069] Additionally or alternatively, the storage 220 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid-state drive), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cassette, a magnetic tape, and / or another type of non-transitory computer-readable medium, and include a corresponding drive.

[0070] According to an embodiment, the storage 220 may be configured to store information to be utilized by the processor 230 to perform one or more operations for managing one or more updates of one or more devices. For example, the storage 220 may be configured to store device registration information (e.g., as will be referred to below). Figures 3 to 5 etc.), service information (e.g., one or more services provided by one or more devices in the vehicle system), user information (e.g., one or more roles of one or more users, one or more services that can be used by one or more users, etc.). In some implementation forms, at least a portion of the information can be stored in a database (e.g., database 140).

[0071] At least one processor 230 may be configured to receive one or more signals defining one or more instructions for performing one or more operations (e.g., via communication interface 210, etc.). Moreover, processor 230 may be implemented by hardware, firmware, or a combination of hardware and software. Processor 230 may include a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and / or another type of processing or computing component.

[0072] According to an embodiment, at least one processor 230 may include one or more processors that may be programmed to perform functions or operations for managing updates of one or more devices. For example, the processor 230 may be configured to execute computer-readable instructions stored in a storage device (e.g., storage device 220, etc.), thereby performing one or more actions or one or more operations described in this specification.

[0073] It is understandable that, referring to Figure 2 The components and structures included in the above-mentioned device management system 200 are merely exemplary implementations. The device management system 200 may include more or fewer components than those described and / or without departing from the technical scope of the present disclosure, the components included in the device management system 200 may be constructed in any method different from the described method.

[0074] For example, according to an embodiment, the device management system 200 may include an input module (e.g., a touch screen display, buttons, switches, microphones, sensors, keyboards, mice, joysticks, keypads, soft keys, etc.) and / or an output module (e.g., a display, a speaker, a ringer, one or more light-emitting diodes (LEDs), active-matrix organic light-emitting diode (AMOLED) displays and other LED-based displays, thin-film transistor (TFT) displays, liquid crystal displays, etc.), which may be configured to receive one or more user inputs from one or more users and / or output information to one or more users.

[0075] Furthermore, according to an embodiment, the device management system 200 may include a session management module, which is a dedicated module included in or associated with the processor 230, and the device management system 200 facilitates and manages the coordination of one or more sessions between devices in the vehicle system. Figure 6 and Figure 7 To provide an illustration of an exemplary use case of a device management system utilizing a session management module.

[0076] In view of the foregoing, exemplary embodiments of the present disclosure provide a device management system that may be configured to perform one or more operations to effectively and efficiently manage one or more devices within one or more vehicle systems.

[0077] Figure 31 is a flow chart of an exemplary method 300 for managing one or more devices in a vehicle system according to one or more embodiments. One or more operations of the method 300 may be performed by a device management system (e.g., Figure 1 System 110, Figure 2 Specifically, a storage storage (e.g., storage 220) of the device management system may store instructions (e.g., computer-readable instructions, computer-executable instructions, etc.), which, when executed by at least one processor, enables the at least one processor to perform one or more operations of the method 300.

[0078] Generally speaking, a device management system (or at least one processor associated therewith) can receive a message from a first device (e.g., one UE among multiple UEs 120-1 to UE 120-N, one device among multiple devices 130-1 to 130-N, etc.) requesting access to a service from a second device (e.g., another device among multiple devices 130-1 to 130-N, a database 140, etc.), and accordingly, access to the first device and communication between the first device and the second device can be managed.

[0079] In this regard, the term "service" as used herein may refer to any suitable operation or service that can be implemented to achieve one or more intended purposes via the communication of data or information between devices within a vehicle system. Figure 5 As described above, the first device may be a TPM corresponding device that can request confidential information from the vault (i.e., the second device). Therefore, the service provided by the vault may refer to the provisioning of one or more information stored therein. It is understood that any other appropriate service may be implemented in the same manner without departing from the technical scope of the present disclosure.

[0080] like Figure 3 As shown, in operation S310, at least one processor of the device management system may be configured to receive a message from the first device for requesting a service from the second device. For example, the message may be provided by the first device via OTA and may be received by at least one processor via a communication interface (e.g., communication interface 210). The message may include information about the requested service (e.g., the title of the service, the time required for the service, etc.), information about the first device (e.g., identification information (ID), subscriber number, information about a user associated with the first device, etc.), and the like.

[0081] When a request message is received from the first device, the method 300 may proceed to operation S320, and at least one processor of the device management system may be configured to determine whether the first device has been registered in the system. For example, the at least one processor may determine whether a public key associated with the first device is available in one or more storage media (e.g., storage 220) of the device management system based on the ID of the first device (contained in the request message). The public key (or information associated therewith) may be stored in one or more storage media in the form of an ID-public key pair or a mapping.

[0082] Therefore, based on the determination that the public key of the first device can be used, the at least one processor may determine that the first device has been registered, and the method 300 proceeds to operation S330, where the at least one processor may be configured to determine whether the first device has been authenticated.

[0083] Otherwise, based on the determination that the public key of the first device cannot be used, the at least one processor may determine that the first device is not registered, and the method 300 proceeds to operation S340, where the at least one processor may be configured to perform one or more operations for registering the first device. Figure 4 An illustration of exemplary operations for registering a first device is provided.

[0084] When operation S340 is performed, method 300 may proceed to operation S350, where at least one processor may be configured to determine whether the first device has been normally registered. Based on the determination that the first device has been normally registered, method 300 may proceed to operation S330. Otherwise, based on the determination that the first device has not been normally registered, method 300 may end.

[0085] When it is determined that the first device has been registered (or has been registered normally), in operation S330, at least one processor of the device management system may be configured to determine whether the first device has been authenticated. Specifically, the at least one processor may determine whether the first device has permission to use the requested service based on the ID of the first device.

[0086] For example, at least a portion of the request message (received by at least one processor in operation S310) may be encrypted or signed by the first device based on a private key, and the at least one processor may obtain the public key of the first device (based on the ID of the first device), and decrypt the encrypted portion of the request message based on the public key, thereby obtaining information about the requested service. Therefore, the at least one processor may determine whether the first device has the authority to utilize the requested service (based on the mapping of service-permitted devices, the role of the user associated with the first device, etc.).

[0087] Therefore, based on the determination that the first device has the permission to use the requested service, at least one processor may determine that the first device has been authenticated, and method 300 proceeds to operation S360, where at least one processor may perform one or more operations for providing access to the requested service to the first device. Hereinafter, with reference to Figure 5 , an exemplary use case associated therewith will be described. Otherwise, based on the determination that the first device does not have the permission to use the requested service, at least one processor may determine that the first device has not been authenticated, and method 300 may end.

[0088] Figure 4 A flowchart of an exemplary method 400 for registering a device in a vehicle system showing one or more embodiments. One or more operations in method 400 may be part of operation S340 described in Figure 3 this specification and may be executed by at least one processor of the device management system. Figure 4 The device management system 410 of Figure 4 may be the same as the device management system described in this specification with reference to other figures,

[0089] and the device 420 of Figure 4 may be the same as the device and / or the first device described in this specification with reference to other figures.

[0090] Generally, the device 420 may communicate with the device management system 410 to perform registration with the device management system 410. In Figure 4 the example, the registration process is out-of-band (OOB: Out-of-Band) registration based on a public key, which is a registration process for registering and verifying the public key of the device in a secure manner. In this regard, the term "out-of-band" may refer to the use of a separate and independent communication channel or method different from the main communication channel typically used for data or information exchange. In other words, when performing OOB registration with a public key, this process involves: verifying the authenticity and integrity of the public key by effectively using a reliable and secure separate communication channel. In this way, it can be ensured that the public key registered in the device management system is associated with the correct device and is not tampered with during transmission.

[0090] As Figure 4 shown, in operation S410, the registration process may be started. For example, the registration process may be started by the device management system 410 (or at least one processor associated therewith) based on the determination that the device 420 is not registered in the system. Additionally or alternatively, the registration process may be started by the device 420 (e.g., by sending a registration request message to the device management system 410, etc.) when the device 420 first accesses the device management system 410.

[0091] When the registration process is initiated, in operation S420, the device management system 410 (or at least one processor included therein) may establish a separate and highly reliable out-of-band (OOB) channel between the device management system 410 and the device 420. The OOB channel may include physical delivery methods such as physical delivery of key material (directly inputting a public key into the device management system via an input / output module of the device management system, etc.), secure messaging protocols, quick response (QR) codes containing encryption keys, authentication tokens, unique identifiers, interactive voice response (IVR), secure email, or secure file sharing, or any other secure communication channel.

[0092] When the OOB channel is established, in operation S430, the device management system 410 (or at least one processor associated therewith) may obtain or receive the public key of the device 420 via the established OOB channel. In this way, the transfer of the public key ensures that the public key reaches the device management system 410 without being intercepted or tampered with.

[0093] When the public key is received, the device management system 410 may use the public key to register the device 420. For example, the device management system 410 may perform a verification or validation process to ensure the authenticity and integrity of the received public key. As an example, the device management system 410 may perform operations such as verifying a digital signature, comparing the fingerprint of the key, or using other cryptographic techniques to verify the received public key using information associated with the establishment of the device 420 and / or information associated with the user associated with the establishment of the device 420.

[0094] When the public key is verified, the device management system 410 may be configured to register the device 420 with the verified public key. For example, the device management system may generate a mapping of the verified public key and the ID of the device 420, and then, the mapping may be stored in one or more storage media (such as the storage 220, etc.) for future use.

[0095] When the device 420 is registered, the device management system 410 may provide a message containing the registration result to the device 420 to notify the device 420 of the completion / end of the registration process (S440). For example, the device management system 410 may send a message to the device 420 via the OOB channel. After that, the device management system 410 may end the OOB channel.

[0096] For this purpose, the device management system 410 can securely register the device 420. When the registration is successful, the device management system 410 can provide the device 420 with detailed access to various services within the vehicle system. For example, as described below with reference to Figure 5 As described, the device management system can enable the device to communicate with a second device (e.g., a vault) of the vehicle system via the device management system, exchange information or services.

[0097] Figure 5 The system configuration 500 of an exemplary use case for providing a device with access to a requested service, showing one or more embodiments. One or more operations associated with Figure 5 can be part of one or more operations of the method 300 of Figure 3 and can be executed by at least one processor of the device management system. The device management system 510 can be the device management system described in this specification with reference to other figures, the device 520 can be the device and / or the first device described in this specification with reference to other figures, and the vault 530 can be another device and / or the second device described in this specification with reference to other figures. According to an embodiment, the device 520 and the vault 530 can be configured at geographically different locations, and / or can be associated with different users.

[0098] In Figure 5 the example of, the first device (i.e., the device 520) can request a service from the second device (i.e., the vault 530) via the device management system 510. In this regard, the service can refer to the pre-configuration of one or more pieces of information stored in the vault 530. The device management system 510 can receive an encrypted message for requesting a service from the vault 530 from the device 520 in the same manner as described above with reference to Figure 3 the above method. When the request message is received, the device management system 510 can determine whether the device 520 has been registered and authenticated in the same manner as described above with reference to Figure 3 the above method before providing access to the vault 530. The information of the public key required in the registration process and the authentication process can be generated and provided by the TPM 520-1 associated with the device 520.

[0099] In this exemplary use case, it is assumed that the device 520 has been registered and authenticated to access the vault 530 and utilize the services of the vault 530. Therefore, the device management system 510 can decrypt the encrypted message based on the public key of the device 520 (stored in one or more storage media of the device management system 510 during the registration process) and obtain the information of the requested service therefrom. Next, the device management system 510 can communicate with the vault 530 to obtain the requested information from the vault 530.

[0100] When the requested information is obtained, the device management system 510 (or at least one processor associated therewith) may encrypt the obtained information with a public key associated with the device 520 and provide the encrypted information to the device 520. When the encrypted information is received, the device 520 may decrypt the encrypted information and thereby utilize the requested information. For example, the TPM 520-1 of the device 520 may be configured to decrypt the encrypted information with a private key.

[0101] It can be understood that, without departing from the technical scope of the present disclosure, the device management system 510 may obtain and provide any other appropriate service in the same manner. In this way, services (or information associated therewith) can be provided and shared securely among devices in the vehicle system, and the device management system 510 can effectively provide fine-grained access to the devices.

[0102] According to an embodiment, in addition to or instead of using a public key-private key pair, the device management system may also be configured to perform role-based access control (RBAC) to provide detailed access to services or information to devices in the vehicle system. For example, the device management system may include a session management module for handling access and communication among devices in the vehicle system, or be communicatively coupled to the session management module. In several implementations, the session management module may be deployed in the form of computer-executable instructions or a software application program that, when executed by at least one processor of the device management system, causes the at least one processor to perform one or more operations associated with RBAC described in this specification.

[0103] According to an embodiment, the device management system can effectively utilize RBAC for user role assignment. In this regard, settings for associating permissions and access rights with user roles can be made, and these settings for permissions and access rights are associated with the specific responsibilities or scopes of duties of users within the vehicle system (e.g., device managers, service providers, suppliers, etc.). By effectively utilizing RBAC, the device management system can be used to assign one or more roles to one or more users based on the responsibilities and / or real-time requirements of one or more users. According to an embodiment, one or more roles can be dynamically and temporarily assigned to one or more users. For example, one or more users can request or apply for additional roles based on specific conditions within a specific period, and as a result, one or more users can temporarily increase the permissions for specific tasks or have time-limited access permissions to specific services, devices, resources, etc.

[0104] According to an embodiment, the device management system can effectively utilize RBAC for access permission management. For example, the device management system can implement the definition and management of permissions associated with specific actions, services, information, or resources within the vehicle system. One or more permissions can be assigned to one or more roles or can be mapped, and users of the vehicle system can inherit these permissions according to the roles they are assigned. The assignment of access permissions can be performed or managed by the manager of the vehicle system, the vehicle manufacturer, or any other trusted or any other recognized party.

[0105] According to an embodiment, the device management system can effectively utilize RBAC for access control policies enforcement. For example, by effectively utilizing RBAC, the device management system can implement the creation and enforcement of access control policies that define the conditions and rules governing users' access to specific operations, services, information, or resources within the vehicle system. The access control policies can be managed by the manager of the vehicle system, the vehicle manufacturer, or any other trusted or any other authorized party based on factors such as user roles, time-based restrictions, location-based restrictions, or any other appropriate factors.

[0106] It should be understood that, without departing from the technical scope of the present disclosure, in addition to or instead of the operations described in this specification, the device management system can be used to perform any other appropriate RBAC operations. Considering the above situation, when the device management system of an exemplary embodiment manages the communication and mutual operation of devices within a vehicle system, in addition to (referring to Figures 3 to 5 the one or more operations using a public key - private key pair described above), or instead of, one or more RBAC operations can be performed. By effectively utilizing RBAC, the device management system of an exemplary embodiment can provide a flexible and scalable method for access management within a vehicle system, enabling fine-grained control over user permissions, simplifying management, enhancing security, and facilitating compliance with restrictive requirements.

[0107] According to an embodiment, the device management system can be used to manage one or more remote sessions. Figure 6 FIG. 600 shows a system configuration for managing one or more remote sessions between one or more user equipment (UEs) and one or more devices within a vehicle system, which illustrates one or more embodiments.

[0108] As Figure 6 shown, the system configuration 600 may include a device management system 610, multiple UEs 620-1 to 620-N, multiple devices 630-1 to 630-N, a database 640, a virtual private network (VPN: Virtual Private Network) 660, a network load balancer 670, and a cluster gateway 680. The device management system 610, UEs 620-1 to 620-N, devices 630-1 to 630-N, and the database 640 may be the same as one or more of those described in this specification, and thus, for the sake of brevity, the redundant descriptions associated therewith are omitted below. Figures 1 to 5

[0109] Moreover, the components of the system configuration 600 may be coupled to each other in a communicable manner via a network (e.g., network 150). The network for coupling the VPN 660 and the network load balancer 670 to other components is sometimes collectively referred to as the public subnet 650-1, and the network for coupling the device management system 610, the database 640, and the cluster gateway 680 is sometimes collectively referred to as the private subnet 650-2.

[0110] ​In this regard, the public subnet 650-1 can be a network segment with publicly routable IP addresses assigned to components. On the other hand, the private subnet 650-2 can be a network segment that uses private IP addresses, which are reserved for private use within the vehicle system and are not routable on the public Internet. That is, components in the public subnet 650-1 (i.e., the VPN 660 and the network load balancer 670) are permitted to be directly accessed by components from the external network. On the other hand, components in the private subnet 650-2 (i.e., the device management system 610, the database 640, and the cluster gateway 680) are prohibited from being directly accessed by components from the external network. The public subnet 650-1 and the private subnet 650-2, as well as the components associated with them (e.g., the device management system 610, the database 640, the VPN 660, the network load balancer 670, and the cluster gateway 680) can be deployed in one or more cloud computing environments.

[0111] By dividing the network into the public subnet 650-1 and the private subnet 650-2, important components such as the device management system 610 and the database 640 are isolated from external components. The public subnet 650-1 can function as an additional protective layer against external threats, thus enhancing the security of the system.

[0112] The VPN 660 within the public subnet 650-1 can act as a security gateway, enabling the UEs 620-1 to 620-N (which can be located in geographically different locations) to connect to the public subnet 650-1 and ultimately securely access components in the private subnet 650-2 (e.g., the device management system 610) via the Internet. According to an embodiment, the VPN 660 can provide a secure and encrypted communication channel to the UEs 620-1 to 620-N, thereby ensuring data privacy and enabling secure access to the private subnet 650-2 from remote locations.

[0113] The database 640 can be a centralized inventory database (e.g., a vault, etc.) configured to store information about multiple devices 630-1 to 630-N and multiple UEs 620-1 to 620-N. According to an embodiment, the centralized inventory database can include multiple partitions, and each partition can be configured to store information associated with its respective user role. For example, the inventory database can include a first partition configured to store device information associated with a device manager, and the inventory database can include a second partition configured to store device information associated with a maintenance engineer, etc.

[0114] The network load balancer 670 can be a component configured to efficiently and effectively distribute network traffic across devices 630-1 to 630-N. According to an embodiment, the network load balancer 670 can be configured to monitor the status of devices 630-1 to 630-N (e.g., the health status of hardware and / or software, the resource availability status, etc.), and based on this, perform one or more load dispersion operations to ensure optimal load dispersion among devices 630-1 to 630-N, prevent overloading of any specific device, thereby improving the scalability and responsiveness of the vehicle system.

[0115] The cluster gateway 680 can be a reverse proxy and / or communication gateway that acts as a medium between devices 630-1 to 630-N and the device management system 610. According to an embodiment, the cluster gateway 680 can be configured to facilitate secure and encrypted communication between devices 630-1 to 630-N and the device management system 610, to ensure that the information or data exchanged between devices 630-1 to 630-N and the device management system 610 remains confidential and is protected from potential security threats such as interception. Additionally or alternatively, the cluster gateway 680 can be configured to manage communication protocols such as protocol conversion, to enable seamless interaction between devices 630-1 to 630-N (which may use different communication protocols) and the device management system 610 while ensuring compatibility and interoperability.

[0116] From the above viewpoints, the device management system 610 can also be configured to interoperate with the above components to provide one or more remote sessions to one or more of UEs 620-1 to 620-N for accessing one or more of devices 630-1 to 630-N, or for utilizing one or more of devices 630-1 to 630-N. By effectively utilizing the public subnet 650-1, the private subnet 650-2, the VPN 660, the network load balancer 670, and the cluster gateway 680, the device management system 610 can provide enhanced security, scalability, and reliability to one or more remote sessions, while ensuring smooth and seamless operation and optimal performance of devices 630-1 to 630-N within the vehicle system.

[0117] According to an embodiment, the device management system 610 can be configured to automatically collect information of multiple devices 630-1 to 630-N, manage the collected device information, and accordingly, provide the collected device information to one or more users. When the device management system 610 manages the access of users accessing the device information, as referred to in Figures 1 to 6As described above, a public key - private key pair and / or one or more RBAC operations and one or more components in system architecture 600 (e.g., VPN 660, network load balancer 670, cluster gateway 680, etc.) can be utilized.

[0118] Figure 7 A flowchart of an exemplary method 700 for managing device information showing one or more embodiments. One or more operations of method 700 can be performed by at least one processor of the device management system described in this specification. Moreover, one or more operations in method 700 can be the same as one or more operations referred to Figures 3 to 6 above, or can be performed in any suitable order before, after, etc. one or more operations referred to Figures 3 to 6 above.

[0119] As Figure 7 shown, in operation S710, at least one processor of the device management system can be configured to collect information from multiple devices (e.g., devices 130 - 1 to 130 - N, devices 630 - 1 to 630 - N, etc.). For example, at least one processor can continuously (or periodically) gather information of multiple devices by executing one or more API calls. The multiple devices can be configured in geographically different locations and can provide information to at least one processor via OTA. The information can include the status of the devices (e.g., the health status of hardware and / or software, resource status, etc.), the locations of the devices, information of the users associated with the establishment of the devices, etc.

[0120] When the device information is collected, at least one processor of the device management system can be configured to store the collected device information (S720). For example, at least one processor can provide the collected device information to an inventory database (e.g., database 140, database 640, etc.) to store the collected information therein. According to an embodiment, at least one processor can use the collected information to update one or more stored information in the inventory database. In this way, the updated information of the devices available in the vehicle system can be effectively and efficiently aggregated and managed in the centralized inventory database regardless of the geographical locations of the devices.

[0121] In operation S730, at least one processor of the device management system can be configured to receive a message for requesting access to information associated with one or more devices. The message can be provided by the UE via OTA. According to an embodiment, at least a part of the message can be signed or encrypted by the UE (e.g., based on a private key). Thus, at least one processor can be in accordance with the reference Figures 3 to 5The same method as described above is used to manage the UE (e.g., determining whether the UE has been registered and / or authenticated, etc.). It should be understood that in several implementations, the message may not be signed or encrypted, and method 700 may be performed without using a public key - private key pair without departing from the technical scope of the present disclosure.

[0122] In operation S740, at least one processor of the device management system may be configured to identify the role of the user associated with the UE establishment. For example, at least one processor may obtain information about the user role from one or more storage media (e.g., an inventory database, a storage within the device management system, etc.) based on the ID of the UE.

[0123] When the user role is identified, in operation S750, at least one processor of the device management system may be configured to retrieve the requested information based on the user's role. For example, it may be that the request message obtained in operation S730 indicates that the user is requesting information about a remote device, and at least one processor determines that the user has an administrator role. Thus, in operation S750, at least one processor may access the inventory database to obtain information about the remote devices permitted for access by a user with an administrator role. According to an embodiment, at least one processor may access a part of a dedicated inventory database for storing and providing device information associated with the administrator. Moreover, the device information may be aggregated into a historical log file, which may contain information indicating operations performed by other users on the device (e.g., user access, update, configuration, change of location, change of cable configuration, etc.).

[0124] When the information is retrieved, in operation S760, at least one processor of the device management system may be configured to provide the retrieved information to the UE. For example, at least one processor may provide the retrieved information to the UE via OTA. According to an embodiment, at least one processor may encrypt the retrieved information with the public key of the UE, and then, may send the encrypted information to the UE.

[0125] Alternatively or additionally, at least one processor may be configured to include additional information in the retrieved information and provide it to the UE. For example, at least one processor may assign one or more permissions for managing the obtained information to the UE according to the role of the user associated with the UE establishment. As an example, at least one processor can provide the user with permissions or approvals such as viewing and editing information (e.g., read - write information, etc.), viewing information (e.g., read - only information, etc.), sharing information, etc.

[0126] It should be understood that the device management system can be configured to manage access to and communication of any suitable service in the same manner as the methods described above in this specification.

[0127] In view of the above, exemplary embodiments of the present disclosure can provide systems and methods for effectively and efficiently managing one or more sessions between multiple UEs and multiple devices within a vehicle system using the systems and methods.

[0128] For this purpose, exemplary embodiments of the present disclosure provide a device management system (and a method for using the system) that can achieve effective and efficient management of one or more devices in a vehicle system, and the device management system addresses the problems in the prior art as described above.

[0129] It should be understood that the specific order or hierarchy of the functional blocks in the processes / flowcharts disclosed in this specification is an example of an exemplary method. It should be understood that, based on design preferences, the specific order or hierarchy of the functional blocks in the processes / flowcharts can be reconfigured. Moreover, several functional blocks can be combined, or several functional blocks can be omitted. The appended method claims present the elements of the various functional blocks in an exemplary order and do not limit the elements of the various functional blocks to the specific order or hierarchy presented.

[0130] In several embodiments, systems, methods, and / or computer-readable media at any possible level of detail of integrated technologies may be involved. Moreover, one or more of the above-described components can be implemented as instructions stored in a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium having computer-readable program instructions for causing the processor to perform operations.

[0131] A computer-readable storage medium can be an entity device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium is not limited to, for example, the following, but can be an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. A more specific, non-exhaustive list of examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM (Erasable Programmable Read Only Memory) or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, punch card, or a mechanically encoded device such as a raised structure in a slot with recorded instructions, and any suitable combination of the above. Such computer-readable media used in this specification should not be construed as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., optical pulses passing through an optical fiber cable), or electrical signals transmitted through a wire, etc., such signals that are transient in nature themselves.

[0132] The computer-readable program instructions described in this specification can be downloaded from a computer-readable storage medium to each computing / processing device, or can be downloaded to an external computer or external storage device via a network such as, for example, the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter or network interface in each computing / processing device receives the computer-readable program instructions from the network and transmits the computer-readable program instructions to store them in the computer-readable storage medium within each computing / processing device.

[0133] The computer-readable program code / instructions for performing the operations can be any one of assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for an integrated circuit, or source code or object code described in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, etc., and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions can be executed entirely on the user's computer, can be executed partially on the user's computer, can be executed partially on the user's computer and partially on a remote computer as an independent software package, or can be executed entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (e.g., using an Internet service provider to connect through the Internet). In several embodiments, in order to execute a solution or operation, an electronic circuit including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) can utilize the status information of the computer-readable program instructions to personalize the electronic circuit, thereby executing the computer-readable program instructions.

[0134] The computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device for manufacturing a machine, so that the instructions executed via the processor of the computer or other programmable data processing device create a component for implementing the functions / actions specified in the function boxes of the flowchart and / or block diagram. The computer-readable program instructions can also be stored in a computer-readable storage medium, which can direct a computer, a programmable data processing device, and / or other devices to function in a particular manner, so that the computer-readable storage medium with the stored instructions constitutes an article of manufacture, which includes instructions for implementing the solution of the functions / actions specified in the function boxes of the flowchart and / or block diagram.

[0135] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer-implemented process such that the instructions executed on the computer, other programmable apparatus, or other devices implement the functions / acts specified in the function boxes of the flowchart and / or block diagram.

[0136] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each functional box in the flowchart or block diagram may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing a particular logical function. The methods, computer systems, and computer-readable media may include additional functional boxes, fewer functional boxes, different functional boxes, or functional boxes configured differently from those shown in Figure 1 The functional boxes shown in the figures. In several alternative implementations, the functions shown in the functional boxes may occur in a different order than shown in the figures. For example, two consecutive functional boxes shown may actually be executed simultaneously or substantially simultaneously, or sometimes the functional boxes may be executed in the reverse order depending on the functions involved. It should also be noted that each functional box in the examples of the block diagrams and / or flowcharts, and combinations of functional boxes in the examples of the block diagrams and / or flowcharts, can be implemented by a dedicated hardware-based system that performs the specified functions or acts, implementing combinations of dedicated hardware and computer instructions.

[0137] The systems and / or methods described herein may be implemented in different ways in hardware, firmware, or a combination of hardware and software. The actual specific control hardware or software code used to implement the systems and / or methods does not limit the implementations. Thus, it is understood that the operations and behaviors of the systems and / or methods are described herein without reference to specific software code, and that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. A method for managing a plurality of devices in a vehicle system, wherein: The method is implemented by at least one processor of the system, and comprises: Acquire a message from the first device, where the message is used to request a service from the second device, and the message includes identification information ID of the first device; Based on the ID of the first device, determining whether the first device has been registered; Based on a determination that the first device is not registered, performing one or more operations for registering the first device; Determining whether the first device has been registered normally; Determining whether the first device has been authenticated based on a determination that the first device has been registered, or based on a determination that the first device has been normally registered; as well as Based on a determination that the first device has been authenticated, access to the requested service is provided to the first device.

2. The method according to claim 1, wherein: Determine whether the first device has been registered: Based on the ID of the first device, determining whether a public key associated with the first device is available in one or more storage media of the system; Based on the public key of the first device, it can be used to determine that the first device has been registered; as well as Based on the determination that the public key of the first device cannot be used, it is determined that the first device is not registered.

3. The method according to claim 1 or 2, wherein: Performing the one or more operations for registering the first device comprises: establishing an out-of-band (OOB) channel between the system and the first device; receiving information of a public key of the first device from the first device through the OOB channel; registering the first device based on the information of the public key; as well as A result of registering the first device is sent to the first device.

4. The method according to claim 2 or 3, wherein: Based on the information of the public key, registering the first device comprises: verifying the public key; and A mapping of the verified public key to the ID of the first device is generated.

5. The method according to any one of claims 1 to 4, wherein: Determine whether the first device has been authenticated to have: Based on the ID of the first device, determining whether the first device has permission to utilize the requested service; determining that the first device has been authenticated based on a determination that the first device has authority to utilize the requested service; as well as Based on the determination that the first device does not have the authority to utilize the requested service, it is determined that the first device is not authenticated.

6. The method according to any one of claims 1 to 5, wherein: At least a portion of the message is encrypted by the first device based on a private key, Determining whether the first device has the authority to use the requested service comprises: Obtaining a public key of the first device; decrypting the encrypted portion of the message to obtain information of the requested service; as well as Based on the information of the requested service and the ID of the first device, it is determined whether the first device has authority to utilize the requested service.

7. The method according to claim 6, wherein: Providing access to the requested service to the first device comprises: obtaining, from the second device, information associated with the requested service; encrypting the information of the requested service obtained from the second device based on the public key of the first device; as well as The encrypted information is provided to the first device.

8. The method according to claim 7, wherein: The first device is equipped with a trusted platform module TPM, the TPM is configured to manage the public key and the private key, and the first device is configured to decrypt the encrypted information based on the private key.

9. The method according to any one of claims 1 to 8, wherein: The second device is a vault, and the service is a preconfiguration of one or more information stored in the vault.

10. The method according to any one of claims 1 to 9, wherein: The first device and the second device are configured in geographically different locations.

11. A system for managing a plurality of devices in a vehicle system, wherein: The system has: a storage memory storing computer executable instructions; and at least one processor communicatively coupled to the storage memory, The at least one processor is configured to execute the following instructions: Acquire a message from the first device, where the message is used to request a service from the second device, and the message includes identification information ID of the first device; Based on the ID of the first device, determining whether the first device has been registered; Based on a determination that the first device is not registered, performing one or more operations for registering the first device; Determining whether the first device has been registered normally; Determining whether the first device has been authenticated based on a determination that the first device has been registered, or based on a determination that the first device has been normally registered; as well as Based on a determination that the first device has been authenticated, access to the requested service is provided to the first device.

12. The system according to claim 11, wherein: The at least one processor is configured to execute the following instructions: Based on the ID of the first device, determining whether a public key associated with the first device is available in one or more storage media of the system, Based on the public key of the first device, it can be determined that the first device is registered. Based on the determination that the public key of the first device cannot be used, it is determined that the first device is not registered, It is thereby determined whether the first device has been registered.

13. The system according to claim 11 or 12, wherein: The at least one processor is configured to execute the following instructions: establishing an out-of-band OOB channel between the system and the first device, receiving information of a public key of the first device from the first device through the OOB channel, registering the first device based on the information of the public key, sending a result of registering the first device to the first device, The one or more operations for registering the first device are thereby performed.

14. The system according to claim 12 or 13, wherein: The at least one processor is configured to execute the following instructions: verifying the public key, generating a mapping of the verified public key to the ID of the first device, The first device is thereby registered based on the information of the public key.

15. A system according to any one of claims 11 to 14, wherein: The at least one processor is configured to execute the following instructions: determining, based on the ID of the first device, whether the first device has permission to utilize the requested service, determining that the first device has been authenticated based on the determination that the first device has the authority to utilize the requested service, Based on the determination that the first device does not have the authority to utilize the requested service, it is determined that the first device is not authenticated, Thereby, it is determined whether the first device has been authenticated.

16. A system according to any one of claims 11 to 15, wherein: At least a portion of the message is encrypted by the first device based on a private key, The at least one processor is configured to execute the following instructions: obtaining a public key of the first device, decrypting the encrypted portion of the message to obtain information about the requested service, determining whether the first device has the authority to utilize the requested service based on the information of the requested service and the ID of the first device, It is thereby determined whether the first device has the authority to utilize the requested service.

17. The system of claim 16, wherein: The at least one processor is configured to execute the following instructions: obtaining information associated with the requested service from the second device, encrypting the information of the requested service obtained from the second device based on the public key of the first device, providing the encrypted information to the first device, The first device is thereby provided with access to the requested service.

18. The system of claim 17, wherein: The first device is equipped with a trusted platform module TPM, the TPM is configured to manage the public key and the private key, and the first device is configured to decrypt the encrypted information based on the private key.

19. A system according to any one of claims 11 to 18, wherein: The second device is a vault, and the service is a preconfiguration of one or more information stored in the vault.

20. The system according to any one of claims 11 to 19, wherein: The first device and the second device are configured in geographically different locations.

Images