KR102251310B1 - In-vehicle infotainment master and in-vehicle infotainment integrated management system using thereof - Google Patents

Abstract

The present invention relates to a vehicle infotainment master device and a vehicle infotainment integrated management system including the same.
The vehicle infotainment master device according to the present invention includes an input unit for receiving a message from a device or a user, a memory in which a program for performing vehicle infotainment management according to the user's authority level and resource level in response to the received message is stored, and the program is executed. It is configured to include a processor.

Description

Vehicle infotainment master device and vehicle infotainment integrated management system including the same {IN-VEHICLE INFOTAINMENT MASTER AND IN-VEHICLE INFOTAINMENT INTEGRATED MANAGEMENT SYSTEM USING THEREOF}

The present invention relates to a vehicle infotainment master device and a vehicle infotainment integrated management system including the same.

In-vehicle infotainment devices/services are supported through agreements with development companies and car manufacturers, but as each car manufacturer, infotainment device manufacturer, and service provider develop technologies in different forms, mutual compatibility is lacking. And there is a problem of redundant investment.

The present invention has been proposed in order to solve the above-described problem, and proposes an IVI master that manages users and resources of vehicle infotainment, and provides a system that performs integrated management of infotainment according to user authority level and resource level. There is a purpose.

The vehicle infotainment master apparatus according to the present invention includes an input unit for receiving a request message from a device or a user, a memory and a program in which a program for performing vehicle infotainment management according to a user's authority level and resource level in response to the received request message is stored. It consists of a processor that runs.

According to the present invention, it is possible to provide a unified interface for integrated management of a user, an in-vehicle infotainment service, and a device.

According to the present invention, integrated management is performed so that the in-vehicle passenger can check, use and control the in-vehicle device according to the level of the user and the resource through the connection with the IVI master, and dynamic addition of the IVI device. /There is an effect that can be removed management.

The effects of the present invention are not limited to those mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the following description.

1 is a block diagram showing an IVI master according to an embodiment of the present invention.
2 and 3 illustrate a registration procedure of a user (owner, temporary owner) having a privilege level of 1 or 2 according to an embodiment of the present invention.
4 and 5 illustrate a registration procedure of a user (private client) having a privilege level of 3 according to an embodiment of the present invention.
6 and 7 illustrate an authentication procedure of a user (public client) having a privilege level of 4 according to an embodiment of the present invention.
8 and 9 illustrate a registration procedure of an IVI device according to an embodiment of the present invention.
10 illustrates a device control procedure of users (owners, temporary owners) having 1 or 2 authority levels according to an embodiment of the present invention.
11 illustrates a data transfer procedure for users (owners, temporary owners) with authority levels 1 and 2 according to an embodiment of the present invention.
12 illustrates a data transfer procedure for users (private clients, public clients) with authority levels 3 and 4 according to an embodiment of the present invention.
13 shows a device occupancy and control procedure according to an embodiment of the present invention.
14 shows a CCIS environment according to an embodiment of the present invention.

The above-described and other objects, advantages, and features of the present invention, and methods of achieving them will become apparent with reference to the embodiments described below in detail together with the accompanying drawings.

However, the present invention is not limited to the embodiments disclosed below, but may be implemented in various different forms, and only the following embodiments are the object of the invention to those of ordinary skill in the art to which the present invention pertains. It is only provided to easily inform the composition and effect, and the scope of the present invention is defined by the description of the claims.

Meanwhile, terms used in the present specification are for explaining embodiments and are not intended to limit the present invention. In this specification, the singular form also includes the plural form unless specifically stated in the phrase. As used in the specification, "comprises" and/or "comprising" refers to the presence of one or more other components, steps, actions and/or elements in which the recited component, step, operation and/or element is Or does not preclude additions.

Hereinafter, in order to aid the understanding of those skilled in the art, the background to which the present invention is proposed will be first described, and then embodiments of the present invention will be described.

With the recent convergence of ICT technology in automobiles, smart car related industries in the IoT environment are developing at a rapid pace, and with the development of autonomous driving and smart cars, automobiles have advanced from the conventional simple means of transportation, It is becoming another living space.

In the early days of the smart car industry, the focus of technological development was focused on driving safety centered on various sensors, but recently, research on various IT technologies applied with IoT such as connected cars, V2X communication, autonomous driving, and driver interaction services is in progress. , Automakers are preparing an In-Vehicle Infotainment (IVI) platform to integrate various IT technologies into automobiles.

With the development of the Internet of Vehicle (IoV) field, research on short-range wireless communication such as Bluetooth, MirrorLink, Wi-Fi hotspot, and wave for connecting various devices inside and outside the vehicle is actively underway. Research on services through services is currently lacking.

The growth of connected cars and autonomous driving brings changes in the automobile industry, and in particular, the vehicle infotainment service field is a technology field showing rapid growth as it is attracting attention as a service field that will benefit the most from the 5th generation mobile communication technology. Development of various infotainment service providing devices is in progress.

In the future, automobiles are expected to be recognized as shared resources rather than owned resources, and car sharing services are being used as one of the major issues in the automobile industry.

In addition, a service that helps users to conveniently use information on a vehicle's infotainment device and service is being studied.

According to the prior art, vehicle infotainment devices and services are provided through an agreement with the automobile manufacturing industry, and devices and services of companies that are not contracted are difficult to use.

As the mobile platform for smart cars progresses, major IT companies such as Google, Apple, Microsoft, and Baidu are developing automobile infotainment platforms, but as described above, they support their services through agreements with automobile manufacturers. In the current situation, as each automobile manufacturer, infotainment device manufacturer, and service provider develop technologies in different forms due to a lack of standards for the technology, there is a problem of lack of interchangeability and a problem of redundant investment.

As a technology to cope with this current situation, the need to develop a standard protocol for connection management of infotainment devices and services in vehicles has emerged, and CCIS (Car Configuration Infotainment Service) will be installed in vehicles in the near future with increasing infotainment services. It has been proposed as an integrated vehicle infotainment management service that efficiently manages many sensors and devices and helps multiple users share it.

The standardization work of CCIS currently underway in IEC/TC 100/TA 17 defines a common interface of vehicle infotainment, enabling the development of a service independent of the vehicle infotainment platform technically, aiming for further enhanced vehicle infotainment platform scalability. Economically, it aims to reduce the cost of development and lower the barriers to entry into infotainment service development by SMEs through the development of infotainment services that operate on various platforms.

An overview of the CCIS service is shown in FIG. 14, and a CCIS user in a vehicle can use, manage, and control various CCIS resources (devices, services, contents) through a communication interface and a CCIS master device.

1 is a block diagram showing an IVI master (CCIS master) according to an embodiment of the present invention.

Since a car is an environment in which several people share a limited space, it is necessary to classify access rights according to users and resources.

According to an embodiment of the present invention, IVI devices are classified into a shared device and a personal device according to whether or not they can be shared, which will be described later in detail with reference to FIG. 13.

When a resource is related to driving, such as a navigation, only a car driver should be able to operate it, and when music is played through a speaker, everyone in the car space can hear it, so it should be possible to distinguish the person who can operate it.

In addition, there is a need to classify users according to various situations, such as a car owner and a family member, a person using a vehicle sharing service, and a person using public transportation such as a bus or a taxi.

According to an embodiment of the present invention, the user permission level is classified into four levels, and the owner is a substantial owner of a vehicle equipped with an IVI master device, and has overall control rights for CCIS functions and services, That is, it has the highest authority.

The owner does not need to be newly authenticated when reconnecting after the connection with the IVI master is disconnected (reconnecting in the form of logging in to the pre-registered master using the most recently transmitted/received authentication key). Performed).

Temporary owners are temporarily granted rights from vehicle owners (e.g. car sharing or rental services, etc.) and have a certain level of control over CCIS services, that is, level 2 authority.

Temporary owners are granted temporary rights and, like car owners, can use all IVI resources, but must recertify when temporary rights are revoked.

The private client has a level of 3 authority, and does not have the right to own the vehicle like the family of the vehicle owner, but uses the CCIS service through a specific authority granted by the owner.

The owner's private client does not need to be authenticated again after initial authentication, but the temporary owner's private client is revoked with the temporary authority of the temporary owner and the authority to IVI resources.

A public client is a customer who temporarily boards a vehicle.

As described above, according to an embodiment of the present invention, a user is classified into owner, temporal owner, private client, and public client type according to the authority level, and the owner, temporal owner, and private client are registered in the IVI master device. Highly convenient services such as automatic login are provided.

For the convenience of explanation of the embodiments of the present invention, the owner, the temporary owner, the private client, and the public client are defined as referring to terminals possessed by each user.

According to an embodiment of the present invention, CoAP, which is a representative IoT protocol, is used for communication for vehicle infotainment management, and an IVI master that manages the vehicle infotainment device is introduced to perform management of the user's smartphone and IVI device. Do it.

In-vehicle infotainment master apparatus 100 according to an embodiment of the present invention includes an input unit 110 that receives a request message from a device or a user, and in-vehicle infotainment according to the user's authority level and resource level in response to the received request message. A memory 120 in which a program for performing management is stored and a processor 130 for executing the program are included.

The processor 130 operates in a registration mode to broadcast registration-related information for registration of an owner or a temporal owner, and when an owner registration request is received from a terminal included in the candidate list, grants an authentication key and provides a service mode. To perform a mode change to.

When a login request through the authentication key is performed, the processor 130 checks the user table and accepts the login request.

At this time, a login request is made using the most recent authentication key among authentication keys transmitted and received between the processor 130 and the user.

When a private client registration request is received through the input unit 110, the processor 130 transmits a request for authorization check to the owner, transmits a response to the registration request of the private client according to the owner's response, and authentication information To the private client.

When a public client authentication request is received through the input unit 110, the processor 130 transmits a request for authorization check to the owner, transmits a response to the public client's authentication request according to the owner's response, and authentication information Is sent to the public client.

In a device registration process, the processor 130 broadcasts information of a master and registers a device responding thereto, or performs a registration procedure for a device based on the device information broadcasted from the device and received.

The processor 130 processes requests for use and occupancy of resources according to the user's authority level and resource level.

In the case of a request to use a personal device, the processor 130 checks the authentication level, transmits a command list to the user, and transmits the command to the personal device.

In the case of a use request for a shared device, the processor 130 transmits a use request to the owner, transmits a command list to the user according to the permission, and transmits the command to the shared device.

The registration procedure of a user is divided into an owner, a temporary owner, and a private client. FIGS. 2 and 3 show that the user with the authority level of 1 or 2, that is, the owner and the temporary owner, according to an embodiment of the present invention. Shows the registration procedure.

As described above, the owner is the actual owner of the vehicle, and the temporary owner is a user who temporarily has ownership of the vehicle through car sharing or rental service. In view, information on the validity period of the temporary authority is additionally transmitted and received.

Referring to FIG. 2, the master 100 operating in the registration mode broadcasts information of the master (S201).

Upon receiving the broadcasted master information, the owner or temporal owner 200 transmits a request for owner registration to the master 100 (S202).

The master 100 receives the owner registration request and performs a confirmation process (S203), and transmits the owner registration result to the owner or the temporary owner 200 (S204).

Subsequently, when the owner or the temporal owner 200 requests authentication information (S205), the master 100 checks the user table (S206), and then transmits the authentication information as a response (S207).

One master must have at least one owner registered, and if the owner is not registered, the master operates in the registration mode.

The master 100 according to an embodiment of the present invention performs an initialization process before the registration process shown in FIG. 3, and at this time, it has a list of candidates that can become owners.

According to an embodiment of the present invention, the master 100 displays a device connected through an application, so that the user can check whether a legitimate owner is registered.

In the registration mode, the master 100 broadcasts a URL for owner registration and waits for reception of a registration request (S301).

When the master 100 operates in the registration mode, the owner 200 requests registration as owner by sending a POST request to the owner registration URL provided by the master 100 (request registration as owner) (S302).

Upon receiving the registration request from the owner 200, the master 100 transmits the authentication key along with the 201 Created message to the owner 200 (S303), and the service mode in the registration mode (Registration Mode). ) Is converted to (S304).

The registered owner 200 transmits a PUT message along with the authentication key received from the master 100 (S305), and the master 100 checks the user table (S306), and then sends a 200 OK message to the owner (200). ) To (S307), the login of the owner 200 is completed.

The authentication key is continuously used to use the IVI service after logging in. In relation to this authentication key, when a ping message is exchanged according to the connection maintenance between the master 100 and the owner 200, the key is sent every preset period. By changing (for example, by changing the authentication key once every 3 times of sending and receiving a ping message), security is enhanced.

The master 100 and the owner 200 share the latest transmitted/received authentication key, and all authentication keys transmitted and received before that are deleted.

The owner 200 registered in the master 100 requests a login using the latest authentication key previously used in the login process in which the connection is attempted again after disconnection.

As described above, in the case of the temporary owner, the registration procedure is performed by additionally transmitting and receiving information on the valid period of the temporary authority.

4 and 5 illustrate a registration procedure of a user (private client) having a privilege level of 3 according to an embodiment of the present invention.

4, the private client 310 transmits a registration request to the master 100 (S401).

The master 100 transmits an authorization check request to the owner or the temporary owner 200 according to the registration request received from the private client 310 (S402).

Upon receiving the authorization check response (S403) from the owner or the temporary owner 200, the master 100 transmits a confirmation message for the authorization check to the owner 200 (S404), and sends a response to the client registration request to the private client. It is transmitted to (S405).

The private client 310 requests authentication information (S406), and the master 100 receiving the authentication information request checks the user table (S407), and sends the authentication information to the private client 310 to respond (S408). ).

A private client defined as a user with a privilege level of 3 can be registered with the master, and even if the master is not in the registration mode, it can be registered with the master.

Referring to FIG. 5, a user who desires to register requests registration by sending a POST message including user information and a desired authority level 3 to the master 100 (S501).

The master 100 generates a URL for permission of the owner 200 according to the request received in step S501 (S502), and transmits a registration permission request notification to the owner 200 (S503).

The owner (or temporal owner, 200) transmits a PUT message to the generated URL to permit registration of the private client (S504), and the master 100 transmits a 200 OK message to the owner 200 (S505).

The master 100 subsequently transmits a 201 Created message including the authentication key to the private client 310 (S506), and the registration procedure is completed.

The private client 310 transmits a PUT message to the master 100 using the corresponding authentication key to request a login (S507), and checks the user table from the master 100 (S508) and transmits a 200 OK message (S509). As it is performed, the login process is completed.

6 and 7 illustrate an authentication procedure of a user (public client) having a privilege level of 4 according to an embodiment of the present invention.

6, the public client 320 requests authentication information from the master 100 (S601).

After checking the user table (S602), the master 100 transmits an authority check request to the owner or the temporal owner 200 (S603).

The master 100 having received the authorization check response from the owner or the temporal owner 200 (S604) transmits the confirmation for the authorization check to the owner or the temporary owner 200 (S605), and transmits authentication information to the public client (S604). 320) and responds (S606).

Referring to FIG. 7, as a public client, a user must first perform an authentication process in order to use a service through the master 100.

Owners, Temporary Owners, and Private Clients already registered in the Master can be authenticated simply by sending a PUT message, but Public Clients that are not registered must obtain permission from the Owner or Temporary Owner to succeed in authentication.

The public client 320 transmits a PUT message including user information as a payload to the master 100 (S701).

The master 100 generates a URL for authentication (S702), and transmits an authentication related notification to the owner 200 (S703).

Upon receiving the PUT message through the URL for authentication (S704), the master 100 transmits a 200 OK message to the owner 200 (S705), and transmits a 200 OK message including the authentication key to the public client 320 Do (S706).

8 and 9 illustrate a registration procedure of an IVI device according to an embodiment of the present invention.

The device registration process is classified into two cases according to the subject of broadcast and discovery.

Case 1 of FIG. 8 is a case where a device (a first device, 410) broadcasts its own information, and the master 100 searches for a device.

In case 2 of FIG. 8, the master 100 broadcasts its own information and the device (a second device 420) searches for the master 100.

Referring to case 1 of FIG. 8, the first device 410 broadcasts its own information (S801), and the master 100 receiving the information transmits a device discovery notification to the owner 200 ( S802).

When the owner 200 transmits confirmation information on device registration to the master 100 (S803), the master 100 transmits a device registration request to the first device 410 (S804).

When a response to the device registration request is received from the first device 410 (S805), the master 100 transmits a confirmation message for device registration to the owner 200 (S806).

Referring to case 2 of FIG. 8, the master 100 broadcasts information of the master (S807), and the second device 420 that receives the information transmits a recognition notification to the master 100 (S808). ).

The master 100 transmits a device discovery notification to the owner 200 (S809), and the owner 200 transmits confirmation information for device registration to the master 100 (S810).

When the master 100 transmits a device registration request to the second device 420 (S811) and receives a response to the device registration request from the second device 420 (S812), A confirmation message is transmitted (S813).

Since the IVI device is managed by the master and provides a service to the user, it must be registered with the master before being used, and FIG. 9 shows the registration process of the IVI device.

Device addition is performed through the owner. As described above, the device registration process is classified into two cases according to the subject of broadcast and discovery.

Case 1 of FIG. 9 is a case where a device (a first device, 410) broadcasts its own information and a master searches for a device.

In case 2 of FIG. 9, the master broadcasts its own information and the device (second device 420) searches for the master.

Referring to case 1 of FIG. 9, the first device 410 broadcasts its own information (S901), and the master 100 receiving the corresponding information transmits a device discovery notification to the owner 200 ( S902).

The owner 200 transmits a POST message including a URL for device registration (S903), and the master 100 transmits a GET message to the first device 410 as a URL (S904).

The first device 410 must be operating in a registration mode, and if it is a normal registration request, the first device 410 transmits a 2.05 Contents message along with its own information, information such as a service that it can provide, and a service interface (S905).

When the first device 410 provides information such as a service interface to the master 100, the information includes use right information for each service.

Such usage rights information can be changed by the owner, but if the manufacturer prohibits the change, the owner cannot change the rights as well.

Upon receiving the 2.05 Contents message, the master 100 stores the information included in the payload in the master's storage and transmits a 201 Created message including the infotainment ID to the owner 200 (S906), indicating that the device has been successfully registered. Inform.

Referring to case 2 of FIG. 9, the master 100 broadcasts information of the master (S907), and the second device 420 that receives the information transmits a PUT message to the master 100 (S908). ).

The master 100 transmits a device discovery notification to the owner (S909), the owner 200 transmits a POST message including a URL for device registration (S910), and the master 100 transmits a second device 420 Sends a GET message to the URL as a URL (S911).

The second device 420 must be operating in a registration mode, and if it is a normal registration request, it transmits a 2.05 Contents message along with its own information, information such as a service that it can provide, and a service interface (S912).

Upon receiving the 2.05 Contents message, the master 100 stores the information included in the payload in the storage of the master 100 and transmits a 201 Created message including the infotainment ID to the owner 200 (S913), and the device It informs you that you have been successfully registered.

Devices are divided into shared devices and personal devices, depending on whether they can be shared, and shared devices are devices shared by in-vehicle users such as air conditioners, navigation, and speakers, and personal devices are heated seats, It is a device that can be used personally, such as a headrest display.

The shared device can be used only by the owner or the temporary owner, and in order for the owner or a user who is not the temporary owner to use it, it can be used only when a permission acquisition procedure is followed.

Personal devices have different access rights depending on the device, and any user who meets the level of access rights can use them.

If a user with an unsuitable access authority level wants to use the device, it must obtain permission from the owner or temporary owner.

10 illustrates a device control procedure of users (owners, temporary owners) having 1 or 2 authority levels according to an embodiment of the present invention.

The owner or the temporal owner 200 transmits a request for device occupancy to the master 100 (S1001), and receives a response to the occupancy request from the master 100 (S1002).

The owner or temporal owner 200 transmits a request for device control to the master 100 (S1003), the master 100 transmits a device control command to the device 400 (S1004), and sends a confirmation message to the device. Received from 400 (S1005), a response to the device control command is transmitted to the owner or temporal owner 200 (S1006).

11 illustrates a data transfer procedure for users (owners, temporary owners) with authority levels 1 and 2 according to an embodiment of the present invention.

When the owner or the temporal owner 200 requests a data transfer from the master 100 (S1101), the master 100 transmits a notification about the data transfer to the device 400 (S1102), and from the device 400 A confirmation of the data transfer is received (S1103), and a response to the data transfer is transmitted to the owner or the temporary owner 200 (S1104).

Subsequently, a data transfer process between the owner or temporal owner 200 and the master 100 and the master 100 and the device 400 is performed (S1105).

12 illustrates a data transfer procedure for users (private clients, public clients) with authority levels 3 and 4 according to an embodiment of the present invention.

When the client 300 transmits a data transfer request to the master 100 (S1201), the master 100 transmits a permission check request to the owner or the temporary owner 200 (S1202).

Upon receiving the response (S1203) to the authority check from the owner or the temporary owner 200, the master 100 transmits a confirmation message for the authority check to the owner or the temporary owner 200 (S1204), and to the data transfer. The notification is transmitted to the device 400 (S1205).

Upon receiving a confirmation message for data transfer from the device 400 (S1206), the master 100 transmits a data transfer response to the client 300 (S1207), and the client 300, the master 100, and the master ( 100) and the data transfer process between the device 400 is in progress (S1208).

13 shows a device occupancy and control procedure according to an embodiment of the present invention.

In order for a user to use a device, a user must request use from the master and occupy the device, and in case of an inappropriate occupancy request, the owner or temporary owner must obtain permission.

Inappropriate occupancy requests include 1) when a user requests occupancy of a device that is already occupied, 2) when a user other than the owner or temporary owner requests occupancy of the shared device, 3) the user does not meet his or her authority There are cases when requesting possession of a device that does not exist.

FIG. 13 is a diagram illustrating a procedure for occupying an appropriate device and an inappropriate device through an occupation and control process of a personal device and a shared device.

The client 300 transmits a GET message to the master 100 using an authentication key obtained in the authentication process (S1301).

The master 100 checks the authority level (S1302), and transmits a command list that can be executed through the device when the occupancy is successful to the client 300 (S1303).

The client 300 having obtained the command list transmits a PUT message including a command and an authentication key that can be transmitted with its own authority to the master 100 (S1304), and the master 100 When it is confirmed that there is no abnormality according to the authorization check, the device 430 transmits a PUT message including a command to perform control (S1305).

The headrest display 430, which is a personal device, transmits the changed state according to the control to the master 100 (S1306), and the master 100 transmits a 200 OK message to the client 400 (S1307).

Devices may have different rights for each service provided, and certain services may require higher rights than occupancy (e.g., changing settings such as screen ratio, resolution, etc.), so the master 100 is authorized for each occupancy request and control request. Perform the inspection.

When the client 300, not the owner or the temporal owner, wants to use the shared device, the client 300 transmits a GET message including an authentication key to the master 100 (S1308), and the master 100 has the authority level And generates a URL for authentication (S1309), and transmits an authentication notification to the owner 200 (S1310).

When receiving a PUT message from the owner 200 through a URL (S1311), the master 100 transmits a 200 OK message to the owner 200 (S1312), and 200 OK including the command list to the client 400 The message is transmitted (S1313).

Upon receiving the PUT message including the command from the client 300 (S1314), the master 100 transmits a PUT message including the command to the air conditioner (an example of a sharing device, 440) to perform control (S1315).

The air conditioner 440, which is a sharing device, transmits the changed state according to the control to the master 100 (S1316), and the master 100 transmits a 200 OK message to the client 300 (S1317).

That is, when a user other than the owner or the temporal owner wants to use the shared device, the master creates a URL for obtaining permission, and waits for a permission message from the owner or the temporary owner.

Upon receiving the permission message, the master delivers the command list and an authentication key that can be used temporarily to the client that requested the occupancy.

According to an embodiment of the present invention, when the first user occupies the device, it is possible to release the occupancy of the device by the second user who has established a preset relationship with the first user.

For example, even if both the first user and the second user are private clients, to respond to a specific scenario, the level authority of the first user and the second user is subdivided into upper/lower private clients based on the administrative supervisory authority. It is possible to become.

That is, it is assumed that the first user is a child and the second user is a guardian of the child. For example, it is assumed that the first user uses a content service through a headrest display (personal device) in a seated position.

Like the first user, the second user corresponds to a private client according to the user classification, but because the second user has the authority to manage and supervise the first user, the second user transmits a request to release the device occupancy of the first user to the master. And, it is possible to release the device occupancy state of the first user.

So far, we have looked at the center of the embodiments of the present invention. Those of ordinary skill in the art to which the present invention pertains will be able to understand that the present invention may be implemented in a modified form without departing from the essential characteristics of the present invention. Therefore, the disclosed embodiments should be considered from an illustrative point of view rather than a limiting point of view. The scope of the present invention is shown in the claims rather than the above description, and all differences within the scope equivalent thereto should be construed as being included in the present invention.

Claims (13)

An input unit for receiving a request message from a device or a user;
A memory storing a program for performing vehicle infotainment management in response to the request message; And
Including a processor that executes the program,
The processor performs integrated management of user registration, device registration, and device occupancy and use according to the user's authority level and resource level,
The level of authority of the user is classified into owner, temporal owner, private client, and public client, and the level of the resource is classified into shared device and personal device,
In transmitting and receiving a ping message according to connection maintenance to the registered device, the processor changes the authentication key every preset period,
The processor classifies and manages the plurality of private clients into upper private clients and lower private clients based on management and supervision authority.
In-vehicle infotainment master device.
delete The method of claim 1,
The processor operates in a registration mode to broadcast registration-related information, and upon receiving an owner registration request, grants an authentication key to perform a registration process, and performs a mode change to a service mode.
In-vehicle infotainment master device.
The method of claim 3,
When a login request using the latest authentication key shared with a user is received, the processor determines whether to accept the login request according to a user table check result.
In-vehicle infotainment master device.
The method of claim 1,
Upon receiving the registration request from the private client, the processor transmits an authorization check request to the owner or the temporary owner, and transmits authentication information to the private client in response to the authorization check request to perform a registration process.
In-vehicle infotainment master device.
The method of claim 1,
The processor receives a registration or authentication request including an authority as a client from a user, transmits an authority check request to the owner or temporary owner, and transmits authentication information to the user in response to the authority check request.
In-vehicle infotainment master device.
The method of claim 1,
The processor transmits the command list of the resource to the user, and transmits the command received from the user to the resource, referring to the level of the resource and the level authority of the user who transmitted the request to use the resource.
In-vehicle infotainment master device.
The method of claim 7,
When receiving a request for use of a personal device, the processor verifies the authentication level and transmits the command list to the user, and when receiving a request for use of the shared device from a user other than the owner, the processor confirms the Delivering a list of commands for shared devices to the user
In-vehicle infotainment master device.
Vehicle infotainment device;
Vehicle infotainment user terminal; And
In consideration of the level of the vehicle infotainment device and the level authority of the vehicle infotainment user terminal, comprising a master device that performs integrated management for registration and use,
The master device changes the authentication key every preset period in transmitting and receiving a ping message according to connection maintenance to the registered user terminal, and the user terminal classified as an owner, a temporary owner, a private client, and a public client. Manages the level authority of, but classifies and manages the plurality of private clients into upper private clients and lower private clients based on management and supervision authority.
In-vehicle infotainment integrated management system.
The method of claim 9,
The vehicle infotainment device is classified into a shared device and a personal device according to whether or not it can be shared.
In-vehicle infotainment integrated management system.
delete The method of claim 9,
After the vehicle infotainment user terminal corresponding to the owner, the temporal owner, and the private client is registered with the master, the vehicle infotainment terminal is logged in by transmitting a message including an authentication key, and the vehicle infotainment terminal corresponding to the public client is the owner or Receiving an authentication key from the master device upon obtaining authentication permission from the temporary owner
In-vehicle infotainment integrated management system.
The method of claim 9,
The master device transmits a command list of the vehicle infotainment device to the vehicle infotainment user terminal in consideration of the level of the vehicle infotainment device and the level authority of the vehicle infotainment user terminal that transmitted the request for use of the vehicle infotainment device. that
In-vehicle infotainment integrated management system.

Images