Pet data processing methods and systems

Abstract

This specification provides a method and system for processing pet data, including: obtaining target-related information of a target pet, wherein the target-related information includes basic information, historical claims information, and hardware perception information of the target pet; the hardware perception information is collected from the target pet by hardware perception devices based on the target pet's environment; determining the target disease of the target pet based on the target-related information; and determining and pushing a target health intervention plan corresponding to the target disease to the owner of the target pet based on a pre-constructed target knowledge graph, wherein the target knowledge graph is used to represent the correspondence between diseases and health intervention plans. This aims to improve the pet's health status, ensuring the pet is as healthy as possible and reducing the pet insurance payout rate.

Description

Technical Field

[0001] This manual relates to the field of pet insurance, and in particular to a method and system for processing pet data. Background Technology

[0002] As material needs are gradually met, people are paying more and more attention to fulfilling their spiritual needs. Keeping pets has become a way to satisfy these needs. More and more people are keeping pets, and more and more people are buying pet insurance.

[0003] Current research directions in the pet insurance industry mainly include: how to determine the appropriate insurance for a given pet, how to process claims (such as reviewing claim requests, and how to improve the speed of claims processing).

[0004] As more and more people purchase pet insurance, the payout rate for pet insurance is increasing. The research directions mentioned above cannot reduce the persistently high payout rate, nor can they truly improve the health of pets.

[0005] It should be noted that the above-mentioned related technologies are only information known to the inventor personally, and do not mean that the above information had entered the public domain before the application date of this specification, nor do they mean that it can be considered prior art in this specification. Summary of the Invention

[0006] This specification provides a method and system for processing pet data to avoid at least one of the aforementioned technical problems.

[0007] Firstly, this instruction manual provides a method for processing pet data, including: Obtain target-related information about the target pet, wherein the target-related information includes the target pet's basic information, historical claims information, and hardware perception information, and the hardware perception information is collected from the target pet by hardware perception devices based on the target pet's environment; Based on the target-related information, determine the target disease of the target pet; and Based on a pre-constructed target knowledge graph, a target health intervention plan corresponding to the target disease is determined and pushed to the owner of the target pet. The target knowledge graph is used to represent the correspondence between the disease and the health intervention plan.

[0008] Secondly, this specification provides a pet data processing system, including: At least one storage medium storing at least one set of instructions for processing pet data; At least one processor is communicatively connected to the at least one storage medium, wherein when the at least one processor is running, it reads the at least one instruction set and executes the method as described in the first aspect according to the instructions of the at least one instruction set.

[0009] As can be seen from the above technical solutions, the pet data processing method and system provided in this manual determine the pet's health status by combining relevant pet information. In order to determine the corresponding health intervention plan when the pet's health status is poor, the pet's health status can be improved, so that the pet can be in the healthiest possible state and the pet insurance payout rate can be reduced.

[0010] The pet data processing methods and other functions of the system provided in this manual are partially listed in the following description. The inventive aspects of the pet data processing methods and systems provided in this manual can be fully explained through practice or use of the methods, apparatus, and combinations described in the detailed examples below. Attached Figure Description

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

[0012] Figure 1 This is a schematic diagram illustrating an application scenario of the pet data processing method provided in the embodiments of this specification; Figure 2 This is a schematic diagram of the pet data processing system provided in the embodiments of this specification; Figure 3 A flowchart illustrating a method for processing pet data provided in one embodiment of this specification; Figure 4 A flowchart illustrating a method for processing pet data according to another embodiment of this specification; Figure 5 This is a schematic diagram of a portion of the target knowledge graph provided in the embodiments of this specification. Detailed Implementation

[0013] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

[0014] It should be understood that the terms “comprising” and “having”, and any variations thereof, in the embodiments of this specification are intended to cover but not exclude inclusion. For example, a product or device that includes a series of components is not necessarily limited to those components that are explicitly listed, but may include other components that are not explicitly listed or that are inherent to such product or device.

[0015] The term "and / or" in the embodiments of this specification describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0016] In the embodiments of this specification, the term "multiple" refers to two or more, and other quantifiers are similar.

[0017] The terms “first,” “second,” “third,” etc., used in this specification are used to distinguish similar or related objects or entities and do not necessarily imply a specific order or sequence, unless otherwise indicated. It should be understood that such terms can be used interchangeably where appropriate, for example, in situations where implementation can proceed in an order other than those given in the embodiments illustrated or described in this specification.

[0018] As used in this specification, the term "unit / module" means any known or subsequently developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and / or software code capable of performing the functions associated with that element.

[0019] To avoid at least one of the technical problems mentioned in the background section, this specification proposes a technical concept developed through inventive effort: intervening in a pet's health based on relevant pet information to ensure the pet remains in a relatively healthier state for a longer period, thereby reducing pet insurance claims. In other words, improving a pet's health status and lowering the pet insurance payout rate through pre-emptive health intervention.

[0020] For example, firstly, the processing system can obtain relevant information about the pet. This information may include: the pet's basic information, the pet's historical claims information, and hardware sensing information obtained by hardware sensing devices in the area where the pet is located (such as pet behavior information collected by hardware sensing devices).

[0021] Then, the processing system can detect the pet's health status based on relevant information to identify the corresponding disease when the pet is sick.

[0022] Finally, the processing system can identify and push health intervention plans corresponding to the pet's disease to the pet's owner by querying the knowledge graph. This allows the owner to care for the pet based on the intervention plan, thereby improving the pet's health and keeping it as healthy as possible. The knowledge graph represents the correspondence between diseases and health intervention plans.

[0023] It is worth noting that the above methods are not for therapeutic purposes; that is, they are used for non-therapeutic purposes and are mainly used to send messages to pet owners.

[0024] The technical solutions provided in this specification are based on the aforementioned technical concepts. As described above, the technical solutions provided in this specification determine a pet's health status by combining relevant pet information. In cases where a pet's health is poor, appropriate health intervention plans are identified and pushed to the pet owner to improve the pet's health, ensuring the pet is as healthy as possible and reducing the payout rate for pet insurance.

[0025] To facilitate readers' understanding of this manual, the application scenarios of this manual are introduced below.

[0026] The technical solutions provided in this manual are applicable to scenarios requiring the processing of pet data, such as monitoring a pet's health status or controlling pet insurance premiums.

[0027] For example, Figure 1 This diagram illustrates an application scenario of the pet data processing method (hereinafter referred to as the processing method) according to embodiments of this specification. The processing method can be applied to, for example... Figure 1 Scene 100 is shown.

[0028] like Figure 1 As shown, scenario 100 may include a pet room 101, a pet 102, a hardware sensing device 103, and a processing system 104. The pet 102 primarily stays within the pet room 101. The hardware sensing device 103 can be a sensor deployed within the pet room 101 to acquire data related to the pet 102 (such as heart rate, audio, and video). The hardware sensing device 103 can communicate with the processing system 104 via wired or wireless means. The pet-related data collected by the hardware sensing device 103 can be referred to as hardware sensing information.

[0029] In some embodiments, the processing system 104 may include a cloud server 105. For example... Figure 1As shown, taking the processing system 104, which includes a cloud server 105, as an example, on the one hand, the cloud server 105 can obtain hardware sensing information collected by the hardware sensing device 103. On the other hand, the cloud server 105 can also obtain the pet's basic information and historical claims information.

[0030] Correspondingly, the cloud server 105 can execute the processing plan provided in this manual based on the obtained hardware perception information, the pet's basic information and historical claims information, in order to determine and push a health intervention plan to the owner of the target pet to intervene in the pet's health status, so as to keep the pet in the healthiest possible state.

[0031] For example, such as Figure 1 As shown, the application scenario also includes user 106 and user 106's terminal device 107. Terminal device 107 can be a mobile terminal, such as a mobile phone.

[0032] The cloud server 105 can push health intervention plans to the terminal device 107.

[0033] Terminal device 107 can output a display interface including a health intervention plan. User 106 can browse the specific content of the health intervention plan through the display interface of terminal device 107, and can raise pet 102 based on the specific content.

[0034] It is worth noting that, Figure 1 and targeting Figure 1 The above description is merely illustrative of possible application scenarios for which the processing method described in this specification may be applicable, and should not be construed as limiting the application scenarios. For example, in some other embodiments, the processing system 104 may include, for instance, […]. Figure 1 The cloud server 105 shown may also include, for example, Figure 1 The hardware sensing device 103 shown is used in conjunction with the cloud server 105 to complete the processing method provided in this specification. The specific implementation principle will be explained later.

[0035] Figure 2 A hardware structure diagram of a processing system 200 according to an embodiment of this specification is shown. The processing system 200 can perform the processing methods described in this specification. The processing methods are described in other parts of this specification.

[0036] like Figure 2 As shown, the processing system 200 may include at least one storage medium 203 and at least one processor 202. In some embodiments, the processing system 200 may also include a communication port 204 and an internal communication bus 201. The processing system 200 may also include I / O components 205.

[0037] The internal communication bus 201 can connect to different system components. For example, the internal communication bus 201 can connect to storage medium 203, processor 202, communication port 204, and I / O component 205.

[0038] I / O component 205 supports input / output between processing system 200 and other components.

[0039] Communication port 204 is used to handle data communication between system 200 and the outside world. For example, communication port 204 can be used to handle data communication between system 200 and a network. Communication port 204 can be a wired communication port or a wireless communication port.

[0040] Storage medium 203 may include a data storage device. The data storage device may be a non-transitory storage medium or a temporary storage medium. For example, the data storage device may include one or more of a disk 2031, a read-only storage medium (ROM) 2032, or a random access storage medium (RAM) 2033. Storage medium 203 also includes at least one instruction set stored in the data storage device. The instruction set includes computer program code, which may include programs, routines, objects, components, data structures, procedures, modules, etc., that execute the processing methods provided in this specification.

[0041] At least one processor 202 may be communicatively connected to at least one storage medium 203. The at least one processor 202 is used to execute the at least one instruction set described above. When the processing system 200 is running, the at least one processor 202 reads the at least one instruction set and, according to the instructions of the at least one instruction set, executes the processing method provided in this specification. The processor 202 may execute all steps included in the processing method. The processor 202 may be in the form of one or more processors. In some embodiments, the processor 202 may include one or more hardware processors, such as a microcontroller, microprocessor, reduced instruction set computer (RISC), application-specific integrated circuit (ASIC), application-specific instruction set processor (ASIP), central processing unit (CPU), graphics processing unit (GPU), physical processing unit (PPU), microcontroller unit, digital signal processor (DSP), field-programmable gate array (FPGA), advanced RISC machine (ARM), programmable logic device (PLD), any circuit or processor capable of performing one or more functions, or any combination thereof.

[0042] For illustrative purposes only, only one processor 202 is shown in the accompanying drawings of the processing system 200. However, it should be noted that the processing system 200 may also include multiple processors. Therefore, the operation and / or method steps disclosed herein may be executed by one processor or by multiple processors in combination. For example, if the processor 202 of the processing system 200 described in this specification executes steps A and B, it should be understood that steps A and B may also be executed jointly or separately by two different processors 202 (e.g., the first processor executes step A, the second processor executes step B, or the first and second processors jointly execute steps A and B).

[0043] Please see Figure 3 , Figure 3 This is a flowchart illustrating a method for processing pet data according to one embodiment of this specification. Figure 3 The execution entity of the processing method shown can be a processing system. For a description of the processing system, please refer to the example above; it will not be repeated here.

[0044] like Figure 3 As shown, the method includes the following steps S301 to S303: S301: Obtain target-related information for the target pet, including the target pet's basic information, historical claims information, and hardware perception information. The hardware perception information is collected by hardware perception devices based on the target pet's environment.

[0045] The target pet can be understood as the individual pet being monitored, analyzed, or served. For example, a Golden Retriever, A.

[0046] Basic information (also known as a pet profile) can be understood as the static attribute information of the target pet. For example, information such as the breed, age, sex, weight, environment, region, and climate (such as season) of a Golden Retriever A.

[0047] Historical claims information (also known as historical claims data) can be understood as information related to the target pet's involvement in claims during a historical period, such as insurance coverage and incidents. In other words, historical claims information can include: the target pet's policy-related information (such as the coverage plan, liability, amount, product terms, etc.) and the target pet's claims-related information (such as incident information, hospital treatment information, claim amount, etc.).

[0048] Hardware-sensing information can be understood as dynamic data of the target pet collected by smart devices (such as cameras, environmental sensors, etc.). Examples include physiological data such as the target pet's heart rate, body temperature, and respiratory rate; behavioral data such as the target pet's activity level, sleep quality, and abnormal posture; and environmental data such as temperature, humidity, air quality, and light intensity.

[0049] For example, in combination Figure 1 As can be seen from the above analysis, hardware sensing devices, such as sensors, can be deployed in the environment where the target pet is located, such as in the pet house where the target pet is located, to collect relevant data of the target pet based on the hardware sensing devices, thereby obtaining hardware sensing information.

[0050] In some embodiments, the hardware sensing device may include at least one of millimeter-wave radar, infrared video stream acquisition device, and voiceprint device.

[0051] Accordingly, the hardware-sensing information may include at least one of the following: breathing information collected by millimeter-wave radar, video stream information obtained by infrared video stream acquisition device, and voiceprint information detected by voiceprint device.

[0052] In addition, this specification mainly uses hardware-sensing information, which includes multimodal information (specifically, the three different types of information mentioned above), as an example for explanation.

[0053] Millimeter-wave radar can be understood as an electromagnetic wave sensor operating in the 60GHz or 77GHz frequency band. Relatively speaking, millimeter-wave radar can penetrate hair. For example, millimeter-wave radar can penetrate the fur of a target pet in a non-contact manner to detect the pet's respiratory information, such as respiratory rate, respiratory rhythm, and heart rate.

[0054] Infrared video stream acquisition devices can include infrared cameras, such as infrared thermal imaging cameras or visible light + infrared fusion cameras. These devices can capture video stream information of a target pet in low light or at night, and can determine the pet's posture, skin wrinkle coefficient, body temperature distribution, movement trajectory, etc., based on the video stream information.

[0055] Voiceprint devices can be high-sensitivity microphone arrays that can collect sound signals such as barks, breathing sounds, and snoring from a target pet.

[0056] Millimeter-wave radar, infrared video stream acquisition devices, and voiceprint devices are non-contact hardware sensing devices. Therefore, in this embodiment, non-contact detection can be achieved without wearing them or disturbing the target pet's sleep, thereby improving the target pet's compliance and data continuity. Especially when combining hardware sensing information obtained from multiple different devices, multimodal data collection of the target pet can be achieved, that is, multimodal perception of the target pet's health, thereby improving the effectiveness and accuracy of subsequent analysis of the target pet's health status based on multimodal data.

[0057] In some embodiments, the infrared video stream acquisition device is a de-reflective camera device.

[0058] The camera device includes an ultraviolet (UV) auxiliary light source, and / or the imaging principle of the camera device includes polarization imaging.

[0059] For example, when using an infrared video stream acquisition device to capture video of a target pet, issues such as overexposure of the image in the video stream may occur due to strong reflections. To avoid this problem, a de-reflective camera device can be used as the infrared video stream acquisition device.

[0060] For example, anti-reflective camera devices can be those that utilize a UV-assisted light source. Specifically, the UV-assisted light source can excite fluorescence in the target pet, allowing for the identification of potential lesions even when the target pet's surface is highly reflective.

[0061] For example, a de-reflective camera device can be a polarization-based imaging device. Specifically, a de-reflective camera device can use a dual-channel camera. One channel has a parallel polarizer, and the other channel has a vertical polarizer, so that the two images of the target pet are fused using a corresponding algorithm to extract the de-reflective, intrinsic skin image of the target pet.

[0062] Continuing with the example above, Golden Retriever A's fur may be very shiny, making it difficult to see the skin inside its ear canal with a regular camera. However, using a reflective camera device can remove the reflection, clearly showing the redness and discharge in the ear canal.

[0063] Therefore, in this embodiment, by using a UV-assisted light source and polarization imaging de-reflective camera device to collect the video stream of the target pet, the drawbacks such as unclear acquisition of certain information about the target pet due to reflection problems can be avoided, thereby improving the accuracy and reliability of subsequent analysis of the target pet's health status.

[0064] S302: Determine the target disease of the target pet based on relevant target information.

[0065] A target disease can be understood as a disease that the processing system infers based on the target pet's health status using relevant target information. For example, the processing system might determine that a Golden Retriever, A, suffers from atopic dermatitis through analysis and reasoning of target-related information.

[0066] This embodiment does not limit the implementation of S302. For example, the processing system can determine the target disease based on a pre-trained disease prediction network model. Specifically, the input to the disease prediction network model is target-related information, and the output is the target disease. Regarding the training of the disease prediction network model, it can employ supervised training or unsupervised training. Taking supervised training as an example: The training system (which can be a processing system or other systems) can collect sample data. For an understanding of the content of the sample data, please refer to the description of the target-related information above; it will not be repeated here.

[0067] Correspondingly, the training system can predict the corresponding diseases based on sample data, calculate the loss function between the predicted diseases and the corresponding labels, and train the disease prediction network model with the goal of minimizing the loss function.

[0068] In addition, this embodiment does not limit the structure of the disease prediction model, which can be determined by the training system based on requirements, historical records, experiments, etc.

[0069] S303: Based on the pre-built target knowledge graph, determine and push the target health intervention plan corresponding to the target disease to the owner of the target pet. The target knowledge graph is used to represent the correspondence between the disease and the health intervention plan.

[0070] A target knowledge graph can be understood as a pre-built structured knowledge base used to describe the mapping relationship between diseases and health intervention programs.

[0071] For example, a target knowledge graph may include nodes and edges, where nodes represent entities and edges between two nodes represent the association between the two entities.

[0072] For example, nodes in a target knowledge graph can represent diseases or health intervention programs. An edge between a node representing a disease and a node representing a health intervention program indicates the correspondence between the two.

[0073] Therefore, once a disease is identified, a corresponding health intervention plan can be determined based on the mapping relationships within the target knowledge graph. Thus, if the processing system determines that a target pet suffers from a target disease, it can determine the target health intervention plan corresponding to the target disease by querying the knowledge graph.

[0074] A health intervention program (also known as a health maintenance strategy, or simply a wellness strategy) can be understood as a set of actionable measures recommended for a specific disease or risk state. Examples include nutritional advice, exercise rehabilitation plans, environmental setup recommendations, medication recommendations, and dietary adjustments.

[0075] Correspondingly, the processing system can push health intervention plans to the owners (such as target users) of the target pets so that the target users can raise the target pets based on the health intervention plans.

[0076] It is worth noting that knowledge graphs can also contain other correspondences, such as those between diseases and symptoms, diseases and diagnostic criteria, diseases and treatment pathways, and diseases and high-risk products.

[0077] Based on the above analysis of S301 to S303, it can be seen that in this embodiment, the processing system determines the target disease by combining the target pet's basic information, historical claims information, and hardware sensing information. This considers not only the target pet's own information, such as breed, age, region, and environment (e.g., season), but also the target pet's historical disease history and claims situation, as well as the target pet's current dynamic data, resulting in high accuracy and reliability in identifying the target disease. Furthermore, by combining knowledge graphs to determine the target health intervention plan, the processing system can achieve full automation from data acquisition to health intervention plan output, requiring no manual intervention and enabling early intervention to prevent disease deterioration and reduce the incidence of large claims.

[0078] To facilitate a deeper understanding of the principles behind the technical solutions provided in this manual, the following is a combination of... Figure 4 The processing methods provided in this manual will be described in more detail.

[0079] like Figure 4 As shown, the method includes: S401: The hardware sensing device collects hardware sensing information corresponding to the target pet, including breathing information, video stream information, and voiceprint information.

[0080] It should be understood that, in order to avoid tedious descriptions, this embodiment will not repeat the same or similar content as the examples above.

[0081] For example, regarding the understanding of 401, please refer to the description of the relevant content in the above example, which will not be repeated here.

[0082] S402: The hardware sensing device sends hardware sensing information to the corresponding edge server. The edge server is a local server that is communicatively connected to the hardware sensing device that receives the hardware sensing information.

[0083] In this embodiment, pet data is processed through an edge-cloud system decision-making approach. Therefore, the edge server is defined relative to the cloud server.

[0084] An edge server can be understood as a computing device deployed in a local network environment (such as a home gateway, a pet hospital's LAN, or a smart pet house control box). It is responsible for receiving, processing, and caching data collected by hardware sensing devices from the target pet, and executing corresponding decisions. Therefore, the edge server for the hardware sensing device that collects the target pet's hardware sensing information is the edge server corresponding to the hardware sensing device. Pets in different regions may correspond to different edge servers.

[0085] Correspondingly, the edge server receives hardware sensing information sent by the hardware sensing device.

[0086] S403: The edge server determines the health status of the target pet based on hardware perception information, which is either an emergency state or a non-emergency state.

[0087] An emergency situation can be understood as a state where the target pet's life is in danger. A non-emergency situation can be understood as a state where the target pet's life is safe, but there may be some health problems, or the pet may be sick or healthy.

[0088] In other words, relatively speaking, an emergency situation indicates a dangerous state in which the target pet may die, that is, there is a life-threatening situation. A non-emergency situation indicates that the target pet is either in a healthy state or in a sub-healthy state (such as being sick), but is not in a life-threatening situation.

[0089] This embodiment does not limit the implementation method of the edge server determining the health status of the target pet based on hardware-sensing information. It can be implemented based on preset rules or a network model.

[0090] Taking the method of preset rules as an example: Based on the above analysis, it can be seen that hardware-sensing information can include one or more of the following: respiratory information, video stream information, and voiceprint information. Accordingly, the edge server can determine the health status of the target pet based on one or more of these sources.

[0091] Taking respiratory information as an example: a preset rule could be that if the target pet is suffocating, then the target pet's health status is determined to be in an emergency. Correspondingly, the edge server can determine whether the target pet is suffocating based on respiratory information, specifically, by determining whether the target pet is suffocating based on its heart rate. If so, the edge server can determine that the target pet is in an emergency.

[0092] Taking video stream information as an example, a preset rule could be that if the target pet is in a convulsive state, then the target pet's health status is determined to be in an emergency. For example, an edge server can determine whether the target pet is in a convulsive state based on video stream information. Specifically, the edge server can identify the video stream information to determine the target pet's posture information. If the posture information indicates that the target pet is in a convulsive state, then the edge server can determine that the target pet is in an emergency state.

[0093] Similarly, this specification does not limit the method by which the edge server identifies video stream information; for example, a network model can be used. Specifically, a three-dimensional convolutional neural network (3D-CNN) can be used to process the video stream information to obtain the corresponding pose information.

[0094] Similarly, the training principle of 3D-CNN can be found in the description of the disease prediction network model in the example above, which will not be repeated here.

[0095] In other embodiments, the infrared video stream acquisition device has an identification function. The infrared video stream acquisition device can identify the video stream information to obtain corresponding posture information and send the posture information to the edge server. Accordingly, the edge server can determine whether the target pet is in a convulsive state based on the posture information, and thus determine whether the target pet's health status is in an emergency.

[0096] Taking voiceprint information as an example, an edge server can determine the pain index of a target pet based on voiceprint information. If the pain index reaches a preset level, the target pet is considered to be in an emergency. The higher the pain index, the greater the degree of pain. The edge server can pre-store the correspondence between voiceprint features and pain indices, so that after feature extraction from the voiceprint information, the corresponding pain index can be determined based on this correspondence. Alternatively, the edge server can also use a network model to determine the pain index corresponding to the voiceprint information. Specifically, a Mel-frequency cepstral coefficient convolutional neural network (MFCC-CNN) can be used to extract voiceprint features (MFCC features) from the voiceprint information and predict the corresponding pain index based on these features.

[0097] Similarly, the training principle of MFCC-CNN can be found in the description of the disease prediction network model in the example above, and will not be repeated here.

[0098] Based on the above analysis, it can be seen that the edge server can determine the skin fold coefficient of the target pet based on video stream information. Similarly, the edge server can also determine the skin fold coefficient of the target pet based on a network model. It is worth noting that different breeds of pets have significant differences in anatomical structure. Therefore, for different breeds of pets, the edge server can use different network models to determine the corresponding skin fold coefficient.

[0099] Accordingly, the target pet's skin fold coefficient can be used in conjunction with the aforementioned respiratory, posture, and voiceprint information to determine whether the pet is in an emergency. Furthermore, the target pet's skin fold coefficient can also be used to subsequently determine parameters such as health index and health risk score.

[0100] Furthermore, taking multiple types of hardware-sensed information, including respiratory information, video stream information, and voiceprint information, as an example: preset rules can assign different weights to different types of information, and different situations within the same type of information can correspond to different levels of life-threatening danger. The edge server can determine the level of life-threatening danger corresponding to different types of information about the target pet, and combine the corresponding weights to determine the final level of life-threatening danger. When the level of life-threatening danger exceeds a preset threshold, the target pet's health status is determined to be in an emergency state.

[0101] For example, hardware-sensing information includes breathing information, video stream information, and voiceprint information: On one hand, edge servers can determine the level of life-threatening danger based on respiratory information, such as heart rate (for clarity, this level of life-threatening danger can be referred to as the first level of life-threatening danger). For example, the edge server stores a mapping table between heart rate and level of life-threatening danger. By querying this table, the first level of life-threatening danger corresponding to the target pet's heart rate can be determined. Specifically, in this mapping table, for heart rate values ​​greater than the pet's healthy heart rate, the higher the heart rate value, the higher the level of life-threatening danger; for heart rate values ​​less than the pet's healthy heart rate, the lower the heart rate value, the higher the level of life-threatening danger. The heart rate value in the pet's healthy state may be a range, which can be determined based on data collected in the actual scenario.

[0102] On the other hand, based on the above analysis, edge servers can identify video stream information to obtain the target pet's posture information (which may also include skin wrinkle coefficients, etc.). Edge servers can store a mapping table between different posture information and their corresponding levels of life-threatening danger. By querying this table, the level of life-threatening danger for the target pet in that aspect can be determined (for ease of distinction, this is called the secondary level of life-threatening danger). For example, posture information can include various postures such as twitching, lameness, rolling, curling up, and aggression, with different posture information corresponding to different levels of life-threatening danger. Specifically, in this mapping table, twitching corresponds to a higher level of life-threatening danger than lameness.

[0103] On the other hand, based on the above analysis, it can be seen that the edge server can store a mapping table between voiceprint features and the degree of life-threatening danger. By querying this table, the third level of life-threatening danger corresponding to the voiceprint information of the target pet can be determined.

[0104] Moreover, breathing information, video stream information, and voiceprint information each have their own corresponding weights, such as the first weight, the second weight, and the third weight, respectively.

[0105] Therefore, the edge server can determine the final life danger level of the target pet by weighted summation, such as the final life danger level of the target pet = first weight * first life danger level + second weight * second life danger level + third weight * third life danger level.

[0106] Correspondingly, if the final level of danger to the target pet's life is greater than or equal to the preset threshold (which can also be determined based on demand, historical records, experiments, etc.), the edge server can determine the target pet's health status as an emergency state; conversely, if the final level of danger to the target pet's life is less than the preset threshold, the edge server can determine the target pet's health status as a non-emergency state.

[0107] Taking the network model as an example: If the edge server determines the health status of a target pet based on one of the following: respiratory information, video stream information, or voiceprint information, a corresponding health status recognition model can be pre-built. This model can then use the relevant information as input to predict whether the pet is in a non-emergency or emergency state. Similarly, regarding the method for building the health status recognition model, please refer to the description of training the disease prediction network model in the example above; it will not be repeated here.

[0108] If the edge server determines the health status of a target pet based on multiple factors, including respiratory information, video stream information, and voiceprint information, it can fuse the features corresponding to these multiple pieces of information to obtain a fused feature, and then determine the target pet's health status based on this fused feature. Similarly, the specific implementation principle can be found in the example above, and will not be repeated here.

[0109] It is worth noting that, either through preset rules or network models, edge servers can also combine information other than the aforementioned breathing, posture, and voiceprint information to determine the target pet's health status. For example, the edge server can obtain the target pet's basic information and historical claims information (e.g., from a cloud server) to determine the target pet's health status.

[0110] S404: If it is an emergency, the edge server generates and outputs alarm information.

[0111] For example, the edge server can output alarm information by sending messages, alarms, etc., so that relevant personnel who care for the pet (such as the owner of the target pet) can send the target pet to the vet in a timely manner.

[0112] In this embodiment, when the target pet's health status is in an emergency state, that is, when the target pet is in danger of death, the edge server generates and outputs alarm information in a timely manner. This can reduce the delay in emergency response and improve the timeliness, effectiveness, and reliability of pet data processing, thereby enabling the target pet to be rescued in a timely manner when its life is in danger.

[0113] S405: If it is not an emergency, the edge server sends hardware awareness information to the cloud server.

[0114] Based on the above analysis, the health status can be either an emergency or a non-emergency state. In an emergency state, the target pet's life is at risk; in a non-emergency state, the target pet's life is not threatened.

[0115] Therefore, in emergency situations, the edge server issues alarm messages to achieve a low-latency response and ensure the safety of the target pet. In non-emergency situations, the edge server sends hardware awareness information to the cloud server, enabling the cloud server to perform subsequent operations based on this information, such as pushing health intervention plans. This allows for edge-cloud collaboration, thereby achieving layered and intelligent processing of pet data.

[0116] Correspondingly, the cloud server receives hardware awareness information sent by the edge server.

[0117] In some embodiments, the edge server can compress the hardware-aware information to obtain feature values, and then transmit these feature values ​​to the cloud server. This reduces communication resources required for data transmission and improves transmission efficiency.

[0118] It is worth noting that in an emergency, the edge server can generate and output alarm information. In some embodiments, since the pet is already in a life-threatening state, the edge server may not need to send hardware awareness information to the cloud server, and the cloud server will not need to determine and push a health intervention plan. In other embodiments, the edge server may also send the corresponding hardware awareness information to the cloud server so that the cloud server can perform subsequent related processing (see the relevant descriptions in the examples below).

[0119] S406: The cloud server determines the target disease of the target pet based on the target pet's basic information, historical claims information, and hardware sensing information.

[0120] In other words, in this embodiment, the target disease is determined under a preset first condition, and the preset first condition is that the edge server determines the target pet's health status as non-emergency based on hardware perception information.

[0121] For example, in conjunction with the above example, if the final level of danger to the target pet's life is greater than or equal to a preset threshold, the edge server determines that the current preset first condition is not met, that is, the edge server determines that the target pet's health status is an emergency state; conversely, if the final level of danger to the target pet's life is less than the preset threshold, the edge server determines that the current preset first condition is met, that is, the edge server determines that the target pet's health status is a non-emergency state.

[0122] In this situation (i.e., when the first preset condition is met), the edge server can send hardware sensing information to the cloud server, such as the target pet's basic information, historical claims information, and hardware sensing information.

[0123] Correspondingly, the cloud server can determine the target disease of the target pet based on the target pet's basic information, historical claims information, and hardware sensing information.

[0124] More specifically, this embodiment can be understood as follows: the cloud server can obtain the basic information and historical claims information of the target pet transmitted by the owner of the target pet, and can obtain the hardware sensing information sent by the hardware sensing device based on the hardware sensing information to determine that the health of the target pet is in a non-emergency state.

[0125] At this point, the cloud server contains the target pet's basic information, historical claims information, and hardware sensing information. Based on this information, the cloud server can then determine the target pet's specific disease.

[0126] Similarly, the technical principles of cloud servers in determining target diseases can be found in the description of S302 in the above example, and will not be repeated here.

[0127] In addition, in some embodiments, prior to S406, the cloud server can first determine the health risk score of the target pet based on the target pet's basic information, historical claims information, hardware sensing information, etc.

[0128] A health risk score can be understood as a quantitative indicator used to comprehensively assess the probability and severity of health events in a target pet. Relatively speaking, the higher the health risk score, the greater the health risk of the target pet, and the greater the possibility of disease or safety hazards.

[0129] Similarly, this specification does not limit the method by which the cloud server determines the health risk score. For example, it can be implemented based on a pre-trained health risk prediction model. The relevant implementation principles can be found in the description of the disease prediction network model above, and will not be repeated here.

[0130] Accordingly, S406 can be used to operate when the health risk score reaches a preset first threshold.

[0131] For example, if the edge server determines a health risk score greater than or equal to a preset first threshold based on the target pet's basic information, historical claims information, and hardware perception information, meaning that the target pet is very likely to have health risks, such as having a disease, the edge server can further determine the target pet's target disease based on the basic information, historical claims information, and hardware perception information.

[0132] In this embodiment, the edge server first determines a health risk score, which indicates that the target pet is likely to have a safety risk, such as having a disease. Then, it determines the target disease of the target pet. This can ensure the effectiveness and reliability of determining the target disease, and can also avoid the drawbacks such as the waste of resources caused by determining the corresponding disease when the target pet is in a healthy state.

[0133] It is worth noting that this manual does not limit the method by which the cloud server obtains the target pet's basic information, historical claims information, and hardware sensing information. For example, the cloud server can obtain the aforementioned information through over-the-air (OTA) downloads.

[0134] S407: The cloud server determines the target disease classification and diagnosis code corresponding to the target disease from the pre-built target knowledge graph, and determines and pushes the target health intervention plan corresponding to the target disease to the owner of the target pet based on the target disease classification and diagnosis code.

[0135] Among them, the target knowledge graph is used to represent the correspondence between diseases and disease classification and diagnosis codes, as well as between disease classification and diagnosis codes and health intervention programs.

[0136] Disease classification and diagnostic coding can be understood as coding that distinguishes different diseases. For example, disease classification and diagnostic coding can be ICD-Vet coding.

[0137] in, Figure 5 This example demonstrates a portion of the target knowledge graph. For instance... Figure 5As shown, the target knowledge graph includes multiple nodes: node 1, node 2, and node 3. Node 1 represents disease entities, such as the disease "canine osteoarthritis"; node 2 represents ICD-Vet encoded entities, such as the ICD-Vet code "ICD-VET M18.0"; node 3 represents health intervention entity, such as the health intervention corresponding to "ICD-VET M18.0" in node 3: "Diet: supplement with glucosamine, control weight; Exercise: aquatic rehabilitation training, avoid strenuous activity; Environment: keep the indoor temperature warm and humid (e.g., temperature 22–25°C, humidity 40–60%)".

[0138] Accordingly, if the edge server determines that the target disease of the target pet, a golden retriever A, is canine osteoarthritis, then the edge server can query the target knowledge graph to determine that the disease classification diagnosis code corresponding to "canine osteoarthritis" is "ICD-VET M18.0". Based on this, the edge server can further query the target knowledge graph to determine that the health intervention plan corresponding to "ICD-VET M18.0" is "Diet: supplement with glucosamine, control weight; Exercise: water rehabilitation training, avoid strenuous activity; Environment: keep the indoor temperature warm and humid (e.g., temperature 22–25°C, humidity 40–60%)", then the edge server can identify this health intervention plan as the target health intervention plan.

[0139] Correspondingly, the edge server can push the target health intervention plan to the owner of the target pet. For example, combining the above analysis and Figure 1 Edge servers can send target health intervention plans to the terminal devices (such as mobile phones) of the target pet's owner.

[0140] Alternatively, the edge server can also send the target health intervention plan to another edge server. The edge server can execute at least part of the target health intervention plan. Or, the edge server can also generate intervention instructions that can be executed or controlled by the edge server, and the edge server can execute the intervention operation corresponding to the intervention instructions.

[0141] For example, the target pet's enclosure may be equipped with temperature and humidity regulators. The edge server can adjust the temperature and humidity of the enclosure based on the environmental information (or corresponding intervention instructions) in the target health intervention plan. Similarly, if the target pet's enclosure has a feeding system, the edge server can adjust aspects such as food type and quantity based on the diet information (or corresponding intervention instructions) in the target health intervention plan. Furthermore, if the target pet's enclosure has a pet-entertainment system, the edge server can adjust and run appropriate pet-entertainment methods (such as letting the target pet play with a ball) based on the exercise information (or corresponding intervention instructions) in the target health intervention plan.

[0142] In some embodiments, a cloud server or other system may pre-build the target knowledge graph. For example, using a cloud server, building the target knowledge graph may include the following steps 11 to 13: Step 11: Obtain the historical data corresponding to each pet. The historical data of any pet includes the pet's basic information and historical claims information.

[0143] For example, in this embodiment, the cloud server can obtain a relatively large and comprehensive sample data to construct a target knowledge graph based on this sample data. The sample data can be understood as the historical relevant data corresponding to each pet.

[0144] For example, a cloud server can access historical data for each of 100,000 existing pets. For any single pet among these 100,000, the historical data includes its basic information and historical claims information. For an understanding of basic information and historical claims information, please refer to the example above; it will not be repeated here.

[0145] Step 12: Construct a disease risk matrix based on historical data. The disease risk matrix is ​​a data structure used to quantify the probability of different pets getting sick under preset dimensions. The preset dimensions include at least breed, age, and season.

[0146] A disease risk matrix can be understood as a multidimensional data structure, such as a table or tensor. It can be used to quantify the probability of a certain type of pet developing a certain disease under a preset combination of dimensions. For example: "A Golden Retriever at age 5 has a 23% probability of developing hip dysplasia in winter."

[0147] Preset dimensions can include at least three types: breed (e.g., genetic susceptibility, such as French Bulldogs' tendency to have breathing problems), age (life cycle stage, such as juvenile / adult / old age), and season (climate influence, such as high incidence of joint diseases in winter and high incidence of allergies in spring). Other preset dimensions can include factors such as region, weight, and sex. This manual primarily uses breed, age, and season as examples.

[0148] Continuing with the example above, in this step, the cloud server can process the historical data of each of the 100,000 pets based on statistical methods to construct a three-dimensional tensor or cross-tabulation (i.e., a disease risk matrix) that at least considers the disease incidence rates corresponding to the three dimensions of breed, age, and season.

[0149] Step 13: Determine the correspondence between diseases and health intervention programs based on the disease risk matrix to obtain the target knowledge graph.

[0150] Continuing with the above analysis, we can see that the disease risk matrix can characterize the probability that a certain breed may contract a certain disease at a certain age and in a certain season. In other words, the disease risk matrix includes various types of diseases.

[0151] Based on this, cloud servers can construct target knowledge graphs that represent the correspondence between diseases and health intervention programs.

[0152] Based on the analysis of steps 11 to 13 above, in this embodiment, the cloud server constructs a disease risk matrix to build a target knowledge graph. The construction of the disease risk matrix considers not only the pet's basic information and historical claims data, but also dimensions such as breed, age, and season, including potential diseases the same pet may suffer from in different seasons. Therefore, the construction of the target knowledge graph can be refined, resulting in higher accuracy and improving the accuracy and reliability of determining corresponding health intervention plans based on the target knowledge graph. Furthermore, since the disease risk matrix is ​​determined based on historical claims data, and the target knowledge graph is determined based on the disease risk matrix, this embodiment can effectively feed historical claims data back into pet health management (such as health interventions), thereby improving the accuracy and reliability of pet health management.

[0153] In some embodiments, step 13 may include the following sub-steps 11 to 13: Sub-step 11: Extract a list of diseases based on the disease risk matrix.

[0154] Building upon the above analysis, the disease risk matrix can be used to quantify the probability of a certain type of pet contracting a certain disease under a preset combination of dimensions. Therefore, the cloud server can extract diseases with relatively high probabilities (e.g., through thresholding, which is not limited in this embodiment) to form a disease list. In other words, the disease list includes multiple diseases, and each disease incorporates factors such as breed, age, and season.

[0155] Sub-step 12: Construct the correspondence between each disease in the disease column and the disease classification diagnosis code to obtain the initial knowledge graph.

[0156] In other words, after extracting the disease list based on the risk matrix, the cloud server can construct an initial knowledge graph representing the correspondence between each disease in the disease list and its disease classification and diagnostic codes. That is, the initial knowledge graph includes the correspondence between diseases and their disease classification and diagnostic codes.

[0157] In other embodiments, the initial knowledge graph may already include entity nodes representing disease classification and diagnosis codes, as well as entity nodes representing some existing diseases and the edges between them and the entity nodes representing disease classification and diagnosis codes. After extracting the disease list, the cloud server can optimize the aforementioned initial knowledge graph to obtain an initial knowledge graph that more completely and comprehensively represents the correspondence between diseases and disease classification and diagnosis codes. That is, in this embodiment, it can be understood as an update and improvement operation on the initial knowledge graph.

[0158] Sub-step 13: Obtain the medical knowledge corresponding to the disease classification diagnostic code, and construct the correspondence between diseases and health intervention programs in the initial knowledge graph based on the medical knowledge to obtain the target knowledge graph.

[0159] Medical knowledge can include medical clinical guidelines, genetic information of breeds, and other knowledge.

[0160] For example, for each disease classification diagnostic code, such as ICD-VET M18.0, the cloud server can obtain the medical knowledge corresponding to ICD-VET M18.0 using other knowledge graphs or retrieval methods. Based on this medical knowledge, it constructs health intervention plan entity nodes in the initial knowledge graph and establishes edges between ICD-VET M18.0 and these entity nodes. This process continues until a target knowledge graph representing the health intervention plan corresponding to each disease classification diagnostic code is constructed.

[0161] In some embodiments, knowledge such as medical clinical guidelines and variety genetic information can also be entity nodes in the target knowledge graph, and the target knowledge graph includes edges representing the association between disease classification diagnostic codes and knowledge such as medical clinical guidelines and variety genetic information.

[0162] Based on the analysis of sub-steps 11 to 13 above, it is clear that in this embodiment, by extracting a disease list based on a disease risk matrix, the disease list can include as many possible diseases as possible. Correspondingly, by constructing a target knowledge graph based on this, the target knowledge graph can achieve a high degree of granularity. This allows for the effective and reliable determination of corresponding health intervention plans for specific diseases. Furthermore, it improves the effectiveness and reliability of applying different health intervention plans to different pets of different breeds, ages, seasons, and regions based on their health status.

[0163] S408: The cloud server obtains the target pet's health index over multiple consecutive time periods and adjusts the target pet's insurance premium based on the health index.

[0164] The health index for any given time period is determined based on relevant pet information for that specific time period. Each time period corresponds to a health index, and the health index for any given time period represents a quantified value of the probability of the target pet experiencing an incident during that time period.

[0165] The health index can be understood as a value used to quantify the overall health status of a target pet within a certain period of time. Relatively speaking, the higher the health index value, the better the health status and the lower the probability of danger.

[0166] For an understanding of pet-related information, please refer to the description of target-related information. For example, target pet-related information might include the target pet's basic information, historical claims information, and hardware sensing information at the current moment. Pet-related information refers to a target pet's basic information, historical claims information, and hardware sensing information over a specific time period, which might be one month or one quarter, etc.

[0167] Therefore, relative to the target-related information, the basic information may change over a certain period of time, such as the age of the target pet may change; the historical claims information may also change over a certain period of time, such as the generation of new claims data corresponding to the target pet during that period; the hardware perception information may also change over a certain period of time, such as the hardware perception information of a certain period of time including all hardware perception information within multiple months.

[0168] For example, the cloud server can obtain the target pet's health index for each of the three consecutive months, resulting in three health indices. The cloud server then adjusts the target pet's insurance premium based on these three health indices.

[0169] For example, the cloud server can obtain pet-related information for the target pet in September, such as the basic information, historical claims information, and hardware perception information of Golden Retriever A in September, and determine the health index for September based on the pet-related information in September (for ease of distinction, this health index is called the first health index).

[0170] The cloud server can obtain pet-related information for the target pet in October, such as the basic information, historical claims information, and hardware perception information of Golden Retriever A in October, and determine the health index for October based on the pet-related information in October (similarly, this health index is called the second health index).

[0171] The cloud server can obtain pet-related information for the target pet in November, such as the basic information, historical claims information, and hardware perception information of Golden Retriever A in November, and determine the health index for November based on the pet-related information in November (similarly, this health index is called the third health index).

[0172] Correspondingly, the cloud server can adjust the insurance premium for the target pet based on the first health index, the second health index, and the third health index.

[0173] For example, the adjusted floating rate = base premium * (1 - α × health score). Wherein, the base premium is the premium before the adjustment, α is a preset coefficient, and the health score can be the average score of various health indices.

[0174] Similarly, the preset coefficient α can be determined by the cloud server based on demand, historical records, experiments, etc., and this embodiment does not limit it.

[0175] Similarly, this instruction manual does not limit the method for determining health indices.

[0176] For example, a cloud server can determine health indices based on a network model. The specific implementation principle can be found in the description of the disease prediction network model in the example above, and will not be repeated here.

[0177] Furthermore, the above example primarily illustrates how a cloud server determines a health index based on pet-related information within a specific time period. However, in other embodiments, the cloud server can also determine the corresponding health index based on hardware-sensing information within the same time period.

[0178] In some other embodiments, the cloud server can also determine the corresponding health index by combining the implementation status of the health intervention plan for the corresponding time period.

[0179] For example, taking the determination of a target pet's primary health index for September by a cloud server: The cloud server can obtain the target pet's relevant information for September and determine the corresponding health index based on this information. The cloud server can also determine the implementation status of the health intervention plan in September. If it was not fully implemented, the cloud server can add a corresponding value to the health index to obtain the target pet's primary health index for September. The cloud server can store the mapping relationship between the implementation status (e.g., implementation percentage) and the added value.

[0180] Furthermore, based on the above analysis, it is clear that pets are in a healthier state when a health intervention program is implemented. Therefore, the higher the percentage implemented, the greater the corresponding increase in value. Conversely, if no health intervention program is implemented, the health index can be determined based on pet-related information, as shown in the example above.

[0181] In other words, when determining the health index for a specific time period, it can be determined by considering the implementation status of the health intervention plan for that period. Relatively speaking, the higher the implementation rate of the health intervention plan during that time period, the higher the corresponding health index; conversely, the lower the implementation rate of the health intervention plan during that time period, the lower the corresponding health index.

[0182] In related technologies, insurance premiums are relatively fixed, either adjusted after a claim is made or after the claim period. In this embodiment, the cloud server adjusts the premium by combining multiple health indices over multiple consecutive time periods, enabling dynamic adjustment of the premium and thus improving its flexibility and diversity.

[0183] Furthermore, based on the above analysis, it can be seen that in an emergency, the edge server can issue alarm information and send hardware awareness information to the cloud server, or it can choose not to issue alarm information to the edge server.

[0184] If the edge server sends hardware awareness information to the cloud server, the cloud server can determine whether to adjust the premium based on the above method.

[0185] If the edge server does not send hardware awareness information to the cloud server, the cloud server can determine, based on multiple consecutive time periods, that no premium adjustment is needed. Continuing with the example above, if Golden Retriever A's health status in September includes an emergency state, the cloud server can determine that Golden Retriever A's premium does not need to be adjusted, or it can determine that Golden Retriever A's premium needs to be increased.

[0186] In some embodiments, the cloud server adjusts the premium for the target pet based on various health indices, which may include: if all health indices reach a preset second threshold, then the premium for the target pet is reduced.

[0187] Similarly, this embodiment does not limit the size of the preset second threshold, which can be determined by the processing system based on requirements, historical records, experiments, etc.

[0188] In contrast, if a certain health index is greater than or equal to a preset second threshold, it means that the target pet is in good health during the time period corresponding to that health index, that is, the target pet is in a relatively healthy state.

[0189] Continuing with the above example, if the first health index, the second health index, and the third health index are all greater than or equal to the preset second threshold, it means that the target pet has been in a relatively healthy state for three consecutive months, and the processing system can reduce the premium for the target pet.

[0190] In this embodiment, if the target pet is in good health for multiple consecutive time periods, the cloud server can adjust the insurance premium for the target pet to achieve dynamic adjustment of the premium, thereby enabling flexibility and diversity in premium determination.

[0191] Furthermore, based on the analysis of S401 to S408 above, it can be seen that the data processing system may include edge servers and cloud servers to achieve collaborative operation between them. It is worth noting that the above examples are merely illustrative of possible collaborative methods between edge servers and cloud servers and should not be construed as limiting the collaborative methods. For example, in other embodiments, the edge server and cloud server may perform more or fewer operations.

[0192] Moreover, based on the above analysis, it can be seen that in this embodiment, through the collaborative operation of edge servers and cloud servers, a closed loop of "intelligent devices (such as multimodal hardware sensing devices) - health intervention (such as pre-intervention of the health status of pets) - insurance pricing (such as dynamically adjusting pet insurance premiums)" can be realized.

[0193] Furthermore, based on the above analysis, this specification may involve the training of network models, and this specification does not limit the selection and training of network models. In some embodiments, the network model may be a large language model. In this specification, a large language model (LLM) can also be simply referred to as a large model. A large language model is a natural language processing model based on deep learning technology, typically with billions to hundreds of billions or even more parameters, possessing powerful language understanding and generation capabilities. Large language models can employ the Transformer architecture or its variants (such as GPT, BERT, etc.), which utilizes an attention mechanism to achieve global modeling of sequential data, efficiently handling long-distance dependencies, thus performing excellently in natural language tasks. Large language models learn the statistical features and semantic relationships of language through pre-training on large-scale corpora, giving them outstanding generalization capabilities. The core capabilities of large language models include, but are not limited to: understanding contextual semantics, generating coherent and grammatically correct text, performing logical reasoning, and handling multi-task scenarios. Its usage typically includes two modes: direct inference and fine-tuning. In direct reasoning mode, users guide the large language model to generate specific outputs by designing prompts. Prompts can be task descriptions or instructions in text form, used to stimulate the large language model's semantic understanding and generation capabilities. In fine-tuning mode, the large language model is further trained on small-scale datasets within a specific domain to optimize its performance on specific tasks. The powerful generalization ability and flexibility of large language models make them an important tool in the field of artificial intelligence, providing efficient and accurate solutions for automated text generation and understanding.

[0194] In some embodiments, large language models can also understand and generate data from other modalities (such as visual and audio data). In this case, large language models can also be called multimodal large language models (MLLMs). MLLMs provide a richer and more natural interactive experience by integrating multiple types of input and output, such as text, images, and sound. The core advantage of MLLMs lies in their ability to process and understand information from different modalities and fuse this information to complete complex tasks. For example, MLLMs can analyze an image and generate descriptive text, or generate a corresponding image based on a text description. This cross-modal understanding and generation capability makes MLLMs widely applicable across multiple fields.

[0195] It should be noted that the key technologies of large language models can be found in the detailed description in the paper "A Survey of Large Language Models" (paper number: arXiv:2303.18223v16, published on March 11, 2025, public link: https: / / doi.org / 10.48550 / arXiv.2303.18223), and will not be repeated here.

[0196] It is worth noting that the above examples are merely illustrative of possible implementations of the processing method described in this specification, and should not be construed as limiting the implementation of the processing method described in this specification. For example, based on the above technical concept, some of the technical features described above can be combined to obtain new embodiments; new technical features can be added to the above examples to obtain new embodiments; some technical features can be removed from the above examples to obtain new embodiments; some technical features in the above examples can be replaced with other technical features; some technical features and their order in the above examples can be adjusted to obtain new embodiments, and so on, which will not be listed here.

[0197] Based on the above-described technical concept, this specification also provides a computer-readable non-transitory storage medium storing at least one instruction set, which, when executed by a processor, implements the steps of the processing method described in this specification.

[0198] In some possible implementations, various aspects of this specification can also be implemented as a program product comprising program code. When the program product is run on the processing system 200, the program code causes the processing system 200 to perform the steps of the processing method described in this specification. The program product for implementing the above method may employ a portable compact disc read-only memory (CD-ROM) containing program code and may run on the processing system 200. However, the program product of this specification is not limited thereto. In this specification, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system. The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. The computer-readable storage medium may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable storage medium may also be any readable medium other than a readable storage medium that can send, propagate, or transmit programs for use by or in connection with an instruction execution system, apparatus, or device. Program code contained on a readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof. Program code for performing the operations described herein can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on processing system 200, partially on processing system 200, as a standalone software package, partially on processing system 200 and partially on a remote processing system, or entirely on remote processing system 200.

[0199] It should be noted that the collection, storage, use, processing, transmission, provision, and disclosure of user and pet-related information (such as region, age, etc.) involved in the technical solution of this specification all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0200] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0201] In summary, after reading this detailed disclosure, those skilled in the art will understand that the foregoing detailed disclosure is presented by way of example only and is not restrictive. Although not explicitly stated herein, those skilled in the art will understand that this specification requires various reasonable changes, improvements, and modifications to the embodiments. These changes, improvements, and modifications are intended to be made by this specification and are within the spirit and scope of the exemplary embodiments described herein.

[0202] Furthermore, certain terms in this specification have been used to describe embodiments of this specification. For example, "an embodiment," "an embodiment," and / or "some embodiments" mean that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment of this specification. Therefore, it is to be emphasized and understood that two or more references to "an embodiment" or "an embodiment" or "alternative embodiment" in various parts of this specification do not necessarily refer to the same embodiment. Moreover, specific features, structures, or characteristics may be suitably combined in one or more embodiments of this specification.

[0203] It should be understood that in the foregoing description of the embodiments in this specification, various features are combined in a single embodiment, drawing, or description for the purpose of simplifying the description and to aid in understanding a feature. However, this does not mean that the combination of these features is necessary, and those skilled in the art, upon reading this specification, may readily identify some of the devices as separate embodiments. That is, the embodiments in this specification can also be understood as an integration of multiple secondary embodiments. And the content of each secondary embodiment is valid even if it contains fewer than all the features of a single foregoing disclosed embodiment.

[0204] Every patent, patent application, publication of a patent application, and other material cited herein, such as articles, books, specifications, publications, documents, and literature (excluding any related historical examination documents), is referenced for all purposes relevant to this document, including in the specification and claims herein. However, in the event of any inconsistency or conflict between the descriptions, definitions, and / or terms used in the foregoing and those used herein, the descriptions, definitions, and / or terms used herein shall prevail.

[0205] Finally, it should be understood that the embodiments disclosed herein are illustrative of the principles of the embodiments described in this specification. Other modified embodiments are also within the scope of this specification. Therefore, the embodiments disclosed in this specification are merely examples and not limitations. Those skilled in the art can implement the applications described in this specification using alternative configurations based on the embodiments in this specification. Therefore, the embodiments in this specification are not limited to the embodiments precisely described in the applications.

Claims

1. A pet data processing method, comprising: obtaining target related information of a target pet, wherein the target related information comprises basic information, historical claim information, and hardware sensing information of the target pet, the hardware sensing information being collected by a hardware sensing device based on an environment in which the target pet is located; determining a target disease of the target pet according to the target related information; and determining, according to a target knowledge graph constructed in advance, and pushing, to an owner of the target pet, a target health intervention scheme corresponding to the target disease, wherein the target knowledge graph is used to represent a corresponding relationship between diseases and health intervention schemes.

2. The method of claim 1, wherein, The method further comprises: obtaining historical related data corresponding to each pet, wherein the historical related data of any pet comprises basic information and historical claim information of the any pet; constructing a disease risk matrix according to the historical related data, wherein the disease risk matrix is a data structure for quantifying disease probabilities of different pets in a preset dimension, and the preset dimension at least comprises breed, age, and season; and determining the corresponding relationship between diseases and health intervention schemes according to the disease risk matrix to obtain the target knowledge graph.

3. The method of claim 2, wherein, Determining the corresponding relationship between diseases and health intervention schemes according to the disease risk matrix to obtain the target knowledge graph comprises: extracting a disease list based on the disease risk matrix; constructing a corresponding relationship between each disease in the disease list and a disease classification diagnosis code to obtain an initial knowledge graph; and obtaining medical knowledge corresponding to the disease classification diagnosis code, and constructing a corresponding relationship between diseases and health intervention schemes in the initial knowledge graph according to the medical knowledge to obtain the target knowledge graph.

4. The method of claim 1, wherein, The method further comprises: determining a health risk score of the target pet according to the target related information; and determining the target disease of the target pet according to the target related information comprises: if the health risk score reaches a preset first threshold, determining the target disease according to the target related information.

5. The method of claim 1, wherein, Determining, according to a target knowledge graph constructed in advance, and pushing, to an owner of the target pet, a target health intervention scheme corresponding to the target disease, comprises: determining, from the target knowledge graph, a target disease classification diagnosis code corresponding to the target disease; and determining, from the target knowledge graph, and pushing, to the owner, the target health intervention scheme corresponding to the target disease according to the target disease classification diagnosis code; wherein the target knowledge graph is used to represent corresponding relationships between diseases and disease classification diagnosis codes, and between disease classification diagnosis codes and health intervention schemes.

6. The method of claim 1, wherein, The method further comprises: obtaining health indexes of the target pet in a plurality of continuous time periods, wherein one time period corresponds to one health index, a health index of any time period represents a quantized value of a risk probability of the target pet in the any time period, and the health index of the any time period is determined based on pet related information of the target pet in the any time period; and Adjust the premium of the target pet according to the health indexes.

7. The method of claim 6, wherein, Adjust the premium of the target pet according to the health indexes, comprising: If the health indexes all reach a preset second threshold, the premium of the target pet is adjusted.

8. The method of claim 1, wherein, The target disease is determined under a preset first condition. The first preset condition comprises: determining that the health state of the target pet is a non-emergency state according to the hardware sensing information.

9. The method of claim 8, wherein, The method further comprises: In response to the health state of the target pet being an emergency state, generating and outputting alarm information.

10. The method of claim 9, wherein, The method is applied to a processing system, the processing system comprising a cloud server and an edge server, the edge server being a local server in communication connection with a hardware sensing device corresponding to the hardware sensing information; The hardware sensing information is sent by the edge server to the cloud server when the edge server determines that the health state of the target pet is a non-emergency state; and / or The alarm information is generated and outputted by the edge server.

11. The method of claim 1, wherein, The hardware sensing information comprises at least one of: Respiratory information collected based on a millimeter wave radar; Video stream information obtained based on an infrared video stream acquisition device; Voiceprint information detected based on a voiceprint device.

12. The method of claim 11, wherein, The infrared video stream acquisition device is an anti-glare camera device; The camera device comprises an ultraviolet auxiliary light source, and / or the imaging principle of the camera device comprises polarization imaging.

13. A pet data processing system, comprising: at least one storage medium storing at least one instruction set for processing pet data; at least one processor in communication connection with the at least one storage medium, wherein the at least one processor reads the at least one instruction set when running, and executes the method according to any one of claims 1 to 12 according to the instruction of the at least one instruction set.

Images