Management of Vehicle Diagnosis

Abstract

A method for managing vehicle maintenance can capture at least one of the user's concerns / inputs related to the requested service or the observed vehicle operation parameters. The method for managing vehicle maintenance can perform diagnosis and filtering based on user input to identify a set of corrective actions to be performed and pre-service treatments that may be required before the service, and the diagnosis and filtering correspond to a series of diagnostic services to be deployed and implemented. The method for managing vehicle maintenance can send at least one processing result associated with the execution of a series of diagnostic services, obtain approval from the user for the service request, and schedule the service.

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This application claims the benefit of U.S. Provisional Application No. 63 / 365,263, filed May 24, 2022, entitled "MANAGING VEHICLE DIAGNOSTICS", which is hereby incorporated by reference in its entirety.

Background Art

[0002] Generally speaking, a computer device and a communication network can be used to exchange data and / or information. In a general application, a computer device can request content from another computer device via a communication network. For example, a computer device can use a software application to collect various data and exchange content with a server computer device via a network (e.g., the Internet). In such an embodiment, the originating computer device can collect or generate information and provide the collected information to the server computer device for further processing or analysis.

[0003] Generally speaking, various vehicles such as electric vehicles, combustion engine vehicles, hybrid vehicles, etc. can be configured using various sensors and components to facilitate the operation of the vehicle or the management of one or more systems included in the vehicle. In a particular scenario, the owner or user of a vehicle may wish to schedule a service appointment with a service technician prior to any form of initial diagnosis or inspection by the service technician. For example, the vehicle owner / user may be provided with the functionality to schedule a service reservation themselves.

Summary of the Invention

[0004] The devices, systems, and methods disclosed herein have several features, none of which alone carry its desirable attributes. Without limiting the scope as expressed by the following claims, some of its more prominent features are briefly described herein. After considering this description, and particularly after reading the section entitled "DETAILED DESCRIPTION," one will understand the advantages that the features of one or more embodiments of the present system and method provide over conventional systems and methods.

[0005] In some aspects, the techniques described herein are methods for managing vehicle maintenance, including capturing or receiving at least one of a user's concern / input related to a requested service or an observed vehicle operation parameter, causing a series of diagnostic services to be performed in response to the at least one received user input, transmitting at least one processing result associated with the execution of the series of diagnostic services, and determining whether to provide a first service request or obtaining approval of a service request from the user and scheduling at least one service at least partially based on the at least one processing result.

[0006] Another aspect is a method of capturing at least one user input, where the at least one user input corresponds to at least one of a requested service or an observed vehicle operation parameter, causing a series of diagnostic services to be performed in the vehicle in response to the at least one captured user input, transmitting at least one processing result associated with the execution of the series of diagnostic services in the vehicle, and obtaining approval of a service request from the user and scheduling at least one service at least partially based on the at least one processing result.

[0007] Yet another aspect is a method for managing vehicle maintenance. This method includes receiving at least one of user inputs related to vehicle components, causing a vehicle to execute a series of diagnostic services in response to the received at least one user input, transmitting at least one processing result associated with the execution of the series of diagnostic services, and determining whether to provide a first service request.

Brief Description of the Drawings

[0008] These features, aspects, and advantages of the present invention, as well as other features, aspects, and advantages, are described herein with reference to the drawings of the preferred embodiments, which are for illustrative purposes of the present invention and not for limiting the present invention.

[0009]

Figure 1

[0010]

Figure 2

[0011]

Figure 3

[0012]

Figure 4

[0013]

Figure 5

[0014]

Figure 6

Embodiments for Carrying Out the Invention

[0015] Generally speaking, one or more aspects of the present disclosure relate to the configuration and management of diagnostic services associated with a vehicle. Exemplarily, the diagnostic service can respond to client / customer input, such as in identifying operational concerns or anticipating scheduling adjustments for vehicle service reservations. As an exemplary example, aspects of the present application correspond to the selection, deployment, and execution of one or more diagnostic services or diagnostic applications for collecting and transmitting operational or measured characteristics of a vehicle. One or more diagnostic services or diagnostic applications may generally be referred to as a series of diagnostic services.

[0016] Generally, conventional approaches for performing vehicle services are based on on-site vehicle inspections, vehicle diagnostics, and vehicle repairs by technicians. More specifically, a customer provides the vehicle to a service center where the technician can physically access the vehicle, and the customer describes the vehicle. Then, the technician performs vehicle diagnostics and repairs based on the customer's description. These conventional approaches can cause inefficiencies for both the customer and the vehicle service center. In one aspect, the customer must visit the service center (or the technician must be physically proximate to the vehicle). In another aspect, the technician performs vehicle diagnostics based on the customer's description. In this aspect, the diagnostic results can vary depending on the technician's knowledge or experience level. In another aspect, the technician performs vehicle repairs based on the diagnostic results. In this aspect, the vehicle repair results can also vary because the diagnostic results can vary depending on the technician's expertise. For example, a technician may require a diagnosis and perform vehicle repairs, but the diagnostic results may be incorrect because the technician may not understand the customer's description. Further, the customer may have to reschedule the service appointment to perform the above vehicle service process. In another aspect, only a software update of the vehicle may be required for the repair, but the customer may have to perform the above vehicle service process. Therefore, conventional approaches for vehicle services can be inefficient for both the customer and the vehicle service center.

[0017] To address at least some of the inefficiencies identified above, one or more aspects of the present application relate to the identification, deployment, and execution of a series of diagnostic and corrective services in response to user input prior to vehicle servicing. Exemplarily, the deployment and execution of the diagnostic services can be combined with or integrated with the management of user input related to the requested service or observed vehicle parameters. Exemplarily, such integration can correspond to an automated workflow of services provided by a vehicle service provider. More specifically, aspects of the present application incorporate automation that includes the following high-level procedures performed by management components within the vehicle.

[0018] According to an exemplary embodiment, the management component captures user concerns / inputs related to the requested service or observed vehicle operation parameters. Exemplarily, a customer (or user) may capture inputs associated with observed vehicle characteristics, self-selected service requests (e.g., 10,000-mile service), etc., using one or more interfaces. The captured user concerns / inputs can be facilitated by using a mobile application (e.g., a cellular phone application) associated with an individual user, an interface included in the vehicle, a kiosk, a personal computer device, a tablet computer device, etc.

[0019] Thereafter, the management component performs diagnosis and filtering of the user input to identify a set of corrective actions to be performed and pre-service treatments that may be required before the service. The series of corrective actions and pre-service treatments can be embodied as a series of diagnostic services to be performed by the vehicle or other computer devices associated with the vehicle, such as a mobile computer device. Exemplarily, the series of diagnostic services is deployed to be performed by at least one of the vehicle or the associated computer device. The series of diagnostic services can correspond to the identified operation parameters based on the user input. Further, the series of diagnostic services may also be investigative in nature in order to measure different operation parameters or attempt to correlate the observed parameters with other operation parameters of the vehicle. For the purposes of this application, the reference to a series of diagnostic services is not intended to limit the functionality of individual services or applications, and can include collection of state information regarding the vehicle or the environment, collection of state information regarding the user / operator, attempts to perform corrective or repair actions, attempts to identify a failure or error condition based on inputs provided to one or more components, etc.

[0020] Furthermore, a series of diagnostic services can further process the processing results of other diagnostic services to determine whether the vehicle needs service. If it is determined that the vehicle needs service, the management component may provide the user with the option to approve the service. A series of diagnostic services can determine whether to provide service to the user / operator (or other relevant individuals) based on the results of the diagnostic services. In some embodiments, the determination of whether to provide service to the vehicle can be mainly based on the results of the diagnostic services of a specific vehicle (for example, whether the diagnostic services indicate that a specific vehicle needs service). The system can further be based on the supply chain information to determine the option to approve the service. The supply chain information may include the availability of parts or the availability of location-specific parts. The system can determine whether to provide service by comparing the severity of the condition with other users in combination with the availability of parts. In other embodiments, the determination of whether to provide service to the vehicle can be based on the relative comparison of the results of the diagnostic services of multiple vehicles. In this embodiment, the service request can be based on the evaluation of the degree of maintenance need compared with other vehicles, especially in scenarios where the availability of parts or the availability of service locations is limited. For example, assume that as a result of the vehicle diagnostic process, service is required, but the failure level is evaluated as "low priority" or "low impact". Even if vehicle service may ultimately be required, the service can be postponed to the next execution of the diagnostic suite (for example, service deferral), or modified or configured to be processed for future services that exceed a minimum threshold. Such service changes can be made automatically (without user input or notification) or in conjunction with user notification or input.

[0021] Once the diagnostic and filtering processes are complete, the management component approves service requests by the user and schedules the service. For example, this can include access to user profile information indicating pre - approval or approval thresholds. In other embodiments, this includes receiving active user input such as the operation of a graphical interface, the operation of a vehicle control device (e.g., operation of pedals, presentation of a short - range communication device, selection of remote control / access inputs, etc.). In some embodiments, one or more aspects of the present application can include some form of feedback or processing result provided to the user indicating the results of the execution of a series of diagnostic services. For example, the feedback / processing result can be in the form of an evaluation of the results (e.g., excellent, good, bad, etc.). In other examples, the feedback / processing result can be in the form of individual values of a series of diagnostic services, determined treatment groups, potential causes of failure, or proposed severity levels of potential failures. After the approval and feedback processes, the network - based management component associated with the physical service provider that may be performing the vehicle service performs component allocation and ordering, as well as payment and support document reconciliation. Exemplarily, the output of a series of diagnostic services can be used for pre - ordering parts, pre - arranging the physical services to be performed, etc. Further, the output of a series of diagnostic services can be used as an input for estimating the time until the completion of the scheduled service.

[0022] As an illustrative example, assume that a user / operator provides some input regarding the observation results of an operation indicating the battery performance of a vehicle via a vehicle interface. In response, a series of diagnostic services are deployed in the vehicle, and various states of the electrical system are captured, including the state of the battery system, the state of the charging system, and the operational usage data related to the battery system. Based on the results of a series of executions of the diagnostic services, the diagnostic services further determine that the required service is the replacement of the vehicle's battery system. Based on this determination, the series of diagnostic services can further evaluate the necessity of replacing the battery system, including the assessment of the degree of failure, the assessment of the probability of failure, the reliability in diagnosis, etc. Based on these processing results, the network-based management service can provide information regarding the current status of the services required for battery system replacement, the inventory status of the battery system, and the availability of service locations for implementing the battery system replacement. Subsequently, the network-based management service can provide an input to the series of diagnostic services regarding the scheduling of the battery system replacement and give the user's input and approval.

[0023] In accordance with some aspects of the present application, capturing a user's concerns and inputs leading to the selection and provision of a series of diagnostic services can, by way of example, be captured through interactions with a vehicle interface, a mobile application, or other computer devices (such as kiosks, tablets, etc.). Such interactions can be based on predetermined categories selectable by the user via the interface. Such interactions can also be based on narrative-type inputs such as spoken words, entered comments, etc. that can be processed to extract key terms, etc. By way of example, a network service provider can utilize third-party services to facilitate the collection or processing of user inputs. Further, in some aspects, user inputs can also include the collection of vehicle operating parameters such as a frozen screen, frequent system resets, or low voltage. User inputs can further include responses to proposals or prompts. For example, a service management component can offer the user an option to perform a battery diagnosis in response to a detected low voltage. The system can provide proposals based on a number of data points, and the proposals can focus on some exemplary vehicle characteristics that can be detected or determined based on a particular system, vehicle history, or network-driven proposals. The user can respond with instructions to complete the proposed treatment. In an alternative example, a service management component can offer the user an option to perform a system diagnosis or infotainment diagnosis in response to frequent system resets or a frozen screen.

[0024] In some embodiments, a series of diagnostic services may be pre - incorporated into a vehicle or software application associated with a customer. In other embodiments, in response to a treatment group, a network service provider may send a vehicle a series of diagnostic services that have been changed or updated according to the processed input. Further, in other embodiments, a vehicle may maintain a general or common series of diagnostic services that can be specified by user input. Specifically, individual iterations of a series of diagnostic services may be performed according to a treatment group or user input such that the execution of the diagnostic services or the order / sequence is customized.

[0025] In some embodiments, a series of diagnostic services are continuously updated by a network service and can be sent to a vehicle. Such transmission can be achieved in response to a decision to deploy and execute one or more diagnostic services. Alternatively, the network service can update a vehicle or vehicle application periodically or asynchronously before deciding to deploy and execute a diagnostic service.

[0026] In a further aspect of the present application, a vehicle or vehicle application may also maintain some historical information related to the output or results of a series of diagnostic services. The historical information can be used to determine trends or provide comparison points regarding the operating state of the vehicle at the time of measurement. Such historical information can be provided to a service provider, especially if the vehicle has not been serviced previously. For example, a repair of a vehicle service for a particular system (e.g., a charging component) can include not only the results of one or more diagnostic services related to the operating characteristics of the current - state charging components, but also the results from previous instances of the same or similar diagnostic services.

[0027] FIG. 1 shows a block diagram of an exemplary environment of a system 100 for providing configuration and management of services associated with a vehicle based on customer input, according to one or more aspects of the present disclosure. The system 100 can include a network 160 that connects a set of vehicles 110, a network service provider 120, and one or more customer devices 130. The components can correspond to software modules implemented or executed by one or more external computer devices, which may be separate stand-alone external computer devices. Thus, the components of the network service provider 120 should be regarded as a logical representation of the services and do not require a specific implementation on one or more external computer devices.

[0028] As shown in FIG. 1, the customer device 130 can be any computer device such as a desktop, laptop, personal computer, tablet computer, wearable computer, server, personal digital assistant (PDA), hybrid PDA / cell phone, cell phone, smartphone, set-top box, voice command device, digital media player, etc. The customer device 130 can execute an application (e.g., a browser, a stand-alone application, etc.) that allows a user to access an interactive user interface and view images, analytics, aggregated data, etc., as described herein. In some embodiments, the customer device 130 is implemented in combination with the vehicle 110 and can provide some functionality associated with the vehicle 110. For example, the vehicle 110 can utilize the customer device 130 to execute one or more functions in conjunction with utilizing vehicle resources such as the vehicle's processor and memory.

[0029] As shown in FIG. 1, network 160 can connect vehicle 110, customer device 130, and network service provider 120. Network 160 can connect any number of devices. In some embodiments, network service provider 120 provides network-based services to customer device 130 via the network. The network service provider refers to a large shared pool of network-accessible computing resources (such as computing, storage, or networking resources, applications, or services) that can implement network-based services and can be virtualized or bare metal. The network service provider can provide on-demand network access to a shared pool of configurable computer resources that can be programmatically provisioned and released in response to customer commands. These resources can be dynamically provisioned and reconfigured to match varying loads. Thus, the concept of "cloud computing" or "network-based computing" can be considered in terms of both applications delivered as services over the network and the hardware and software of the network service providers that provide those services.

[0030] Network 160 can comprise any combination of wired and / or wireless networks such as, for example, one or more direct communication channels, local area networks, wide area networks, personal area networks, and / or the Internet. In some embodiments, the communication between vehicle 110 and customer device 130 can be performed via a short-range communication protocol such as Bluetooth, Bluetooth Low Energy (“BLE”), and / or Near Field Communication (“NFC”). The communication between vehicle 110 and network service provider 120 can be performed via network 160 through one or more security-protected networks such as, for example, a local area network that communicates securely with network service provider 120 via the Internet. However, network 160 can include the same communication protocol, service, hardware, and / or some or all of the others. Thus, in the discussion herein, the communication between vehicle 110 and customer device 130 via network 160 and the communication between vehicle 110 and network service provider 120 via network 160 can be described, but the communication of the devices is not so limited. The various communication protocols described herein are merely examples and the present application is not limited thereto.

[0031] In some embodiments, network 160 can utilize other wireless communication technologies such as high-speed 4G LTE or 5G communication. Thus, in some embodiments, network 160 can include one or more wireless networks such as a Global System for Mobile Communications (GSM) network, a Code Division Multiple Access (CDMA) network, a Long Term Evolution (LTE) network, or any other type of wireless network. Network 160 can use protocols and components for communicating via the Internet or any of the other types of networks described above. For example, protocols used by network 160 can include, but are not limited to, Hypertext Transfer Protocol (HTTP), HTTP Secure (HTTPS), Message Queuing Telemetry Transport (MQTT), and Constrained Application Protocol (CoAP). Protocols and components for communicating via the Internet or any of the other types of communication networks described above are well known to those of ordinary skill in the art and will not be described in further detail herein.

[0032] As applied to the various aspects of the present application, a set of vehicles 110 corresponds to one or more vehicles configured with a series of diagnostic services 112 for execution by vehicle 110 or other computer devices associated with the vehicle, such as mobile computer device 130. As described above, the reference to a series of diagnostic services 112 is not intended to limit the functionality of individual services or applications and can include, for example, collection of status information regarding the vehicle or environment, collection of status information regarding the user / operator, attempts to implement corrective or repair actions, and attempts to identify a failure or error condition based on inputs provided to one or more components.

[0033] Exemplarily, the network service provider 120 can include a vehicle network-based management component 122 that provides functionality responsive to the processing of customer input to provide configuration and management of services associated with a vehicle as applied to aspects of the present application. As described above, the network-based management component 122 can be associated with a physical service provider that may be performing services for the vehicle, allocate and facilitate input to an inventory or parts ordering system, and perform parts ordering and payment and support document reconciliation. Further, the network-based management component 122 can further process processing results from multiple vehicles 110 to facilitate prioritization, filtering, or other relative comparison of diagnostic processes, as described herein. The network-based services can include multiple data stores 124 for maintaining various information associated with aspects of the present application. The network-based management component 122 of FIG. 1 is in effect logical and can be implemented in the network service provider 120 in various ways.

[0034] Referring now to FIG. 2, an exemplary architecture for implementing a series of diagnostic services 112 within the vehicle 110 on one or more local resources or network services will be described. The series of diagnostic services 112 may be part of a component / system that provides functionality associated with, for example, a vehicle service provider.

[0035] The architecture of FIG. 2 is illustrative in nature and should not be construed as requiring a particular hardware or software configuration for vehicle 110 (or computer device 130 associated with the vehicle). The general architecture of vehicle 110 shown in FIG. 2 includes an arrangement of computer hardware and software components that can be used to implement aspects of the present disclosure. As shown, vehicle 110 includes a processing unit 204, a network interface 206, a computer-readable media drive 207, and an input / output device interface 208, all of which can communicate with each other via a communication bus. The components of vehicle 110 may be physical hardware components or may be implemented in a virtualized environment.

[0036] Network interface 206 can provide connectivity to one or more networks or computing systems, such as the network of FIG. 1. Thus, processing unit 204 can receive information and instructions from other computing systems or services via the network. Processing unit 204 can also communicate with memory 250 and further provide output information to an optional display (not shown) via input / output device interface 208. In some embodiments, vehicle 110 may include more (or fewer) components than those shown in FIG. 2.

[0037] Memory 250 can include computer program instructions that are executed by processing unit 204 to implement one or more embodiments. Memory 250 generally includes RAM, ROM, or other persistent or non-transitory memory. Memory 250 can store interface software 252 and operating system 254, and the operating system provides computer program instructions used by processing unit 204 in the general management and operation of network-based management component 122. Memory 250 can further include computer program instructions and other information for implementing aspects of the present disclosure.

[0038] Memory 250 can include an input processing component 256 for processing customer input. In these embodiments, the input processing component 256 can correspond to one or more machine learning models for processing natural human language, such as narrative-form language input, used to identify one or more symptoms related to the vehicle. In some embodiments, the machine learning model.

[0039] Memory 250 can also include an input processing component 258. In some embodiments, a customer can provide customer input by using the customer device 130, and the input processing component 256 can filter the customer input used to predict one or more symptoms related to the customer input. For example, the input processing component 258 can extract one or more key terms from the customer input and use the key terms to predict symptoms. In these embodiments, the customer input can be provided to the input processing component 258 in text form or in the context of an oral expression.

[0040] In some embodiments, a customer can provide customer input in the form of natural language. In these embodiments, the customer input can be narrative. For example, a customer can input one or more sentences related to the vehicle or describe the vehicle in the context of natural human language. In some embodiments, the input processing component 256 processes these customer inputs to determine one or more customer inputs that can be used to predict vehicle symptoms. For example, there may be a customer input such as "There is a yellow border around the touch screen of my car." In this example, the input processing component 256 can filter the customer input and determine "touch screen malfunction." In another example, there may be a customer input such as "My car drifts to the left on the highway." In this example, the input processing component 258 processes the customer input and determines the customer input as "wheels are not aligned."

[0041] In some embodiments, the input processing component 256 can be configured to process natural language provided as customer input using a machine learning model. For example, if the customer input is "My car smells", the machine learning model can process the customer input and determine that the customer input is "Malfunction of the heating, ventilation, and air conditioning (HAVC) system".

[0042] In some embodiments, the input processing component 256 receives customer input as a set of vehicle symptoms. In these embodiments, the customer device 130 can provide a list of vehicle symptoms, and the customer can select one or more symptoms from the list of vehicle symptoms. For example, the customer device 130 can have a list of vehicle symptoms such as "Engine warning lamp on", "Vehicle vibration", "Safety function inoperative", "Battery malfunction", and other pre-defined vehicle symptoms. In this example, the customer can select one or more symptoms from the pre-defined list of vehicle symptoms.

[0043] The memory 250 can also include, by way of example, a vehicle symptom analysis component 258 corresponding to a series of diagnostic services 112. As described above, the reference to a series of diagnostic services 112 is not intended to limit the functionality of individual services or applications, and can include collection of status information regarding the vehicle or the environment, collection of status information regarding the user / operator, attempts to implement corrective or repair actions, attempts to identify a failure or error condition based on inputs provided to one or more components, and the like. As will be described below, in some embodiments, user input may be associated with one or more treatment groups that facilitate logically grouping natural language input into potential symptoms for vehicle maintenance. Next, the series of diagnostic services 112 can be associated with the treatment groups in a way that collects the necessary information, attempts corrective actions, and provides additional input based on the processing of the user input mapped to the treatment groups.

[0044] Memory 250 can also include a service feedback component 260 for providing feedback (or evaluation of feedback) to the customer. As described above, the feedback can, by way of example, include additional diagnostic services or requests for user observations. In other aspects, the feedback can include approvals or inputs related to scheduling of services, parts ordering, financial commitments, and the like.

[0045] Referring now to FIG. 3, an exemplary interaction of the components of system 100 for providing vehicle services based on the processing results of customer input is described. For purposes of illustration, it can be assumed that network service provider 120 has been configured to implement network-based management component 122 on behalf of a set of customers. This application is not intended to be limited to a particular type of service provider or number of individual services that can be accessed as part of the execution of an application on behalf of a customer or that can generate processing results. Further, this application is not intended to be limited to the number of network service providers as shown in FIG. 1.

[0046] As shown in FIG. 3, at (1), the customer can provide customer input to network-based management component 122 by transmitting the customer input via customer device 130. The customer input can correspond to text, images, and / or natural language. In some aspects, the customer input can also include a collection of vehicle operation parameters that can be applicable or related to customer input such as sensor / instrument values, warnings or notifications, recommended action items, and the like.

[0047] Exemplarily, a customer can provide customer input by using an interface (such as an integrated display screen or a microphone) within the vehicle 110 or via a customer device 130 associated with the vehicle 110. The vehicle or the customer device 130 can execute an application (such as a browser, a stand-alone application, etc.) that enables the customer to input customer input, access an interactive user interface, and view images, analyses, aggregated data, etc., as described herein.

[0048] In some embodiments, customer input can be provided to the network-based management component 122 in the form of text or in the context of an oral expression. In some embodiments, the customer can provide customer input in the form of natural language. In these embodiments, the customer input can be narrative. For example, the customer can input one or more sentences related to the vehicle or can describe the vehicle in the context of natural human language.

[0049] As an exemplary example, user input can be evaluated as potentially belonging to one or more of a defined set of treatment groups. Each individual treatment group defines a confidence value that maps a related symptom / cause and the symptom / cause to the captured user input. Each individual treatment group then defines one or more corrective treatments or response actions that can be performed by the vehicle, a technician, an additional third party, etc. Thus, based on the mapping of the input to the treatment groups, the network service provider can define and execute treatments (such as diagnostic treatments, information collection treatments, or corrective treatments) that can be used to complete the requested service or to address the observed vehicle parameters. Although described herein for purposes of illustration, the use of treatment groups or aspects of treatment groups is not essential in some embodiments.

[0050] Exemplarily, the network service provider can select relevant treatment groups by first applying some form of threshold or filtering out any treatment groups that do not meet a minimum threshold of trust value. For example, treatment groups having a trust value less than 60%, 65%, 70%, 75%, or other specified value can be excluded from consideration. The trust value may be due to or assigned based on the symptoms of the treatment group based on manual input, implementation of machine learning, etc., and the trust value may also be updated based on historical information based on the respective experiences unique to the customer or vehicle, the organizational experiences unique to a defined subset of individuals or vehicles, or more generally applicable thresholds. Subsequently, the remaining potentially applicable treatment groups can be ranked or classified to select the most likely applicable treatment group. The classification or ranking may be based strictly on numerical principles or may be via a weighting scheme, for example, weighting based on past interactions with a user, vehicle, series of vehicles, series of users, or combinations thereof. In some embodiments, if the trust value of any of the treatment groups does not meet a threshold (which may be the same as or different from the filtering threshold), the network service provider can cause the system to collect supplementary user input or perform an initial diagnosis before selecting a treatment group.

[0051] Once selected, each individual treatment group defines a set of treatments such as diagnostic treatments, information-providing treatments, or corrective treatments, thereby facilitating a service workflow based on user input that can be embodied in a series of diagnostic services 112. For example, a series of diagnostic services 112 can include executing an automatic information collection tool / application that can collect vehicle data and identify data patterns. In another example, the treatment can include executing an automatic diagnostic tool that can be performed by the vehicle. The output generated by the series of diagnostic services can be accessed by a technician as provided by the vehicle, such as a high-level transmission from the vehicle or service application.

[0052] In some embodiments, there may be one or more treatment groups mapped to the initial user input. As a result of the mapping to the one or more treatment groups, the service management component may determine an additional treatment group. The additional treatment group can be determined based on the trust value of the first treatment group or other treatment groups. For example, if the network-based management component 122 determines that the trust level of treatment group 1 is 50%, the trust level of treatment group 2 is 45%, and the trust level of treatment group 3 is 5%, the service management component may execute all or part of the treatments (e.g., diagnostic treatments, information collection treatments, or corrective treatments) associated with group 1 and treatment group 2. The network-based management component 122 may perform a diagnosis associated with both treatment group 1 and treatment group 2 to determine the root cause of the problem. When determining whether to execute the physical implementation of treatment group 1 and treatment group 2, the network-based management component 122 may further analyze the corrective treatments associated with each group, e.g., the parts and labor required for treatment group 1 and treatment group 2.

[0053] In some embodiments, the network-based management component 122 may map an additional treatment group or treatment based on the determined treatment group, or the diagnostic treatment, information collection treatment, or corrective treatment of the treatment group. The additional treatment group may be independent of the initial user input. The additional treatment group can be determined based on criteria associated with the treatment group, including diagnosis, vehicle history, vehicle age, and services required for the determined treatment group.

[0054] In some embodiments, some treatment groups may specify a variety of treatments that can be in a logical order (e.g., information collection / diagnosis / repair). In other embodiments, the treatment groups may be limited to a specific type of treatment, such as a diagnostic service that depends on the results of other diagnostic services. The treatments can also be structured or ordered such that the results / conclusions of preceding treatments can depend on or affect subsequent treatments (e.g., the values from information collection determine which diagnostic treatments to select). Thus, in some aspects of the present application, the selection, execution order, and parameters passed between the executed diagnostic services of a series of diagnostic services can be based on user input and the determined treatment groups.

[0055] Exemplarily, treatment groups can be mapped or clustered based on the vehicle's mechanisms such that they can be aligned with the vehicle's major mechanism groups (e.g., powertrain, HVAC, etc.). Other treatment groups can be mapped to individual components or services. Yet another treatment group can be continuously monitored, adjusted, or updated based on the processing results by a network service provider. For example, less selected treatment groups can be changed or integrated. In another example, treatment groups that do not lead to an appropriate service experience or incorrect diagnosis can be abolished, updated, or split.

[0056] In (2), the network-based management component 122 causes the vehicle to perform user input diagnosis and filtering to identify a set of corrective actions to be executed and pre-service procedures that may be required before the services to be performed. The series of corrective actions and pre-service procedures can be embodied as a series of diagnostic services 112 executed by a vehicle or other computer device associated with the vehicle, such as a mobile computer device. Exemplarily, the series of diagnostic services are deployed to be executed by at least one of the vehicle or the associated computer device. The series of diagnostic services may correspond to specified operating parameters based on user input. Further, the series of diagnostic services may also be exploratory in nature, to measure different operating parameters or to attempt to correlate the observed parameters with other operating parameters of the vehicle.

[0057] In (3), a series of diagnostic services may further process the processing results of other diagnostic services to determine whether the vehicle needs service. If it is determined that the vehicle needs service, the management component may provide the user with an option to approve the service. A series of diagnostic services may determine whether to provide service to the user / operator (or other relevant individuals) based on the results of the diagnostic services. In some embodiments, the determination of whether to provide service to the vehicle may be mainly based on the results of the diagnostic services of a specific vehicle (for example, whether the diagnostic services indicate that the specific vehicle needs service). The system may further be based on the supply chain information as a criterion for the option to approve the service. The supply chain information may include the availability of parts or the availability of location-specific parts. The system may determine whether to provide service by comparing the severity of the condition with other users in combination with the availability of parts. In other embodiments, the determination of whether to provide service to the vehicle may be based on a relative comparison of the results of the diagnostic services of multiple vehicles. In this embodiment, the service request may be based on an assessment of the degree of maintenance need compared to other vehicles, especially in scenarios where the availability of parts or the availability of service locations is limited. For example, assume that as a result of the vehicle diagnostic process, service is required, but the failure level is evaluated as "low priority" or "low impact". Even if vehicle service may ultimately be required, the service provision may be postponed to the next execution of the diagnostic suite (for example, service deferral), or modified or configured to be processed for future services that exceed a minimum threshold. Such service changes can be made automatically (without user input or notification) or in conjunction with user notification or input.

[0058] When the diagnostic and filtering processes are complete, at (4), the network-based management component 122 receives approval of the service request by the user and the service schedule. For example, this can include access to user profile information indicating pre-approval or approval thresholds. In other embodiments, this can include receiving positive user input such as operation of a graphical interface, operation of a vehicle control device (e.g., operation of a pedal, presentation of a short-range communication device, selection of a remote control / access input, etc.). In some embodiments, one or more aspects of the present application can include some form of feedback or processing result provided to the user indicating the results of the execution of a series of diagnostic services. For example, the feedback / processing result can be in the form of an evaluation of the results (e.g., excellent, good, bad, etc.). In other examples, the feedback / processing result can be in the form of individual values of a series of diagnostic services, a determined treatment group, a potential cause of failure, or a proposed severity level of a potential failure.

[0059] Following the approval and feedback process, at (5), the network-based management component 122 can interface with an inventory and order system that assigns and orders parts and coordinates payment and support documentation. Exemplarily, the output of a series of diagnostic services can be used for pre-ordering of parts, pre-arrangement of physical services to be performed, etc. Further, the output of a series of diagnostic services can be used as an input for estimating the time until completion of a scheduled service.

[0060] Figure 4 is a flowchart illustrating routine 400 for providing a vehicle diagnostic management service according to one or more embodiments as disclosed herein. Routine 400 begins at block 402 and captures at least one user input. The user input may be user-initiated, for example, where the user reports a problem with the vehicle, or it may be component-initiated, for example, where the management component proposes to the user and the user responds, or some combination thereof. The user input may be captured within the associated vehicle, on a mobile device, or via any associated means. The user may provide an input in the form of a verbal command, a verbal phrase, an input in a touch pattern, an input of a phrase, an input of a command, or any other associated form of input. The input may be a report of a problem with the vehicle, such as "the screen freezes" or "the car lock does not unlock", or the management component may display a message such as "There may be a problem with the battery. Do you want to run a diagnostic?".

[0061] At block 404, the vehicle deploys and executes a series of diagnostic services 112 in response to the at least one captured user input. The series of diagnostic services 112 may include identifying a set of corrective actions or pre-service actions to be performed. The corrective actions may also be determined by first identifying a treatment group. One or more treatment groups may be based on the user input or may be determined prior to block 404. The determined treatment group can determine a series of diagnostic services, and the treatment group may include communication with the network or corrective actions. The analysis, processing, and / or decisions associated with the execution of the series of diagnostics may be performed in the vehicle, at a network service provider, or in cooperation with a network service provider.

[0062] A series of diagnostic services 112 may be investigative in nature, to measure different operating parameters or to attempt to correlate observed parameters with other operating parameters of the vehicle. A series of diagnostic services may be remedial in nature, such as software updates, system resets, or adjustment of operating parameters. A series of diagnostic services for identifying a set of corrective actions to be performed may include determining a treatment group based on user input. A series of diagnostic services in response to user input for identifying a set of corrective actions to be performed may include obtaining at least one diagnostic service from a service provider. Diagnostic and filtering (a series of diagnostic services) of user input for identifying a set of corrective actions to be performed may include changing at least one diagnostic service.

[0063] A series of diagnostic services may include communicating with a network service provider. A service management component may communicate with a network service provider to determine a treatment group. The network service provider may further perform procedures including diagnostic procedures, information collection procedures, or corrective procedures.

[0064] Block 406 includes transmitting the results of a series of diagnostic services. The results of a series of diagnostic services may be transmitted to a network-based management component 122. Additionally or alternatively, the results of a series of diagnostic services may be transmitted to a service shop or technician.

[0065] Block 408 includes obtaining approval for the service requested by the user. The approval may be obtained via a user device such as a mobile phone or via an interface within the vehicle. Block 408 may further include scheduling the service. The service may be scheduled based on part availability, shop availability, and the urgency of the service request.

[0066] Figure 5 is a flowchart illustrating routine 500 for providing a vehicle diagnostic management service according to one or more embodiments disclosed herein. Routine 500 begins at lock 502 and captures at least one user input. The capture of user input 502 may be similar to or the same as block 402 (Figure 4).

[0067] At block 504, vehicle 110 deploys and executes a series of diagnostic services 112 in response to the at least one captured user input. A series of diagnostic services 112 may be used to determine corrective actions. In some embodiments, a series of diagnostic services may be selected by first identifying treatment groups. One or more treatment groups may be based on mapping natural language input provided by the user and potential symptoms. In other embodiments, a series of diagnostic services may be configured to map directly to user input (such as via a touch interface) or may be hierarchically structured to repeat various diagnoses. Through a series of diagnostic services 112 that include communication with network 160, treatment groups and / or corrective actions associated with the treatment groups can be determined.

[0068] At block 506, the results of the series of diagnostic services can be transmitted. It should be understood that blocks 504 and 506 may be in either order or in combination. The transmitted results may be sent to a technician or the network as described with respect to block 406. The results of the series of diagnostic services may include the severity of the problem and / or the severity of the corrective action.

[0069] Block 508 includes determining whether to provide a first service request. The determination of whether to provide the first service request may be based on the severity of the problem, the necessary corrective actions, the necessary parts, the availability of the parts, the availability of the store, the results of a series of diagnostic services, and many other factors. The determination may be made by the network. The network may compare the severity or urgency of the problem with the severity or urgency of problems associated with other users' vehicles to determine who to prioritize. This type of determination is most useful when the number of available parts is limited. The system may further determine or change the corrective action based on the availability of other vehicles 110 and parts within the network. For example, vehicle 110 may have a hardware problem that requires a new infotainment unit, but the number of available infotainment units is limited. Therefore, software-related corrective actions may be prescribed for the user's care until parts become available or the severity of the problem rises to a point where the user's vehicle is prioritized.

[0070] The determination of whether to provide the first service request may be further based on a second problem. The second problem may be associated with a second treatment group and a second corrective action. The network may determine not to provide the first service request until parts or time for completing the second service request are available such that both the first service request and the second service request can be completed simultaneously.

[0071] Figure 6 is a flowchart illustrating a routine 600 for providing a vehicle diagnostic management service according to one or more embodiments as disclosed herein. Routine 600 begins at block 602 and captures at least one user input. The capture of the user input may be similar to or the same as blocks 402 and 502 (Figures 4 and 5).

[0072] Block 604 includes causing a vehicle to execute a series of diagnostic services in response to at least one captured user input. As described above, the series of diagnostic services 112 can be used to determine vehicle state information, attempt one or more corrective actions, or otherwise provide additional diagnostic information. The analysis, processing, and / or decisions associated with the execution of the series of diagnostic services 112 may be performed on the vehicle, by a network service provider, or in cooperation with a network service provider.

[0073] Block 606 includes determining a set of additional actions based on the processing results of the first series of diagnostic services 112 or additional user input. Block 606 may include additional diagnostic services in response to the corrective actions that have been attempted. The additional actions may be related to the corrective actions determined during the filtering of the diagnostic services and user input. The additional actions may be determined by analyzing the corrective actions.

[0074] For example, the required corrective action may be the replacement of a wheel bearing. The replacement of the wheel bearing may require the removal of the brake assembly and the wheel. Based on the vehicle age, mileage, usage data, recent service, and other factors, the system may determine whether the brakes require service or will require service in the near future. Thus, based on the corrective actions associated with the diagnostic services and the filtering of the user input, it may be determined that the brakes should also be replaced. In an alternative example, the additional actions may be completely unrelated. For example, the required corrective action may be a wheel bearing. Based on the determination that the vehicle requires service, additional diagnostics covering the whole or part of the vehicle may be performed.

[0075] In one example, whether the battery should also be replaced when the vehicle is undergoing its corrective action can be determined based on sensor data, years of use, usage amount, voltage, or other criteria. This step enables optimization of store hours and labor. The system can analyze overlapping service requirements to determine whether additional components should be replaced during the service of the first component. In some embodiments, block 606 is executed after obtaining approval of service request 610 or after determining that a service request should be provided.

[0076] Block 608 includes transmitting the results of a series of diagnostic services. The results of the series of diagnostic services can be transmitted to the cloud, a network, or a processor. The results of the series of diagnostic services can be transmitted to a service store or a technician. The results may further be transferred to both.

[0077] Block 610 includes obtaining approval of the service requested by the user. The approval can be obtained via a user device such as a mobile phone or via an interface in the vehicle. Block 608 may further include scheduling the service. The service can be scheduled based on the availability of parts, the availability of the store, and the urgency of the service request.

[0078] Although various aspects are described according to exemplary embodiments and combinations of features, those skilled in the relevant art will understand that the examples and combinations of features are exemplary in nature and should not be construed as limiting. More specifically, the aspects of the present application may be applicable to various types of vehicle data or vehicle processes. However, those skilled in the art will understand that the aspects of the present application are not necessarily limited to any particular type of vehicle data, data communication, or exemplary interaction between third parties, customers, and network service providers.

[0079] The foregoing disclosure is not intended to limit the present disclosure to the exact forms disclosed or to a particular field of use. Accordingly, various alternative embodiments and / or modifications to the present disclosure, whether explicitly described or implied herein, are contemplated as possible in light of the present disclosure. Having thus described embodiments of the present disclosure, those skilled in the art will recognize that changes in form and detail can be made without departing from the scope of the present disclosure. Accordingly, the present disclosure is limited only by the claims.

[0080] In the foregoing specification, the present disclosure has been described with reference to specific embodiments. However, as will be understood by those skilled in the art, the various embodiments disclosed herein can be implemented in various ways without departing from the spirit and scope of the present disclosure. Accordingly, this description should be regarded as exemplary and is for the purpose of teaching those skilled in the art how to make and use the various embodiments of the disclosed air venting assembly. It should be understood that the forms of the disclosure shown and described herein are to be construed as representative embodiments. Equivalent elements, materials, processes, or procedures may be substituted for those typically shown and described herein. Further, certain features of the present disclosure may be utilized independently of other features, all of which will become apparent to those skilled in the art after benefit of this description of the present disclosure. Expressions such as "including," "comprising," "incorporating," "consisting of," "have," "is," etc., used to describe and claim the present disclosure are to be construed in a non-exclusive manner, i.e., intended to allow for the presence of items, components, or elements not explicitly described. References to the singular are also to be construed as relating to the plural.

[0081] Furthermore, the various embodiments disclosed herein should be construed in an illustrative and explanatory sense and should never be construed as limiting the present disclosure. All coupling references (e.g., attached, affixed, coupled, connected, etc.) are used only to assist the reader's understanding of the present disclosure and, in particular, do not result in any limitation with respect to the positions, orientations, or uses of the systems and / or methods disclosed herein. Accordingly, coupling references, if any, are to be construed broadly. Moreover, such coupling references do not necessarily imply that two elements are directly connected to each other.

[0082] Furthermore, all numerical terms such as "first", "second", "third", "primary", "secondary", "main", or any other common and / or numerical terms, not limited to these, should also be understood only as identifiers to assist the reader's understanding with respect to the various elements, embodiments, variations, and / or modifications of the present disclosure, and in particular, do not result in any limitation with respect to the order or priority of any element, embodiment, variation, and / or modification with respect to, or beyond, another element, embodiment, variation, and / or modification.

[0083] It should also be understood that one or more of the elements shown in the drawings / figures may also be implemented in a more separated or integrated manner, or even deleted or discarded as inoperable in certain cases, as useful for a particular application.

Claims

1. A system for managing vehicle maintenance, comprising: a first computer device associated with a vehicle, the first computer device being configured to: capture at least one user input corresponding to at least one of a requested service or an observed vehicle operation parameter; execute a series of diagnostic services in response to the captured at least one user input; transmit at least one processing result associated with the series of diagnostic services; a first computer device having a processor and a memory that execute computer-readable instructions; a second computer device associated with a network-based management component, the second computer device being configured to: acquire the at least one transmitted processing result associated with the series of diagnostic services; determine whether to provide a service request based on the transmitted processing result, the first computer device being further operable to receive a determined provision for the service request; a second computer device having a processor and a memory that execute computer-readable instructions; A system comprising the above.

2. The system according to claim 1, wherein the computer-readable instructions further cause the network-based management component to obtain approval of the service request by a user.

3. The system according to claim 1, wherein the execution of the series of diagnostic services includes identifying a corrective action or a pre-service action to be performed.

4. The system according to claim 3, wherein determining whether to provide the service request is based on the availability of vehicle components, and the vehicle components are based on the corrective action.

5. The system according to claim 1, wherein the first computer device is integrated into the vehicle.

6. A method for managing vehicle maintenance, comprising: capturing at least one user input, the at least one user input corresponding to at least one of a requested service or an observed vehicle operation parameter; executing, in the vehicle, a series of diagnostic services in response to the captured at least one user input; transmitting, in the vehicle, at least one processing result associated with the execution of the series of diagnostic services; Obtaining approval of a service request by a user and scheduling at least one service based at least in part on the at least one processing result; A method comprising. **Claim 7** The method according to claim 6, wherein the execution of a series of diagnostic services includes identifying a set of corrective actions or pre-service actions to be performed. **Claim 8** The method according to claim 7, wherein the execution of a series of diagnostic services includes performing the series of corrective actions or the pre-service actions to be performed. **Claim 9** The method according to claim 6, wherein the step of causing a series of diagnostic services to be executed in the vehicle includes obtaining at least one diagnostic service from a service provider. **Claim 10** The method according to claim 6, wherein the step of causing a series of diagnostic services to be executed in the vehicle includes modifying at least one diagnostic service. **Claim 11** The method according to claim 6, wherein the series of diagnostic services corresponds to a continuous series of diagnostic services. **Claim 12** The method according to claim 6, further comprising maintaining historical information corresponding to multiple executions of the series of diagnostic services. **Claim 13** A method for managing vehicle maintenance, comprising: Receiving at least one of user inputs related to vehicle components; Causing a series of diagnostic services to be executed in the vehicle in response to the at least one received user input; Transmitting at least one processing result associated with the execution of the series of diagnostic services; Determining whether to provide a first service request; A method comprising. **Claim 14** The method according to claim 13, wherein the vehicle component is a battery system. **Claim 15** The method according to claim 13, further comprising prompting the user to enter the user input. **Claim 16** The method according to claim 13, further comprising generating a proposal for additional vehicle diagnostics based on the at least one processing result associated with the execution of the series of diagnostic services. **Claim 17** The method according to claim 13, wherein the execution of a series of diagnostic services includes identifying a corrective action or pre-service action to be performed. **Claim 18** The method according to claim 17, wherein the step of determining whether to provide the first service request is based on the availability of a vehicle component, and the vehicle component is based on the corrective action. **Claim 19** The method according to claim 17, wherein the step of determining whether to provide the first service request is based on the severity of the first problem compared to a plurality of other users, and the first problem is associated with the corrective action.

20. The method according to claim 13, further comprising the step of obtaining approval of the service request by the user.

Images