System and method for managing devices in vehicle system

Abstract

To provide a method and a system for managing devices in a vehicle system.SOLUTION: The method includes: obtaining, from a first device, a message for requesting a service from a second device and including identification information (ID) of the first device; on the basis of the ID of the first device, determining whether the first device is registered; on the basis of determining that the first device is not registered, performing operations to register the first device; determining whether the first device is successfully registered; on the basis of determining that the first device is registered or on the basis of determining that the first device is successfully registered, determining whether the first device is authenticated; and on the basis of determining that the first device is authenticated, providing the first device with an access to the requested service.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] Systems and methods consistent with embodiments as examples of the present disclosure relate to vehicle systems and, in particular, 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 interoperate to provide essential functions such as propulsion, safety, entertainment, connectivity, and advanced driver assistance. Further, in the process of vehicle development and manufacturing, a significant number of devices are involved. For example, various fleet devices or mobile hardware are involved at each stage of vehicle manufacturing, various static hardware such as servers are utilized to store and share information, and various testing hardware is involved in testing the functions of the vehicle.

[0003] In this regard, devices within a vehicle system often need to communicate and share information to ensure seamless operation and improve the user experience. However, efficiently and safely managing these devices poses significant challenges. In particular, conventional systems and approaches for managing devices in vehicle systems often lack comprehensive access management and information control capabilities, causing various problems to be addressed.

[0004] First, conventional systems and approaches often lack a robust mechanism for identifying and authenticating devices, especially when the device is interacting with different users such as users with different roles or responsibilities, users from different teams, users of the vendor, users located in geographically different locations, etc. This can allow unauthorized or compromised devices to access the system, potentially causing security violations or malfunctions.

[0005] Furthermore, conventional systems and approaches often lack centralized comprehensive device information management. This can make it difficult to provide accurate information about all available devices when the number of available devices is significant. For example, it is difficult to comprehensively and timely identify which devices are available, where each device is located, how each device is connected, what the role of each device is, etc. The process for collecting and managing device information can become particularly complex when devices are located in geographically different locations.

[0006] Furthermore, conventional systems and approaches often lack a fine-grained access control mechanism. Therefore, it is difficult to provide appropriate information to users. For example, a user may be provided with a significant amount of information, which can be overwhelming and inefficient when the user tries to quickly grasp the desired information from it. Conversely, a user may be provided with an inefficient amount of information, which can be less information and the user may need to manually obtain additional information.

[0007] In view of at least the above, there is a need to provide an improved system, method, device, etc. for managing devices and related information within a vehicle system. SUMMARY OF THE INVENTION

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

[0009] According to an embodiment, a method for managing a plurality of devices within a vehicle system is provided. The method may be implemented by at least one processor of the system and includes obtaining, from a first device, a message for requesting a service from a second device, the message including identification information (ID) of the first device; determining, based on the ID of the first device, whether the first device is registered; performing one or more operations for registering the first device based on a determination that the first device is not registered; determining whether the first device is registered successfully; determining whether the first device is authenticated based on a determination that the first device is registered or based on a determination that the first device is registered successfully; and providing the first device with access to the requested service based on a determination that the first device is authenticated. The second device may include a bolt, and the service may include provisioning of one or more information stored in the bolt. The first device and the second device may be located at geographically different locations.

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

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

[0012] According to an embodiment, determining whether a first device is authenticated may include determining, based on an ID of the first device, whether the first device has a right to use a requested service, determining that the first device is authenticated based on the determination that the first device has a right to use the requested service, and determining that the first device is not authenticated based on the determination that the first device does not have a right to use the requested service.

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

[0014] According to an embodiment, providing access to a requested service to a first device may include obtaining information related to the requested service from a second device, encrypting the information of the requested service obtained from the second device based on the 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 information encrypted based on the private key.

[0015] According to an embodiment, a system for managing a plurality of devices within a vehicle system is provided. The system may include a memory storage storing computer-executable instructions and at least one processor communicatively coupled to the memory storage. The at least one processor may obtain, from a first device, a message for requesting a service from a second device, the message including identification information (ID) of the first device, determine whether the first device is registered based on the ID of the first device, execute one or more operations for registering the first device based on a determination that the first device is not registered, determine whether the first device is successfully registered, determine whether the first device is authenticated based on a determination that the first device is registered or based on a determination that the first device is successfully registered, and execute instructions for providing the first device with access to the requested service based on a determination that the first device is authenticated. The second device may include a bolt, and the service may include provisioning of one or more pieces of information stored in the bolt. The first device and the second device may be located at geographically different locations.

[0016] According to an embodiment, at least one processor may be configured to execute instructions to determine whether a public key associated with a first device is available in one or more storage media of the system based on the ID of the first device, determine that the first device is registered based on a determination that the public key of the first device is available, and determine that the first device is not registered based on a determination that the public key of the first device is not available, thereby determining whether the first device is registered.

[0017] According to an embodiment, at least one processor may be configured to execute instructions to establish an OOB channel between the system and a 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 the 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 instructions to register a first device by verifying the public key and generating a mapping between the verified public key and the ID of the first device.

[0018] According to an embodiment, at least one processor may be configured to execute instructions to determine whether a first device has the right to use a requested service based on the ID of the first device, determine that the first device is authenticated based on a determination that the first device has the right to use the requested service, and determine that the first device is not authenticated based on a determination that the first device does not have the right to use the requested service, thereby determining whether the first device is authenticated.

[0019] According to an embodiment, at least a part of the message can be encrypted by a first device based on a private key, and at least one processor obtains a public key of the first device, decrypts the encrypted part of the message to obtain information on the requested service, and determines whether the first device has the right to use the requested service by determining whether the first device has the right to use the requested service based on the information on the requested service and the ID of the first device. It can be configured to execute an instruction.

[0020] According to an embodiment, at least one processor obtains information related to the requested service from a second device, encrypts the information on the requested service obtained from the second device based on the public key of the first device, and provides the encrypted information to the first device, so as to provide the first device with access to the requested service. It can be configured to execute an instruction. The first device may include a Trusted Platform Module (TPM), the TPM may be configured to manage public and private keys, and the first device may be configured to decrypt information encrypted based on the private key.

[0021] Additional aspects are partially described in the following description, are partially apparent from the description, or can be realized by practicing the presented embodiments of the present disclosure.

Brief Description of the Drawings

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

[0023]

Figure 1

[0024]

Figure 2

[0025]

Figure 3

[0026]

Figure 4

[0027]

Figure 5

[0028]

Figure 6

[0029]

Figure 7

DETAILED DESCRIPTION OF THE INVENTION

[0030] The following detailed description of the embodiments as examples refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the embodiments to the exact forms disclosed. Modifications and variations are possible in light of the above disclosure, or can be obtained by practice of the embodiments. Additionally, one or more features or components of one or more embodiments can be incorporated into, or combined with, other embodiments (or one or more features of other embodiments). Further, in the description of the operations provided below, it is understood that one or more operations can be omitted, one or more operations can be added, one or more operations can be performed simultaneously (at least in part), and the order of one or more operations can be switched.

[0031] Even if a particular combination of features is recited in the claims and / or disclosed herein, that combination is not intended to limit the disclosure of possible implementations. Indeed, many of these features can be combined in ways not specifically recited in the claims and / or disclosed herein. Each of the dependent claims listed below can depend directly 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] Any element, operation, or instruction used herein should not be construed as decisive or essential unless explicitly described as such. Also, as used herein, the articles "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 intended, the term "one" or similar language is used. Also, as used herein, terms such as "have," "having," "include," "including," etc. are intended to be unrestricted, open terms. Further, the phrase "based on" is intended to mean "at least partially based on" unless explicitly described otherwise. Further, expressions such 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 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 one embodiment," and similar terms throughout this specification may all refer to the same embodiment, but not necessarily so.

[0034] Furthermore, the features, advantages, and characteristics of the present disclosure described can be combined in any suitable manner in one or more embodiments. One of ordinary skill in the art will recognize, in view of the description herein, that the present disclosure can be practiced without using one or more of the particular features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in particular embodiments that may not be present in all embodiments of the present disclosure.

[0035] In addition, as used herein, terms such as "vehicle" can refer to any electric and / or mechanical machine capable of transporting or conveying people and / or goods, such as automobiles, trucks, motorcycles, buses, bicycles, mobility scooters, and the like.

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

[0037] It is intended that the features, advantages, and significance of the above exemplary embodiments are only a part of the present disclosure and are not intended to be comprehensive or to limit the technical scope of the present disclosure. Further explanations of the features, components, configurations, operations, and implementations of the exemplary embodiments of the present disclosure, as well as related technical advantages and significance, are provided below.

[0038] FIG. 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. As shown in FIG. 1, the system configuration 100 can include a device management system 110, a plurality of user equipment (UEs) 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 within a vehicle system" described herein can 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, the device management system 110 can be communicatively coupled to the plurality of UEs 120-1 to 120-N, the plurality of devices 130-1 to 130-N, and the database 140 via the network 150 and can be configured to manage the interoperability between the devices. For example, the device management system 110 can be configured to manage the access of the UE 120-1 to the device 130-1 and / or the database 140 and can be configured to aggregate and collect information such as that of the devices 130-1 to 130-N. The components that can be included in the device management system 110 are described below with reference to FIG. 2, and the operations that can be performed by the device management system 110 are described below with reference to FIGS. 3 to 7.

[0040] The plurality of UEs 120-1 to 120-N may include one or more systems, devices, and any other suitable equipment that can be used by one or more users associated with one or more of the devices 130-1 to 130-N. The one or more users may include, but are not limited to, software developers for developing software / firmware associated with one or more of the devices 130-1 to 130-N, one or more managers of one or more of the devices 130-1 to 130-N, the device management system 110, and / or the database 140, vehicle manufacturers or device vendors of one or more of the devices 130-1 to 130-N, one or more drivers / users of one or more of the devices 130-1 to 130-N, etc. The one or more users may be located at geographically different locations from each other.

[0041] The plurality of UEs 120-1 to 120-N can be used by one or more associated users to access and utilize the device management system 110. Specifically, a user can access the device management system 110 via the associated UE to manage one or more devices within the vehicle system. For example, a user can use the device management system 110 via the associated UE to search for one or more available devices, view information about one or more available devices, request information or services from one or more available devices, etc. Further, a user can use the device management system 110 to register information related to 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 UEs 120-1 to 120-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 smartphone, etc.), a wearable device (e.g., a pair of smart glasses or a smartwatch), a SIM-based device, or any other suitable device that may be associated with one or more users. Also, the plurality of UEs 120-1 to 120-N may include, for example, a workstation, a test system, a software development system, etc.

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

[0044] According to an embodiment, the devices 130-1 to 130-N may include one or more remote devices associated with a vehicle system. In this regard, the remote devices described herein may refer to electronic components, subsystems, and / or modules that are interconnected (e.g., via the network 150) and capable of communicating with one or more systems (e.g., the device management system 110) and one or more devices (e.g., the UEs 120-1 to 120-N, the database 140, etc.). These devices can include, but are not limited to, the following. · Devices related to control units in vehicles such as electronic control units (ECUs), transmission control units (TCUs), body control module (BCM) units, etc. · Devices for vehicle infotainment systems and functions such as audio / video entertainment systems, navigation systems, connectivity functions, user interfaces, etc. · Telematics devices such as devices or components responsible for vehicle communication and remote monitoring that enable services such as remote diagnosis, vehicle tracking, and emergency assistance. · Sensor devices such as devices that collect data from various sensors, such as those related to advanced driver assistance systems (ADAS) and environmental monitoring.

[0045] Additionally or alternatively, devices 130-1 to 130-N may include a plurality of fleet devices or mobile hardware involved in each stage of vehicle manufacturing, a plurality of test hardware involved in testing vehicle functions, etc.

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

[0047] Referring further to FIG. 1, the database 140 may include any suitable device configured to store data or information related to one or more services provided by a server, repository, or device, information related to 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., related to one or more devices within the vehicle system. According to an embodiment, the database 140 can utilize the indexing and querying functionalities of a database (such as PostgreSQL, etc.) when storing and provisioning device information. Thus, the database 140 can efficiently manage and retrieve device information based on various criteria such as device models, software / firmware information, device locations, information of associated users, etc.

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

[0049] According to an embodiment, the database 140 (e.g., bolts, etc.) can operate a centralized inventory database. For example, the database 140 may be configured to aggregate and store information of a plurality of devices 130-1 to 130-N, information of a plurality of UEs 120-1 to 120-N, and / or information of related users, etc., and may be configured to provide appropriately aggregated information as needed. In this regard, the term "centralized" described in this specification may refer to the nature of the database 140 when collectively and centrally managing device information regardless of the geographical location of the devices.

[0050] Referring further to FIG. 1, the network 150 may include one or more wired and / or wireless networks configured to couple the device management system 110, the plurality of UEs 120-1 to 120-N, the plurality of devices 130-1 to 130-N, and the database 140 to each other.

[0051] For example, 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 Network (PLMN), a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a telephone line network (e.g., a Public Switched Telephone Network (PSTN)), a private network, an ad hoc network, an intranet, the Internet, an optical fiber-based network, etc., and / or a combination of these or other types of networks.

[0052] According to an embodiment, network 150 may include a virtual network that includes one or more physical network components (e.g., Ethernet (registered trademark), a WiFi module, telecommunications network hardware, etc.) on which one or more virtual network functions (e.g., a Controller Area Network (CAN) bus, etc.) are implemented.

[0053] According to an embodiment, one or more devices within a vehicle system can be interconnected with each other via network 150, and communication between these devices can be executed via OTA (Over-the-Air). For example, device management system 110 can utilize OTA capabilities to manage interoperability between one or more devices within the vehicle system, database 140 can utilize OTA capabilities to collect and provide information to one or more devices within the vehicle system, and multiple devices 130-1 to 130-N can utilize OTA capabilities to deliver one or more services (or related information) to other devices within the vehicle system. In this way, OTA communication between device management system 110 and one or more devices within the vehicle system (for example, UE120-1 to 120-N, devices 130-1 to 130-N, and database 140) enables information or services to be communicated in the form of data packages, thereby enabling efficient, secure, and reliable communication and information exchange.

[0054] According to an embodiment, one or more devices within a vehicle system (for example, one of multiple UE120-1 to 120-N, one of multiple devices 130-1 to 130-N, database 140, etc.) can include a Trusted Platform Module (TPM). The TPM can include at least one hardware-based security component such as a security chip, a microcontroller chip, etc., and the security chip, the microcontroller chip, etc. are integrated into the associated device and are configured to provide a range of hardware-based security functions and features including storage of security information (for example, security keys, digital certificates, etc.), encryption and / or decryption of data, etc.

[0055] 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 keypair. The public-private keypair may include a pair of cryptographic keys used in asymmetric encryption (i.e., encryption that uses two separate keys, a public key and a private key, for encrypting and decrypting data or information). For example, the public key may be used to encrypt information that can only be decrypted by the private key, and the public key may be freely shared with any suitable device within the vehicle system. On the other hand, the private key is kept secret in the associated device and may be used to decrypt data encrypted with the corresponding public key. According to an embodiment, the public key may be utilized to register the associated device with a device management system (described below with reference to FIG. 4), and the public-private keypair may be utilized by the device when accessing services or information from another device via the device management system (described below with reference to FIG. 5).

[0056] The components and their configurations included in the system configuration 100 described above with reference to FIG. 1 are merely exemplary embodiments, and the system configuration may include more or fewer components than those described, and / or the components included therein may be configured in any manner different from those described without departing from the technical scope of the present disclosure. For example, as shown in FIG. 6, the system configuration may further include one or more fleet gateways, one or more network load balancers, and one or more virtual private networks.

[0057] FIG. 2 is a block diagram of exemplary components of a device management system 200 according to one or more embodiments. The device management system 200 may be similar to the device management system 110 of FIG. 1.

[0058] As shown in FIG. 2, 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.).

[0059] 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, etc.

[0060] For example, the communication interface 210 may couple the device management system 200 (or one or more components included therein) to a plurality of UEs (e.g., UEs 120-1 to 120-N in FIG. 1, etc.), to a plurality of devices (e.g., devices 130-1 to 130-N in FIG. 1, etc.), and / or to a database (e.g., database 140 in FIG. 1, etc.), thereby enabling them to communicate and interoperate with each other. As another example, the communication interface 210 may enable 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 interoperate with each other.

[0061] According to an embodiment, the communication interface 210 may include a hardware-based interface such as 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, etc. According to an embodiment, the communication interface 210 may include at least one controller area network (CAN) bus configurable to communicatively couple components of the device management system 200 (such as the storage 220, the processor 230, etc.) to a plurality of UEs (such as UEs 120-1 to 120-N), a plurality of devices (such as devices 130-1 to 130-N), and / or a database (such as 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 (such as a virtual CAN bus, etc.).

[0062] 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 it to the processor 230 for further processing and / or to the storage 220 for storage. For example, the communication interface 210 may receive one or more information related thereto from a plurality of UEs and provide it 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.

[0063] Referring further to FIG. 2, at least one storage 220 can include one or more storage media suitable for storing data, information, and / or computer-readable / computer-executable instructions. According to an embodiment, the storage 220 can 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) for storing information and / or instructions for use by the processor 230.

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

[0065] According to an embodiment, the storage 220 can be configured to store information 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 can be configured to store device registration information (e.g., one or more mappings of public keys and device identification information (ID) further described below with reference to FIGS. 3 - 5, etc.), service information (e.g., one or more services provided by one or more devices within a vehicle system), user information (e.g., one or more roles of one or more users, one or more services that can be utilized by one or more users, etc.). In some implementations, at least a portion of the information can be stored in a database (e.g., database 140).

[0066] At least one processor 230 may be configured to receive one or more signals (e.g., via communication interface 210, etc.) that define one or more instructions for performing one or more operations. Further, processor 230 may be implemented in 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.

[0067] 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, processor 230 may execute computer-readable instructions stored in a memory storage (e.g., storage 220, etc.), thereby being configured to perform one or more operations or one or more actions described herein.

[0068] It should be understood that the components and their configurations included in the device management system 200 described above with reference to FIG. 2 are merely exemplary embodiments, and the device management system 200 may include more or fewer components than those described, and / or the components included therein may be configured in any manner different from those described without departing from the technical scope of the present disclosure.

[0069] 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, speaker, ringer, one or more light-emitting diodes (LEDs), an LED-based display such as an active-matrix organic light-emitting diode (AMOLED) display, a thin-film transistor (TFT) display, a liquid crystal display, etc.), and may be configured to receive one or more user inputs from one or more users and / or output information to one or more users.

[0070] Furthermore, according to an embodiment, the device management system 200 may include a session management module that is a dedicated module included in or associated with the processor 230, and facilitates and manages the coordination of one or more sessions between devices within the vehicle system. An exemplary use case of the device management system utilizing the session management module is provided below with reference to FIGS. 6 and 7.

[0071] In view of the above, an exemplary embodiment of the present disclosure provides 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.

[0072] FIG. 3 is a flow diagram of an exemplary method 300 for managing one or more devices within a vehicle system according to one or more embodiments. One or more operations of method 300 may be performed by at least one processor (e.g., processor 230) of a device management system (e.g., system 110 of FIG. 1, system 200 of FIG. 2, etc.). Specifically, the memory storage (e.g., storage 220) of the device management system may store instructions (e.g., computer-readable instructions, computer-executable instructions, etc.) that, when executed by at least one processor, enable the at least one processor to perform one or more operations of method 300.

[0073] Generally, a device management system (or at least one processor associated therewith) may receive a message from a first device (e.g., one of the plurality of UEs 120-1 to 120-N, one of the plurality of devices 130-1 to 130-N, etc.) to request access to a service from a second device (e.g., another device among the plurality of devices 130-1 to 130-N, database 140, etc.), and in response, may manage access of the first device and communication between the first device and the second device.

[0074] In this regard, the "service" described herein may refer to any suitable operation or service that may be implemented via communication of data or information between devices within a vehicle system to achieve one or more intended purposes. For example, as described below with reference to FIG. 5, the first device may be a TPM-compatible device and may request confidential information from a bolt (i.e., the second device). Thus, the service provided by the bolt may refer to the provisioning of one or more information stored therein. It can be understood that any other suitable service may be implemented similarly without departing from the technical scope of the present disclosure.

[0075] As shown in FIG. 3, in operation S310, at least one processor of the device management system may be configured to receive a message from a first device to request a service from a second device. For example, the message may be provided by the first device via OTA and 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 when the service is required, etc.), information about the first device (e.g., identification information (ID), subscriber number, information about the user associated with the first device, etc.).

[0076] Upon receiving a request message from the first device, 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 is registered in the system. For example, at least one processor may determine whether a public key associated with the first device (included in the request message) 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. The public key (or related information) may be stored in one or more storage media in the form of an ID-public key pair or a mapping.

[0077] Therefore, based on the determination that the public key of the first device is available, at least one processor may determine that the first device is registered, and method 300 may proceed to operation S330, and at least one processor may be configured to determine whether the first device is authenticated.

[0078] Otherwise, based on the determination that the public key of the first device is not available, at least one processor may determine that the first device is not registered, and method 300 may proceed to operation S340, where at least one processor may be configured to perform one or more operations to register the first device. An explanation of exemplary operations for registering the first device is provided below with reference to FIG. 4.

[0079] Upon performing operation S340, method 300 may proceed to operation S350, where at least one processor may be configured to determine whether the first device is successfully registered. Based on the determination that the first device is successfully registered, method 300 may proceed to operation S330. Otherwise, based on the determination that the first device is not successfully registered, method 300 may end.

[0080] Upon determining that the first device is registered (or successfully registered), in operation S330, at least one processor of the device management system may be configured to determine whether the first device is authenticated. Specifically, at least one processor may be able to determine whether the first device has the right to use the requested service based on the ID of the first device.

[0081] 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 at least one processor may obtain the public key of the first device (based on the ID of the first device), decrypt the encrypted portion of the request message based on the public key, and thereby obtain information about the requested service. Accordingly, at least one processor may determine whether the first device has the right to use the requested service (based on, for example, the service - permission device mapping and the role of the user associated with the first device).

[0082] Accordingly, based on determining that the first device has the right to use the requested service, at least one processor can determine that the first device is authenticated, and method 300 proceeds to operation S360, where at least one processor can perform one or more operations to provide the first device with access to the requested service. With reference to FIG. 5, an illustrative use case related thereto is provided below. Otherwise, based on the determination that the first device does not have the right to use the requested service, at least one processor can determine that the first device is not authenticated, and method 300 can end.

[0083] FIG. 4 shows a flowchart of an exemplary method 400 for registering a device in a vehicle system according to one or more embodiments. One or more operations in method 400 can be part of operation S340 described herein with reference to FIG. 3 and can be performed by at least one processor of a device management system. The device management system 410 in FIG. 4 can be similar to the device management system described herein with reference to other figures, and the device 420 in FIG. 4 can be similar to the device and / or the first device described herein with reference to other figures.

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

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

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

[0087] Once the OOB channel is established, at operation S430, the device management system 410 (or at least one processor associated therewith) can obtain or receive the public key of the device 420 via the established OOB channel. In this way, the transmission of the public key is guaranteed to reach the device management system 410 without the public key being intercepted or tampered with.

[0088] Upon receiving the public key, the device management system 410 can register the device 420 using the public key. For example, the device management system 410 may perform verification or validation procedures to ensure the authenticity and integrity of the received public key. By way of example, the device management system 410 may perform operations such as checking a digital signature, comparing the key fingerprint, or using other cryptographic techniques to verify the received public key using information associated with the device 420 and / or the user associated with the device 420.

[0089] Upon verifying the public key, 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 store the mapping in one or more storage media (such as storage 220, etc.) for future use.

[0090] Upon registering the device 420, the device management system 410 can provide a message containing the registration result to the device 420 to notify the device 420 of the completion / end of the registration procedure (S440). For example, the device management system 410 can send a message to the device 420 via the OOB channel. Thereafter, the device management system 410 can terminate the OOB channel.

[0091] For this purpose, the device management system 410 can securely register the device 420. Upon successful registration, the device management system 410 can provide detailed access of the device 420 to various services within the vehicle system. For example, as described below with reference to FIG. 5, the device management system can enable the device to communicate with a second device (such as a bolt) of the vehicle system via the device management system and exchange information or services.

[0092] FIG. 5 shows a system configuration 500 of an exemplary use case for providing a device access to a requested service according to one or more embodiments. One or more operations related to FIG. 5 may be part of one or more operations of method 300 of FIG. 3 and may be executed by at least one processor of the device management system. The device management system 510 may be the device management system described herein with reference to other figures, the device 520 may be the device and / or the first device described herein with reference to other figures, and the bolt 530 may be another device and / or the second device described herein with reference to other figures. According to an embodiment, the device 520 and the bolt 530 may be located at geographically different locations and / or associated with different users.

[0093] In the example of FIG. 5, the first device (i.e., device 520) can request a service from the second device (i.e., bolt 530) via the device management system 510. In this regard, the service may refer to the provisioning of one or more information stored in the bolt 530. The device management system 510 can receive an encrypted message from the device 520 for requesting a service from the bolt 530 in a similar manner as described above with reference to FIG. 3. Upon receiving the request message, the device management system 510 can determine whether the device 520 is registered and authenticated before providing access to the device 520 in a similar manner as described above with reference to FIG. 3. The public key information required in the registration and authentication procedures can be generated and provided by the TPM 520-1 associated with the device 520.

[0094] In this exemplary use case, it is assumed that device 520 is registered, accesses bolt 530, and is authenticated to utilize the services of bolt 530. Thus, the device management system 510 can decrypt the encrypted message based on the public key of device 520 (stored in one or more storage media of the device management system 510 during the registration process) and then obtain the information of the requested service. Subsequently, the device management system 510 can communicate with bolt 530 to obtain the information requested from bolt 530.

[0095] Upon obtaining the requested information, the device management system 510 (or at least one processor associated therewith) can encrypt the obtained information with the public key associated with device 520 and provide the encrypted service to device 520. Upon receiving the encrypted information, device 520 can decrypt the encrypted information and thereby utilize the requested information. For example, the TPM 520-1 of device 520 can be configured to decrypt the encrypted information with the private key.

[0096] It can be understood that the device management system 510 can obtain and provide any other suitable service in a similar manner without departing from the technical scope of the present disclosure. In this way, services (or information related thereto) can be provided and shared securely among devices within the vehicle system, and the device management system 510 can effectively provide fine-grained access to the devices.

[0097] According to an embodiment, in addition to or instead of using a public-private key pair, the device management system may be configured to perform role-based access control (RBAC) to provide detailed access to services or information to devices within the vehicle system. For example, the device management system may include or be communicatively coupled to a session management module for handling access and communication between devices within the vehicle system. In some implementations, the session management module may be deployed in the form of computer-executable instructions or software applications that cause at least one processor of the device management system to perform one or more operations related to RBAC as described herein when executed by the at least one processor.

[0098] According to an embodiment, the device management system can utilize RBAC for user role assignment. In this regard, user roles can be associated with or assigned to the setting of permissions and access rights related to specific responsibilities or job scopes of users within the vehicle system (e.g., device manager, service provider, vendor, etc.). By utilizing RBAC, the device management system can be used to assign one or more roles to one or more users associated with the vehicle system based on the responsibilities and / or real-time requirements of one or more users. According to an embodiment, one or more roles can be assigned to one or more users dynamically and temporarily. For example, one or more users can request or apply for additional roles based on specific conditions for a specific period of time, as a result of which one or more users can temporarily elevate their permissions for specific tasks or time-limited access rights to specific services, devices, resources, etc.

[0099] According to an embodiment, the device management system can utilize RBAC for access right management. For example, the device management system can enable the definition and management of rights related to specific operations, services, information, or resources within the vehicle system. One or more rights can be assigned or mapped to one or more roles, and users of the vehicle system can inherit these rights according to their assigned roles. The assignment of access rights can be executed or managed by the administrator of the vehicle system, the vehicle manufacturer, or any other reliable or any other authorized party.

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

[0101] It should be understood that the device management system can be utilized to perform any other suitable RBAC operations in addition to, or as an alternative to, the operations described herein, without departing from the technical scope of the present disclosure. In view of the above, the device management system of the exemplary embodiment, when managing the communication and interoperability of devices within the vehicle system, in addition to, or as an alternative to, one or more operations that utilize the public-private key pair (described above with reference to FIGS. 3 to 5), can perform one or more RBAC operations. By leveraging RBAC, the device management system of the exemplary embodiment provides a flexible and extensible approach to access management within the vehicle system, enables fine-grained control over user permissions, simplifies management, promotes security, and facilitates compliance with regulatory requirements.

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

[0103] As shown in FIG. 6, the system configuration 600 can include a device management system 610, a plurality of UEs 620-1 to 620-N, a plurality of devices 630-1 to 630-N, a database 640, a virtual private network (VPN) 660, a network load balancer 670, and a fleet gateway 680. The device management system 610, the UEs 620-1 to 620-N, the devices 630-1 to 630-N, and the database 640 can be similar to those described herein with reference to one or more of FIGS. 1 to 5, and thus, the related redundant descriptions can be omitted hereinafter for the sake of brevity.

[0104] Furthermore, the components of the system configuration 600 can be communicatively coupled to each other via a network (e.g., network 150). The network for coupling the VPN 660 and the network load balancer 670 to other components may be collectively referred to as the public subnet 650-1, and the network for coupling the device management system 610, the database 640, and the fleet gateway 680 may be collectively referred to as the private subnet 650-2.

[0105] In this regard, the public subnet 650-1 may be a network segment having a publicly routable IP address assigned to a component, while the private subnet 650-2 may be a network segment reserved for private use within the vehicle system and utilizing a private IP address that is not routable on the public Internet. That is, the components of 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 an external network, while the components of the private subnet 650-2 (i.e., the device management system 610, the database 640, and the fleet gateway 680) are prohibited from being directly accessed by components from an external network. The public subnet 650-1 and the private subnet 650-2, as well as the components associated therewith (e.g., the device management system 610, the database 640, the VPN 660, the network load balancer 670, and the fleet gateway 680) may be deployed in one or more cloud computing environments.

[0106] By dividing the network into a public subnet 650-1 and a private subnet 650-2, important components such as the device management system 610 and the database 640 are isolated from external components, and the public subnet 650-1 can function as an additional protection layer against external threats, so the security of the system can be enhanced.

[0107] The VPN 660 within the public subnet 650-1 can operate as a secure 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 (such as the device management system 610) in the private subnet 650-2 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 guaranteeing data privacy and enabling secure access to the public subnet 650-1 from remote locations.

[0108] The database 640 can be a centralized inventory database (such as bolts) configured to store information of a plurality of devices 630-1 to 630-N and a plurality of UEs 620-1 to 620-N. According to an embodiment, the centralized inventory database can include a plurality of partitions, and each partition can be configured to store information related to each user role. For example, the inventory database can include a first partition configured to store device information associated with a device manager, and can include a second partition configured to store device information associated with a maintenance engineer or the like.

[0109] 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., hardware and / or software health status, resource availability status, etc.), ensure optimal load distribution among devices 630-1 to 630-N, and perform one or more load balancing operations based thereon to prevent overloading of any particular device, thereby enhancing the scalability and responsiveness of the vehicle system.

[0110] The fleet gateway 680 can be a reverse proxy and / or communication gateway that operates as a mediator between devices 630-1 to 630-N and the device management system 610. According to an embodiment, the fleet 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 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 eavesdropping. Additionally or alternatively, the fleet gateway 680 can be configured to manage communication protocols such as protocol conversion to enable devices 630-1 to 630-N (which may utilize different communication protocols) to seamlessly interact with the device management system 610 while ensuring compatibility and interoperability.

[0111] From the above perspective, the device management system 610 may be configured to interoperate with the above-described components to access one or more of the devices 630-1 to 630-N or to provide one or more remote sessions to one or more of the UEs 620-1 to 620-N for using one or more of them. By leveraging the public subnet 650-1, the private subnet 650-2, the VPN 660, the network load balancer 670, and the fleet 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 the devices 630-1 to 630-N within the vehicle system.

[0112] According to an embodiment, the device management system 610 may be configured to automatically collect information of a plurality of devices 630-1 to 630-N, manage the collected device information, and provide the collected device information to one or more users accordingly. When managing access of a user accessing the device information, the device management system 610 may utilize a public-private key pair and / or one or more RBAC operations, as well as one or more components in the system configuration 600 (such as the VPN 660, the network load balancer 670, the fleet gateway 68, etc.), as described above with reference to FIGS. 1 to 6.

[0113] FIG. 7 shows a flowchart of an exemplary method 700 for managing device information according to one or more embodiments. One or more operations of the method 700 may be executed by at least one processor of the device management system described herein. Further, one or more operations in the method 700 may be similar to one or more operations described above with reference to FIGS. 3 to 6, or may be executed in any suitable order, such as before, after, etc., one or more operations described above with reference to FIGS. 3 to 6.

[0114] As shown in FIG. 7, in operation S710, at least one processor of the device management system may be configured to collect information from a plurality of 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) aggregate information of a plurality of devices by executing one or more API calls. The plurality of devices may be located in geographically different locations and may provide information to at least one processor via OTA. The information may include the status of the device (e.g., the health status of hardware and / or software, resource status, etc.), the location of the device, information of the user associated with the device, and the like.

[0115] Upon collecting device information, at least one processor of the device management system may be configured to store the collected device information. For example, at least one processor can provide the collected device information to an inventory database (e.g., database 140, database 640, etc.) and 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 a centralized inventory database regardless of the geographical location of the devices.

[0116] In operation S730, at least one processor of the device management system can be configured to receive a message for requesting access to information related to one or more devices. The message can be provided by the UE via OTA. According to an embodiment, at least a portion of the message can be signed or encrypted by the UE (e.g., based on a private key). Thus, the at least one processor can manage the UE (e.g., determine whether the UE is registered and / or authenticated) in a manner similar to that described above with reference to FIGS. 3 to 5. In some implementations, the message may not be signed or encrypted, and it should be understood that method 700 can be executed without departing from the technical scope of the present disclosure and without using a public-private key pair.

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

[0118] 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, the request message obtained in operation S730 indicates that the user is requesting information about a remote device, and at least one processor can determine that the user has an administrator role. Thus, in operation S740, at least one processor can access the inventory database to obtain information about remote devices that is permitted to be accessed by a user with an administrator role. According to an embodiment, at least one processor can access a portion of a dedicated inventory database for storing and providing administrator-related device information. Further, the device information can be aggregated in a history log file that may include information indicating what other users have done on the device (e.g., user access, updates, configurations, location changes, cable configuration changes, etc.).

[0119] When retrieving the information, 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 can provide the retrieved information to the UE via OTA. According to an embodiment, at least one processor can encrypt the retrieved information with the public key of the UE and then transmit the encrypted information to the UE.

[0120] 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 can assign one or more permissions for managing the acquired information to the UE according to the user role associated with the UE. As an example, at least one processor can provide the user with permissions or authorizations such as viewing and editing information (e.g., read and write information, etc.), viewing information (e.g., read-only information, etc.), sharing information, etc.

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

[0122] In view of the above, exemplary embodiments of the present disclosure may provide a system and method for utilizing the same to effectively and efficiently manage one or more sessions between a plurality of UEs and a plurality of devices within a vehicle system.

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

[0124] It should be understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed herein is an example of an exemplary approach. Based on design preferences, it should be understood that the specific order or hierarchy of blocks in a process / flowchart can be reconfigured. Further, some blocks can be combined or omitted. The appended method claims present the elements of the various blocks in an exemplary order and are not limited to the specific order or hierarchy presented.

[0125] Some embodiments can relate to systems, methods, and / or computer-readable media at any possible technical detail level of integration. Further, one or more of the above-described components can be stored on a computer-readable medium and implemented as instructions executable by at least one processor (and / or can include at least one processor). The computer-readable medium can include a computer-readable non-transitory storage medium having computer-readable program instructions for causing a processor to perform operations.

[0126] A computer-readable storage medium can be a tangible device that holds and stores instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but is not limited to, 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 foregoing. A list that does not purport to exhaust all more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, punch cards, mechanically encoded devices such as a raised structure in a groove having recorded instructions, and any suitable combination of the foregoing. A computer-readable medium as used herein should not be construed to be a transitory signal per se, such as radio waves, or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., optical pulses passing through an optical fiber cable), or electrical signals transmitted through a wire.

[0127] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device, or 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 comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each computing / processing device.

[0128] The computer-readable program code / instructions for performing the operations may be in source code or object code in any combination of one or more programming languages, including assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages such as Smalltalk, C++, and procedural programming languages such as the "C" programming language or similar program languages. The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer, and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, 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., through the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute the computer-readable program instructions by personalizing the electronic circuit using the state information of the computer-readable program instructions to perform the aspects or operations.

[0129] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / operations specified in the flowchart and / or block diagram blocks. These computer-readable program instructions can also be stored in a computer-readable storage medium having stored therein instructions that cause a computer, programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium comprises a manufactured article including instructions for implementing the functions / operations specified in the flowchart and / or block diagram blocks.

[0130] The computer-readable program instructions can also be loaded onto a computer, other programmable apparatus, or other device, such that a series of operational steps are performed on the computer, other programmable apparatus, or other device to produce a process that is implemented by the computer, so as to implement the functions / operations specified in the flowchart and / or block diagram blocks.

[0131] The flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible realizations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in the flowchart or block diagram can represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing the specified logical function. The methods, computer systems, and computer-readable media can include additional blocks, fewer blocks, different blocks, or blocks arranged differently than those shown in FIG. 1. In some alternative realizations, the functions shown in the blocks can occur in a different order than shown in the figures. For example, two blocks shown in succession can actually be executed simultaneously, or substantially simultaneously, or, depending on the functions involved, can be executed in the reverse order of the blocks. It will also be noted that each block in the illustration of the block diagram and / or flowchart, and combinations of blocks in the illustration of the block diagram and / or flowchart, can be implemented by a system based on special-purpose hardware that performs the specified function or operation, and a combination of special-purpose hardware and computer instructions.

[0132] The systems and / or methods described herein can be realized in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to realize these systems and / or methods does not limit the embodiments. Therefore, the operation and behavior of the systems and / or methods have been described herein without reference to specific software code, and it is understood that software and hardware can be designed to realize the systems and / or methods based on the description herein.

Claims

1. 1. A method for managing a plurality of devices in a vehicle system, comprising: The method is performed by at least one processor of a system, Obtaining a message from a first device for requesting a service from a second device, the message including an identification (ID) of the first device; determining whether the first device is registered based on the ID of the first device; performing one or more operations to register the first device based on a determination that the first device is not registered; determining whether the first device is successfully registered; determining whether the first device is authenticated based on a determination that the first device is registered or based on a determination that the first device is successfully registered; providing the first device with access to a requested service based on a determination that the first device is authenticated; and A method for providing the above.

2. Determining whether the first device is registered includes: determining whether a public key associated with the first device is available in one or more storage media of the system based on the ID of the first device; determining that the first device is registered based on a determination that the public key for the first device is available; and determining that the first device is not registered based on a determination that the public key for the first device is not available; The method of claim 1 , comprising:

3. Performing the one or more operations to register the first device includes: establishing an out-of-band (OOB) channel between the system and the first device; receiving public key information of the first device from the first device over the OOB channel; registering the first device based on the information of the public key; sending, to the first device, a result of registering the first device; The method according to claim 1 or 2, comprising:

4. Registering the first device based on the information of the public key includes: verifying the public key; generating a mapping between the verified public key and the ID of the first device; The method of claim 3 comprising:

5. Determining whether the first device is authenticated includes: determining whether the first device is authorized to use the requested service based on the identity of the first device; determining that the first device is authenticated based on a determination that the first device is authorized to use the requested service; determining that the first device is not authorized to use the requested service based on a determination that the first device is not authorized to use the requested service; and The method according to claim 1 or 2, comprising:

6. at least a portion of the message is encrypted by the first device based on a private key; Determining whether the first device is authorized to use the requested service includes: Obtaining a public key of the first device; decrypting the encrypted portion of the message to obtain information of the requested service; and determining whether the first device is authorized to use the requested service based on the information of the requested service and the ID of the first device; The method of claim 5 comprising:

7. Providing the first device with access to the requested service includes: obtaining information related to 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 method of claim 6 comprising:

8. the first device comprises a Trusted Platform Module (TPM), the TPM configured to manage the public key and the private key, and the first device configured to decrypt the information encrypted based on the private key; The method of claim 7.

9. the second device is a vault and the service is provisioning of one or more pieces of information stored in the vault; The method according to claim 1 or claim 2.

10. the first device and the second device are located in different geographic locations; The method according to claim 1 or claim 2.

11. 1. A system for managing a plurality of devices in a vehicle system, comprising: a memory storage device storing computer executable instructions; at least one processor communicatively coupled to the memory storage; Equipped with The at least one processor receiving, from a first device, a message for requesting a service from a second device, the message including an identification (ID) of the first device; determining whether the first device is registered based on the ID of the first device; based on a determination that the first device is not registered, perform one or more operations to register the first device; determining whether the first device is successfully registered; determining whether the first device is authenticated based on a determination that the first device is registered or based on a determination that the first device is successfully registered; providing the first device with access to the requested service based on a determination that the first device is authenticated; configured to execute instructions; system.

12. The at least one processor determining whether a public key associated with the first device is available in one or more storage media of the system based on the ID of the first device; determining that the first device is registered based on determining that the public key for the first device is available; determining that the first device is not registered based on a determination that the public key of the first device is not available; determining whether the first device is registered; configured to execute instructions; The system of claim 11.

13. The at least one processor establishing an out-of-band (OOB) channel between the system and the first device; receiving from the first device, via the OOB channel, public key information of the first device; registering the first device based on the information of the public key; Transmitting a result of registering the first device to the first device; performing the one or more operations to register the first device; configured to execute instructions; 13. A system according to claim 11 or claim 12.

14. The at least one processor Verifying the public key; by generating a mapping between the verified public key and the ID of the first device; registering the first device based on the information of the public key; configured to execute instructions; The system of claim 13.

15. The at least one processor determining whether the first device is authorized to use the requested service based on the identity of the first device; determining that the first device is authenticated based on a determination that the first device is authorized to use the requested service; determining that the first device is not authorized to use the requested service based on a determination that the first device is not authorized to use the requested service; determining whether the first device is authenticated; configured to execute instructions; 13. A system according to claim 11 or claim 12.

16. at least a portion of the message is encrypted by the first device based on a private key; The at least one processor Obtaining a public key for the first device; decrypting the encrypted portion of the message to obtain information about the requested service; determining whether the first device is authorized to use the requested service based on the information of the requested service and the ID of the first device; determining whether the first device is authorized to use the requested service; configured to execute instructions; The system of claim 15.

17. The at least one processor obtaining information related to 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; providing the first device with access to the requested service; configured to execute instructions; 17. The system of claim 16.

18. the first device comprises a Trusted Platform Module (TPM), the TPM configured to manage the public key and the private key, and the first device configured to decrypt the information encrypted based on the private key; 20. The system of claim 17.

19. the second device is a vault and the service is provisioning of one or more pieces of information stored in the vault; 13. A system according to claim 11 or claim 12.

20. the first device and the second device are located in different geographic locations; 13. A system according to claim 11 or claim 12.

Images