Vehicle end right benefit processing method and device, vehicle and storage medium

Abstract

The application provides a vehicle-end right processing method and device, a vehicle and a storage medium. The method comprises the following steps: obtaining a data ontology file and at least one skill directory; constructing a target right graph based on the data ontology file and the at least one skill directory; and in the case that a target right operation request is received, processing a target vehicle-end right corresponding to the target right operation request according to the target right graph. This technical solution introduces the data ontology file and the at least one skill directory to construct the target right graph. When the target right operation request is received, the target right graph can be used for reasoning. The right verification logic does not need to be fixed in the business code. The target right graph generated by the data ontology and the skill directory is used to process the vehicle-end right. The dependence on code modification and redeployment is significantly reduced. The right expansion flexibility and the business operation stability are improved.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a method, apparatus, vehicle, and storage medium for processing vehicle-side rights. Background Technology

[0002] In the field of intelligent connected vehicles, vehicle-side rights are used to define the eligibility of users for vehicle functions, subscription services, after-sales benefits, and other services. The vehicle-side rights management and authentication system is a core business component for realizing rights issuance, permission verification, and service delivery.

[0003] The current mainstream approach to implementing vehicle-side benefits mainly involves embedding the authentication and verification logic within the business code. By using a pre-defined function switch status table, instructions are sent from the cloud to modify the switch values ​​in order to activate the corresponding vehicle-side benefits.

[0004] While the above implementation method can complete the basic rights authentication and activation business, it is necessary to modify the corresponding business code and redeploy it every time a new right is added, changed, or a right is activated, making it difficult to balance the flexibility of rights expansion and the stability of business operation. Summary of the Invention

[0005] The purpose of this application is to provide a method, apparatus, vehicle, and storage medium for processing vehicle-side rights, to solve the technical problem that while existing technologies can complete basic rights authentication and activation, each time a right is added, changed, or activated, the corresponding business code needs to be modified and redeployed, making it difficult to balance the flexibility of rights expansion with the stability of business operation. The specific technical solution is as follows: In a first aspect of this application, a method for processing vehicle-side rights is provided, the method comprising: Obtain the data ontology file and at least one skill directory; Based on the data ontology file and at least one of the skill directories, a target rights graph is constructed; Upon receiving a target benefit operation request, the target vehicle-side benefit corresponding to the target benefit operation request is processed according to the target benefit map.

[0006] In an optional implementation, constructing the target rights graph based on the data ontology file and at least one of the skill directories includes: The data ontology file is parsed to determine the map hierarchy information; For any of the aforementioned skill catalogs, determine the corresponding rights and interests information for that skill catalog; Based on the rights and interests information corresponding to each of the skill catalogs and the map hierarchy information, the target rights and interests map is constructed.

[0007] In an optional implementation, determining the rights and benefits information corresponding to the skills catalog includes: The skill catalog is parsed to determine the configuration files and file information; Extract the ontology registration section from the configuration file. The ontology registration section contains at least the rights item identifier, rights item classification, and associated function code. If the file information includes a package-type file, obtain the package attributes and sub-service identifier list from the package-type file, and determine the ontology registration section, the package attributes, and the sub-service identifier list as the rights and benefits information corresponding to the skill catalog; If the file information does not contain package-type files, the ontology registration section will be identified as the rights and benefits information corresponding to the skill catalog.

[0008] In an optional implementation, constructing the target rights graph based on the rights item information corresponding to each of the skill directories and the graph hierarchy information includes: Based on the graph hierarchy information, at least one concept node, relation edge template, and axiom rule are determined; For any of the skill catalogs, obtain the rights item category, rights item identifier, and associated function code from the rights item information corresponding to the skill catalog; Based on the classification of the rights items, a target concept node is determined from at least one of the concept nodes; If the rights and benefits information corresponding to the skill catalog contains a list of sub-service identifiers, then at least one rights and benefits node corresponding to a sub-service is determined based on the list of sub-service identifiers, and a package node is created based on the rights and benefits identifier and the associated function code; Along the relationship edge in the relationship edge template, attach the benefit item nodes corresponding to each sub-service to the package node, and along the inheritance relationship edge in the relationship edge template, attach the package node to the target concept node; Obtain the rules corresponding to the package node and the rules corresponding to the benefit item nodes of each sub-service from the axiom rules; The rules corresponding to the package node are attached to the package node, and the rules corresponding to the benefit item nodes corresponding to each sub-service are attached to the benefit item nodes corresponding to each sub-service, to obtain the target benefit graph.

[0009] In an optional implementation, the method further includes: If the rights and benefits information corresponding to the skill catalog does not include the sub-service identifier list, then a rights and benefits node is created based on the rights and benefits identifier and the associated function code; Attach the equity item node to the target concept node along the inheritance relationship edge in the relationship edge template; Obtain the rule corresponding to the equity item node from the axiom rules; The rules are attached to the rights and interests nodes to obtain the target rights and interests graph.

[0010] In an optional implementation, determining at least one rights item node corresponding to a sub-service based on the sub-service identifier list includes: For any sub-service identifier in the sub-service identifier list, determine the target skill directory and sub-service corresponding to the sub-service identifier; The target skill catalog is parsed, and the corresponding rights item nodes for the sub-services are created.

[0011] In an optional implementation, processing the target vehicle-side rights corresponding to the target rights operation request based on the target rights graph includes: If the target rights operation request is an authorization request, obtain the target function code carried in the target rights operation request; Based on the target function code, reasoning is performed in the target rights graph to obtain a first reasoning result; If the first inference result representation allows its use, the target vehicle-side rights corresponding to the target rights operation request are allowed to be used. If the first inference result indicates that the target vehicle-side rights corresponding to the target rights operation request are refused use, the use of the target rights operation request will be refused.

[0012] In an optional implementation, processing the target vehicle-side rights corresponding to the target rights operation request based on the target rights graph includes: If the target benefit operation request is a purchase pre-inspection request, obtain the target benefit item identifier carried in the target benefit operation request; Based on the target equity item identifier, reasoning is performed in the target equity graph to obtain a second reasoning result; If the second reasoning result indicates that purchase is permitted, then the purchase of the target vehicle-side rights corresponding to the target rights operation request is permitted; If the second reasoning result indicates a refusal to purchase, then the purchase of the target vehicle-side rights corresponding to the target rights operation request will be refused.

[0013] In a second aspect of this application, a processing apparatus for vehicle-side rights is also provided, the apparatus comprising: The data acquisition module is used to acquire the data ontology file and at least one skill directory; The graph construction module is used to construct a target rights graph based on the data ontology file and at least one of the skill directories; The rights and interests processing module is used to process the target vehicle-side rights and interests corresponding to the target rights and interests operation request based on the target rights and interests map when a target rights and interests operation request is received.

[0014] In a third aspect of the embodiments of this application, a vehicle is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; The processor, when executing a program stored in memory, implements the processing method for the vehicle-end rights as described in any of the first aspects above.

[0015] In a fourth aspect of the embodiments of this application, a storage medium is also provided, wherein the storage medium stores instructions that, when executed on a computer, cause the computer to perform the processing method for vehicle-side rights as described in any of the first aspects above.

[0016] In a fifth aspect of the embodiments of this application, a computer program product including instructions is also provided, which, when run on a computer, causes the computer to perform the processing method for vehicle-side rights as described in any of the first aspects above.

[0017] The technical solution provided in this application involves acquiring a data ontology file and at least one skill directory; constructing a target rights graph based on the data ontology file and at least one skill directory; and processing the target vehicle-side rights corresponding to the target rights operation request based on the target rights graph upon receiving a target rights operation request. This technical solution, by introducing a data ontology file and at least one skill directory to construct a target rights graph, can perform reasoning based on this target rights graph upon receiving a target rights operation request. It eliminates the need to embed rights verification logic in the business code; it only utilizes the target rights graph jointly generated by the data ontology and skill directories to process vehicle-side rights, significantly reducing reliance on code modification and redeployment, and improving the flexibility of rights expansion and the stability of business operation. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0020] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0021] Figure 1 A schematic diagram illustrating the implementation process of a method for processing vehicle-side rights provided in this application embodiment; Figure 2 A schematic diagram illustrating the implementation process of a method for constructing a target rights map, provided in an embodiment of this application; Figure 3 A schematic diagram illustrating the implementation process of another method for processing vehicle-side rights provided in this application embodiment; Figure 4 A schematic diagram illustrating the implementation process of another method for processing vehicle-side rights provided in this application embodiment; Figure 5 A schematic diagram illustrating the implementation process of another method for processing vehicle-side rights provided in this application embodiment; Figure 6 A schematic diagram of the structure of a target rights map provided in an embodiment of this application; Figure 7 A schematic diagram of a device for processing vehicle-side rights provided in an embodiment of this application; Figure 8 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0024] The method for processing vehicle-side rights provided in this application will be further explained below with reference to the accompanying drawings and specific embodiments. These embodiments do not constitute a limitation on the embodiments of this invention.

[0025] To address the technical challenge that while existing technologies can perform basic rights authentication and activation, each new, modified, or activated right requires modification of the corresponding business code and redeployment, making it difficult to balance the flexibility of rights expansion with the stability of business operation, this application provides a method for processing vehicle-side rights. This method involves obtaining a data ontology file and at least one skill directory; constructing a target rights graph based on the data ontology file and at least one skill directory; and, upon receiving a target rights operation request, processing the target vehicle-side rights corresponding to the target rights operation request according to the target rights graph.

[0026] This technical solution constructs a target rights graph by introducing a data ontology file and at least one skill catalog. Upon receiving a target rights operation request, it can perform inference based on this target rights graph. It eliminates the need to embed rights verification logic into the business code; it only utilizes the target rights graph generated jointly by the data ontology and skill catalog to process vehicle-side rights. This significantly reduces reliance on code modifications and redeployment, improving the flexibility of rights expansion and the stability of business operations. Simultaneously, since the target rights graph is constructed from the data ontology file and skill catalog, changes to the skill catalog can be instantly applied by rebuilding the target rights graph, avoiding service interruptions caused by business code modifications or configuration polling updates. Furthermore, inference through the target rights graph allows for chain-like reasoning along relational edges, enabling zero-code expansion and online hot loading of vehicle-side rights. This ensures the stability of rights services while improving the flexibility of rights expansion and the accuracy of rights verification.

[0027] like Figure 1 The diagram shown illustrates the implementation flow of a method for processing vehicle-side rights according to an embodiment of this application, which may specifically include the following steps: S101, Obtain the data ontology file and at least one skill directory.

[0028] The aforementioned data ontology file refers to a declarative file that uniformly defines the object types (i.e., rights packages, rights items, vehicle functions, and activation conditions), object relationships (i.e., rights packages contain rights items, rights items are mapped to vehicle functions, and the corresponding activation conditions for rights items) and constraint rules (i.e., one-to-many inclusion relationships between rights packages and rights items; one-to-one mapping relationships between rights items and vehicle functions; one-to-one triggering relationships between rights items and activation conditions; all objects must have unique identifiers; changes in the state of a rights package must synchronously update the state of all associated rights items under it) in the vehicle-side rights domain, and can be stored in YAML format.

[0029] Furthermore, the data ontology file contains at least a concept layer, a relation layer, and an axiomatic layer. The concept layer defines allowed concept types and classification levels, including concepts such as rights, rights items, and packages, and their classifications (e.g., vehicle warranty, basic services, car maintenance care, travel care, travel protection, single services, etc.). Each concept definition includes at least a concept identifier, concept name, parent concept identifier, concept description, and a set of allowed attributes. The parent concept identifier is used to construct the inheritance hierarchy between concepts, allowing child concepts to automatically inherit the common attributes of parent concepts. Rights refer to the collective term for service qualifications and benefits that users can obtain, hold, or use. In scenarios where there is no need to distinguish between type definitions and holding records, rights items and packages are collectively referred to as rights. A rights item refers to the smallest service unit that can be independently identified, configured, verified, and cancelled. For example, a roadside assistance service, a basic maintenance service, or a certain period of vehicle-to-everything (V2X) data service. A package refers to a combination unit set up for purchase or distribution scenarios, which itself has a package identifier, name, pricing, validity period, and scope of application, and is associated with one or more rights items through inclusion relationships. After a user purchases or receives a package, a corresponding benefits holding record can be generated based on the inclusion relationship between the package and the benefits. It should be noted that fields such as package identifier, name, pricing, validity period, and scope of application are fields in the allowed attribute set of the package concept type. That is, the package type node can attach these attribute fields to describe the specific business information of the package.

[0030] The allowed attribute set refers to the list of allowed attribute fields defined for each concept type in the concept layer. It specifies which attribute fields can be attached to nodes belonging to that concept type. For example, the allowed attribute set for the concept type "Benefit Item" may include fields such as Benefit Item Identifier, Benefit Item Name, Benefit Item Category, Associated Function Code, Validity Period, and Remaining Quota, used to describe the specific business information of the benefit item. Similarly, the allowed attribute set for the concept type "Package" may include fields such as Package Identifier, Package Name, Pricing, Validity Period, and Scope of Application, used to describe the specific business information of the package.

[0031] The relationship layer defines the types of directed relationships that can be established between different concepts, including inclusion relationships (indicating which benefits constitute the package), inheritance relationships (indicating that lower-level categories or benefits inherit common attributes from higher-level concepts), dependency relationships (indicating that obtaining, purchasing, or using a benefit requires satisfying another benefit), mutual exclusion relationships (indicating that two benefits cannot be held or used simultaneously), substitution relationships (indicating that one benefit can override another), enabling relationships (indicating that a benefit can enable a target function), upgrade relationships (indicating that the current benefit can be converted to a higher-level benefit), and renewal relationships (indicating that the current benefit can be transferred to the target benefit before or after its expiration). Each relationship definition includes at least a relationship identifier, source concept type, target concept type, direction, whether multiple values ​​are allowed, and relationship constraints.

[0032] The axiomatic layer defines rules for validating, deriving, and transitioning states of concepts and relation types. These rules include pricing rules, purchase validation rules, usage validation rules, preconditions, lifecycle rules, and sequence constraints. Preconditions are conditions that must be met before a purchase, activation, use, upgrade, or renewal operation can be performed. They are used to verify whether the target user meets the prerequisites for performing a specific operation during the reasoning process. When a condition requires holding another benefit item, it is represented by the source benefit item identifier and target benefit item identifier in the dependency relationship. For example, to purchase advanced maintenance, one must first hold basic maintenance, expressed through dependency edges. When conditions are based on attributes such as vehicle model, user level, vehicle status, region, or remaining quota, they are represented by the condition identifier, applicable operation, condition object, attribute name, comparison operator, target value, and condition combination method in the precondition data. For example, the vehicle model is a sedan, the user level is membership, and the remaining quota is greater than 0, expressed through the precondition data structure. Lifecycle refers to the states and state transition rules that a benefit undergoes from creation to termination. It is used to determine the current state of a benefit item during reasoning and execution, and to determine whether a specific state transition operation is allowed. It is represented by the initial state, allowed state set, activation conditions, activation time, expiration time, validity period, suspension conditions, resumption conditions, termination conditions, and a state transition table in the lifecycle data. The allowed state set can include pending activation, valid, suspended, exhausted, expired, and terminated. Sequence constraints refer to the order and time intervals that must be satisfied between multiple operations or state transitions. They are used to verify the temporal legality of operations or state transitions during reasoning and execution. They are represented by the preceding event, succeeding event, minimum interval, maximum interval, allowed execution period, repetition cycle, and timeout time in the sequence constraint data. For example, activation is required for cancellation, a preset period before expiration is required for renewal, and the original benefit item terminates after an upgrade. Pricing rules are the rules used to calculate the price of a benefit item or package, including pricing methods, discount strategies, and billing cycles. Purchase verification rules are used to verify whether a purchase operation meets preset conditions, including precondition verification, mutual exclusion verification, and substitution verification. Usage verification rules are used to verify whether a usage operation meets preset conditions, including quota verification, validity period verification, and status verification.

[0033] The aforementioned skill catalog can be understood as a collection of service delivery units stored in a catalog format. Each skill catalog corresponds to one skill (used to carry the specific service logic and delivery process of the benefit item). A skill catalog at least includes a service manual file (a file used to describe the business logic, applicable scenarios, and constraints of the benefit service corresponding to the skill in natural language), a configuration file (a file used to declare the benefit item information and service delivery execution steps corresponding to the skill), and a metadata file (a file used to record management information such as the skill's version number and update time). The configuration file contains an ontology registration section and a workflow definition. The ontology registration section is used to declare the benefit item information corresponding to the skill (at least including the benefit item identifier, benefit item category, and associated function code). The benefit item identifier refers to the unique identity of the benefit item, used to uniquely identify a specific benefit item. For example, `roadside_assistance` represents the roadside assistance benefit item. The benefit item category refers to the concept category to which the benefit item belongs, used to indicate the target concept node to which the benefit item node belongs within the concept nodes. For example, travel protection, car maintenance care, basic services, etc. The associated function code refers to the list of function codes that the benefit item can enable, used to match with the target function code during authorization. For example, the associated function codes for roadside assistance benefits may include TOWING, JUMP_START, TIRE_CHANGE, etc. Workflow definitions are used to declare the complete sequence of service delivery execution steps for this skill, from verification to cancellation.

[0034] In addition, the skill catalog may also include a package definition file (a file used to declare the skill as a package class and define the package attributes). The package definition file shall at least include package attributes (referring to the attribute information of the package itself declared in the package definition file, such as package identifier, pricing, validity period, applicable vehicle models, etc.) and a sub-service identifier list (i.e., a list of rights item identifiers corresponding to all sub-services included in the package listed in the package definition file).

[0035] In this embodiment, a data ontology file and at least one skill catalog are obtained. This step provides a data foundation for the subsequent construction of the target rights graph. The data ontology file provides a static knowledge skeleton of the rights domain, and the skill catalog provides pluggable dynamic service units; both serve as the source for constructing the target rights graph.

[0036] As an optional implementation, a predefined data ontology file and deployed skill directories can be read through a preset storage path. The data ontology file is pre-configured and stored in a specified location during system initialization; each skill directory can be created by operators according to a preset directory structure and file format and stored in a specified scanning directory, which is periodically scanned to obtain all skill directories.

[0037] S102, construct a target rights graph based on the data ontology file and at least one skill directory.

[0038] The aforementioned target rights graph refers to a directed knowledge graph composed of a set of nodes, a set of relation edges, and a set of axiom rules, used to represent the knowledge system and semantic relationships between rights items in the vehicle-side rights domain. The node set includes concept nodes (defined by the concept layer of the data ontology file), rights item nodes, or package nodes (generated from skill catalog registration); the relation edge set includes directed relation edges generated from various types of relation edge templates defined by the relation layer; and the axiom rule set includes various rules defined by the axiom layer, attached to the corresponding nodes or edges.

[0039] In this embodiment, a target rights graph can be constructed based on a data ontology file and at least one skill catalog. This step is used to integrate the static knowledge representation (data ontology) of the rights domain with pluggable service units (skill catalog) to form a complete knowledge graph structure that can be queried and reasoned by the inference engine.

[0040] As for the specifics of how the target interest graph is constructed based on the data ontology file and at least one skill catalog, this will be explained below. Figure 2 The process shown will be explained in detail here.

[0041] S103: Upon receiving a target benefit operation request, process the target vehicle-side benefit corresponding to the target benefit operation request according to the target benefit map.

[0042] The aforementioned target benefit operation request refers to a request initiated by the vehicle-side that requires verification or operation of a target vehicle-side benefit. This target benefit operation request can be either an authorization request or a purchase pre-check request. An authorization request is an operation request initiated by the vehicle-side when a user requests to use a certain vehicle-side benefit (or function), used to verify whether the user holds the corresponding benefit. This request carries the target function code (i.e., the function code corresponding to the vehicle-side function the user requests to use, such as TOWING, DEEP_INSPECTION, etc., used to match the associated function code of the corresponding benefit in the target benefit graph). A purchase pre-check request is an operation request initiated by the vehicle-side before a user purchases a benefit, used to verify whether the user meets the purchase conditions (such as whether they already hold a prerequisite dependent benefit, whether there is a mutually exclusive benefit, whether it has been replaced, etc.). This request carries the target benefit identifier.

[0043] In this embodiment of the application, upon receiving a target benefit operation request, determining whether to allow the user to use the target function or purchase the target benefit item requires processing the target vehicle-side benefit corresponding to the target benefit operation request based on the target benefit map.

[0044] Regarding the case where the target benefit operation request is an authorization request, the specific process for handling the target vehicle-side benefits corresponding to the target benefit operation request based on the target benefit graph will be explained below. Figure 3 The process shown will be explained in detail here.

[0045] Regarding the case where the target benefit operation request is a purchase pre-inspection request, the specific process for handling the target vehicle-side benefits corresponding to the target benefit operation request based on the target benefit map will be explained below. Figure 4 The process shown will be explained in detail here.

[0046] Based on the above description of the technical solution provided in the embodiments of this application, a target rights graph is constructed by obtaining a data ontology file and at least one skill directory; upon receiving a target rights operation request, the target vehicle-side rights corresponding to the target rights operation request are processed according to the target rights graph. This technical solution constructs a target rights graph by introducing a data ontology file and at least one skill catalog. Upon receiving a target rights operation request, it can perform inference based on this target rights graph. It eliminates the need to embed rights verification logic into the business code; it only utilizes the target rights graph jointly generated by the data ontology and skill catalog to process vehicle-side rights, significantly reducing reliance on code modifications and redeployment. Simultaneously, since the target rights graph is constructed from the data ontology file and skill catalog, changes to the skill catalog can be instantly applied by rebuilding the target rights graph, avoiding service interruptions caused by business code modifications or configuration polling updates. Furthermore, inference through the target rights graph allows for chain-like reasoning along relational edges, enabling zero-code expansion and online hot loading of vehicle-side rights. This ensures the stability of rights services while improving the flexibility of rights expansion and the accuracy of rights verification.

[0047] like Figure 2 The diagram shown is a schematic representation of the implementation process of a method for constructing a target rights map according to an embodiment of this application. Figure 2 exist Figure 1 Based on this, a detailed description is provided on how to construct a target rights graph using a data ontology file and at least one skills catalog, which may include the following: S201, parse the data ontology file to determine the map hierarchy information.

[0048] The aforementioned graph hierarchy information refers to the hierarchical data structure obtained after parsing the data ontology file, used to construct the target equity graph. This includes concept layer information, relation layer information, and axiomatic layer information. Specifically, concept layer information is used to create concept nodes in the target equity graph, relation layer information is used to create relation edge templates in the target equity graph, and axiomatic layer information is used to create axiomatic rules in the target equity graph.

[0049] In this embodiment of the application, the data ontology file can be parsed to determine the map hierarchy information.

[0050] S202, for any skill catalog, determine the corresponding rights and interests information for that skill catalog.

[0051] The aforementioned rights and benefits information refers to the relevant information of the rights and benefits items corresponding to the skill catalog, which is used to create corresponding rights and benefits item nodes or package nodes in the target rights and benefits graph. It includes at least the rights and benefits item identifier, rights and benefits item classification and associated function code, and may also include package attributes and a list of sub-service identifiers.

[0052] In this embodiment of the application, for any skill catalog, the corresponding rights item information is determined. This step is used to extract rights item information from each skill catalog so that the instance nodes of each rights item can be injected into the target rights graph to complete the instance data of the target rights graph.

[0053] It should be noted that each skill catalog contains at least three files: a service manual file (e.g., SKILL.md), which describes the business logic, applicable scenarios, and constraints of the corresponding rights and benefits services in natural language, so that the agent can understand the meaning of the service; a configuration file (e.g., config.yaml), which contains an ontology registration section and a workflow definition. The ontology registration section declares the rights and benefits information corresponding to the skill, and the workflow definition declares the service delivery execution steps of the skill; and a metadata file (e.g., _meta.json), which records management information such as the version number and update time of the skill.

[0054] As an optional embodiment, determining the rights and interests information corresponding to the skills catalog may specifically include the following steps: Step 11: Parse the skill catalog to determine the configuration files and file information.

[0055] The aforementioned configuration file refers to the file contained in the skill catalog that declares the rights and interests information and service delivery execution steps corresponding to the skill, and at least includes an ontology registration section and a workflow definition.

[0056] The aforementioned file information refers to the summary information of various files contained in the skill catalog after parsing, which is used to determine whether the skill catalog contains package-type files.

[0057] In this embodiment of the application, the skill catalog can be parsed to determine the configuration file and file information.

[0058] For example, the skill directory is parsed to obtain a list of files in that directory, from which configuration files (such as config.yaml) are identified, and it is determined whether the directory contains package-type files (such as product.yaml), which are then included as part of the file information.

[0059] Step 12: Extract the ontology registration section from the configuration file. The ontology registration section should contain at least the rights item identifier, rights item category, and associated function code.

[0060] The aforementioned ontology registration section is used to declare the rights and interests information corresponding to the skill. After being parsed by the skill loading engine, it is used to create the corresponding rights and interests node in the data ontology graph.

[0061] The aforementioned rights item identifier refers to a unique identifier for a rights item, used to uniquely identify a specific rights item. For example, roadside_assistance represents the roadside assistance rights item.

[0062] The above-mentioned rights and interests classification refers to the conceptual classification to which a rights and interests item belongs, used to indicate the target conceptual node to which the rights and interests item node belongs within the conceptual nodes. For example, "travel guarantee" indicates that the rights and interests item belongs to the "travel guarantee" category.

[0063] The aforementioned associated function codes refer to the list of function codes that can be enabled by this benefit item, used for matching with the target function code during authorization. For example, the associated function codes for the roadside assistance benefit item may include TOWING, JUMP_START, and TIRE_CHANGE.

[0064] In this embodiment, an ontology registration section can be extracted from the configuration file. The ontology registration section includes at least the rights item identifier, rights item classification, and associated function code.

[0065] For example, the ontology registration section is extracted from the configuration file as the rights item identifier: roadside_assistance, rights item category: travel protection, associated function code: [TOWING, JUMP_START, TIRE_CHANGE], where roadside_assistance is the rights item identifier, travel protection is the rights item category, and [TOWING, JUMP_START, TIRE_CHANGE] is the associated function code.

[0066] Step 13: If the file information includes package-type files, obtain the package attributes and sub-service identifier list from the package-type files, and identify the ontology registration section, package attributes, and sub-service identifier list as the rights and interests information corresponding to the skill catalog.

[0067] The aforementioned package-type files refer to optional files included in the skill catalog used to declare the skill as a package and define package attributes, such as product.yaml. Package-type files must at least contain package attributes (such as pricing, validity period, applicable vehicle models, etc.) and a list of sub-service identifiers.

[0068] The aforementioned package attributes refer to the attribute information of the package itself declared in the package category file, including but not limited to package identifier, name, pricing, validity period, and scope of application.

[0069] The aforementioned sub-service identifier list refers to the list of rights item identifiers corresponding to all sub-services included in the package as listed in the package category file. It is used to attach each sub-service rights item node to the package node along the inclusion relationship edge when constructing the graph.

[0070] In this embodiment of the application, when the file information includes package-type files, it indicates that the skill corresponding to the skill catalog is a package-type skill, meaning that the skill is not only an independent benefit item but also contains multiple sub-services. In this case, it is necessary to obtain the package attributes and sub-service identifier list from the package-type files, and determine the ontology registration section, package attributes, and sub-service identifier list as the benefit item information corresponding to the skill catalog.

[0071] Step 14: If the file information does not contain package-type files, identify the ontology registration section as the rights and benefits information corresponding to the skill catalog.

[0072] In this embodiment of the application, if the file information does not contain package-type files, it indicates that the skill corresponding to the skill catalog is a single service skill, meaning that the skill corresponds to only one independent benefit item and does not contain sub-services. In this case, it is only necessary to determine the ontology registration section as the benefit item information corresponding to the skill catalog.

[0073] S203, construct the target rights graph based on the rights item information and graph hierarchy information corresponding to each skill catalog.

[0074] In this embodiment of the application, a target rights graph can be constructed based on the rights item information and graph hierarchy information corresponding to each skill catalog.

[0075] As an optional implementation, a target rights graph is constructed based on the hierarchical information of the rights items corresponding to each skill catalog. This may specifically include the following steps: Step 21: Determine at least one concept node, relation edge template, and axiom rule based on the graph hierarchy information.

[0076] The aforementioned concept nodes refer to nodes created in the target rights graph based on the concept layer information in the graph hierarchy, used to represent concept types such as rights classification. For example, concept nodes may include rights classification nodes such as vehicle warranty, basic services, car maintenance care, travel care, travel protection, and individual services.

[0077] The aforementioned relation edge templates refer to the directed relation type definitions created in the target equity graph based on the relation layer information in the graph hierarchy information, used to generate specific relation edges between instance nodes. Relationship edge templates include at least the following: containing relation edge templates, inheritance relation edge templates, dependency relation edge templates, mutual exclusion relation edge templates, replacement relation edge templates, enabling relation edge templates, upgrading relation edge templates, and renewal relation edge templates.

[0078] The aforementioned axiomatic rules refer to rule objects created in the target equity graph based on the axiomatic layer information in the graph hierarchy, attached to the corresponding concept nodes or equity item nodes, and invoked during the reasoning process. Axiomatic rules include pricing rules, purchase verification rules, usage verification rules, preconditions, lifecycle rules, and timing constraints, etc.

[0079] In the embodiments of this application, at least one concept node, relation edge template, and axiom rule can be determined based on the graph hierarchy information.

[0080] Step 22: For any skill catalog, obtain the rights item category, rights item identifier, and associated function code from the rights item information corresponding to the skill catalog.

[0081] In this embodiment of the application, for any skill catalog, the rights item classification, rights item identifier and associated function code can be obtained from the rights item information corresponding to the skill catalog.

[0082] For example, the rights and benefits information corresponding to skill catalog A is used to obtain the rights and benefits category as travel protection, the rights and benefits identifier is roadside_assistance, and the associated function code is [TOWING, JUMP_START, TIRE_CHANGE].

[0083] Step 23: Based on the classification of rights items, determine the target concept node from at least one concept node.

[0084] The aforementioned target concept node refers to the concept node that matches the category of rights and interests, and is used as the parent node of the rights and interests node or package node in the concept hierarchy.

[0085] In this application embodiment, a target concept node can be determined from at least one concept node according to the classification of rights items.

[0086] For example, if the rights and interests are categorized as travel protection, then a concept node named "travel protection" can be found in the concept nodes as the target concept node.

[0087] Step 24: If the rights and benefits information corresponding to the skills catalog contains a list of sub-service identifiers, then determine at least one rights and benefits node corresponding to a sub-service based on the list of sub-service identifiers, and create a package node based on the rights and benefits identifier and the associated function code.

[0088] The aforementioned sub-services refer to individual service units included in the package, with each sub-service corresponding to a benefit item. For example, the Premium Travel Package includes sub-services such as roadside assistance, basic maintenance, and connected car data.

[0089] The benefit item nodes corresponding to the aforementioned sub-services refer to the benefit item nodes created in the target benefit graph, determined based on the sub-service identifiers in the sub-service identifier list. Sub-service benefit item nodes are attached to the package node along the inclusion relationship edge to indicate that the package consists of these sub-services.

[0090] The aforementioned package nodes refer to nodes created in the target benefits graph based on the benefits information in the package-type skills catalog. They represent a combined benefits unit containing multiple sub-services. Package nodes have package attributes such as package identifier, name, pricing, validity period, and scope of application, and are associated with one or more sub-service benefit nodes through inclusion relationships.

[0091] In this embodiment of the application, if the rights and benefits information corresponding to the skills catalog includes a list of sub-service identifiers, then at least one rights and benefits node corresponding to a sub-service can be determined based on the list of sub-service identifiers, and a package node can be created based on the rights and benefits identifier and the associated function code.

[0092] As an optional embodiment, determining at least one rights item node corresponding to a sub-service based on the sub-service identifier list may specifically include the following steps: Step 241: For any sub-service identifier in the sub-service identifier list, determine the target skill directory and sub-service corresponding to the sub-service identifier.

[0093] In this embodiment of the application, for any sub-service identifier in the sub-service identifier list, the target skill directory and sub-service corresponding to the sub-service identifier are determined.

[0094] For example, if the sub-service identifier list is [roadside_assistance, basic_maintenance, telematics_traffic], then the target skill directory corresponding to roadside_assistance is determined to be the roadside assistance skill directory, the target skill directory corresponding to basic_maintenance is the basic maintenance skill directory, and the target skill directory corresponding to telematics_traffic is the vehicle-to-everything (V2X) traffic skill directory.

[0095] Step 242: parse the target skill catalog and create the corresponding rights item nodes for the sub-services.

[0096] In this embodiment of the application, the target skill catalog is parsed to create rights item nodes corresponding to sub-services.

[0097] For example, the roadside assistance skills catalog is parsed, and based on the ontology registration section in its configuration file, an equity item node corresponding to the sub-service with the equity item identifier "roadside_assistance" is created.

[0098] In addition, when creating a benefit item node corresponding to a sub-service, if the benefit item node already exists (for example, if the sub-service has been referenced by other packages or has been registered as a single benefit item), there is no need to create it again, and the existing benefit item node can be reused directly.

[0099] Step 25: Along the containment relationship edge in the relationship edge template, attach the rights item nodes corresponding to each sub-service to the package node, and along the inheritance relationship edge in the relationship edge template, attach the package node to the target concept node.

[0100] The aforementioned "relationship edge" refers to the directed relationship edge in the relationship edge template used to represent the compositional relationship between the package and the benefit items. The direction is from the package to the benefit item, indicating which benefit items make up the package.

[0101] The aforementioned mounting refers to the operation of connecting a rights item node or package node to a concept node or other nodes to establish a hierarchical or inclusion relationship, used to establish hierarchical or inclusion relationships between nodes. For example, a rights item node is mounted to the corresponding concept node along the inheritance relationship edge, and a rights item node corresponding to a sub-service is mounted to the package node along the inclusion relationship edge.

[0102] The aforementioned inheritance relationship edge refers to the directed relationship edge in the relationship edge template used to represent the common attribute inheritance relationship between the subclass concept and the parent class concept. The direction is from the subclass to the parent class, and it is used to support the inheritance deduction in the authentication process.

[0103] In this embodiment of the application, the rights and interests nodes corresponding to each sub-service can be attached to the package node along the inclusion relationship edge in the relationship edge template, and the package node can be attached to the target concept node along the inheritance relationship edge in the relationship edge template.

[0104] Step 26: Obtain the rules corresponding to the package node and the rules corresponding to the rights item nodes of each sub-service from the axiom rules.

[0105] In this embodiment of the application, the rules corresponding to the package node and the rules corresponding to the rights item nodes of each sub-service are obtained from the axiomatic rules.

[0106] Specifically, rules applicable to the package node can be selected from the axiomatic rules based on the node type and node attributes of the package node; rules applicable to the rights item nodes corresponding to each sub-service can be selected from the axiomatic rules based on the node type and node attributes of the rights item nodes corresponding to each sub-service.

[0107] For example, if the node type of a package node is "package", then the pricing rules and purchase verification rules applicable to the package are obtained from the axiomatic rules; if the node type of the rights item node corresponding to the sub-service is "rights item", then the precondition rules and usage verification rules applicable to the rights item are obtained from the axiomatic rules.

[0108] Step 27: Connect the rules corresponding to the package node to the package node, and connect the rules corresponding to the rights item nodes of each sub-service to the rights item nodes of each sub-service to obtain the target rights graph.

[0109] The above-mentioned attachment refers to the operation of associating axiom rules with corresponding nodes, which is used to establish the relationship between rules and nodes.

[0110] In this embodiment, the rules corresponding to the package node can be attached to the package node, and the rules corresponding to the rights item nodes of each sub-service can be attached to the rights item nodes of each sub-service to obtain the target rights graph.

[0111] Correspondingly, steps 24 to 27 above describe how to construct the target rights graph when the rights information corresponding to the skill catalog includes a list of sub-service identifiers. However, if the rights information corresponding to the skill catalog does not include a list of sub-service identifiers, then steps 28 to 210 need to be performed: Step 28: Create a rights item node based on the rights item identifier and associated function code.

[0112] In this embodiment of the application, a rights item node can be created based on the rights item identifier and the associated function code.

[0113] For example, if the rights item information corresponding to the skill catalog has the rights item identifier as basic_maintenance and the associated function code as [OIL_CHANGE, FILTER_REPLACE], then a rights item node with the rights item identifier as basic_maintenance and the associated function code as [OIL_CHANGE, FILTER_REPLACE] will be created.

[0114] Step 29: Attach the equity item node to the target concept node along the inheritance relationship edge in the relationship edge template.

[0115] In this embodiment of the application, after creating the rights item node, it is necessary to attach the rights item node to the target concept node along the inheritance relationship edge in the relationship edge template in order to represent the rights category to which the rights item belongs.

[0116] For example, if the equity item node basic_maintenance is classified as car maintenance care, then the basic_maintenance node will be attached to the car maintenance care concept node along the inheritance relationship edge.

[0117] Step 210: Obtain the rule corresponding to the equity item node from the axiom rules, attach the rule to the equity item node, and obtain the target equity graph.

[0118] In this embodiment of the application, the rules corresponding to the equity item nodes can be obtained from the axiomatic rules, and the rules can be attached to the equity item nodes to obtain the target equity graph.

[0119] Specifically, rules applicable to a stake item node can be selected from the axiomatic rules based on the node type and node attributes of the stake item node. For example, if the node type of a stake item node is a stake item, then rules applicable to stake items, such as precondition rules, usage verification rules, and lifecycle rules, can be obtained from the axiomatic rules.

[0120] For example, if the basic_maintenance node has a precondition rule (vehicle mileage not exceeding 5000 kilometers) and a lifecycle rule (validity period of 12 months), then these rules will be attached to the basic_maintenance node.

[0121] like Figure 3 The diagram shown is a schematic representation of the implementation flow of another method for processing vehicle-side rights provided in this application. Figure 3 exist Figure 1 Based on this, the paper details how to process the target vehicle-side rights corresponding to the target rights operation request according to the target rights graph when the target rights operation request is an authorization request. Specifically, this may include the following: S301, if the target rights operation request is an authorization request, obtain the target function code carried in the target rights operation request.

[0122] In this embodiment, when the target benefit operation request is an authentication request, it indicates that the current request is to use a certain vehicle-side benefit, and it is necessary to verify whether the user holds the corresponding benefit. In this case, the target function code carried in the target benefit operation request is obtained. This target function code is the function code corresponding to the vehicle-side benefit requested by the user; for example, "TOWING" represents the towing function, and "DEEP_INSPECTION" represents the depth sensing function.

[0123] S302, based on the target function code, reason in the target rights graph to obtain the first reasoning result.

[0124] The aforementioned reasoning refers to querying and verifying the target user's eligibility for the vehicle-side benefits corresponding to the target function code within the target benefit graph according to a pre-defined reasoning path. This can be understood as progressive reasoning, where multiple reasoning steps are executed sequentially from simple to complex. If a previous step succeeds, an allowed result is returned, and subsequent steps are not executed.

[0125] In this embodiment of the application, a first reasoning result can be obtained by reasoning in the target rights graph based on the target function code.

[0126] Specifically, the process can first query the target equity graph to see if the associated function code of the equity item node held by the target user contains the target function code. If the query is successful, a first inference result indicating that the use is permitted is obtained. If the query is unsuccessful, the process can then query along the inheritance relationship edge to see if the associated function code of the parent node of the equity item node held by the target user contains the target function code. If the query along the inheritance relationship edge is successful, a first inference result indicating that the use is permitted is obtained. If the query along the inheritance relationship edge is unsuccessful, the process can then verify along the enabling relationship edge and the dependency relationship edge whether there is a prerequisite equity item that satisfies the target function code. If such an item exists, a first inference result indicating that the use is permitted is obtained. If such an item does not exist, a first inference result indicating that the use is denied is obtained.

[0127] S303, if the first inference result indicates that it is permissible to use, the target vehicle-side rights corresponding to the target rights operation request are permitted to be used.

[0128] In this embodiment of the application, if the first reasoning result indicates that the user is allowed to use the function, it means that the user holds the rights item corresponding to the target function code or the user is qualified to use the function. In this case, the target vehicle-side rights corresponding to the target rights operation request are allowed to be used.

[0129] S304, if the first reasoning result indicates that the target vehicle-side rights corresponding to the target rights operation request are refused to be used.

[0130] In this embodiment of the application, if the first reasoning result indicates a refusal to use, it means that the user does not possess the rights corresponding to the target function code or it cannot be confirmed that the user is qualified to use the function. In this case, the target vehicle-side rights corresponding to the target rights operation request are refused. That is, the user is refused to use the vehicle-side function he / she requested, and a refusal result and the identifier of the missing rights item can be returned to the vehicle.

[0131] like Figure 4 The diagram shown is a schematic representation of the implementation flow of another method for processing vehicle-side rights provided in this application. Figure 4 exist Figure 1 Based on this, the paper details how to process the target vehicle-side rights corresponding to the target rights operation request according to the target rights graph when the target rights operation request is a purchase pre-inspection request. Specifically, this may include the following: S401, if the target equity operation request is a purchase pre-inspection request, obtain the target equity item identifier carried in the target equity operation request.

[0132] In this embodiment of the application, when the target benefit operation request is a purchase pre-check request, it means that the user is currently requesting to purchase a certain benefit item. Before the user places an order, it is necessary to verify whether the user meets the purchase conditions, such as whether they already hold the prerequisite dependent benefit item, whether there is a mutually exclusive benefit item, or whether it has been replaced. At this time, the target benefit item identifier carried in the target benefit operation request is obtained.

[0133] S402, based on the target equity item identifier, reason in the target equity graph to obtain the second reasoning result.

[0134] In this embodiment of the application, a second reasoning result is obtained by reasoning in the target rights graph based on the target rights item identifier.

[0135] Specifically, the system can check whether the target user already possesses all the prerequisite dependent benefits required for the benefit corresponding to the target benefit identifier along the dependency relationship edge; if the dependency check passes, it can check whether there are any mutually exclusive benefit items among the benefit items already possessed by the target user that are mutually exclusive with the benefit corresponding to the target benefit identifier along the mutual exclusion relationship edge; if the conflict check passes, it can check whether the benefit corresponding to the target benefit identifier has been replaced by other benefit items possessed by the target user along the substitution relationship edge; if the dependency check, conflict check, and substitution check all pass, a second inference result representing permission to purchase is obtained; otherwise, a second inference result representing refusal to purchase is obtained.

[0136] S403, if the second inference result indicates that purchase is permitted, the target vehicle-side rights corresponding to the target rights operation request are permitted to be purchased.

[0137] In this embodiment of the application, if the second inference result indicates that the purchase is permitted, it means that all the conditions for the right item corresponding to the target right item identifier are met (pre-dependency verification passed, no mutual exclusion conflict, and not overridden by replacement). At this time, the target vehicle-side right corresponding to the purchase right operation request is permitted.

[0138] S404, if the second reasoning result indicates a refusal to purchase, refuse to purchase the target vehicle-side rights corresponding to the target rights operation request.

[0139] In this embodiment of the application, when the second inference result indicates a refusal to purchase, it indicates that the conditions for purchasing the right item corresponding to the target right item identifier are not met (there is a missing prerequisite right item, there is a mutually exclusive right item, or it has been replaced or covered). In this case, the target vehicle-side right corresponding to the target right operation request is refused. That is, the user's order to purchase the requested right item is refused, and the refusal result and the missing prerequisite right item identifier or conflict reason can be returned to the vehicle.

[0140] Furthermore, in this application embodiment, the method for processing vehicle-side rights provided in this application embodiment is explained with reference to specific examples: like Figure 5 The diagram shown illustrates the implementation flow of another method for processing vehicle-side rights provided in this application, which may specifically include the following: Step 1: Construct the initial skeleton map of the data ontology.

[0141] In this embodiment, the initial construction phase will build an initial skeleton graph data ontology file based on the data ontology, including a concept layer, a relation layer, and an axiomatic layer. The concept layer contains the definition of concept types and classification levels, such as core concepts and their classifications, like rights, rights items, and packages; the relation layer contains the definition of directed relation types between different concept instances, such as inclusion, inheritance, dependency, mutual exclusion, substitution, enabling, upgrade, and renewal relationships; the axiomatic layer contains the definition of rules for verifying, deriving, and state transitioning concept nodes and relation edges, such as pricing rules, purchase verification rules, usage verification rules, preconditions, lifecycle rules, and temporal constraints.

[0142] The ontology loading engine reads the data ontology file and constructs an initial directed knowledge graph through four stages: syntax parsing, semantic mapping, reference verification, and graph loading. At this point, the initial skeleton graph contains concept nodes (such as rights and interests classification nodes like vehicle warranty, basic services, car maintenance care, travel care, travel protection, and individual services), relationship edge templates (such as edge templates containing relationships and inheritance relationships), and axiom rules, but does not yet contain any specific rights and interests nodes or package nodes.

[0143] Step 2: Initial skeleton map (nodes without equity items).

[0144] In this embodiment, the initial skeleton graph only contains concept nodes, relation edge templates, and axiom rules defined in the data ontology file. At this stage, the graph does not yet contain any specific benefit item nodes or package nodes, resembling a skeleton without flesh and blood. For example, the graph already contains the concept node "travel guarantee" and the edge template "inheritance relationship," but the road rescue benefit item node has not yet been created. In the initial skeleton graph produced at this stage, the data ontology file contributes approximately 10% of the skeleton nodes (category nodes, concept levels, relation types, and axiom rules), awaiting subsequent skill registration to populate the remaining approximately 90% of the instance nodes.

[0145] Step 3: Automatic skill registration completes the data ontology and parses the ontology registration section.

[0146] In this embodiment, the skill loading engine scans the entire skill catalog, parses the configuration files in each skill catalog one by one, and extracts the ontology registration section from the configuration files. The ontology registration section contains at least a rights item identifier, rights item category, and associated function code, which are used to declare the rights item information corresponding to the skill.

[0147] After reading the configuration files of each skill catalog, the skill loading engine extracts the ontology registration section and parses information such as the rights item identifier, rights item category, and associated function code. For example, extracting the ontology registration section from the configuration file of the roadside assistance skill catalog yields a rights item identifier of "roadside_assistance", a rights item category of "travel protection", and associated function code of "[TOWING, JUMP_START, TIRE_CHANGE]".

[0148] Step 4: Determine if product.yaml exists.

[0149] In this embodiment of the application, when parsing the skill catalog, it is necessary to determine whether the skill catalog contains a package definition file (such as product.yaml) in order to determine whether the skill is a package-type skill or a single service-type skill.

[0150] Specifically, the skill loading engine checks whether the file information in the current skill directory contains package-type files. If it does, it means that the skill is a package-type skill, that is, the skill is not only an independent benefit item, but also contains multiple sub-services, and needs to be registered according to the package-type processing procedure; if it does not, it means that the skill is a single-service-type skill, that is, the skill corresponds to only an independent benefit item, does not contain sub-services, and only needs to be registered according to the single-service-type processing procedure.

[0151] Step 5: If product.yaml exists, create the package and sub-service nodes.

[0152] In this embodiment of the application, when it is determined that the skill catalog contains package-type files, a package node is created based on the ontology registration section, and the rights item node corresponding to each sub-service is determined based on the sub-service identifier list in the package-type file, and the corresponding rights item node corresponding to the sub-service is created.

[0153] Specifically, if the rights and benefits information corresponding to the skill catalog includes a list of sub-service identifiers, then at least one rights and benefits node corresponding to a sub-service is determined based on the list of sub-service identifiers, and a package node is created based on the rights and benefits identifier and associated function code. After creating the package node and the rights and benefits nodes corresponding to each sub-service, the rights and benefits nodes corresponding to each sub-service are attached to the package node along the inclusion relationship edge, the package node is attached to the target concept node along the inheritance relationship edge, and the corresponding rules are obtained from the axiom rules and attached to each node.

[0154] For example, if the Premium Travel Package skill catalog contains a package definition file, then create a "Premium Travel Package" package node, and create or reuse the benefit item nodes corresponding to the three sub-services "Roadside Assistance", "Basic Maintenance", and "Vehicle Internet Traffic" according to the sub-service identifier list "[roadside_assistance, basic_maintenance, telematics_traffic]". Attach the three sub-service nodes to the "Premium Travel Package" node along the inclusion relationship edge, and then attach the "Premium Travel Package" node to the corresponding concept node along the inheritance relationship edge.

[0155] Step 6: If product.yaml does not exist, create a single equity item node.

[0156] In this embodiment of the application, if it is determined that the skill catalog does not contain package-type files, a benefit item node is created based on the benefit item identifier and associated function code.

[0157] Specifically, if the rights item information corresponding to the skill catalog does not include a list of sub-service identifiers, it means that the skill catalog is a single service type skill catalog. In this case, rights item nodes are created based on rights item identifiers and associated function codes, and rights item nodes are attached to the target concept node along the inheritance relationship edge. The rules corresponding to the rights item nodes are obtained from the axiom rules and attached to the rights item nodes.

[0158] For example, if the advanced maintenance skills catalog does not contain a package definition file, then create an "advanced_maintenance" benefit item node with the associated function code "[DEEP_INSPECTION, AC_FILTER]". Attach this node to the "car care" concept node along the inheritance relationship edge, and obtain the rule "basic maintenance must be held first" from the prerequisite rules and attach it to this node.

[0159] Step 7: Generate the target equity map.

[0160] In this embodiment of the application, after the scanning and registration of all skill catalogs are completed, all rights item nodes and package nodes have been created and attached to the corresponding concept nodes, and the axiom rules have also been attached to the corresponding nodes, forming a complete target rights graph composed of a set of nodes, a set of relation edges, and a set of axiom rules.

[0161] As an optional implementation, a car manufacturer offers the following benefits package: Premium Travel Package (¥2,999 / year) includes three sub-services: roadside assistance, basic maintenance, and connected car data. Roadside assistance provides 3 free towing, jump-start, and tire change services per year. Basic maintenance provides 2 free oil and filter changes per year. Connected car data provides 10GB of in-car Wi-Fi data per month. Advanced maintenance requires prior basic maintenance and includes 2 full vehicle inspections and air conditioning filter replacements per year. Unlimited data upgrade package allows connected car data users to upgrade to unlimited data.

[0162] The following content is predefined in the data ontology: The conceptual layer defines three categories of rights: travel protection, which covers rights in travel scenarios such as roadside assistance and accident handling, and allows the inclusion of attributes such as function codes, quotas, and validity periods; vehicle care, which covers rights in vehicle maintenance scenarios such as maintenance and repair, and has the same attributes as above; and basic services, which cover rights in basic functional scenarios such as data traffic and communication, and has the same attributes as above.

[0163] The skill loading engine scans the entire skill directory, parses the configuration files in each skill directory one by one, and extracts the ontology registration section from the configuration files. Specifically: Skill category 1 is roadside assistance. Its registration information identifies the rights item as "roadside assistance", its category is "travel protection", and its associated function codes are "roadside assistance service (ROADSIDE_ASSIST)", "towing (TOWING)", "jump-start (JUMP_START)" and "tire change (TIRE_CHANGE)". Then, create a rights item node [roadside assistance] and attach it to the "travel protection" concept node.

[0164] Skill catalog 2 is basic maintenance. Its registration information identifies the rights item as "basic maintenance", its category is "car care", and its associated function codes are "oil change (OIL_CHANGE)" and "filter change (FILTER_REPLACE)". Then, create the rights item node [basic maintenance] and attach it to the "car care" concept node.

[0165] Skill category 3 is vehicle network traffic. Its registration information identifies the rights item as "vehicle network traffic", its category is "basic services", and its associated function codes are "in-vehicle Wi-Fi hotspot (WIFI_HOTSPOT)" and "10GB monthly data (DATA_10GB)". Then, create a rights item node [vehicle network traffic] and attach it to the "basic services" concept node.

[0166] Skill category 4 is the Premium Travel Package, which includes a package definition file. The package definition identifies it as the "Premium Travel Package," priced at ¥2,999 / year, and includes sub-services such as roadside assistance, basic maintenance, and connected car data. The skill loading engine determines that this skill is a package type, creates a package node [Premium Travel Package], parses the skill catalog corresponding to each sub-service one by one, and attaches the benefit item nodes corresponding to the three sub-services "Roadside Assistance," "Basic Maintenance," and "Connected Car Data" to this package node along the include relationship edge (includes).

[0167] Skill category 5 is Advanced Maintenance. Its registration information identifies the right item as "Advanced Maintenance", its category is "Car Care", and its associated function codes are "Deep Inspection (DEEP_INSPECTION)" and "Air Conditioning Filter Replacement (AC_FILTER)". It also declares the dependency as Basic Maintenance. Therefore, a right item node [Advanced Maintenance] is created, attached to the "Car Care" concept node, and its dependency edge (requires) is used to point it to [Basic Maintenance].

[0168] Skill category 6 is the Unlimited Data Upgrade Package. Its registration information identifies the benefit item as "Unlimited Data Upgrade Package," categorizes it as "Basic Services," and associates it with the function codes "In-Vehicle Wi-Fi Hotspot (WIFI_HOTSPOT)" and "Unlimited Data (DATA_UNLIMITED)," declaring that it can be upgraded from connected vehicle data. Therefore, a benefit item node [Unlimited Data Upgrade Package] is created, attached to the "Basic Services" concept node, and associated with [Connected Vehicle Data] along the upgrade relationship edge (upgrades_to). The resulting target benefit graph is as follows: Figure 6 As shown.

[0169] Figure 6 This is a schematic diagram of the structure of a target rights map provided in an embodiment of this application. Figure 6 The target equity map includes the following: Conceptual nodes (skeleton layer): These include rights and interests categories such as "travel protection", "car maintenance care" and "basic services". These conceptual nodes form the skeleton of the graph and are used to receive instance nodes generated by skill registration.

[0170] Package Node: Includes the "Premium Travel Package" package node, which includes the benefits corresponding to the three sub-services: "Roadside Assistance", "Basic Maintenance" and "Vehicle Connectivity Data". Along the inclusion relationship edge (includes), the benefit nodes corresponding to each sub-service are attached to this package node.

[0171] Benefit Item Nodes (Instance Layer): These contain multiple benefit item nodes, such as "Roadside Assistance," "Basic Maintenance," "Vehicle Connected Data," "Advanced Maintenance," and "Unlimited Data Upgrade Package." Each benefit item node is attached to its corresponding concept node. For example, "Roadside Assistance" is attached to the "Travel Guarantee" concept node, "Basic Maintenance" and "Advanced Maintenance" are attached to the "Car Care" concept node, and "Vehicle Connected Data" and "Unlimited Data Upgrade Package" are attached to the "Basic Services" concept node.

[0172] Relationship edges: Nodes are connected by directed relationship edges. For example, an inclusion relationship edge (includes) represents the composition relationship between a package and a benefit item, i.e., the "Premium Travel Package" includes three sub-services: "Roadside Assistance," "Basic Maintenance," and "Connected Car Data." An inheritance relationship edge (is_a) represents the affiliation relationship between a benefit item and a category, i.e., each benefit item node belongs to its corresponding category node. A dependency relationship edge (requires) represents the prerequisite dependency relationship between benefit items, i.e., "Advanced Maintenance" depends on "Basic Maintenance." An upgrade relationship edge (upgrades_to) represents the relationship that a benefit item can be upgraded to a higher level, i.e., "Connected Car Data" can be upgraded to "Unlimited Data Upgrade Package."

[0173] Function Codes: Each benefit item node carries associated function code attributes. For example, the "Roadside Assistance" benefit item node is associated with function codes such as "Roadside Assistance Service / Towing / Jump Start / Tire Change"; the "Basic Maintenance" benefit item node is associated with function codes such as "Oil Change / Filter Change"; the "Vehicle Connectivity Data" benefit item node is associated with function codes such as "In-Vehicle Wi-Fi / 10GB / Month"; the "Advanced Maintenance" benefit item node is associated with function codes such as "Deep Inspection / Air Conditioning Filter"; and the "Unlimited Data Upgrade Package" benefit item node is associated with function codes such as "In-Vehicle Wi-Fi / Unlimited Data".

[0174] Axioms and rules: Each node is associated with a corresponding axiom. For example, the "Advanced Maintenance" benefit node is associated with a dependency rule, indicating that it depends on the "Basic Maintenance" benefit node; the "Vehicle Internet Traffic" benefit node is associated with an upgrade rule, indicating that it can be upgraded to the "Unlimited Traffic Upgrade Package".

[0175] Through the above structure, the target rights graph fully depicts the conceptual classification system, rights item instances, package composition structure, semantic relationship chain, and axiom rules in the field of vehicle rights, providing a complete knowledge source and reasoning basis for subsequent authorization authentication and purchase pre-check.

[0176] Step 8: Receive user requests.

[0177] In this embodiment of the application, after the target rights graph is constructed and put into operation, the data ontology inference engine enters the running stage, and the vehicle can receive various rights operation requests initiated by users. User requests may include types such as permission authentication requests (users request to use a certain vehicle function) and purchase pre-check requests (users request to purchase a certain rights item).

[0178] After receiving a user request, the vehicle-side device transmits the request type and its parameters (target function code or target benefit identifier) ​​to the data ontology inference engine, triggering subsequent inference processing. For example, if a user clicks the "Roadside Assistance" button on the vehicle's infotainment system, the vehicle-side device generates an authorization request, carrying the target function code "TOWING," and sends it to the data ontology inference engine for processing.

[0179] Step 9: Determine the request type and determine the skill workflow based on the request type.

[0180] In this embodiment, after receiving a user request, the data ontology inference engine first determines the request type (permission authentication request or purchase pre-inspection request), then executes the corresponding inference process according to the request type, and determines the corresponding skill workflow after the inference is successful. The data ontology provides all knowledge sources for inference; the inference engine does not care whether the knowledge is directly declared in the data ontology file or generated by skill registration, thus achieving decoupling between the knowledge layer and the inference layer.

[0181] Specifically, if the request type is an authentication request, a three-step progressive authentication reasoning process is executed. That is, the three steps are arranged in order from simple to complex. If the previous step is successful, permission is returned and no further steps are executed, thereby avoiding unnecessary graph traversal. The first step is direct matching. In the target rights graph, we query whether the associated function codes of the rights item nodes held by the target user contain the target function codes (i.e., feature_codes). If the query matches, the user is allowed to use the corresponding skill's workflow.

[0182] The second step is inheritance derivation. If a direct match is not found, the process traverses upwards along the inheritance relationship (i.e., is_a) from the target user's rights item node to its parent node (i.e., the superior package node or concept node associated with the rights item through the inheritance relationship edge). The process checks whether the associated function code of the parent node contains the target function code. If a match is found along the inheritance relationship edge, the process allows the use of the corresponding skill and triggers the workflow.

[0183] The third step is precondition verification. If the inheritance deduction still fails, the system searches along the enabling relationship (i.e., `enables`) to see if any of the target user's rights items point to the target function code through the enabling relationship (i.e., the rights item enables the target function). Simultaneously, it searches the target rights graph for rights item nodes whose associated function codes contain the target function code (i.e., the rights items corresponding to that function code). It then checks along the dependency relationship (i.e., `requires`) of that node to verify whether all the prerequisite rights items it depends on are held by the target user. If all conditions are met, the system allows use and triggers the corresponding skill's workflow. If all three steps fail, use is rejected, and missing rights item identifiers may be attached.

[0184] If the request type is a purchase pre-inspection request, then execute the three-step sequential decision-making process: The first step is dependency checking. It traverses the target benefits graph along the dependency relationships (i.e., require) to verify whether the target user already has all the prerequisite dependent benefits required for the target benefit. If any are missing, it returns a list of missing dependent benefit identifiers (i.e., which benefits the user needs to acquire before purchasing the current target).

[0185] The second step is conflict detection. If the dependency verification passes, the target equity graph is traversed along the mutual exclusion relationship (i.e., conflicts_with) to check whether there are any equity items that are mutually exclusive with the target equity item among the equity items already owned by the target user; if so, the purchase is blocked.

[0186] The third step is substitution analysis. If the conflict check passes, the target benefit graph is traversed along the substitution relationships (i.e., supersedes) to check whether the target benefit item has been replaced or covered by other benefits owned by the target user. If it has been covered, a message is displayed indicating that there is no need to purchase again. If the dependency check, conflict check, and substitution check all pass, the purchase is allowed and the corresponding skill workflow is triggered.

[0187] After the reasoning is successful, the skill execution engine determines the corresponding skill workflow based on the request. This involves reading the workflow definition from the corresponding skill configuration file and executing the service delivery process according to the defined sequence of steps. The workflow definition is written into the configuration file along with the ontology registration section during skill registration, declaring the complete execution steps for the skill from verification to cancellation.

[0188] The skill execution engine calls the step processors sequentially according to the steps defined in the workflow. The system has seven built-in step processors: the rights verification processor receives the user identifier and the target rights item identifier, calls the data ontology inference engine to perform a three-step progressive authentication inference, and returns pass or rejection; the quota check processor reads the remaining number of times or days in the user's holding record for the rights item and compares it with the consumption amount of this request; if the quota is insufficient, it returns failure; the rule evaluation processor performs general condition judgments, such as distance not exceeding a preset threshold, battery not lower than a preset percentage, etc., and returns true or false for each rule; the work order creation processor assembles the rights item information, user information, and timestamp into a service work order and writes it into the work order system; the external call processor connects to external services such as payment gateways or dispatch systems, passes in order information and waits for callback; the notification push processor informs the user of the execution result with a templated message (SMS, push, in-site message); and the completion verification processor deducts the quota in the user's holding record and updates the rights status after all steps are passed.

[0189] The execution flow is as follows: if the current step processor returns success, it proceeds to the next step specified by the branch (pass branch) in the workflow definition; if it returns failure, it proceeds to the failure branch. The failure branch can be configured to retry the current step, skip the current step and continue execution, or terminate the entire workflow. Each step processor can be trimmed or extended according to business needs. To add a new processor, simply register a processing function using the decorator pattern and reference it in the workflow definition.

[0190] Step 10: Write back the data ontology map.

[0191] In this embodiment, after reasoning or execution is completed, the scheduling module in the skill execution engine performs specific rights purchase, authentication, renewal, and upgrade / downgrade operations based on the output results. At the same time, the execution results are written back to the data ontology graph to update the status information of relevant rights item nodes (such as quota deduction, status change, and validity period update), realizing a complete two-way closed loop of "data ontology driving skill execution and skill execution results being written back to the data ontology", ensuring the timeliness of subsequent queries.

[0192] Specifically, after the workflow is completed, the status of the corresponding benefit item node in the target benefit graph is updated based on the execution results. For example, if a user successfully purchases advanced maintenance, the status of the advanced maintenance benefit item node is updated to "valid," with a validity period set to one year and a quota set to twice per year; if a user uses roadside assistance once, the remaining quota of the roadside assistance benefit item node is deducted, and the status is updated to show a corresponding reduction in remaining uses; if a user's purchased package expires, the status of the corresponding benefit item node is updated from "valid" to "expired" according to the lifecycle rules.

[0193] By writing back the execution results, the status of the rights and interests nodes in the data ontology graph is always consistent with the actual situation, thereby supporting the accurate reasoning of subsequent authorization authentication and purchase pre-inspection, forming a complete two-way closed loop of "data ontology driving skill execution and skill execution results writing back to the data ontology".

[0194] Step 11: Skill change-driven hot loading of the data ontology.

[0195] In this embodiment, a hot-loading mechanism is triggered when a skill catalog is added, removed, or modified (i.e., a skill change). Specifically, the skill registry rescans the skill catalog, compares it item by item with the registered skills, and calculates the difference set (added, removed, updated). Subsequently, the target rights graph is fully reconstructed to build a new graph instance. The execution process is as follows: the old graph continues to respond to business requests during the reconstruction (i.e., the old graph continues to provide services), and after the new graph is built, an atomic replacement is performed (switching the global graph reference from the old instance to the new instance), ensuring uninterrupted service.

[0196] Hot loading can be triggered by an HTTP interface, where operations personnel actively call the interface to trigger a rescanning of the skill catalog and reconstruction of the graph; it can also be automatically triggered by file system monitoring, where the system automatically executes the hot loading process when it detects changes in the skill catalog. This step ensures that the data ontology and skills are always synchronized, meaning that any changes to skills are immediately reflected in the target rights graph, realizing online hot loading and immediate effectiveness of rights services.

[0197] Corresponding to the above method embodiments, this application also provides a processing device for vehicle-side rights, such as... Figure 7As shown, the device may include a data acquisition module 701, a map construction module 702, and a rights processing module 703.

[0198] Data acquisition module 701 is used to acquire a data ontology file and at least one skill directory; Graph construction module 702 is used to construct a target rights graph based on a data ontology file and at least one skills directory; The rights and interests processing module 703 is used to process the target vehicle-side rights and interests corresponding to the target rights and interests operation request based on the target rights and interests graph when a target rights and interests operation request is received.

[0199] This application also provides a vehicle, such as... Figure 8 As shown, it includes a processor 801, a communication interface 802, a memory 803, and a communication bus 804. The processor 801, communication interface 802, and memory 803 communicate with each other via the communication bus 804. Memory 803 is used to store computer programs; In one embodiment of this application, when the processor 801 executes a program stored in the memory 803, it performs the following steps: Obtain a data ontology file and at least one skill directory; construct a target rights graph based on the data ontology file and at least one skill directory; upon receiving a target rights operation request, process the target vehicle-side rights corresponding to the target rights operation request according to the target rights graph.

[0200] The communication bus mentioned in the above vehicles can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0201] The communication interface is used for communication between the aforementioned vehicle and other devices.

[0202] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0203] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be 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, or discrete hardware components.

[0204] In another embodiment provided in this application, a storage medium is also provided, which stores instructions that, when run on a computer, cause the computer to execute any of the vehicle-side rights processing methods described in the above embodiments.

[0205] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the vehicle-side rights processing methods described in the above embodiments.

[0206] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a storage medium or transmitted from one storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0207] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0208] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0209] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the protection scope of this application.

Claims

1. A method for processing vehicle-side rights, characterized in that, The method includes: Obtain the data ontology file and at least one skill directory; Based on the data ontology file and at least one of the skill directories, a target rights graph is constructed; Upon receiving a target benefit operation request, the target vehicle-side benefit corresponding to the target benefit operation request is processed according to the target benefit map.

2. The method according to claim 1, characterized in that, The construction of the target rights graph based on the data ontology file and at least one of the skill directories includes: The data ontology file is parsed to determine the map hierarchy information; For any of the aforementioned skill catalogs, determine the corresponding rights and interests information for that skill catalog; Based on the rights and interests information corresponding to each of the skill catalogs and the map hierarchy information, the target rights and interests map is constructed.

3. The method according to claim 2, characterized in that, The process of determining the rights and interests information corresponding to the skills catalog includes: The skill catalog is parsed to determine the configuration files and file information; Extract the ontology registration section from the configuration file. The ontology registration section contains at least the rights item identifier, rights item classification, and associated function code. If the file information includes a package-type file, obtain the package attributes and sub-service identifier list from the package-type file, and determine the ontology registration section, the package attributes, and the sub-service identifier list as the rights and benefits information corresponding to the skill catalog; If the file information does not contain package-type files, the ontology registration section will be identified as the rights and benefits information corresponding to the skill catalog.

4. The method according to claim 3, characterized in that, The construction of the target rights graph based on the rights item information corresponding to each of the skill directories and the graph hierarchy information includes: Based on the graph hierarchy information, at least one concept node, relation edge template, and axiom rule are determined; For any of the skill catalogs, obtain the rights item category, rights item identifier, and associated function code from the rights item information corresponding to the skill catalog; Based on the classification of the rights items, a target concept node is determined from at least one of the concept nodes; If the rights and benefits information corresponding to the skill catalog contains a list of sub-service identifiers, then at least one rights and benefits node corresponding to a sub-service is determined based on the list of sub-service identifiers, and a package node is created based on the rights and benefits identifier and the associated function code; Along the relationship edge in the relationship edge template, attach the benefit item nodes corresponding to each sub-service to the package node, and along the inheritance relationship edge in the relationship edge template, attach the package node to the target concept node; Obtain the rules corresponding to the package node and the rules corresponding to the benefit item nodes of each sub-service from the axiom rules; The rules corresponding to the package node are attached to the package node, and the rules corresponding to the benefit item nodes corresponding to each sub-service are attached to the benefit item nodes corresponding to each sub-service, to obtain the target benefit graph.

5. The method according to claim 4, characterized in that, The method further includes: If the rights and benefits information corresponding to the skill catalog does not include the sub-service identifier list, then a rights and benefits node is created based on the rights and benefits identifier and the associated function code; Attach the equity item node to the target concept node along the inheritance relationship edge in the relationship edge template; Obtain the rule corresponding to the equity item node from the axiom rules; The rules are attached to the rights and interests nodes to obtain the target rights and interests graph.

6. The method according to claim 4, characterized in that, The step of determining at least one rights item node corresponding to a sub-service based on the sub-service identifier list includes: For any sub-service identifier in the sub-service identifier list, determine the target skill directory and sub-service corresponding to the sub-service identifier; The target skill catalog is parsed, and the corresponding rights item nodes for the sub-services are created.

7. The method according to claim 1, characterized in that, The step of processing the target vehicle-side rights corresponding to the target rights operation request based on the target rights graph includes: If the target rights operation request is an authorization request, obtain the target function code carried in the target rights operation request; Based on the target function code, reasoning is performed in the target rights graph to obtain a first reasoning result; If the first inference result representation allows its use, the target vehicle-side rights corresponding to the target rights operation request are allowed to be used. If the first inference result indicates that the target vehicle-side rights corresponding to the target rights operation request are refused use, the use of the target rights operation request will be refused.

8. The method according to claim 1, characterized in that, The step of processing the target vehicle-side rights corresponding to the target rights operation request based on the target rights graph includes: If the target benefit operation request is a purchase pre-inspection request, obtain the target benefit item identifier carried in the target benefit operation request; Based on the target equity item identifier, reasoning is performed in the target equity graph to obtain a second reasoning result; If the second reasoning result indicates that purchase is permitted, then the purchase of the target vehicle-side rights corresponding to the target rights operation request is permitted; If the second reasoning result indicates a refusal to purchase, then the purchase of the target vehicle-side rights corresponding to the target rights operation request is refused.

9. A device for processing vehicle-side rights, characterized in that, The device includes: The data acquisition module is used to acquire the data ontology file and at least one skill directory; The graph construction module is used to construct a target rights graph based on the data ontology file and at least one of the skill directories; The rights and interests processing module is used to process the target vehicle-side rights and interests corresponding to the target rights and interests operation request based on the target rights and interests map when a target rights and interests operation request is received.

10. A vehicle, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

Images