Greeting method, device, vehicle, medium, and program product

Abstract

This application provides a welcoming method, device, vehicle, medium, and program product. In this method, in response to a vehicle entry event, the driver type is determined, indicating the degree of intimacy between the driver and the vehicle; a greeting event is determined; based on the driver type and the greeting event, a greeting is obtained, with the driver type indicating the tone and style of the greeting, and the greeting event indicating the content of the greeting; the vehicle is then controlled to play the greeting. This application indicates the tone and style of the greeting and the content of the greeting based on the driver type and the greeting event, respectively. This achieves automatic adaptation of the tone and style according to the degree of intimacy between the driver and the vehicle, and automatic adaptation of the greeting content according to the greeting event. This reduces the possibility of user discomfort due to a mismatch between the tone and intimacy when playing the greeting, and avoids the repetitive feeling caused by playing a fixed greeting.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more particularly to a welcoming method, device, vehicle, medium, and program product. Background Technology

[0002] Currently, with the rapid improvement of vehicle intelligence and the increasing demands of users for personalized driving experiences, in-vehicle welcome greeting functions have become increasingly popular. Existing technologies typically use fixed greetings, lacking a personalized experience. Summary of the Invention

[0003] This application provides a welcoming method, device, vehicle, medium, and program product that can solve the problem of the lack of personalized experience in welcoming greetings in the prior art.

[0004] Firstly, embodiments of this application provide a welcoming method applied to a welcoming device in a vehicle, comprising: responding to a vehicle entry event, determining the driver's type, wherein the driver's type indicates the degree of intimacy between the driver and the vehicle; determining a greeting event; obtaining a greeting based on the driver's type and the greeting event, wherein the driver's type indicates the tone and style of the greeting, and the greeting event indicates the content of the greeting; and controlling the vehicle to play the greeting. According to the above technical means, since the driver's type and the greeting event respectively indicate the tone and style and content of the greeting, the method automatically adapts the tone and style according to the degree of intimacy between the driver and the vehicle, and automatically adapts the greeting content according to the greeting event. This reduces the possibility of user discomfort due to a mismatch between the tone and intimacy when playing the greeting, and avoids the repetitive feeling caused by playing a fixed greeting.

[0005] In conjunction with the first aspect mentioned above, one possible implementation involves obtaining a greeting based on the driver type and the event to be greeted. This includes: determining tone-style cue words based on the driver type; determining text cue words based on the event to be greeted; and inputting the tone-style cue words and text cue words into a large language model to obtain the greeting output by the large language model. By converting the driver type and the event to be greeted into tone-style cue words and text cue words respectively, the large language model is simultaneously guided by both tone style and text content when generating greetings. This results in outputting a greeting that is both appropriate to the driver's relationship with the vehicle and matches the current event to be greeted, improving the flexibility and relevance of greeting generation.

[0006] In conjunction with the first aspect mentioned above, one possible implementation involves determining the tone style cue word based on the driver's type. This includes: when the driver's type indicates a level of intimacy (first level), a first tone style cue word is determined, which guides the large language model to output a formal greeting; when the driver's type indicates a level of intimacy (second level), a second tone style cue word is determined, which guides the large language model to output a semi-formal greeting; and when the driver's type indicates a level of intimacy (third level), a second tone style cue word is determined, which guides the large language model to output an informal greeting. Based on these technical means, a clear mapping relationship between driver type and tone style is established, enabling the playback of greetings with different tone styles for drivers with varying levels of intimacy.

[0007] In conjunction with the first aspect mentioned above, one possible implementation involves inputting tone-style prompts and text prompts into a large language model to obtain the greeting output by the large language model. This includes inputting character length prompts, tone-style prompts, and text prompts into the large language model to obtain the greeting output by the large language model. The character length prompts are used to guide the large language model to ensure that the character length of the greeting output by the large language model is less than or equal to a preset character length. Based on the above technical means, by adding a character length constraint, the greeting output by the large language model can be expressed within the preset character length range, avoiding the problem of excessively long greetings caused by the large language model's free generation, and reducing the degree of interference with driving.

[0008] In conjunction with the first aspect mentioned above, one possible implementation involves determining the event to be greeted, which includes: acquiring multi-source data and determining the event to be greeted based on the multi-source data. The multi-source data includes at least one of user data, vehicle data, and environmental data. By introducing multi-source data to determine the event to be greeted, the detection of the event is no longer limited to a single data source. Instead, it can comprehensively utilize multi-dimensional information such as user data, vehicle data, and environmental data, expanding the types and scope of detectable events to be greeted, thereby covering more diverse vehicle usage scenarios.

[0009] In conjunction with the first aspect mentioned above, in one possible implementation, the multi-source data includes user data, which includes the driver's current driving behavior data and historical driving behavior profiles. Based on the multi-source data, the event to be greeted is determined, including: if the current driving behavior data does not conform to the historical driving behavior profile, then the event to be greeted includes a contrast event. Using the above technical means, by comparing the current driving behavior data with the historical driving behavior profile, contrast events can be automatically identified when the driver's current behavior deviates from their historical habitual behavior. This allows the greeting to respond to the driver's unconventional behavior, expanding the dimensions of scenarios that trigger the greeting.

[0010] In conjunction with the first aspect mentioned above, in one possible implementation, the historical driving behavior profile is used to indicate at least one of the driver's historical vehicle entry time, historical clothing type, and historical number of passengers. The current driving behavior data includes at least one of the current vehicle entry time, current clothing type, and current number of passengers. Based on the aforementioned technical means, the specific comparison dimensions between the historical driving behavior profile and the current driving behavior data are clarified, enabling the detection of contrasting events to be based on quantifiable dimensions such as vehicle entry time, clothing type, and number of passengers, thus improving the operability and multidimensionality of contrasting event identification.

[0011] In conjunction with the first aspect mentioned above, before obtaining the greeting based on the driver type and the event to be greeted, the process further includes: acquiring sensory data within the vehicle; detecting whether the in-vehicle environment is a negative environment based on the sensory data; and obtaining the greeting based on the driver type and the event to be greeted, including: if the in-vehicle environment is not a negative environment, then obtaining the greeting based on the driver type and the event to be greeted. By introducing negative environment detection before obtaining the greeting, the acquisition of the greeting can be actively suppressed when the in-vehicle environment is negative, avoiding the output of greetings in inappropriate scenarios, thereby improving the scene adaptability and user experience of the welcoming interaction.

[0012] In conjunction with the first aspect mentioned above, determining the driver's type includes: obtaining the account creation time corresponding to the driver; and determining the driver's type based on the current time and the account creation time. Using the aforementioned technical means, the driver type is determined by the time difference between the account creation time and the current time, providing a clear temporal basis for classifying relationships and eliminating reliance on subjective judgment.

[0013] Secondly, embodiments of this application provide a welcoming device, including: a type determination module, used to determine the type of driver in response to a vehicle boarding event, wherein the driver type is used to indicate the degree of intimacy between the driver and the vehicle; an event determination module, used to determine a greeting event; an acquisition module, used to acquire a greeting based on the driver type and the greeting event, wherein the driver type is used to indicate the tone and style of the greeting, and the greeting event is used to indicate the content of the greeting; and a control module, used to control the vehicle to play the greeting.

[0014] In one possible implementation, the acquisition module is used to: determine tone style prompts based on the driver type; determine text prompts based on the event to be greeted; input the tone style prompts and text prompts into a large language model, and acquire the greeting output by the large language model.

[0015] In one possible implementation, the acquisition module is used to: determine the tone style cue as the first tone style cue when the driver type indicator is at level one, and use the first tone style cue to guide the large language model to output a formal greeting; determine the tone style cue as the second tone style cue when the driver type indicator is at level two, and use the second tone style cue to guide the large language model to output a semi-formal greeting; and determine the tone style cue as the second tone style cue when the driver type indicator is at level three, and use the second tone style cue to guide the large language model to output an informal greeting.

[0016] In one possible implementation, the acquisition module is used to: input character length prompts, tone style prompts, and text prompts into the large language model, and acquire the greeting output by the large language model. The character length prompts are used to guide the character length of the greeting output by the large language model to be less than or equal to a preset character length.

[0017] In one possible implementation, the event determination module is used to: acquire multi-source data, and determine the event to be greeted based on the multi-source data, wherein the multi-source data includes at least one of user data, vehicle data, and environmental data.

[0018] In one possible implementation, the multi-source data includes: the driver's current driving behavior data and historical driving behavior profile; the event determination module is used to: determine the event to be greeted, including the contrast event, if the current driving behavior data does not match the historical driving behavior profile.

[0019] In one possible implementation, the historical driving behavior profile is used to indicate at least one of the driver's historical vehicle entry time, historical clothing type, and historical number of passengers, while the current driving behavior data includes at least one of the current vehicle entry time, current clothing type, and current number of passengers.

[0020] In one possible implementation, the welcoming device further includes a sensing module for: acquiring sensing data inside the vehicle; detecting whether the in-vehicle environment is a negative environment based on the sensing data; and an acquisition module for acquiring a greeting based on the driver type and the event to be greeted if the in-vehicle environment is not a negative environment.

[0021] In one possible implementation, the type determination module is used to: obtain the account creation time corresponding to the driver; and determine the driver's type based on the current time and the account creation time.

[0022] Thirdly, this application provides a vehicle that includes the welcoming device described in the second aspect and any possible implementation thereof.

[0023] Fourthly, this application provides a computer-readable storage medium storing a computer program or instructions that, when executed by a device, cause the device to perform the method of the first aspect or any possible implementation thereof.

[0024] Fifthly, this application provides a computer program product including computer instructions that, when executed on a device, cause the device to perform the method in the first aspect or any possible implementation thereof.

[0025] The second to fifth aspects described above correspond to the technical solutions of the first aspect of the embodiments of this application. The beneficial effects achieved by each aspect and its corresponding feasible implementation are similar, and will not be repeated here. It should be noted that various possible implementations of any aspect described above can be combined, provided that the solutions do not contradict each other. Attached Figure Description

[0026] Figure 1 A flowchart illustrating one embodiment of the welcoming method provided in this application; Figure 2 A flowchart illustrating one embodiment of obtaining a greeting provided in this application; Figure 3 A flowchart illustrating another embodiment of the welcoming method provided in this application; Figure 4 A flowchart illustrating another embodiment of the welcoming method provided in this application; Figure 5 A schematic diagram of a functional module of the welcoming device provided in the embodiments of this application; Figure 6 This is a schematic diagram of a frame of a welcoming device provided in an embodiment of this application. Detailed Implementation

[0027] The embodiments of this application will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Those skilled in the art will recognize that, with the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0028] This application provides a welcome device applicable to the vehicle's IVI (In-Vehicle Infotainment system). The welcome device can be a standalone ECU (Electronic Control Unit), such as a CDC (Cockpit Domain Controller) or onboard unit in the vehicle, or it can be a software module or firmware module integrated into any ECU, such as a welcome device deployed in the CDC.

[0029] Existing in-vehicle greeting methods often suffer from the following technical problems: using the same set of greetings for all users. These templates typically include fixed forms of address (such as nicknames or full names), fixed emotional expressions (such as "dear," "esteemed," etc.), and fixed sentence structures. When this template is applied indiscriminately to all users, it creates significant social discomfort. For example, for new car owners, a greeting containing a nickname or overly enthusiastic language can feel offensive and overly intimate. For long-time users, hearing the same greeting every day becomes monotonous background noise; they don't feel special attention but rather perceive it as mechanical repetition and a lack of sincerity. For casual visitors (such as designated drivers or friends / relatives temporarily driving), it can be confusing and abrupt. Therefore, fixed greeting templates cannot adapt to the dynamic changes in the level of intimacy between the driver and the vehicle.

[0030] To address the aforementioned technical problems, the technical concept proposed in this application is as follows: In response to a boarding event, the driver type and a greeting event are determined separately. The driver type indicates the degree of intimacy between the driver and the vehicle, while the greeting event indicates the content of the greeting. The "driver type" and the "greeting event" serve as two independent decision dimensions. The former controls "how to say it" (tone and style), while the latter controls "what to say" (content). Both work together to determine the greeting, achieving decoupling and adaptive matching of the greeting across the tone and content dimensions.

[0031] The welcoming method provided in this application will be described below with reference to specific embodiments. These embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0032] Reference Figure 1 , Figure 1 This is a flowchart illustrating one embodiment of the welcoming method provided in this application. The entity executing the welcoming method provided in this application can be a welcoming device; in the following embodiments, a CDC (Center for Diagnostics and Health) is used as an example. Figure 1 As shown, the welcoming method provided in this application embodiment may include: Step S10: In response to the boarding event, determine the driver type, which is used to indicate the degree of closeness between the driver and the vehicle.

[0033] In this embodiment of the application, a vehicle entry event refers to a user entering the vehicle and completing the action of preparing to drive. The CDC determines that a vehicle entry event has occurred when at least one of the following conditions is met: Condition 1: The CDC detects that there is an occupant in the driver's seat, and all doors (including the driver's door, passenger door, and rear doors) change from open to closed.

[0034] Condition 2: The CDC detects that the vehicle's power status has switched from OFF to ACC or ON.

[0035] Condition 3: The CDC detects that the driver's seatbelt buckle signal has changed from unlocked to locked.

[0036] Conditions 1 to 3 above are illustrative examples. Conditions for determining whether a boarding event occurs can be configured based on actual needs. This application does not impose any restrictions on this.

[0037] After the CDC confirms that a boarding incident has occurred, it determines the driver type. The driver type is used to indicate the driver's familiarity with the vehicle. In this embodiment, the driver type is divided into three categories: visitor, new user, and old user. A visitor indicates that the driver is completely unfamiliar with the vehicle, a new user indicates that the driver is relatively familiar with the vehicle, and an old user indicates that the driver is very familiar with the vehicle.

[0038] In some embodiments, the degree of intimacy can be divided into different levels, which are used to characterize different degrees of intimacy between the driver and the vehicle. This embodiment of the application uses three levels of intimacy as an example. For instance, a visitor is used to indicate the first level of intimacy, a new user is used to indicate the second level, and a returning user is used to indicate the third level.

[0039] In some embodiments, the CDC maintains a cumulative recognition count field for each driver. This field records the total number of times each driver has been successfully recognized by the facial recognition system, and increments by 1 after each successful recognition. The larger the field, the more frequently the driver uses the vehicle. When the CDC determines the driver's type, it obtains the driver's cumulative recognition count and compares it with a preset threshold: if the cumulative recognition count is less than or equal to the first threshold, the driver is determined to be a visitor; if the cumulative recognition count is greater than the first threshold but less than or equal to the second threshold, the driver is determined to be a new user; if the cumulative recognition count is greater than the second threshold, the driver is determined to be a returning user. In this embodiment, classifying drivers by cumulative recognition count provides an objective and quantitative basis for judgment, avoiding the uncertainty caused by subjective judgment. The cumulative recognition count reflects the frequency of the driver's use of the vehicle; the larger the cumulative recognition count, the higher the driver's familiarity with the vehicle. Based on this, drivers can be classified as visitors, new users, and returning users, which can more accurately reflect the true degree of familiarity between the driver and the vehicle.

[0040] In some embodiments, the CDC may also obtain the account creation time corresponding to the driver and determine the driver type based on the current time and the account creation time.

[0041] In this embodiment, the vehicle is equipped with a DMS (Driver Monitoring System). The DMS collects the driver's facial image, extracts features, and compares them with templates in a local registry. If the comparison is successful, the DMS outputs the user's corresponding UID (User Identifier); if it cannot be identified (e.g., the user is not registered, the face is obscured, or the recognition confidence is below a preset threshold), the DMS outputs an empty UID. The DMS transmits the recognition result (UID or empty UID) to the CDC via an in-vehicle communication network (such as CAN bus or Ethernet). Upon receiving the UID, the CDC uses it as the current driver's identity information and queries the local database to obtain the driver's account creation time (i.e., the timestamp of the first time the driver was successfully identified by the facial recognition system and an identity file was established). If an empty UID is received, the CDC determines that the current driver's account creation time is empty. The CDC determines the driver's type based on the time difference between the current time and the account creation time. If the account creation time is empty, the time difference is invalid, and the CDC determines the driver type as a visitor. If the time difference is less than or equal to a preset first threshold (e.g., 30 days), the CDC determines the driver type as a new user. If the time difference is greater than a preset second threshold (the second threshold is greater than or equal to the first threshold, e.g., 60 days), the CDC determines the driver type as an existing user. In this embodiment, the driver type is determined by the time difference between the account creation time and the current time, providing a clear temporal basis for classifying the degree of intimacy, eliminating the need for subjective judgment.

[0042] Step S20: Determine the event to be greeted.

[0043] In this embodiment, each event to be greeted corresponds to an objectively occurring situation, such as the current date being the driver's birthday or wedding anniversary. The CDC can detect each event to be greeted sequentially or in parallel. For example, it can detect whether the date corresponding to the current boarding time is a public holiday, whether the date corresponding to the current boarding time is the driver's birthday, whether the date corresponding to the current boarding time is the driver's wedding anniversary, and so on. For example, assuming that the date corresponding to the current boarding time is both a public holiday and the driver's birthday, the events to be greeted include both public holiday events and birthday events.

[0044] In some embodiments, the CDC may acquire multi-source data and determine the event to be greeted based on the multi-source data, which includes at least one of user data, vehicle data, and environmental data.

[0045] In this embodiment, the CDC can determine the event to be greeted based on multi-source data. Multi-source data includes at least one of the following: user data (such as current boarding time, last boarding time, driver's UID, driver's clothing type, passenger's UID, current number of passengers, and historical driving behavior profiles), vehicle data (such as in-vehicle temperature, humidity, and in-vehicle audio / video data), and environmental data (such as weather information, ambient temperature, and road condition information). The CDC can run multiple event detectors in parallel, with each detector outputting whether an event has been detected based on the multi-source data. For example, the idle detector calculates the time difference between the current boarding time and the last boarding time. If it is greater than or equal to a preset value, the CDC determines that the event to be greeted includes the vehicle idle event. The anniversary detector checks whether the current boarding time is a couple's anniversary, checks whether there is a UID among all the currently acquired passenger UIDs that is in a couple relationship with the driver's UID, and checks whether there is arguing in the car and whether the driver and passengers are in negative emotions based on in-vehicle audio / video data. If it is a couple's anniversary, there is a UID that is in a couple relationship with the driver's UID, there is no arguing, and neither the driver nor the passengers are in negative emotions, the CDC determines that the event to be greeted includes the couple's anniversary event.

[0046] In this embodiment of the application, by introducing multi-source data to determine the event to be greeted, the detection of the event to be greeted is no longer limited to a single data source, but can comprehensively utilize multi-dimensional information such as user data, vehicle data, and environmental data, thus expanding the types and scope of events to be greeted that can be detected.

[0047] In some embodiments, the multi-source data includes user data, which includes the driver's current driving behavior data and historical driving behavior profile; determining the greeting event based on the multi-source data includes: if the current driving behavior data does not match the historical driving behavior profile, then determining that the greeting event includes a contrast event.

[0048] In this embodiment, the multi-source data includes the driver's current driving behavior data and historical driving behavior profile. The historical driving behavior profile describes the driver's stable habits and typical patterns formed during past vehicle use. The historical driving behavior profile is stored in the CDC local database, using the UID as the primary key. After each vehicle entry event, the CDC updates the current driving behavior data to the driver's history and re-determines the driver's historical driving behavior profile. Current driving behavior data refers to the driving behavior information collected by the CDC in the current vehicle entry event. If the CDC detects that the current driving behavior data does not match the historical driving behavior profile, it determines that the event to be addressed includes a contrasting event.

[0049] Through the embodiments of this application, it is possible to automatically identify contrast events when the driver's current behavior deviates from its historical habitual behavior, thereby enabling the greeting to respond to the driver's unconventional behavior and expanding the scope of scenarios that trigger the greeting.

[0050] In some embodiments, the historical driving behavior profile is used to indicate at least one of the driver's historical vehicle entry time, historical clothing type, and historical number of passengers, and the current driving behavior data includes at least one of the current vehicle entry time, current clothing type, and current number of passengers.

[0051] In this embodiment, in response to each boarding event, the CDC obtains the boarding time and the UID of the user in the driver's seat. Over time, a set of boarding times corresponding to each UID is obtained. For each UID, the CDC performs statistical analysis on the set of boarding times corresponding to that UID to determine the regular boarding time period corresponding to that UID. For example, for a specific UID, the CDC determines the time period within the set of boarding times recorded over the past 30 days, thus determining the regular boarding time period. For instance, if the CDC determines that the time periods from 8:00 to 8:30 and 17:00 to 17:30 are the two time periods containing the most boarding times, then the CDC determines that the regular boarding time period corresponding to that UID includes the 8:00 to 8:30 and 17:00 to 17:30 time periods. If the CDC obtains the current boarding time as 9:00 in response to the latest boarding event, then the CDC determines that a work-rest discrepancy event has occurred; if the CDC obtains the current boarding time as 21:00 in response to the latest boarding event, then the CDC determines that a work-rest discrepancy event has occurred.

[0052] In some embodiments, in response to each vehicle entry event, the DMS or CDC identifies the clothing type of the user in the driver's seat. Over time, a clothing type record corresponding to each UID is obtained. For example, if the clothing type record for a certain UID shows that casual wear appeared 28 times and formal wear appeared 2 times in the past 30 days, then the driver's usual clothing type for that UID is casual wear. If, in response to the latest vehicle entry event, the CDC obtains that the current driver's clothing type is formal wear, then the CDC determines that a clothing discrepancy event exists.

[0053] In some embodiments, in response to each boarding event, the OMS (Occupant Monitoring System) or CDC identifies the number of occupants and determines the UID of the user in the driver's seat. Over time, a record of the number of occupants corresponding to each UID is obtained. For example, if the record for a certain UID shows that the number of occupants was 0 28 times in the past 30 days, then the number of regular passengers corresponding to that UID is 0. If, in response to the latest boarding event, the CDC obtains a current number of passengers that is not 0, then the CDC determines that a discrepancy in passenger numbers has occurred.

[0054] Through the embodiments of this application, the detection of contrast events can be carried out based on quantifiable dimensions such as boarding time, clothing type, and number of passengers, which improves the operability and multidimensionality of contrast event recognition.

[0055] Step S30: Obtain a greeting based on the driver type and the event to be greeted. The driver type indicates the tone and style of the greeting, and the event to be greeted indicates the content of the greeting.

[0056] In some embodiments, the CDC is configured with a mapping table that records the correspondence between driver type, greeting event, and greeting message. Once the CDC determines the driver type and greeting event, it directly queries the mapping table using the driver type and greeting event as indexes to obtain the corresponding greeting message. For example, if the driver type is a visitor and the greeting event is a rainy day event, the corresponding greeting message in the mapping table is "Dear passenger, the roads are slippery in the rain, please be careful." If the driver type is a returning user and the greeting event is a birthday event, the corresponding greeting message in the mapping table is "Happy birthday! How are you planning to spend your day?". The mapping table can also pre-set greeting messages for driver type + combined events. For example, the greeting message for returning user + combined events (work-rest discrepancy event + vehicle idle event) is "Long time no see! You're back so late, you must be tired." This mapping table covers various common combinations of driver types and greeting events, suitable for scenarios with limited vehicle-side computing power or unstable network connections.

[0057] In addition to the above-mentioned method of obtaining greetings based on a mapping table, embodiments of this application also provide another method of obtaining greetings based on a large language model. In some embodiments, refer to Figure 2 , Figure 2 This is a schematic flowchart illustrating one embodiment of obtaining a greeting provided in this application. Figure 2As shown, the greeting is obtained based on the driver type and the event to be greeted, including: step S201, determining tone style cue words based on the driver type; step S202, determining text cue words based on the event to be greeted; step S203, inputting the tone style cue words and text cue words into the large language model to obtain the greeting output by the large language model.

[0058] In this embodiment, the CDC is configured with a first prompt word template, which is used to record the correspondence between driver type and tone style prompt words. For example, the first tone style prompt word for visitors is as follows: Please generate a formal and polite greeting; use the honorific "you" to address the driver as "Dear Driver"; use a complete subject-verb-object sentence structure, without omitting any sentence components; do not use interjections such as "ya," "la," etc.; do not use nicknames. The second tone style prompt word for new users is as follows: Please generate a friendly and gentle greeting; you can use "you" or "you" to address the user by their nickname; the sentence should be basically complete, with a small amount of gentle interjections such as "ya," "la," "oh," etc. allowed; avoid overly casual expressions. The third tone style prompt word for returning users is as follows: Please generate a natural and friendly greeting. No honorific is needed, "you" can be used; the subject or predicate can be omitted (e.g., simply say "You're back"); interjections such as "ya," "la," "ne," etc. are allowed. Based on the currently identified driver type, the CDC retrieves the corresponding tone style cue from the first cue word template.

[0059] Through the embodiments of this application, based on the pre-stored template, the CDC does not need to regenerate the tone style prompts for each greeting. It only needs to directly index and call them according to the determined driver type, which significantly reduces the resource overhead of real-time computing.

[0060] The CDC also includes a second prompt word template, which records the correspondence between the event to be greeted and the text prompt words. For example, the text prompt word for a "contrast in work and rest schedule" event is "The user's boarding time tonight is unusual," and the text prompt word for a "contrast in attire" event is "The user's attire today is different from usual." The CDC retrieves the corresponding text prompt word from the second prompt word template based on the currently identified event to be greeted. The CDC then concatenates the tone-style prompt word and the text prompt word and sends them to the Large Language Model (LLM). The LLM generates the corresponding greeting based on the input prompt word. The CDC then retrieves the greeting word generated by the LLM.

[0061] This application embodiment transforms the driver type and the event to be greeted into tone style cue words and text cue words, respectively. This allows the large language model to be guided by both tone style and text content when generating greetings, thereby outputting greetings that are both appropriate to the driver's relationship with the vehicle and match the current event to be greeted, thus improving the flexibility and relevance of greeting generation.

[0062] In some embodiments, step S201 includes: when the driver type indicator is at a first level of intimacy, determining a tone style cue as a first tone style cue, which guides the large language model to output a formal greeting; when the driver type indicator is at a second level of intimacy, determining a tone style cue as a second tone style cue, which guides the large language model to output a semi-formal greeting; and when the driver type indicator is at a third level of intimacy, determining a tone style cue as a second tone style cue, which guides the large language model to output an informal greeting.

[0063] In this embodiment, formal greetings convey a higher level of respect and / or greater sentence completeness compared to semi-formal greetings; semi-formal greetings convey a higher level of respect and / or greater sentence completeness compared to informal greetings. Wherein: The level of respect shown in a greeting is determined by a combination of three sub-characteristics: the use of honorifics, the manner of address, and the level of politeness in the wording. For example, formal greetings must use honorifics, be formally addressed, and be highly polite. An example of a formal greeting is: "Dear driver / sir / madam, please fasten your seatbelt." Semi-formal greetings contain only some of the three sub-characteristics, such as using only honorifics, using a nickname, and being highly polite. An example of a semi-formal greeting is: "Xiao Li, welcome back, please be careful." Informal greetings may omit honorifics entirely, use a nickname, or not address the person at all. An example of an informal greeting is: "You're back, fasten your seatbelt." Therefore, formal greetings convey a higher level of respect than semi-formal greetings, and semi-formal greetings convey a higher level of respect than informal greetings.

[0064] Sentence completeness is measured by whether the greeting conforms to standard grammatical structure. Formal greetings are considered high in sentence completeness; they must have a subject, verb, and object. An example of a formal greeting is: "Do you need navigation today?" Semi-formal greetings are considered medium in sentence completeness; they may lack a subject but have a complete verb. An example of a semi-formal greeting is: "Welcome back!" Informal greetings are considered low in sentence completeness; they allow the subject and verb to be omitted. An example of an informal greeting is: "You're back?" Through the embodiments of this application, a clear mapping relationship between driver type and tone style is established, enabling different greetings with different tone styles to be played for drivers with different levels of intimacy.

[0065] To reduce the interference of broadcast greetings on driving operations, in some embodiments, step S203 includes: inputting character length prompts, tone style prompts, and text prompts into a large language model, obtaining the greetings output by the large language model, wherein the character length prompts are used to guide the character length of the greetings output by the large language model to be less than or equal to a preset character length.

[0066] In this embodiment, the character length prompt is used to guide the large language model to output a greeting with a character length less than or equal to a preset character length. This is to ensure that the duration of the greeting played by the vehicle does not exceed the preset playback duration. The preset character length can be determined by the preset playback duration and playback rate. For example, a character length prompt could be: "Please ensure that the total number of characters in the output greeting does not exceed 70." By using the character length prompt, excessively long greetings caused by the large language model spontaneously expanding the text are avoided.

[0067] Step S40: Control the vehicle to play a greeting.

[0068] In this embodiment, the CDC sends the greeting (text format) to the TTS (Text to Speech) engine via the audio bus. The TTS engine synthesizes the greeting into audio data, which is then converted from digital to analog and played through the vehicle's amplifier and speakers.

[0069] In some embodiments, the CDC can also control the ambient lighting to switch to the corresponding mode and control the vehicle display screen to display corresponding content based on the type of the event to be greeted, in order to create a sense of ceremony that matches the event. For example, if the event to be greeted includes a birthday event, the ambient lighting can be controlled to switch to a warm color mode, a birthday animation and birthday card can be displayed on the screen, and birthday music can be played.

[0070] In addition, if the vehicle's safety imaging function is activated during the greeting playback, the CDC will immediately interrupt the greeting playback and all lights and screen outputs to prioritize driving safety.

[0071] In some embodiments, refer to Figure 3 , Figure 3 This is a flowchart illustrating another embodiment of the welcoming method provided in this application. Figure 3 As shown, before step S30, the procedure further includes: Step S301: Acquire perception data inside the vehicle; Step S302: Detect whether the in-vehicle environment is a negative environment based on the perception data.

[0072] In this embodiment, a negative environment refers to a scenario where the cabin is in a conflicted atmosphere or where the driver or at least one passenger is in a negative emotional state, making it unsuitable to extend a greeting. This embodiment identifies negative environments using the following two modalities: I. Detecting whether the cabin environment is negative based on audio data, including: The CDC (Catch-Up Diagnostics Center) acquires audio data streams from a microphone array within the vehicle cabin and uses a deep learning classifier to detect the presence of at least one of the following sound types: arguing, sighing, and crying. If the CDC detects the presence of at least one of these sound types, it determines that the cabin environment is negative based on the audio data. If the CDC detects the absence of any of these sound types, it determines that the cabin environment is not negative based on the audio data.

[0073] II. Detecting whether the vehicle cabin is in a negative environment based on image data, including: The CDC (Discrete Functional Acquisition) acquires facial images of the driver and passengers and determines their facial expression types based on an expression recognition model. If the CDC determines that the driver's or passenger's facial expression type is any one of sadness, anger, fear, or disgust, then the CDC determines that the cabin environment is negative based on the image data. If the CDC determines that the driver's or passenger's facial expression type does not belong to any of sadness, anger, fear, or disgust, then the CDC determines that the cabin environment is not negative based on the image data.

[0074] If the CDC determines that a negative environment is detected inside the vehicle cabin based on audio data or image data, it will enter silent mode and will not broadcast greetings.

[0075] When the CDC determines, based on both audio and image data, that the cabin environment is not negative, steps S30 to S40 are executed, avoiding the negative experience of broadcasting greetings in inappropriate situations. Through this embodiment, by introducing negative environment detection before acquiring greetings, the acquisition of greetings can be actively suppressed when the cabin environment is negative, avoiding the output of greetings in inappropriate scenarios, thereby improving the scene adaptability and user experience of the welcoming interaction.

[0076] To more clearly illustrate the complete execution logic of the welcoming method in this application, the execution logic of the welcoming method in a specific business scenario is explained below. (Refer to...) Figure 4 , Figure 4 This is a flowchart illustrating another embodiment of the welcoming method provided in this application. Figure 4 As shown, the execution logic of the welcoming method in this application is as follows: After a user boards the vehicle, the Driver Management System (DMS) identifies the driver's UID. The Driver Control Center (CDC) then obtains the UID identification result from the DMS to determine the driver's type. If the user is a visitor, the CDC performs a basic greeting process (such as playing a default greeting). If the user is a new or returning user, the CDC retrieves the driver's user profile, which includes data such as nickname, birthday, anniversary, partner UID, and historical behavioral profiles. The CDC acquires multi-source data, covering six dimensions: calendar, time series, visual, environmental, audio / video, and occupant. This includes collecting data on birthdays, anniversaries, public holidays, solar terms, vehicle usage intervals, driver attire, weather, vehicle charge status, cabin temperature, occupant UID identification results, number of occupants, and cabin audio / video data. Based on the acquired multi-source data, the CDC performs parallel detection on events such as anniversary events (e.g., birthday events, statutory holiday events, solar term events, emotional anniversary events, car delivery anniversary events, etc.), personalized events (e.g., long-awaited reunion events, formal attire events, driver care events, rare passenger sharing events, working under the stars and moon events, sun exposure complaints events, etc.), and environmental alert events (e.g., rain / snow / fog / haze events, low charge state events, etc.). The CDC then aggregates the detected events to obtain a set of detected events. Invalid events are removed from the set of detected events. Specifically, when the set of detected events includes an emotional anniversary event, if the CDC detects that only the driver and one passenger are present in the vehicle cabin, and the passenger's UID matches the partner UID in the user profile, and there is no arguing or negative interaction in the cabin, the CDC determines the emotional anniversary event to be valid; otherwise, the CDC removes the emotional anniversary event from the set of detected events. When the event set includes a personalized event, if the CDC detects that the in-vehicle environment is not a negative environment, the CDC determines that the personalized event is valid; otherwise, it removes the personalized event from the event set. The CDC determines text prompts based on the remaining events in the event set. The CDC determines tone-style prompts based on the driver type. The CDC inputs the character length prompt, tone-style prompt, and text prompt into the large language model, and obtains the greeting output by the large language model. After obtaining the greeting, the CDC detects the activation of safety functions such as 360-degree surround view and door opening warning, immediately prohibiting all greeting interactions until the safety functions are deactivated, and then re-determining the issue. If the safety functions are not activated, the multi-channel collaborative output stage begins. In the multi-channel collaborative output stage: the TTS engine implements voice broadcasting with corresponding intonation, the ambient lights switch colors and lighting modes matching the event semantics, the AI ​​interactive screen plays themed animations / emoticons, the central control screen renders holiday / commemorative cards, and the in-vehicle music player plays background music matching the event semantics, achieving multi-channel semantic collaboration of voice, lights, screen, and music.

[0077] It should be noted that the processing of data protected by the laws and regulations of relevant countries and regions involved in this application embodiment (e.g., collection, storage, use, processing, transmission, provision, and disclosure) complies with the relevant laws and regulations of those countries and regions. In some embodiments, when a user creates a driver account, the CDC can prominently display the personal information processing rules to the user through the in-vehicle central control screen (e.g., a pop-up window or a separate privacy policy interface), clearly informing the user that their personal privacy data (including birthdays, anniversaries, etc.) will be collected for the personalized greeting function, and explaining the purpose, method, scope, and storage period of the data processing. Only after the user makes a voluntary and explicit consent with full knowledge can the CDC store and use the aforementioned personal privacy data. The above compliant processing method is only an illustrative example. In actual deployment, it should comply with the laws, regulations, and mandatory national standards in effect at the time, and can be adapted to the specific requirements of different jurisdictions.

[0078] The welcoming method of the present application embodiments has been described above. The apparatus for performing the above method provided in the present application embodiments is described below. Those skilled in the art will understand that the methods and apparatus can be combined with and referenced by each other. The related apparatus provided in the present application embodiments can perform the steps in the above welcoming method. The related apparatus can be referred to in the following description: Figure 5 This is a schematic diagram of a functional module of the welcoming device provided in an embodiment of this application. Figure 5 As shown, the welcoming device 500 may include: a type determination module 510, used to determine the type of driver in response to a vehicle entry event, wherein the driver type is used to indicate the degree of intimacy between the driver and the vehicle; an event determination module 520, used to determine a greeting event; an acquisition module 530, used to acquire a greeting based on the driver type and the greeting event, wherein the driver type is used to indicate the tone and style of the greeting, and the greeting event is used to indicate the content of the greeting; and a control module 540, used to control the vehicle to play the greeting.

[0079] In some embodiments, the acquisition module 530 is configured to: determine tone style prompts based on the type of driver; determine text prompts based on the event to be greeted; input the tone style prompts and text prompts into a large language model, and acquire the greeting output by the large language model.

[0080] In some embodiments, the acquisition module 530 is configured to: determine a tone style prompt as a first tone style prompt when the driver type indicator is at a first level, the first tone style prompt being used to guide the large language model to output a formal greeting; determine a tone style prompt as a second tone style prompt when the driver type indicator is at a second level, the second tone style prompt being used to guide the large language model to output a semi-formal greeting; and determine a tone style prompt as a second tone style prompt when the driver type indicator is at a third level, the second tone style prompt being used to guide the large language model to output an informal greeting.

[0081] In one possible implementation, the acquisition module 530 is used to: input character length prompts, tone style prompts, and text prompts into the large language model, and acquire the greeting output by the large language model. The character length prompts are used to guide the character length of the greeting output by the large language model to be less than or equal to a preset character length.

[0082] In one possible implementation, the event determination module 520 is used to: acquire multi-source data, and determine the event to be greeted based on the multi-source data, wherein the multi-source data includes at least one of user data, vehicle data, and environmental data.

[0083] In one possible implementation, the multi-source data includes: the driver's current driving behavior data and historical driving behavior profile; the event determination module 520 is used to: determine that the event to be greeted includes a contrast event if the current driving behavior data does not match the historical driving behavior profile.

[0084] In one possible implementation, the historical driving behavior profile is used to indicate at least one of the driver's historical vehicle entry time, historical clothing type, and historical number of passengers, while the current driving behavior data includes at least one of the current vehicle entry time, current clothing type, and current number of passengers.

[0085] In one possible implementation, the welcoming device further includes a sensing module for: acquiring sensing data inside the vehicle; detecting whether the in-vehicle environment is a negative environment based on the sensing data; and an acquisition module 530 for acquiring a greeting based on the driver type and the event to be greeted if the in-vehicle environment is not a negative environment.

[0086] In one possible implementation, the type determination module 510 is used to: obtain the account creation time corresponding to the driver; and determine the driver's type based on the current time and the account creation time.

[0087] This application also provides a welcoming device, as shown in the embodiments. Figure 6The welcoming device 600 may include a memory 610 and a processor 620. The memory 610 and processor 620 are connected via an internal connection. The memory 610 stores instructions, and the processor 620 executes the instructions stored in the memory 610, enabling the welcoming device 600 to implement the aforementioned welcoming method. Optionally, the memory 610 may be coupled to the processor 620 via an interface, or it may be integrated with the processor 620.

[0088] The processor 620 stores one or more computer programs, which include instructions. When the instructions are executed by the processor 620, the welcoming device 600 performs the methods described in the above embodiments.

[0089] In implementation, each step of the above method can be completed by the integrated logic circuits in the hardware of the processor 620 or by instructions in software form. The method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 610, and the processor 620 reads the information in memory 610 and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are not provided here.

[0090] As one possible implementation, the welcome device 600 can be a physical device, such as including one or more of the following modules: central processing unit, microprocessor, application-specific integrated circuit, field-programmable gate array, complex programmable logic device (CPLD), coprocessor (assisting the central processing unit in completing corresponding processing and applications), microcontroller unit (MCU), domain controller (DC), vehicle domain controller unit (VDC), electronic control unit (ECU), cockpit domain controller (CDC), vehicle integration unit (VIU), vehicle control unit (VCU), motor control unit (MCU), etc. Furthermore, the welcome device 600 includes at least one processor integrated in the form of a system-on-chip (SoC), commonly referred to by those skilled in the art as an SoC. This SoC may include at least one processor, and when the SoC includes multiple processors, the types of the multiple processors may be different.

[0091] Optionally, Figure 6 The memory 610 can store at least one of the following data: the cumulative number of recognitions field, historical driving behavior profile, mapping relationship table, first prompt word template, second prompt word template, etc. Figure 6 The processor 620 can execute instructions stored in the memory 610 to implement the steps in the welcoming method in the foregoing embodiments.

[0092] This application also provides a computer-readable storage medium storing program code that, when run on a computer, causes the computer to perform any of the methods described in the above embodiments.

[0093] This application also provides a computer program product, which includes a computer program that, when run, causes the computer to perform any of the methods described in the above embodiments.

[0094] This application also provides a chip, including: a circuit for performing any of the methods in the above embodiments.

[0095] This application also provides a device, including... Figure 5 The welcome device 500 shown or Figure 6 The welcoming device 600 shown can perform any of the methods described in the above embodiments.

[0096] This application also provides a vehicle, including... Figure 5 The welcome device 500 shown or Figure 6 The welcoming device 600 shown.

[0097] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0098] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0099] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0100] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the embodiments of this application, depending on actual needs.

[0101] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0102] If a functional unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0103] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0104] The terms "first," "second," etc., used in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the description of embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0105] It is understood that, in the embodiments of this application, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

Claims

1. A method for welcoming guests, characterized in that, The method for using a welcome device in a vehicle includes: In response to a boarding event, the type of driver is determined, which indicates the degree of familiarity between the driver and the vehicle; Identify the events to be addressed; A greeting is obtained based on the driver type and the event to be greeted, wherein the driver type indicates the tone and style of the greeting, and the event to be greeted indicates the content of the greeting; Control the vehicle to play the greeting.

2. The welcoming method according to claim 1, characterized in that, The step of obtaining a greeting based on the driver's type and the event to be greeted includes: Based on the type of driver, determine the tone style cue words; Based on the event to be greeted, determine the text prompt words; Input the tone style cue words and the text cue words into the large language model to obtain the greeting output by the large language model.

3. The welcoming method according to claim 2, characterized in that, The step of determining tone style cue words based on the driver type includes: When the type of the driver indicates that the degree of intimacy is at the first level, the tone style cue word is determined as the first tone style cue word, which is used to guide the large language model to output a formal greeting. When the type of the driver indicates that the degree of intimacy is at the second level, the tone style cue word is determined to be the second tone style cue word, which is used to guide the large language model to output the semi-formal greeting; When the type of the driver indicates that the degree of intimacy is level three, the tone style cue word is determined to be the second tone style cue word, which is used to guide the large language model to output the informal greeting.

4. The welcoming method according to claim 2 or 3, characterized in that, The step of inputting the tone style cue words and the text cue words into the large language model and obtaining the greeting output by the large language model includes: Input the character length prompt, the tone style prompt, and the text prompt into the large language model to obtain the greeting output by the large language model. The character length prompt is used to guide the character length of the greeting output by the large language model to be less than or equal to a preset character length.

5. The welcoming method according to claim 1, characterized in that, The determination of the event to be greeted includes: Acquire multi-source data and determine the event to be greeted based on the multi-source data, wherein the multi-source data includes at least one of user data, vehicle data, and environmental data.

6. The welcoming method according to claim 5, characterized in that, The multi-source data includes the user data, which includes: the driver's current driving behavior data and historical driving behavior profile; determining the event to be greeted based on the multi-source data includes: If the current driving behavior data does not match the historical driving behavior profile, then the event to be greeted is determined to include a contrast event.

7. The welcoming method according to claim 6, characterized in that, The historical driving behavior profile is used to indicate at least one of the driver's historical vehicle entry time, historical clothing type, and historical number of passengers. The current driving behavior data includes at least one of the current vehicle entry time, current clothing type, and current number of passengers.

8. The welcoming method according to any one of claims 1 to 3, characterized in that, Before obtaining the greeting based on the driver's type and the event to be greeted, the method further includes: Acquire sensing data inside the vehicle; Based on the perceived data, detect whether the in-vehicle environment is a negative environment; The step of obtaining a greeting based on the driver's type and the event to be greeted includes: If the in-vehicle environment is not the negative environment, then a greeting is obtained based on the driver type and the event to be greeted.

9. The welcoming method according to any one of claims 1 to 3, characterized in that, The determination of the driver type includes: Obtain the account creation time corresponding to the driver; The driver's type is determined based on the current time and the account creation time.

10. A welcoming device, characterized in that, include: A type determination module is used to determine the type of the driver in response to a boarding event, wherein the type of the driver is used to indicate the degree of familiarity between the driver and the vehicle; The event determination module is used to determine the events to be greeted. The acquisition module is used to acquire a greeting based on the driver type and the event to be greeted, wherein the driver type is used to indicate the tone and style of the greeting, and the event to be greeted is used to indicate the content of the greeting; The control module is used to control the vehicle to play the greeting.

11. A vehicle, characterized in that, The vehicle includes the welcoming device as described in claim 10.

12. A computer-readable storage medium, characterized in that, When the computer-executable instructions stored in the computer-readable storage medium are executed by the device, the device is capable of performing the method as described in any one of claims 1-9.

13. A computer program product, said computer program product comprising computer instructions, characterized in that, When the computer instructions are executed on the device, the device is able to perform the method as described in any one of claims 1-9.

Images