Task processing method, vehicle and storage medium

Abstract

The invention provides a task processing method, a vehicle and a storage medium, and relates to the technical field of intelligent cabins. The method comprises the steps of receiving an application processing instruction, and generating a to-be-executed task according to the application processing instruction; the to-be-executed task comprises a plurality of sub-tasks; loading a plug-in corresponding to the to-be-executed task to execute the plurality of sub-tasks; for the executed subtask, identifying an interface after the execution of the subtask is completed to obtain a first identification result of the interface, and determining whether the execution of the subtask fails or not according to the first identification result; and if the execution of the sub-task fails, determining a failure reason according to the first identification result, and performing adjustment according to the failure reason so as to enable the execution of the sub-task to be successful, thereby improving the success rate of the sub-task, and further improving the success rate of the overall to-be-executed task.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of intelligent cockpit, and particularly relates to a task processing method, a vehicle and a storage medium. BACKGROUND

[0002] In an intelligent cockpit system, a user often needs to interact with various vehicle-mounted applications through a graphical user interface (GUI), including but not limited to navigation, music and system settings.

[0003] In related technologies, the intelligent cockpit system lacks dynamic adaptation capability for application version iteration and function update. When the actual interface does not match the expectation (such as button position change), the system cannot automatically adjust the operation strategy, resulting in task failure. SUMMARY

[0004] Embodiments of the present application provide a task processing method, a vehicle and a storage medium to solve the problem that the intelligent cockpit system cannot automatically adjust the operation strategy when the actual interface does not match the expectation, resulting in task failure in related technologies.

[0005] In a first aspect, embodiments of the present application provide a task processing method, comprising: receiving an application processing instruction, and generating a to-be-executed task according to the application processing instruction; the to-be-executed task includes a plurality of sub-tasks; loading a plug-in corresponding to the to-be-executed task to execute the plurality of sub-tasks; for the executed sub-tasks, identifying an interface after completion of the sub-task execution to obtain a first identification result of the interface, and determining whether the sub-task execution fails according to the first identification result; if the sub-task execution fails, determining a failure cause according to the first identification result, and adjusting according to the failure cause to make the sub-task execution successful.

[0006] Based on the above technical content, after receiving the application processing instruction, the embodiment of the application generates a to-be-executed task according to the application processing instruction, and the to-be-executed task contains a plurality of sub-tasks. The plug-in corresponding to the to-be-executed task is loaded to execute the plurality of sub-tasks. For the executed sub-task, the interface after the execution of the sub-task is identified, the first identification result of the interface is obtained, and whether the execution of the sub-task fails is determined according to the first identification result. Since the first identification result can reflect the actual state of the interface after the execution of the sub-task, when the execution of the sub-task fails, the reason for the failure of the execution of the sub-task can be determined according to the first identification result, and then corresponding adjustment is made according to the failure reason, forming a closed-loop processing of task generation-task execution-failure analysis and adjustment, improving the correction ability, improving the success rate of the sub-task, and then improving the success rate of the overall to-be-executed task. In addition, automation of task processing is also realized without human intervention.

[0007] In a possible implementation, the to-be-executed task is generated according to the application processing instruction, including: performing semantic understanding on the application processing instruction to obtain instruction information; identifying the current interface to obtain a second identification result of the current interface; generating the to-be-executed task according to the instruction information and the second identification result.

[0008] In the embodiment of the application, since the interface currently located is different when the application processing instruction is received, the process of processing the application processing instruction will also be different, therefore, the corresponding to-be-executed task is generated according to the instruction information and the second identification result representing the current interface information, so that the to-be-executed task matches the current actual interface, the flexibility is high, and the accuracy of the to-be-executed task is also effectively improved, thereby being beneficial to improving the processing efficiency and success rate of the to-be-executed task.

[0009] In a possible implementation, the to-be-executed task is generated according to the instruction information and the second identification result, including: generating an initial to-be-executed task according to the instruction information and a preset task template; wherein the preset task template contains a set of interface nodes corresponding to different instruction information, a node function description and a node inter-jump path; adjusting the initial to-be-executed task based on the second identification result to obtain a final to-be-executed task.

[0010] Here, the second identification result can represent the information of the current interface, and the initial to-be-executed task is dynamically adjusted according to the current actual interface, so that the final to-be-executed task matches the current actual interface, the optimization of the to-be-executed task is realized, the flexibility is high, and at the same time, redundant operations are effectively avoided, which is beneficial to improving the task processing efficiency.

[0011] One possible implementation involves adjusting based on the cause of failure to ensure successful subtask execution, including: Based on the reason for failure, a feedback log is generated; the feedback log includes the subtask that failed, the first recognition result, screenshots of the interface corresponding to the failed subtask and the previous subtask, as well as a screenshot of the current interface and the second recognition result. Adjustments were made based on the feedback logs to ensure that failed subtasks were executed successfully.

[0012] The feedback log contains information from multiple dimensions, including failed subtasks, the first identification result, screenshots of the failed subtask and the corresponding interface of the previous subtask, as well as a screenshot of the current interface and the second identification result. This improves the accuracy of adjustments based on the feedback log, thereby increasing the probability of successful subtask execution.

[0013] In one possible implementation, the interface after the subtask is completed is identified, and the first identification result of the interface is obtained, including: Obtain information about the structured controls on the interface; Take a screenshot of the interface and identify the information contained in the screenshot; Based on the structured control information and the information contained in the screenshot, the first recognition result of the interface is obtained.

[0014] This application's embodiments combine the structured control information of the interface with the information contained in the screenshot to obtain the first recognition result of the interface, thereby improving the robustness and reliability of interface recognition. Furthermore, for non-standard user interfaces, the first recognition result can still be obtained by recognizing the information contained in the screenshot, thus enabling the recognition of various types of interfaces and improving versatility and recognition accuracy.

[0015] In one possible implementation, determining whether the subtask execution failed based on the first identification result includes: Get the expected interface information after the subtask is completed; Based on the initial identification result and the expected interface information, determine whether the subtask execution has failed.

[0016] Based on the aforementioned technical aspects, using the expected interface information as a benchmark provides a clear and objective standard for determining whether a subtask has failed, avoiding execution chaos caused by subjective or vague judgment logic. Furthermore, by comparing the initial identification result with the expected interface information, not only can the failure of a subtask be determined, but also the reason for the failure can be identified with high accuracy.

[0017] In one possible implementation, determining whether the subtask execution failed based on the first identification result and the expected interface information includes: If the first recognition result does not contain the expected interface information, then obtain the retry policy corresponding to the subtask and re-execute the subtask according to the retry policy; The third recognition result of the interface after the subtask has been re-executed; Based on the third identification result and the expected interface information, determine whether the subtask execution has failed.

[0018] In this embodiment of the application, when the first identification result does not contain the expected interface information, the subtask is re-executed according to the retry strategy, instead of directly determining that the subtask has failed. This enables the system to have a preliminary, automatic problem-solving capability and improves processing efficiency.

[0019] In one possible implementation, if a subtask fails, the cause of failure is determined based on the first identification result, including: If the subtask fails to execute, the reason for the failure is determined based on the first identification result, the third identification result, and the expected interface information.

[0020] In this embodiment, the cause of failure is determined based on the first identification result after the subtask is executed for the first time, the third identification result after re-execution, and the expected interface information, which helps to improve the efficiency and accuracy of determining the cause of failure.

[0021] Secondly, embodiments of this application provide a task processing apparatus, including: The task generation module is used to receive application processing instructions and generate tasks to be executed based on the application processing instructions; each task to be executed contains multiple subtasks. The task execution module is used to load the plugins corresponding to the tasks to be executed, so as to execute multiple subtasks; The task execution module is also used to identify the interface after the subtask is completed, obtain the first identification result of the interface, and determine whether the subtask execution has failed based on the first identification result. The task analysis module is used to determine the cause of failure based on the first identification result if a subtask fails, and to make adjustments based on the cause of failure so that the subtask can be executed successfully.

[0022] In one possible implementation, the task generation module is specifically used for: Perform semantic understanding on application processing instructions to obtain instruction information; Identify the current interface and obtain the second identification result of the current interface; Based on the instruction information and the second identification result, generate the task to be executed.

[0023] In one possible implementation, the task generation module is specifically used for: Based on the instruction information and the preset task template, an initial task to be executed is generated; the preset task template includes a set of interface nodes corresponding to different instruction information, the jump path between nodes, and the description of the node functions. Based on the second identification result, the initial task to be executed is adjusted to obtain the final task to be executed.

[0024] In one possible implementation, the task analysis module is specifically used for: Based on the reason for failure, a feedback log is generated; the feedback log includes the subtask that failed, the first recognition result, screenshots of the interface corresponding to the failed subtask and the previous subtask, as well as a screenshot of the current interface and the second recognition result. Adjustments were made based on the feedback logs to ensure that failed subtasks were executed successfully.

[0025] In one possible implementation, the task execution module is specifically used for: Obtain information about the structured controls on the interface; Take a screenshot of the interface and identify the information contained in the screenshot; Based on the structured control information and the information contained in the screenshot, the first recognition result of the interface is obtained.

[0026] In one possible implementation, the task execution module is specifically used for: Get the expected interface information after the subtask is completed; Based on the initial identification result and the expected interface information, determine whether the subtask execution has failed.

[0027] In one possible implementation, the task execution module is specifically used for: If the first recognition result does not contain the expected interface information, then obtain the retry policy corresponding to the subtask and re-execute the subtask according to the retry policy; The third recognition result of the interface after the subtask has been re-executed; Based on the third identification result and the expected interface information, determine whether the subtask execution has failed.

[0028] In one possible implementation, the task analysis module is specifically used for: If the subtask fails to execute, the reason for the failure is determined based on the first identification result, the third identification result, and the expected interface information.

[0029] Thirdly, embodiments of this application provide a vehicle including a memory and a processor. The memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the task processing method as described in any of the first aspects.

[0030] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the task processing method as described in any of the first aspects.

[0031] It is understood that the beneficial effects of the second to fourth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here.

[0032] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this specification. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a schematic diagram of an application scenario provided by an embodiment of this application; Figure 2 This is a flowchart illustrating a task processing method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the plugin loading process provided in an embodiment of this application; Figure 4 This is a flowchart illustrating a task processing method provided in another embodiment of this application; Figure 5 This is a schematic diagram of the structure of a task processing device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of a vehicle provided in one embodiment of this application. Detailed Implementation

[0035] The present application will be described more clearly below with reference to specific embodiments. These embodiments will help those skilled in the art to further understand the function of the present application, but do not limit the present application in any way. It should be noted that those skilled in the art can make several modifications and improvements without departing from the concept of the present application. These all fall within the protection scope of the present application.

[0036] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0037] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0038] In the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0039] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0040] Furthermore, the term "multiple" mentioned in the embodiments of this application should be interpreted as two or more.

[0041] First, the terms used in the embodiments of this application will be explained: Accessibility services refer to the provision of corresponding support functions by taking into account the needs of people with disabilities in the design of intelligent cockpit systems.

[0042] In related technologies, intelligent cockpit systems suffer from a lack of dynamic adaptation to application version iterations and function updates. When the actual interface does not match the expected interface, the system cannot automatically adjust its strategy, leading to mission failure.

[0043] In addition, in related technologies, intelligent cockpit systems integrate accessibility services. However, because accessibility services rely on predefined control attributes of the system and lack the ability to understand the semantics of dynamic page elements, the recognition rate is low in unstructured controls or dynamically rendered interfaces, and the operation target cannot be accurately identified, which can also lead to task failure.

[0044] Meanwhile, for complex tasks, users usually need to manually complete multiple interface jumps, resulting in a lengthy operation path. Furthermore, the intelligent cockpit system cannot automatically identify target controls, indicating weak automation capabilities.

[0045] The applicant has found that, in order to improve the success rate of task processing, it is necessary to consider a new method for task processing.

[0046] To improve task processing success rate, in the embodiments of this application, upon receiving an application processing instruction, a task to be executed can be generated according to the instruction, containing multiple subtasks. The corresponding plugin for the task to be executed is loaded to execute the multiple subtasks. For each executed subtask, the interface after execution is identified, obtaining a first identification result. Based on this first identification result, it is determined whether the subtask execution failed. Since the first identification result reflects the actual state of the interface after subtask execution, the reason for the failure can be determined based on the first identification result when the subtask fails. This allows for corresponding adjustments based on the reason for failure, forming a closed-loop process of task generation, task execution, and failure analysis and adjustment. This improves the correction capability, increases the success rate of subtasks, and consequently improves the overall success rate of the tasks to be executed. Furthermore, it automates task processing without human intervention.

[0047] First refer to Figure 1 , Figure 1 The illustration schematically depicts an application scenario provided according to an embodiment of this application, where the application scenario is clearing the cache of a map application. Specifically, the user can call the in-vehicle voice assistant and output the application processing command "clear map cache," to which the in-vehicle voice assistant can reply, "I have called the cockpit management system to clear the map cache." When the cockpit management system clears the map cache, the multi-agent collaborative control module can generate a task to be executed based on system prompts and application processing commands. The task to be executed may include multiple sub-tasks. Then, the corresponding plugins for the task to be executed can be loaded from the plugin management module to simulate user clicks and other operations, causing interface changes and realizing the execution of the sub-tasks. Accessibility services are used to extract relevant information from the interface, and a screenshot is taken. Optical Character Recognition (OCR) technology is used to identify the information contained in the screenshot. The accessibility service and the information extracted by OCR are input to the multi-agent collaborative control module so that when a sub-task fails, the multi-agent collaborative control module can perform failure analysis based on the accessibility service and OCR information, obtain the cause of failure, and make corresponding adjustments based on the cause of failure to ensure the successful execution of the sub-task.

[0048] The multi-agent collaborative control module comprises multiple agents, each with a corresponding system prompt word defining its identity. These agents play different roles; for example, the module might include a planning agent, an execution agent, and a reflection agent. The planning agent generates tasks, the execution agent loads plugins and executes the tasks, and the reflection agent analyzes failures when subtasks fail, determining the reasons for failure and achieving closed-loop processing. These agents work collaboratively to automate task processing.

[0049] The following is combined with Figure 1 Application scenarios, refer to Figure 2 and Figure 4 This application describes a task processing method provided according to exemplary embodiments. It should be noted that the above application scenarios are shown only to facilitate understanding of the spirit and principles of this application, and the embodiments of this application are not limited in any way. Rather, the embodiments of this application can be applied to any applicable scenario.

[0050] It should be noted that the embodiments of this application can be applied to vehicles, and the vehicle can be a server or a host of the vehicle, that is, the task processing method provided by the exemplary embodiments of this application can be executed on the server or the host of the vehicle.

[0051] The server can be a monolithic server or a distributed server spanning multiple computers or computer data centers. Servers can also be of various categories, such as, but not limited to, web servers, application servers, database servers, or proxy servers.

[0052] Optionally, a server may include hardware, software, or embedded logic components for performing suitable functions supported or implemented by the server, or a combination of two or more such components. For example, a server may be a blade server, a cloud server, or a server group consisting of multiple servers, which may include one or more of the above-mentioned categories of servers, etc.

[0053] It should be noted that the task processing method provided according to the exemplary embodiments of this application can be executed on the same device or on different devices.

[0054] refer to Figure 2 , Figure 2 This is a flowchart illustrating a task processing method provided in an embodiment of this application. Figure 2 As shown, the method in this embodiment can be executed by the cockpit management system, and the method may include: Step 201: Receive application processing instructions and generate a task to be executed based on the application processing instructions; the task to be executed contains multiple subtasks.

[0055] Application processing instructions can be user-interactive input instructions, programmatically invoked instructions, or timed or event-triggered instructions. User-interactive input instructions include, but are not limited to, natural language instructions or instructions generated by clicking predefined task buttons. Natural language instructions can be voice instructions or text instructions; for example, application processing instructions could be "clear map cache" or "open music."

[0056] In one implementation scenario, upon receiving an application processing instruction, semantic understanding can be performed on the instruction to obtain corresponding instruction information, and then a corresponding task to be executed can be generated based on the instruction information. This instruction information includes, but is not limited to, the target object and the corresponding operation type.

[0057] Here, we take the application processing command "clear map cache" as an example. The tasks to be executed at this time can include: start cockpit manager → enter application management → locate map → click to delete cache and other sub-tasks.

[0058] Step 202: Load the plugin corresponding to the task to be executed to execute multiple subtasks.

[0059] In one implementation scenario, the plugins adopt a pluggable modular design, with specific functions written for different plugins.

[0060] Optionally, plugins can be in JavaScript (JS) format. Additionally, plugins can define parameterized operation paths, such as cleanAppCache(pkgName), including but not limited to target entry points, redirection logic, element identification strategies, and exception handling rules.

[0061] The target entry point refers to the starting point for the plugin to execute the task to be performed, used to determine the application function entry point corresponding to the task to be performed. The jump logic defines the path from the current interface to the final execution page. For example, for a plugin that clears application cache, its corresponding jump logic could be "Start the cockpit management system - Enter application management - Locate the target application - Click to delete cache," etc. The target application is the application whose cache data is to be cleared, which can be identified by pkgName. The element recognition strategy refers to the method of recognizing elements in the interface, which can be based on accessibility services, OCR, or a combination of both. The exception handling rules are the strategies for handling exception scenarios. For example, if a subtask fails to execute on its first attempt, the subtask can be re-executed based on the retry strategy corresponding to the subtask.

[0062] In one implementation scenario, the plugin can be located in the cloud. Figure 3 This is a schematic diagram of the plugin loading process provided in an embodiment of this application, for reference. Figure 3 As shown, the cloud distributes a JS plugin to the vehicle's infotainment system's plugin loader. The plugin loader loads and runs the JS plugin, obtaining callable interfaces. The cockpit management system executes the JS plugin logic during JS runtime by calling the generated interfaces. The JS plugin calls the native interfaces provided by the vehicle's operating system through native bridging, ultimately manipulating interface elements and causing corresponding changes in the in-vehicle GUI, thus executing multiple subtasks. Furthermore, when a new plugin is added from the cloud, the plugin loader can also load and run it, sending the plugin to the cockpit management system.

[0063] Compared to hard-coding the operation process into the intelligent cockpit system, which cannot dynamically adapt to different application versions or new functions, this application embodiment supports the distribution of JS format plugins from the cloud. When the interface of an application changes, causing the plugin to malfunction, developers can update the plugin in the cloud. The local vehicle can then retrieve and load the new plugin, which takes effect without restarting the system, achieving hot updates for plugins. Furthermore, developers can add new plugins in the cloud, which the local vehicle can dynamically acquire, gaining access to previously unpreset automated task processing capabilities. This achieves dynamic expansion, enabling plugin updates and additions without over-the-air (OTA) technology, and without requiring system or threshold script recompilation, offering high flexibility.

[0064] Step 203: For the executed subtask, identify the interface after the subtask is completed, obtain the first identification result of the interface, and determine whether the subtask execution has failed based on the first identification result.

[0065] Here, the first recognition result is the recognition information of the corresponding interface after the subtask is completed. In one implementation scenario, the interface after the subtask is completed can be recognized through accessibility services and / or character recognition technology to obtain the first recognition result of the interface. Among them, character recognition technology includes, but is not limited to, optical character recognition technology.

[0066] In some embodiments, when determining whether a subtask execution has failed based on the first identification result, expected interface information for each subtask's corresponding interface can be preset. The failure of the subtask execution can be determined by comparing the first identification result with the expected interface information. The expected interface information includes, but is not limited to, fields and component IDs in the interface.

[0067] In one implementation scenario, if the first recognition result contains the expected interface information, it indicates that the current subtask has been executed successfully.

[0068] In another implementation scenario, if the first recognition result does not contain the expected interface information, it indicates that the current subtask has failed.

[0069] Step 204: If the subtask fails to execute, determine the reason for the failure based on the first identification result, and make adjustments based on the reason for the failure to make the subtask execute successfully.

[0070] In one implementation scenario, the cause of failure can be determined based on the initial recognition result and the expected interface information. Causes of failure include, but are not limited to, interface recognition errors, operation timeouts, and process interruptions.

[0071] Optionally, after determining the cause of failure, when making adjustments based on the cause of failure, a new task to be executed can be regenerated and executed based on the cause of failure and the originally generated task to be executed. Alternatively, the originally generated task to be executed can be updated based on the cause of failure, and then the updated task to be executed can be executed.

[0072] In one implementation scenario, a corresponding suggested strategy can be generated based on the cause of failure, and a new task to be executed can be regenerated or the previously generated task to be executed can be updated according to the suggested strategy.

[0073] In this embodiment, upon receiving an application processing instruction, a task to be executed is generated based on the instruction. This task contains multiple subtasks. The corresponding plugin for each subtask is loaded to execute these subtasks. For each executed subtask, the interface after execution is identified, yielding a first identification result. Based on this result, it is determined whether the subtask execution failed. Since the first identification result reflects the actual state of the interface after subtask execution, the reason for failure can be determined based on this result. This allows for adjustments based on the failure reason, forming a closed-loop process of task generation, task execution, and failure analysis and adjustment. This improves the correction capability, increases the success rate of subtasks, and consequently improves the overall success rate of the tasks to be executed. Furthermore, it automates task processing without human intervention.

[0074] In addition, after receiving the application processing instruction, this application embodiment also needs to consider how to generate the task to be executed according to the application processing instruction, how to identify the interface after the subtask is completed in order to improve the accuracy of the first identification result, and how to determine the failure reason according to the first identification result in order to improve the accuracy of the failure reason, etc. Figure 4 This is a flowchart illustrating a task processing method provided in another embodiment of this application, such as... Figure 4 As shown, the method includes: Step 401: Receive application processing instructions.

[0075] Here, for the implementation of step 401, please refer to [link / reference]. Figure 2 The relevant descriptions in the embodiments will not be repeated here.

[0076] Step 402: Perform semantic understanding on the application processing instructions to obtain instruction information, identify the current interface to obtain the second identification result of the current interface, and generate a task to be executed based on the instruction information and the second identification result. The task to be executed contains multiple sub-tasks.

[0077] Here, the second recognition result is the recognition information of the current interface when the application processing instruction is received.

[0078] Optionally, a Large Language Model (LLM) can be used to perform semantic understanding of the application processing instructions to obtain the corresponding instruction information, and then combine the second recognition result to generate the task to be executed.

[0079] In addition to large language models, semantic understanding of application processing instructions can also be achieved by extracting keywords and then matching them with preset templates, or by performing semantic understanding of application processing instructions based on multimodal fusion or by using statistical models. This application does not limit the method of performing semantic understanding of application processing instructions.

[0080] In some embodiments, the process of processing application processing instructions may differ depending on the current interface when the instructions are received. In one implementation scenario, if the current interface is not considered, and the corresponding task to be executed is generated solely based on the instruction information, it may lead to a mismatch between the task to be executed and the current interface, resulting in problems such as the task failing to execute or low processing efficiency.

[0081] Therefore, the current interface needs to be identified before generating the task to be executed. In this embodiment, the corresponding task to be executed is generated based on the instruction information and the second identification result representing the current interface information. This makes the task to be executed match the current actual interface, which is highly flexible and effectively improves the accuracy of the task to be executed, thereby helping to improve the processing efficiency and success rate of the task to be executed.

[0082] Here, the current interface can be identified through accessibility services and / or optical character recognition technology to obtain a second recognition result. For details, please refer to the process of obtaining the first recognition result below. The principle is basically the same, and it will not be elaborated here.

[0083] In some embodiments, generating a task to be executed based on instruction information and a second identification result includes: generating an initial task to be executed based on instruction information and a preset task template; wherein the preset task template includes a set of interface nodes corresponding to different instruction information, jump paths between nodes, and node function descriptions; and adjusting the initial task to be executed based on the second identification result to obtain the final task to be executed.

[0084] In one implementation scenario, the operation of the application can be abstracted and organized into a graph structure to obtain a preset task template that includes a set of interface nodes, jump paths between nodes, and descriptions of node functions.

[0085] One example of a preset task template is shown below: {node: [Main Interface, Application Management Interface, Storage Management Interface] Expected interface information for the application management interface: The application management interface should display a list of managed applications. path: ("Main Interface" → "Application Management Interface") Action: Click "Application Management" Function: (Clear app memory, Application Management Interface) } For example, if the application processing instruction is "clear map cache", based on the preset task template, the large language model can match the function of "clear app memory", and then plan a multi-step path, i.e. multiple sub-tasks, that is, first start the cockpit management system, click application management to enter the application management interface, then refresh the application list, click to match the corresponding package name, and finally click "clear cache".

[0086] In one implementation scenario, the initial tasks to be executed are dynamically adjusted based on the second recognition result, including but not limited to adjusting the order, type, and number of subtasks within the initial tasks to be executed. For example, when "clearing map cache" as mentioned above, if the second recognition result determines that the current interface is the application management interface, then after starting the cockpit management system, one can directly refresh the application list, click the corresponding package name, and finally click "clear cache".

[0087] In some embodiments, tasks to be executed can also be generated using scripting.

[0088] Here, the second recognition result can characterize the information of the current interface. Based on the current actual interface, the initial task to be executed is dynamically adjusted so that the final task to be executed matches the current actual interface, thereby optimizing the task to be executed. This method is highly flexible and also effectively avoids redundant operations, which helps to improve task processing efficiency.

[0089] Step 403: Load the plugin corresponding to the task to be executed to execute multiple subtasks.

[0090] For the implementation of step 403, please refer to [link / reference]. Figure 2 The relevant descriptions in the embodiments will not be repeated here.

[0091] Step 404: For the executed subtask, obtain the structured control information of the interface after the subtask is completed, take a screenshot of the interface, identify the information contained in the screenshot, and obtain the first identification result of the interface based on the structured control information and the information contained in the screenshot.

[0092] In one possible implementation, the accessibility service can be invoked to obtain the structured control information of the interface after the subtask is completed.

[0093] The structured control information of the interface includes, but is not limited to, the control ID, text, coordinates, and operable status of the interface.

[0094] In addition to accessibility services, other accessibility technologies, such as haptic feedback, may also be used, and this application does not limit them.

[0095] In one implementation scenario, after taking a screenshot of the interface, a lightweight OCR engine can be called to recognize the information contained in the screenshot. The information contained in the screenshot includes, but is not limited to, visible text information and corresponding coordinates.

[0096] In addition to OCR, other character recognition technologies can also be used to recognize information in the screenshot, such as deep learning-based text recognition, and this application does not impose any specific limitations on this.

[0097] In some embodiments, when obtaining the first recognition result of the interface based on the structured control information and the information contained in the screenshot, the structured control information and the information contained in the screenshot can be fused. For example, the coordinates of a control in the structured control information and the corresponding coordinates of the control in the information contained in the screenshot can be weighted and summed to obtain the final coordinates of the control. In addition, the text information in the structured control information and the visible text information in the information contained in the screenshot can be verified and fused.

[0098] In one implementation scenario, the first recognition result can be an Enhanced UISemantic Graph.

[0099] Accessibility services typically cannot recognize dynamic interfaces, such as mini-games or webviews, nor can they recognize interfaces developed using React Native (RN). OCR suffers from poor accuracy, low coordinate accuracy, poor performance, and slow recognition speed, making it inaccurate for dynamic, complex interfaces with repetitive components.

[0100] Here, this application embodiment constructs a dual-channel interface perception system. Specifically, by combining the structured control information of the interface with the information contained in the screenshot, the first recognition result of the interface is obtained, improving the robustness and reliability of interface recognition. Furthermore, for non-standard user interfaces (UI), the first recognition result can still be obtained by recognizing the information contained in the screenshot, thus enabling the recognition of various types of interfaces and improving versatility and recognition accuracy. The non-standard UI interface can be an unstructured control interface or a dynamically rendered interface; specifically, it can be an H5 page, a gamified interface, etc.

[0101] Step 405: Obtain the expected interface information after the subtask is completed. Based on the first identification result and the expected interface information, determine whether the subtask execution has failed.

[0102] In one implementation scenario, the preset task template also includes the expected interface information for each node. Referring to the preset task template in the example above, the expected interface information for the application management interface includes a list of applications under management. For the storage management interface, it may include buttons such as "Clear Cache".

[0103] Based on the initial recognition result and the expected interface information, it is determined whether the subtask execution has failed. Specifically, multimodal element matching and comparison can be performed on the initial recognition result and the expected interface information, and the failure of the subtask execution can be determined based on the comparison result. Among them, multimodal elements include, but are not limited to, text, controls, etc.

[0104] Here, the expected interface information is used as a benchmark, providing a clear and objective standard for judging whether a subtask has failed, thus avoiding execution disorder caused by subjective or vague judgment logic. Furthermore, by comparing the first identification result with the expected interface information, not only can the failure of a subtask be determined, but also the reason for the failure can be identified with high accuracy.

[0105] In some embodiments, determining whether the subtask execution has failed based on the first identification result and the expected interface information includes: if the first identification result does not contain the expected interface information, obtaining the retry policy corresponding to the subtask and re-executing the subtask according to the retry policy; identifying the third identification result of the interface after the subtask has been re-executed; and determining whether the subtask execution has failed based on the third identification result and the expected interface information.

[0106] In one implementation scenario, the preset task template also includes retry strategies for the jump paths between each node. The retry strategies include, but are not limited to, sliding, waiting, and switching recognition modes.

[0107] For example, the action to navigate from the main interface to the application management interface is "click on application management". If this fails, a preset retry strategy, such as swiping, can be used to navigate from the main interface to the application management interface.

[0108] Here, switching recognition modes refers to switching between the methods of obtaining the first and second recognition results of the interface. Taking the first recognition result as an example, as shown in step 404 above, the structured control information of the interface can be obtained by calling the accessibility service, and the information contained in the screenshot can be recognized by calling the OCR engine to obtain the first recognition result. However, in a poor network environment, one of the recognition methods can be turned off, such as turning off the OCR engine, and only obtaining the structured control information by calling the accessibility service, using this structured control information as the first recognition result. Since only one method is used to obtain the first recognition result at this time, to avoid errors in the first recognition result, the recognition mode can be switched, that is, switched to the OCR engine to recognize the information contained in the screenshot for retry.

[0109] After determining the retry strategy and re-executing the subtask according to the retry strategy, a third identification result can be identified in the interface after the subtask has been re-executed. Therefore, the third identification result is the identification information of the corresponding interface after the subtask has been re-executed. In one implementation scenario, if the third identification result does not contain the expected interface information, it indicates that the subtask execution has failed. In another implementation scenario, if the third identification result contains the expected interface information, it indicates that the subtask execution has succeeded, and the next subtask can be executed.

[0110] In this embodiment of the application, when the first identification result does not contain the expected interface information, the subtask is re-executed according to the retry strategy, instead of directly determining that the subtask has failed. This enables the system to have a preliminary, automatic problem-solving capability and improves processing efficiency.

[0111] Here, during the execution of the task to be executed, the complete execution trajectory can be recorded, including but not limited to: operation actions, first recognition result, second recognition result, third recognition result, timestamp, screenshot, information in the screenshot, and structured control information, etc.

[0112] Step 406: If the subtask fails to execute, determine the reason for the failure based on the first identification result, and generate a feedback log based on the reason for the failure. The feedback log includes the subtask that failed to execute, the first identification result, screenshots of the interface corresponding to the failed subtask and the previous subtask, as well as a screenshot of the current interface and the second identification result. Adjustments are made based on the feedback log to ensure that the failed subtask executes successfully.

[0113] In some embodiments, if a subtask fails to execute, the reason for the failure is determined based on the first identification result, the third identification result, and the expected interface information.

[0114] In one implementation scenario, if a subtask fails, the first and third recognition results can be compared with the expected interface information to determine the discrepancy. For example, neither the first nor the third recognition result may contain the target button from the expected interface information. Once the discrepancy is determined, the cause of failure can be identified. For instance, the cause of failure could be that the OCR misidentified "clear" as "remove," resulting in the first and third recognition results not containing the "clear" button.

[0115] Here, the cause of failure is determined based on the first identification result after the subtask is executed for the first time, the third identification result after re-execution, and the expected interface information, which helps to improve the efficiency and accuracy of determining the cause of failure.

[0116] In another implementation scenario, each subtask can have a preset waiting time. If the corresponding interface is not displayed within the waiting time after the subtask is executed, it can be considered an operation timeout. For example, the reason for failure could be that the application list has not finished loading.

[0117] Besides operation timeout, failure reasons can also include process interruption. In one implementation scenario, if a keyboard is displayed on the screen, the keyboard may obscure some controls. Because these controls cannot be operated, the next subtask cannot be executed, i.e., the process is interrupted.

[0118] Optionally, the cause of failure can be determined and a feedback log can be generated using a large language model. Specifically, the application processing instructions, tasks to be executed, the first recognition result of each subtask, and the corresponding expected interface information are input into the large language model. The large language model determines the cause of failure, generates a feedback log based on the cause of failure, and outputs the feedback log.

[0119] Here, the feedback log includes failed subtasks, the first identification result, screenshots of the interfaces corresponding to the failed subtasks and the previous subtask, a screenshot of the current interface, and the second identification result. In addition, it may include suggested strategies and other information. In one implementation scenario, the feedback log can be a structured feedback log.

[0120] In some embodiments, after generating feedback logs, the generation strategy for subsequent similar tasks can be dynamically adjusted based on the feedback logs. For example, a "wait for list loading" step can be added. Optionally, the tasks to be executed can be regenerated based on the feedback logs and application processing instructions. Specifically, the feedback logs and application processing instructions can be input into a large language model so that the large language model outputs updated tasks to be executed, and the updated tasks can then be executed.

[0121] In some embodiments, after generating feedback logs, corresponding plugin updates in the cloud can be triggered based on the feedback logs, such as correcting OCR keyword matching rules, to achieve continuous optimization of system capabilities.

[0122] The feedback log contains information from multiple dimensions, including failed subtasks, the first identification result, screenshots of the failed subtask and the corresponding interface of the previous subtask, as well as a screenshot of the current interface and the second identification result. This improves the accuracy of adjustments based on the feedback log, thereby increasing the probability of successful subtask execution.

[0123] In another implementation scenario, after a subtask fails to execute, the rules engine can be used to make corresponding adjustments to ensure that the subtask executes successfully.

[0124] In this embodiment, an application processing instruction is received, and semantic understanding is performed on the instruction to obtain instruction information. The current interface is identified, and a second identification result of the current interface is obtained. Based on the instruction information and the second identification result, a task to be executed is generated, ensuring that the task to be executed matches the current actual interface, which helps improve the processing efficiency and success rate of the task to be executed. The task to be executed contains multiple subtasks. The corresponding plugin for the task to be executed is loaded to execute the multiple subtasks. For each executed subtask, the structured control information of the interface after the subtask is completed is obtained, a screenshot of the interface is taken, and the information contained in the screenshot is identified. Based on the structured control information and the information contained in the screenshot, a first identification result of the interface is obtained, improving the robustness and reliability of interface identification. It can also identify non-standard user interfaces and obtain corresponding first identification results, improving versatility. After obtaining the first identification result of the interface, the expected interface information after the subtask is completed is obtained. Based on the first identification result and the expected interface information, it is determined whether the subtask execution has failed. If the subtask execution fails, the reason for failure is determined based on the first identification result, and a feedback log is generated based on the reason for failure. Adjustments are made based on the feedback log to ensure that the failed subtask is executed successfully. Because the feedback log contains information from multiple dimensions, including failed subtasks, the first identification result, screenshots of the interfaces corresponding to the failed and previous subtasks, a screenshot of the current interface, and the second identification result, the accuracy of adjustments based on the feedback log is improved, thereby increasing the probability of successful subtask execution. As can be seen, this embodiment forms a closed-loop process of task generation, task execution, and failure analysis and adjustment, improving correction capabilities, increasing the success rate of subtasks, and consequently improving the overall success rate of tasks to be executed. Furthermore, it automates task processing without requiring human intervention.

[0125] It should be understood that the sequence number of each step in the above embodiments 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.

[0126] Figure 5 This is a schematic diagram of the structure of a task processing device provided in an embodiment of this application. Figure 5 As shown, the task processing device provided in this embodiment may include: a task generation module 501, a task execution module 502, and a task analysis module 503.

[0127] The task generation module 501 is used to receive application processing instructions and generate tasks to be executed according to the application processing instructions; the tasks to be executed contain multiple subtasks. Task execution module 502 is used to load the plugin corresponding to the task to be executed, so as to execute multiple subtasks; The task execution module 502 is also used to identify the interface after the execution of the subtask, obtain the first identification result of the interface, and determine whether the execution of the subtask has failed based on the first identification result. The task analysis module 503 is used to determine the cause of failure based on the first identification result if the subtask fails to execute, and to make adjustments based on the cause of failure so that the subtask can be executed successfully.

[0128] In one implementation scenario, the task generation module 501, the task execution module 502, and the task analysis module 503 can be respectively connected to... Figure 1 The multi-agent collaborative control module includes a planning agent, an execution agent, and a reflection agent, which work together to automate task processing.

[0129] In one possible implementation, the task generation module 501 is specifically used for: Perform semantic understanding on application processing instructions to obtain instruction information; Identify the current interface and obtain the second identification result of the current interface; Based on the instruction information and the second identification result, generate the task to be executed.

[0130] In one possible implementation, the task generation module 501 is specifically used for: Based on the instruction information and the preset task template, an initial task to be executed is generated; the preset task template includes a set of interface nodes corresponding to different instruction information, the jump path between nodes, and the description of the node functions. Based on the second identification result, the initial task to be executed is adjusted to obtain the final task to be executed.

[0131] In one possible implementation, the task analysis module 503 is specifically used for: Based on the reason for failure, a feedback log is generated; the feedback log includes the subtask that failed, the first recognition result, screenshots of the interface corresponding to the failed subtask and the previous subtask, as well as a screenshot of the current interface and the second recognition result. Adjustments were made based on the feedback logs to ensure that failed subtasks were executed successfully.

[0132] In one possible implementation, the task execution module 502 is specifically used for: Obtain information about the structured controls on the interface; Take a screenshot of the interface and identify the information contained in the screenshot; Based on the structured control information and the information contained in the screenshot, the first recognition result of the interface is obtained. In one possible implementation, the task execution module 502 is specifically used for: Get the expected interface information after the subtask is completed; Based on the initial identification result and the expected interface information, determine whether the subtask execution has failed.

[0133] In one possible implementation, the task execution module 502 is specifically used for: If the first recognition result does not contain the expected interface information, then obtain the retry policy corresponding to the subtask and re-execute the subtask according to the retry policy; The third recognition result of the interface after the subtask has been re-executed; Based on the third identification result and the expected interface information, determine whether the subtask execution has failed.

[0134] In one possible implementation, the task analysis module 503 is specifically used for: If the subtask fails to execute, the reason for the failure is determined based on the first identification result, the third identification result, and the expected interface information.

[0135] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0136] Figure 6 This is a schematic diagram of the structure of a vehicle provided in one embodiment of this application. Figure 6 As shown, the vehicle 600 in this embodiment includes a processor 610 and a memory 620, wherein the memory 620 stores a computer program 621 that can run on the processor 610. When the processor 610 executes the computer program 621, it implements the steps in any of the above method embodiments, for example... Figure 2 Steps 201 to 204 are shown. Alternatively, when processor 610 executes computer program 621, it implements the functions of each module / unit in the above-described device embodiments, for example... Figure 5 The functions of modules 501 to 503 are shown.

[0137] For example, computer program 621 may be divided into one or more modules / units, one or more of which are stored in memory 620 and executed by processor 610 to complete this application. One or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 621 in vehicle 600.

[0138] Those skilled in the art will understand that Figure 6This is merely an example of a vehicle and does not constitute a limitation on the vehicle. It may include more or fewer components than shown, or combinations of certain components, or different components, such as input / output devices, network access devices, buses, etc.

[0139] The processor 610 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0140] The memory 620 can be an internal storage unit of the vehicle, such as a hard drive or memory, or an external storage device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc. The memory 620 can also include both internal and external storage devices. The memory 620 is used to store computer programs and other programs and data required by the vehicle. The memory 620 can also be used to temporarily store data that has been output or will be output.

[0141] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0142] An embodiment of this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described task processing method.

[0143] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0144] 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.

[0145] In the embodiments provided in this application, it should be understood that the disclosed devices / vehicles and methods can be implemented in other ways. For example, the device / vehicle embodiments described above are merely illustrative. For instance, the division of modules or 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 mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0146] 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 this embodiment according to actual needs.

[0147] Furthermore, 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0148] If the integrated module / 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, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0149] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A task processing method characterized by, The method comprises the following steps: receiving an application processing instruction, and generating a to-be-executed task according to the application processing instruction; the to-be-executed task comprises a plurality of sub-tasks; loading a plug-in corresponding to the to-be-executed task to execute the plurality of sub-tasks; for an executed sub-task, identifying an interface after the execution of the sub-task is completed, obtaining a first identification result of the interface, and determining whether the execution of the sub-task fails according to the first identification result; if the execution of the sub-task fails, determining a failure cause according to the first identification result, and adjusting according to the failure cause to make the execution of the sub-task successful.

2. The task processing method according to claim 1, characterized by, The step of generating a to-be-executed task according to the application processing instruction comprises the following steps: performing semantic understanding on the application processing instruction to obtain instruction information; identifying a current interface to obtain a second identification result of the current interface; generating the to-be-executed task according to the instruction information and the second identification result.

3. The task processing method according to claim 2, characterized by, The step of generating the to-be-executed task according to the instruction information and the second identification result comprises the following steps: generating an initial to-be-executed task according to the instruction information and a preset task template; the preset task template comprises a set of interface nodes corresponding to different instruction information, a node function description, and a node function description; adjusting the initial to-be-executed task based on the second identification result to obtain a final to-be-executed task.

4. The task processing method according to claim 2, characterized by, The step of adjusting according to the failure cause to make the execution of the sub-task successful comprises the following steps: generating a feedback log according to the failure cause; the feedback log comprises a sub-task that fails to execute, a first identification result, a screenshot of an interface corresponding to the sub-task that fails to execute and a previous sub-task, and a screenshot of a current interface and a second identification result; adjusting according to the feedback log to make the sub-task that fails to execute successful.

5. The task processing method according to any one of claims 1 to 4, characterized by, The step of identifying an interface after the execution of the sub-task is completed to obtain a first identification result of the interface comprises the following steps: obtaining structured control information of the interface; taking a screenshot of the interface and identifying information contained in the screenshot; obtaining the first identification result of the interface according to the structured control information and the information contained in the screenshot.

6. The task processing method according to any one of claims 1 to 4, characterized by, The step of determining whether the execution of the sub-task fails according to the first identification result comprises the following steps: obtaining expected interface information after the execution of the sub-task is completed; determining whether the execution of the sub-task fails according to the first identification result and the expected interface information.

7. The task processing method according to claim 6, characterized by, The step of determining whether the execution of the sub-task fails according to the first identification result and the expected interface information comprises the following steps: if the first identification result does not contain the expected interface information, obtaining a retry strategy corresponding to the sub-task, and re-executing the sub-task according to the retry strategy; identifying a third identification result of an interface after the re-executed sub-task is completed; determining whether the execution of the sub-task fails according to the third identification result and the expected interface information.

8. The task processing method according to claim 7, characterized by, The step of determining a failure cause according to the first identification result if the execution of the sub-task fails comprises the following steps: if the execution of the sub-task fails, determining the failure cause according to the first identification result, the third identification result, and the expected interface information.

9. A vehicle characterized by comprising: A computer program product comprising a memory and a processor, said memory having stored therein a computer program operable to run on said processor, characterized in that said processor, when executing said computer program, implements the task processing method according to any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 9. The computer program product, when executed by the processor, implements the task processing method according to any one of claims 1 to 8.

Images