CN114219527A

CN114219527A - Method, device, medium, program product and electronic equipment for generating insurance document

Info

Publication number: CN114219527A
Application number: CN202111502340.0A
Authority: CN
Inventors: 施瑜; 蔡纯钢; 王嘉杰; 吴秀群; 韩忠俊; 莫元武
Original assignee: eBaoTech Corp
Current assignee: eBaoTech Corp
Priority date: 2021-12-09
Filing date: 2021-12-09
Publication date: 2022-03-22
Also published as: WO2023103725A1

Abstract

The application relates to a method, a device, a medium, a program product and an electronic device for generating an insurance document. The method comprises the following steps: receiving a generation request of an insurance document; determining a target field required for calculating the premium of the insurance document; calculating a premium based on the target field, and carrying out distinguishing signature on the target field and the premium to obtain a signature result; and generating an insurance document, and associating the signature result with the insurance document, wherein the signature result is used for verifying the insurance document in a set business link. According to the technical scheme, the safety performance of the insurance business system is improved in the generation process of the insurance document, the situation that the insurance fee is recalculated under the condition that the insurance fee is not required to be recalculated can be avoided, and the problem that the insurance fee is inaccurate after the insurance fee in the same insurance policy is recalculated due to different interest rates of nodes at different time can be solved.

Description

Method, device, medium, program product and electronic equipment for generating insurance document

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, a medium, a program product, and an electronic device for generating an insurance document.

Background

Currently, as users become increasingly aware of the importance of insurance as their security awareness increases, more and more users are engaged in insurance purchasing lines. During the application process, the insurance company enters the user's policy information, such as applicant information, insured life information, insurance terms, insurance type, amount of insurance, premium, and the like. In some cases, for example, the insurance company system has a security hole, the policy information of the user may be maliciously tampered, thereby possibly causing loss to the insurance company.

Disclosure of Invention

In view of the above, the present application relates to a method, an apparatus, a medium, a program product, and an electronic device for generating an insurance document. According to the technical scheme, the target field and the premium of the insurance document are distinguished and signed in a business setting link, so that whether the safety risk exists can be judged quickly. And under the condition that the risk is confirmed, the risk level can be quickly determined, and corresponding operations such as alarming and the like are executed. The method and the system not only improve the safety performance of the insurance service system, but also can avoid the problem that the premium amount is inaccurate after the premium in the same insurance policy is recalculated due to different interest rates of nodes at different time under the condition that the premium is not required to be recalculated.

In a first aspect, an embodiment of the present application provides a method for generating an insurance document, including: receiving a generation request of an insurance document; determining a target field required for calculating the premium of the insurance document; calculating a premium based on the target field, and carrying out distinguishing signature on the target field and the premium to obtain a signature result; and generating an insurance document, and associating the signature result with the insurance document, wherein the signature result is used for verifying the insurance document in a set business link.

In a possible implementation of the first aspect, the method further includes: determining target fields required to calculate a premium for an insurance document, including:

determining the type of insurance products carried in the insurance document generation request;

and determining a target field required for calculating the premium of the insurance document according to the corresponding relation between the preset insurance product type and the target field.

The insurance documents can be electronic documents of various insurance services related in an insurance service scene, such as insurance documents, batch documents and other electronic documents.

In a possible implementation of the first aspect, the method further includes: distinguishing and signing the target field and the insurance fee to obtain a signature result, wherein the signature result comprises the following steps:

arranging the target fields according to a first arrangement rule to obtain a first character string;

signing the first character string by using a first signature algorithm to obtain a first signature result;

arranging the first signature result and the premium according to a second arrangement rule to obtain a second character string;

signing the second character string by using a second signature algorithm to obtain a second signature result;

the first signature result and the second signature result are stored.

In a possible implementation of the first aspect, the method further includes: the insurance document is verified by using the signature result in the following modes:

under the condition that the current set business link is determined, signing the character string obtained by arranging the target field according to the first arrangement rule by using a first signature algorithm to obtain a first verification result; and is

Signing the first verification result and the character string obtained by arranging the premium according to a second arrangement rule by using a second signature algorithm to obtain a second verification result;

and obtaining a verification result of the insurance document in a set service link based on the first verification result, the stored first signature result, the second verification result and the stored second signature result.

In a possible implementation of the first aspect, the method further includes: and determining the existing safety risk according to the verification result, and executing the operation corresponding to the safety risk.

In a possible implementation of the first aspect, the method further includes: determining a risk level according to the verification result, and executing corresponding risk response according to the risk level, wherein the risk response comprises the following steps:

under the condition that the first verification result and the first signature result are different, determining that a first risk exists, and recalculating the premium according to the determined first risk;

determining that a second risk exists under the condition that the second verification result and the second signature result are different, and generating alarm information according to the determined second risk;

wherein the risk rating of the second risk is higher than the risk rating of the first risk.

In a possible implementation of the first aspect, the method further includes: the first signature algorithm and/or the second signature algorithm comprises: HMAC-SHA256 algorithm.

In a possible implementation of the first aspect, the method further includes: calculating a premium based on the target field, including:

determining a calculation rule of premium in the insurance document;

and calculating the premium based on the target field according to a calculation rule.

In a possible implementation of the first aspect, the method further includes: the setting business link comprises at least one of a submitting link and an auditing link of the insurance document.

In a possible implementation of the first aspect, the method further includes: the insurance document comprises at least one of an enquiry, a policy and a batch.

In a second aspect, an embodiment of the present application provides an apparatus for generating an insurance document, including:

the receiving module is used for receiving a generation request of the insurance document;

the determining module is used for determining a target field required for calculating the premium of the insurance document;

the signature module is used for calculating the premium based on the target field and distinguishing and signing the target field and the premium to obtain a signature result;

and the generation module is used for generating the insurance document, associating the signature result with the insurance document, and verifying the signature result in the set business link of the insurance document.

In a third aspect, an embodiment of the present application provides a computer-readable storage medium, where instructions are stored on the computer-readable storage medium, and when the instructions are executed on an electronic device, the instructions cause the electronic device to perform the method for generating an insurance document according to any one of the first aspect and various possible implementations of the first aspect.

In a fourth aspect, an embodiment of the present application provides a chip apparatus, including:

a communication interface for inputting and/or outputting information;

and a processor configured to execute a computer-executable program to enable an electronic device in which the chip apparatus is installed to execute the method for generating an insurance document according to the first aspect and any one of various possible implementations of the first aspect.

In a fifth aspect, the present application provides a computer program product, where the computer program product includes instructions that, when executed, perform the method for generating an insurance document according to any one of the first aspect and various possible implementations of the first aspect.

In a sixth aspect, an embodiment of the present application provides an electronic device, including:

a memory for storing instructions for execution by one or more processors of the electronic device, an

A processor configured to execute the instructions stored in the memory when the instructions are executed by one or more processors of the electronic device, the instructions when executed performing the method of generating an insurance document according to the first aspect and any one of the various possible implementations of the first aspect.

Drawings

FIG. 1 illustrates an insurance business scenario diagram, according to some embodiments of the present application;

FIG. 2 illustrates an interactive flow diagram of insurance document generation, according to some embodiments of the present application;

FIG. 3 illustrates a graphical user interface diagram during generation of an insurance document, according to some embodiments of the present application;

FIG. 4 illustrates a flow diagram of a method of insurance document generation, according to some embodiments of the present application;

FIG. 5 illustrates a diagram of a method of obtaining a signature result or a verification result using a signature algorithm, according to some embodiments of the present application;

FIG. 6 illustrates a block diagram of an insurance document generation apparatus 600, according to some embodiments of the present application;

fig. 7 illustrates a schematic diagram of a server 200, according to some embodiments of the present application.

Detailed Description

Illustrative embodiments of the present application include, but are not limited to, a method, medium, program product, and electronic device for generating an insurance document.

In order to make the objects, technical solutions and advantages of the present application clearer, the technical solutions of the embodiments of the present application are described in further detail below by combining the drawings and the embodiments. It is to be understood that the embodiments described are only some embodiments of the invention, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The technical solutions of the embodiments of the present application are described in detail below with reference to the accompanying drawings.

Fig. 1 illustrates an insurance business scenario to which the technical solution of the present application is applied, according to some embodiments of the present application. As shown in fig. 1, it includes an applicant, a business person of an insurance company, a user terminal 100 used by the applicant, a business terminal 300 used by the business person of the insurance company, a server 200 of the insurance company, and a database 400.

The user terminal 100 and the service terminal 300 may be connected to the server 200 through a network to perform data transmission. For example, the user terminal 100 and the service terminal 300 may communicate with the server 200 through a Wireless Fidelity (Wi-Fi) network, a bluetooth (bluetooth) Wireless network, or the like. The user terminal 100 may be installed with client software of an insurance company, such as an insurance Application (APP), and an applicant may purchase an insurance product required by the applicant through the APP installed in the user terminal 100, such as filling in an insurance document and paying a premium through the user terminal 100. The server 200 may be used to calculate the premium in insurance documents filled by the applicant, to verify insurance document documents submitted by the user terminal 100, etc. The service terminal 300 is used for displaying insurance documents, such as an inquiry document, a policy, a batch document and the like, filled by the applicant through the user terminal 100, so that the service personnel of the insurance company can check the insurance documents filled by the applicant. The database 400 may store policy models corresponding to various risk categories of the insurance company, such as policy models corresponding to various risk categories of people's life risk, severe disease risk, medical risk, accident risk, and endowment risk.

In some embodiments, the server 200, after receiving the insurance document submitted by the applicant through the user terminal 100, only performs validity check on the insurance document itself, for example, checks whether the insurance seed, applicant, insurance time, insured, premium, insurance period (including insurance start time and insurance end time), premium, etc. of the insurance document are legal. For example, checking whether the amount of the insurance in the dangerous case purchased by the user, the insurance period, etc. match. The insurance amount refers to the highest limit amount of the insurance contract made by the applicant and the insurance company, wherein the insurance company can undertake the responsibility of compensating or paying insurance money, namely the amount of money given to the applicant or the insured life by the insurance company in the process of settlement. The premium is the fee that the insurer needs to pay to the insurance company according to the agreement of the insurance contract in order to obtain insurance guarantee.

However, in some cases, in the process of insuring by the user, the insurance document filled by the user may be attacked by the network, and some fields in the insurance document are maliciously tampered, so that the insurance company may be damaged. For example, a premium in an insurance document is tampered from a higher amount to a lower amount, thereby causing economic loss to the insurer.

For this reason, in some embodiments of the present application, after receiving a request for generating an insurance document, the server 200 first determines a target field related to premium calculation in the insurance document, then calculates a premium in the insurance document based on the determined target field, and discriminates and signs the target field and the premium of the insurance document to obtain a signature result. And after generating the insurance document, associating the signature result with the insurance document, wherein the signature result is used for verifying the insurance document in a set business link. In addition, the distinguishing signature can mean that after the target field of the insurance document is signed, the signature result of the target field and the premium are signed as a whole. By distinguishing and signing the target field and the premium, whether the target field and the premium are changed or not can be quickly determined when the target field and the premium are verified in some verification links, so that the risk level is quickly determined, and corresponding operations such as alarming and the like are executed.

For convenience of understanding the technical solution of the present application, the method for generating an insurance document provided by the present application will be briefly described below by taking the generation of an insurance policy related to the first insurance application of a user as an example. For example, in some embodiments, upon receiving the policy submitted by the applicant via the user terminal 100 during the inquiry phase (possibly, the user fills only the information related to the premium calculation in the policy), the server 200 may form a string of fields related to the premium calculation (hereinafter referred to as premium calculation factors), such as the insurance limit, the insurance seed, the insurance amount, etc., in the policy according to the set arrangement rules, and then sign the string of characters via a set signature algorithm, such as the HMAC-SHA256 algorithm. After calculating the premium by using the premium calculation factor, the signature result and the premium of the premium calculation factor are formed into a character string according to a set arrangement rule, and the character string is signed by using a set signature algorithm. And stores the signature results locally at the server 200, or in the database 400.

After the user completes the filling of other information in the policy, and submits the policy to the server 200, the server 200 verifies the premium and the premium calculation factor in the policy, which is submitted again by the user through the user terminal 100. And if the verification is passed, the insurance policy is sent to the service terminal 300 for the service personnel to verify, and then the insurance fee and the insurance fee calculation factor in the verified insurance policy returned by the service terminal 300 are verified. And if the verification is passed, and the insurance policy takes effect after the user pays the insurance fee. If the verification is not passed, judging the risk level according to the verification result, and carrying out corresponding processing according to the determined risk level, such as alarming or recalculating the premium.

For example, in some cases, when the service personnel audits the policy submitted by the user through the service terminal 300, some fields in the policy are mistakenly changed due to misoperation of the service personnel, and in order to enable the service personnel of the insurance company to timely find that the policy data is mistakenly changed due to self misoperation, the server 200 may generate a prompt message to prompt the service personnel of misoperation. For another example, in some cases, when the service personnel submits the checked policy data through the service terminal 300, a network security attack exists, which causes the policy data submitted to the server 200 by the service terminal 300 to be tampered, so that the service personnel can timely find an illegal network attack, and the server 200 can generate alarm information to notify the service personnel to timely isolate the network attack.

Therefore, according to the technical scheme, only the premium calculation factor and the premium field related to the premium calculation need to be checked, and whether risks exist can be quickly judged. And under the condition that the risk is confirmed, the risk level can be quickly determined, and corresponding operations such as alarming and the like are executed. The method and the system not only improve the safety performance of the insurance service system, but also can avoid the problem that the premium amount is inaccurate after the premium in the same insurance policy is recalculated due to different interest rates of nodes at different time under the condition that the premium is not required to be recalculated.

It should be noted that the user terminal 100 in the application scenario shown in fig. 1 may be any electronic device that can be installed in a client of an insurance company and has a display screen. Also, the service terminal 300 may be any electronic device to which a service terminal of an insurance company can be installed and which has a display screen. The user terminal 100 and the service terminal 300 include, but are not limited to, one of a mobile phone, a tablet computer, a smart screen, a wearable device (e.g., a watch, a bracelet, a helmet, a headset, etc.), an in-vehicle device, an Augmented Reality (AR)/Virtual Reality (VR) device, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a Personal Digital Assistant (PDA), and other electronic devices. The server 200 may be a single server or a server cluster including a plurality of servers.

Further, it is understood that the insurance categories of different insurance companies may differ, and the same insurance company typically includes multiple insurance categories. Thus, for the same insurance company, when an applicant purchases different insurance products and creates different policies, the premium calculation factors involved in the respective policies may differ. Premium calculation factors may be determined based on different insurance categories.

For facilitating understanding of the technical solution of the embodiment of the present application, in the following, taking as an example that in the scenario shown in fig. 1, an insurance applicant purchases an insurance product through a User terminal 100, and a service person of an insurance company reviews a policy created by a User through a service terminal 300, the whole process of generating the policy through the applied technical solution is described in detail with reference to various Graphical User interfaces (GUI for short) shown in fig. 3A to 3D. Specifically, the interaction flow chart shown in fig. 2 includes the following steps:

s201: the user terminal 100 sends an application request to the server 200.

In some embodiments, the user terminal 100 sends an application request to the server 200 in response to an operation by the user. Wherein the application request includes information that can characterize the insurance product type.

Illustratively, after the user opens the insurance APP, and clicks a button link on the interface of the user terminal 100, which can be used to create the insurance policy, the user terminal 100 receives the user's operation to generate an insurance application request, and sends the insurance application request to the server 200.

S202: server 200 sends a get manifest page request to database 400.

In some embodiments, the server 200 sends a request for obtaining the manifest page to the database 400 according to the request information after receiving the application request. Wherein, the menu page comprises the insurance policies to be filled out corresponding to different insurance product types.

Illustratively, the type of the policy page included in the application request is a vehicle insurance type, and the server 200 sends a request for obtaining the vehicle policy page to the database 400 according to the vehicle insurance type included in the application request, so as to obtain a blank vehicle policy corresponding to the vehicle insurance type.

S203: database 400 returns a list page to server 200.

In some embodiments, the database 400 returns the menu page to the server 200 after searching a corresponding menu page from a plurality of pre-stored menu pages according to the menu page request sent by the server 200.

Illustratively, the database 400 returns a vehicle policy page to the server 200 after finding a corresponding vehicle policy page in the database 400 according to a request for obtaining the vehicle policy page sent by the server 200.

S204: the server 200 transmits the ticket page to the user terminal 100.

In some embodiments, after receiving the menu page sent by the database 400, the server 200 sends the menu page to the user terminal 100.

For example, after receiving the vehicle policy sheet page sent by the database 400, the server 200 sends the vehicle policy sheet page to the user terminal 100, so that the user terminal 100 displays the corresponding policy sheet page, thereby facilitating the user to input policy data.

S205: the user terminal 100 transmits the basic insurance elements input by the applicant to the server 200.

In some embodiments, after receiving the entry sheet to be filled out sent by the server 200, the user terminal 100 displays the insurance policy to be filled out on the user terminal 100. When the user inputs the basic application elements in the display interface on the user terminal 100, the user terminal 100 transmits the basic application elements input by the applicant to the server 200. Wherein the basic insurance element is a premium calculation factor used to calculate the premium.

Illustratively, after receiving the vehicle insurance policy page sent by the server 200, the user terminal 100 displays the policy page as shown in fig. 3A, where the basic insurance elements needing user input are denoted by "×" 303A "in fig. 3A. The user enters basic insurance elements on the vehicle policy to be filled, such as target fields of the name of the insurer, the kind of insurance, the term of insurance, the amount of insurance, etc. shown in fig. 3A, and the user can selectively enter some unnecessary fields, such as contact address, home address, etc. When the user input is completed, the basic application element is determined by clicking the determination button 302A. The user terminal 100 transmits data in the vehicle policy to the server 200.

S206: the server 200 calculates the premium and signs the target field and premium.

In some embodiments, the server 200 calculates the premium based on the received base application factors (i.e., premium calculation factors), uses the calculated premium as a target field, and signs the target field and the premium through a signature algorithm.

In some embodiments, after obtaining the premium according to the premium calculation factor, the server 200 signs the character string composed of the premium calculation factor through a signature algorithm to obtain a first signature result, then forms a new character string by combining the first signature result and the premium obtained through the calculation factor, and signs the character string through the same signature algorithm to obtain a second signature result.

For example, after obtaining the vehicle insurance policy with the basic insurance elements filled by the user, the server 200 first determines the premium range of the insurance according to the insurance types in the vehicle insurance policy, for example, if the vehicle insurance types are commercial insurance of the motor vehicle, the basic range of the insurance is obtained according to the commercial insurance of the motor vehicle; and then, narrowing the selectable range of the premium according to the insurance limit filled by the user, for example, different fees are corresponding to the business insurance of the motor vehicle for 1 year or 2 years, and when the insurance limit is 1 year, the selectable range of the premium can be further narrowed according to the insurance amount selected by the user, and finally the premium is determined. And then signing the calculation factor in the policy, for example, firstly signing a character string consisting of a name field of the insurer, a kind of insurable risk and a term of insurance by a signature algorithm to obtain a first signature result, and then signing the first signature result and a character string consisting of a premium field calculated according to the name field of the insurer, the kind of insurable risk and the term of insurance to obtain a second signature result.

It should be noted that the insurance name field, insurance type field and insurance period field included in the premium calculation factor are only an exemplary illustration. In other embodiments, the premium calculation factor may include other fields, which are not limited in this application.

S207: the server 200 returns premium data to the user terminal 100.

Illustratively, the server 200 returns premium data calculated from the premium calculation factor in the vehicle insurance to the user terminal 100.

S208: the user terminal 100 sends the complete policy data entered by the applicant to the server 200.

In some embodiments, after the user terminal 100 receives the premium data sent by the server 200, the user continues to fill in the complete policy data on the policy for which the user terminal 100 displays the premium data. For example, policy data that the user continues to fill may include, but is not limited to, non-critical field information that is not relevant to premium calculations. After the user completes the completion, the ok button is clicked. The user terminal 100 transmits the complete policy data input by the applicant to the server 200 in response to the user's operation.

Illustratively, after receiving the vehicle insurance premium data sent by the server 200, the user terminal 100 obtains a vehicle insurance policy page 301B as shown in fig. 3B, and the user continues to fill in complete insurance policy data, such as specific information of contact, home address, etc., on the vehicle insurance policy to obtain an interface diagram of a vehicle insurance policy page 301C as shown in fig. 3C. After the user clicks the confirmation button 302A, the user terminal 100 detects the user's operation and transmits the complete policy data input by the applicant to the server 200.

S209: the server 200 checks the destination field and the premium.

In some embodiments, after the server 200 receives the complete policy data entered by the applicant sent by the user terminal 100, a first verification result is obtained for the target field in the policy using the same signature method as in step S206 to verify whether the target field in the policy is modified by the user. And then, the obtained first verification result and the premium field form a character string, and the character string is used for obtaining a second verification result in the same signature mode as the second signature result obtained in the step S206, which is not described herein in detail.

Illustratively, upon receiving complete vehicle insurance policy data entered by the applicant from the user terminal 100, the server 200 includes not only basic insurance elements but also non-basic insurance elements. The same signature method as in step S206 is used for the target field in the policy to obtain a first verification result and a second verification result.

S210: the server 200 checks whether the target field and the premium pass the check.

In some embodiments, after obtaining the first verification result and the second verification result, the server 200 compares the first signature result with the first verification result, and compares the second signature result with the second verification result, if the obtained comparison result is that the results are consistent, step S211 is performed, and policy data is sent to the database 400; if the comparison result of the two signature results is inconsistent, it indicates that the target field and the premium check are not passed, and the process proceeds to step S213, where the premium is recalculated and the target field is re-signed.

Illustratively, the server 200 obtains a first verification result and a second verification result of the vehicle insurance policy, compares the first signature result with the first verification result, and compares the second signature result with the second verification result, and if the two comparison results are the same, it indicates that the target field in the vehicle insurance policy is not changed by the user; if one of the two signature results is different, the comparison result indicates that the target field and the premium check are not passed, and the method enters step S213, recalculates the vehicle premium and re-signs the target field.

S211: the server 200 sends policy data to the database 400.

In some embodiments, the server 200 sends the policy data to the database 400 upon confirming that the target field passes the premium check. Wherein the policy data includes complete information needed to generate the policy.

Illustratively, the server 200 sends the complete vehicle warranty data to the database 400.

S212: the database 400 stores policy data.

In some embodiments, the database 400 stores the policy data as policy data that the server 200 sends to the service terminal 300 in step S214 and requires review by the service personnel.

Illustratively, the database 400 maintains vehicle warranty data.

S213: the server 200 recalculates the premium and re-signs the target field and premium.

In some embodiments, the server 200 calculates the premium again according to the premium calculation factor included in the complete policy data input by the applicant, and uses the signature algorithm to sign the premium calculation factor again to obtain a new first signature result, where the signature method is the same as the signature method for obtaining the first signature result in step S206, and the specific process is not described herein again. At this time, the acquired complete policy data is used as the policy data which is sent by the server 200 to the service terminal 300 in step S214 and needs to be checked by the service personnel.

Illustratively, the server 200 recalculates the premium based on the calculated factor in the complete vehicle policy data entered by the applicant and signs the new premium and the premium calculation factor to obtain new first and second signature results.

S214: the server 200 transmits a policy audit notification to the service terminal 300.

In some embodiments, the server 200 sends a policy audit notification to the service terminal 300, wherein the policy audit notification includes the complete policy data.

Illustratively, the server 200 sends vehicle warranty data to the service terminal 300 to notify the service personnel of the audit.

S215: the service terminal 300 returns the audited policy data to the server 200.

In some embodiments, after the service terminal 300 receives the policy audit notification sent by the server 200, the policy to be audited is displayed on the service terminal 300. After the service personnel audits the complete policy data on the service terminal 300, the service terminal 300 returns the audited policy data to the server 200 after receiving the operation that the service personnel completes the audit.

Illustratively, after the service terminal 300 receives the policy audit notification sent by the server 200, a policy interface 301D to be audited is displayed on the service terminal 300 as shown in fig. 3D. After the service personnel clicks the "audit confirmation" button 302D, the service terminal 300 detects an audit confirmation instruction triggered by the user, and returns the warranty data after the vehicle warranty audit to the server 200.

S216: the server 200 verifies the target fields and the premium in the audited policy data.

In some embodiments, after receiving the verified policy data sent by the service terminal 300, the server 200 performs signature verification again on the target field and the premium in the policy data to obtain a first verification result and a second verification result obtained by using the new target field and the new premium. The obtaining manner of the new verification result is the same as the first signature and the second signature result obtained for the target field and the premium in step S206, and the specific manner is not described herein again.

For example, after receiving the policy data sent by the service terminal 300 and indicating that the vehicle insurance is checked, the server 200 signs the policy data to obtain a new verification result.

S217: the server 200 checks whether the target field and the premium pass the check.

In some embodiments, the server 200 compares the first verification result and the second verification result obtained in step S216 with the first signature result and the second signature result, respectively, if the values are the same, it indicates that the target field is verified, and step S218 is entered, and a policy validation notification is sent to the user terminal 100; if the values are different, it indicates that the target field check is not passed, and step S220 is entered, and the risk level is determined according to the check result. The first signature result and the second signature result may be obtained in step S206, or may be obtained in step S213.

Illustratively, the server 200 obtains a new first verification result and a new second verification result of the vehicle insurance policy, compares the new first verification result and the new second verification result with the first signature result and the second signature result respectively, if the two results are the same, it indicates that the target field and the insurance premium check are passed, and then step S218 is performed; if the two results are different, it indicates that the target field and the premium check are not passed, and the process proceeds to step S220.

S218: the server 200 transmits a policy validation notification to the user terminal 100.

In some embodiments, after obtaining the message that the target field and the premium check pass, the server 200 determines that the target field and the corresponding premium data in the policy are correct, and sends a policy validation notification to the user terminal 100.

Illustratively, the server 200 determines that the target field in the vehicle policy and its corresponding premium data are correct, and sends a notice of validation of the vehicle policy to the user terminal 100. In some embodiments, where the server 200 determines that the target field in the vehicle policy and the premium are correct, and determines that the user has completed payment via the user terminal 100, a policy validation notification is sent to the user terminal 100.

S219: the user terminal 100 displays a policy validation interface.

In some embodiments, after receiving the policy validation notification sent by the server 200, the user terminal 100 displays the policy validation interface according to the policy validation notification sent by the server 200.

S220: and the server 200 judges the risk level according to the verification result.

In some embodiments, the server 200 determines the risk level based on the failure of the target field check. If the first signature result is the same as the first verification result and the second signature result is different from the second verification result, the premium is tampered, the premium is judged to be a first-level risk, the step S221 is entered, the premium is recalculated, and the alarm information is sent; and if the first signature result is different from the first verification result, the premium calculation factor is tampered, the secondary risk is judged, and the step S223 is carried out to recalculate the premium. It can be understood that after the premium is tampered with, the user can obtain a higher premium with a lower premium, and the insurance company is disastrous; when the premium calculation factor is tampered, the insurance company needs to verify the data again and calculate the premium, which consumes manpower and material resources.

S221: the server 200 transmits alarm information to the service terminal 300.

In some embodiments, after obtaining the result that the risk level determination result is the first-level risk result, the server 200 sends an alarm message to the service terminal 300 to remind the service personnel that the premium is tampered, thereby reducing loss and preventing a higher premium from being obtained with an extremely low premium. It is understood that, in some embodiments, the server 200 may also send an instruction to recalculate the premium to the service terminal 300 after obtaining the result that the risk level determination result is the primary risk result.

S222: the service terminal 300 displays the alarm information.

In some embodiments, after the service terminal 300 receives the instruction for recalculating the premium and the alarm information sent by the server 200, a prompt message is displayed on the service terminal 300 to notify the service staff that the premium is tampered.

S223: the server 200 recalculates the premium.

After obtaining the result of the risk level judgment as the result of the secondary risk, the server 200 recalculates the premium.

It should be understood that the execution sequence of steps S201 to S223 is only an illustration, and in other embodiments, other execution sequences may be adopted, and some steps may be split or combined, which is not limited herein.

Fig. 4 shows a flowchart of a method for generating an insurance document, wherein the execution subject of each step is the server 200, according to some embodiments of the present application, and specifically, the flowchart shown in fig. 4 includes the following steps:

s401: a request for generation of an insurance document is received.

In some embodiments, the insurance document may include, but is not limited to, electronic documents such as insurance policies, price lists, lots, and the like. The server 200 receiving a request for generation of an insurance document may include, but is not limited to, receiving a request for creation of an insurance document to be filled, receiving a request for generation of a fully filled insurance document, receiving a request for generation of a modified insurance document.

S402: the target fields in the insurance product type that are needed to calculate the premium are determined.

In some embodiments, the server 200, upon receiving a request for generation of an insurance document, may determine the fields that are required to calculate a premium based on the type of insurance product carried in the request. For example, the insurance product types can include, but are not limited to, vehicle insurance product types, endowment insurance product types, health insurance product types, life insurance product types, and the like.

For example, for an endowment insurance product, the target fields in which premium calculation is required may be, but are not limited to, insurance type field, insurance period, insurer age, etc.; for health insurance documents, the fields in which premium calculations are required may be, but are not limited to, insurance seed, insurance duration, insurer health status, insurer age, etc.

S403: and calculating a premium according to the target field, and distinguishing and signing the target field and the premium to obtain a signature result.

That is, after the server 200 determines the target field, the premium is calculated according to the target field, and the target field and the premium are signed in a distinguishing manner.

In some embodiments, the user enters the application information including the target fields on the policy to be filled. After the server 200 obtains the insurance information containing the target field, the insurance premium of the policy is obtained according to the target field calculation, the signature algorithm is firstly used for signing the target field, and then the signature result of the target field is combined with the insurance premium field for signing. It can be understood that by distinguishing the signature, it is possible to quickly judge whether the target field data is falsified or the premium is falsified.

In some embodiments, after the user inputs the basic insurance element information in the price inquiry, the server 200 receives the basic insurance element information, extracts the target field in the basic insurance element information to calculate the premium, signs the target field by using a signature algorithm after obtaining the premium data, and then combines the signature result of the target field with the premium field to sign.

In some embodiments, after the user enters data on the insurance document that needs to be completed, the server 200 signs the target field using a signature algorithm, and then signs the target field by combining the signature result with the premium.

In other embodiments, after the business personnel review the complete insurance document, the server 200 signs the target field in the reviewed insurance document by using a signature algorithm, and then combines the signature result of the target field with the premium field to sign.

S404: and generating an insurance document, and associating the signature result with the insurance document, wherein the associated signature result is used for verifying a set business link.

In some embodiments, the server 200 stores the signature results of the target field and the premium in the price inquiry link, after the server 200 receives the complete policy filling data sent by the user terminal 100, the server 200 needs to verify the target field and the premium in the complete policy filling data by using the same signature algorithm to obtain a verification result, and after the target field and the premium are verified, the confirmed complete policy is sent to the user terminal 100.

In other embodiments, after receiving the audited policy data sent by the service terminal 300, the server 200 verifies the target field and the premium field in the manually audited policy to obtain a verification result, so as to prevent the service staff from tampering the policy data due to misoperation in the auditing process or network attack. The server 200 compares the verification result obtained by verifying the target field and the premium with the stored signature result, and if the signature result is consistent with the verification result, the insurance document is determined to be generated. It is to be understood that generating an insurance document herein means that the insurance document is in effect.

It is understood that the execution sequence of steps S401 to S404 is only an example, in other embodiments, other execution sequences may also be adopted, and partial steps may also be split or combined, which is not limited herein.

The following takes the flowchart shown in fig. 5 as an example, and the specific steps involved in the above-mentioned fig. 2 and 4 that use the signature algorithm to obtain the signature result or the verification result are described. The execution of the steps in the flowchart shown in fig. 5 by the subject server 200, specifically, the flowchart shown in fig. 5 includes the following steps:

s501: and acquiring a target field and a premium field.

In some embodiments, business personnel may configure the target fields of the base application element that need to be signed and the premium fields in a configuration file. When a signature result or a verification result needs to be obtained, the server 200 acquires the extraction target field and the premium field from the database 400.

Illustratively, the server 200 sets a data model to which a target field required to be signed in the basic application element belongs in the configuration file, and acquires the corresponding field according to the data model. The data model includes but is not limited to a policy basic information model, a target model, an applicant model and an application responsibility model. Fields corresponding to the basic information model of the policy include, but are not limited to, product code, insurance period, total premium, commission; fields corresponding to the applicant model include but are not limited to a client name, a certificate number and a contact address; target models (exemplified by vehicle insurance) include, but are not limited to, vehicle model, license plate number, displacement, price; the application responsibility model includes, but is not limited to, terms/responsibility codes, and application amount. After the configuration is completed, the server 200 extracts object fields in the different data models of the above-described configuration, such as a product code, a term of insurance, a total premium, and a commission amount field in the basic information model of the policy, a certificate number field in the model of the applicant, a model field in the object model, and an amount of insurance and an obtained premium field in the model of the responsibility of the application. For example, the product code field may be ABC, the insurance period field is one, the total premium field is 100, the commission field is 10, the certificate number field is 02, the vehicle type field is xiaojiaoche, and the insurance amount field is 1000, and it is understood that ABC, one, 100, 10,02, car, 1000 in the above fields are merely exemplary illustrations, and may be other character strings, and the specific contents of the fields are not specified.

S502: and splicing the extracted fields to obtain a character string result arranged according to a certain sequence.

After acquiring the target field and the corresponding premium field, the server 200 concatenates the extracted target field according to a certain rule to obtain a character string with a fixed sequence.

For example, in step S501, after the obtained product code field is ABC, the insurance period is one, the total premium is 100, the commission is 10, the certificate number field is 02, the vehicle type field is xiaojiaoche, and the target field and the premium field of the insurable amount is 1000 are applied, the server 200 extracts the target field and the corresponding premium field, which are ABC, one,10,02, xiaojiaoche,1000,100. The target fields are spliced into character strings according to a certain sequence, the sequence can be that the initial letters of the fields are arranged according to an ASCII value sequence, for example, the spliced character strings can be '02101000 ABCConexiaojiaoche', and can also be arranged according to the length of the fields, for example, 'xiaojiaoche 1000ABCONE 0210' is arranged in front of the long field, and the splicing mode is not specifically required. It is understood that the target field extracted by the server 200 is only an example, and it may be a field extracted in any manner.

S503: and signing the character string through a signature algorithm to obtain a signature result.

After obtaining the character strings arranged according to a certain rule, the server 200 performs signature on the obtained character strings by using an HMAC-SHA256 signature algorithm to obtain signature results.

For example, in some embodiments, the obtained character string may be signed using HMAC-SHA256 algorithm to obtain a signature result. Specifically, in the above step, the obtained target field character string obtained by splicing according to a certain rule is encrypted to obtain a target field signature result, where the target field signature is a first signature result or a first verification result in the insurance document generation method. And splicing the obtained target field signature and the extracted premium field according to a certain rule to obtain a new character string with a certain sequence, wherein the splicing rule can be the same as or different from the splicing mode of the obtained target field character string, and encrypting the new character string by using an HMAC-SHA256 algorithm to obtain a signature result containing the premium field, wherein the signature result is a second signature result or a second verification result in the insurance document generation method.

Fig. 6 provides a block diagram of an insurance document generation apparatus 600, according to some embodiments of the present application.

As shown in fig. 6, the generation apparatus 600 of the insurance document includes a receiving module 601, a determining module 602, a signature module 603, and a generating module 604.

The receiving module 601 is configured to receive a request for generating an insurance document;

a determining module 602, configured to determine a target field required for calculating a premium of an insurance document;

the signature module 603 is configured to calculate a premium based on the target field, and perform signature differentiation on the target field and the premium to obtain a signature result;

the generating module 604 is configured to generate an insurance document, associate the signature result with the insurance document, and verify the insurance document in a set business link.

To facilitate understanding of the technical solutions of the embodiments of the present application, a hardware structure of the server 200 is described below.

Further, fig. 7 illustrates a schematic diagram of a server 200, according to some embodiments of the present application. As shown in fig. 7, the server 200 for executing the insurance document generation method provided in this application and shown in fig. 4 may include one or more processors 201, a system Memory 202, a Non-Volatile Memory (NVM) 203, an input/output (I/O) device 204, a communication interface 205, and a system control logic 206 for coupling the processors 201, the system Memory 202, the NVM 203, the communication interface 204, and the I/O device 205.

Wherein: processor 201 may include one or more single-core or multi-core processors. In some embodiments, the processor 201 may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In some embodiments, the processor 201 may be configured to determine that the insurance management system is attacked, and then obtain the risk level of the insurance service to reduce the loss of the insurance company, where the obtaining includes obtaining configuration information in a configuration file, signing the key field of the user attribute information and the corresponding premium to obtain a first signature result, detecting that the insurance management system is attacked by the network, and eliminating the network attack, and then signing the key field of the user attribute information and the premium field in the configuration file again to obtain a second signature result, and comparing the signature results to obtain a risk level determination result.

The system Memory 202 is a volatile Memory, such as a Random-Access Memory (RAM), a Double Data Rate Synchronous Dynamic Random Access Memory (DDR SDRAM), and the like. The system memory is used for temporarily storing data and/or instructions, for example, in some embodiments, the system memory 202 may be used for storing the executable program for implementing the risk level determination method described above.

Non-volatile memory 203 may include one or more tangible, non-transitory computer-readable media for storing data and/or instructions. In some embodiments, the non-volatile memory 203 may include any suitable non-volatile memory such as flash memory and/or any suitable non-volatile storage device, such as a Hard Disk Drive (HDD), Compact Disc (CD), Digital Versatile Disc (DVD), Solid-State Drive (SSD), and the like. In some embodiments, the non-volatile memory 203 may also be a removable storage medium, such as a Secure Digital (SD) memory card or the like.

In particular, system memory 202 and non-volatile storage 203 may each include: a temporary copy and a permanent copy of instruction 207. The instructions 207 may include: program instructions which, when executed by at least one of the processors 201, cause the server 200 to implement the method for insurance document generation provided by embodiments of the present application.

Input/output (I/O) devices 204 may include a user interface to enable a user to interact with server 200. For example, in some embodiments, input/output (I/O) device 204 may include a display or other output device for displaying the insurance management system interface in server 200, and may also include a keyboard, mouse, touch screen or other input device. Product developers may interact with the server 200 through a user interface and input devices such as a keyboard, mouse, touch screen, etc.

The communication interface 205 may include a transceiver to provide a wired or wireless communication interface for the server 200 to communicate with any other suitable device over one or more networks. In some embodiments, the communication interface 205 may be integrated with other components of the server 200, for example, the communication interface 205 may be integrated in the processor 101. In some embodiments, the server 200 may communicate with other devices through the communication interface 205.

System control logic 206 may include any suitable interface controllers to provide any suitable interfaces with the other modules of server 200. For example, in some embodiments, system control logic 206 may include one or more memory controllers to provide an interface to system memory 202 and non-volatile memory 203.

In some embodiments, at least one of the processors 201 may be packaged together with logic for one or more controllers of the System control logic 206 to form a System In Package (SiP). In other embodiments, at least one of the processors 201 may also be integrated on the same Chip with logic for one or more controllers of the System control logic 206 to form a System-on-Chip (SoC).

It is understood that the server 200 may be any electronic device capable of executing the risk level obtaining method provided by the present application, including but not limited to a computer, a server, a tablet computer, a handheld computer, and the like, and the embodiments of the present application are not limited thereto.

It is to be understood that the structure of the server 200 shown in the embodiment of the present application does not specifically limit the server 200. In other embodiments of the present application, server 200 may include more or fewer components than shown, or combine certain components, or split certain components, or a different arrangement of components. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of these implementations. Embodiments of the application may be implemented as computer programs or program code executing on programmable systems comprising at least one processor, a storage system (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device.

Program code may be applied to input instructions to perform the functions described herein and generate output information. The output information may be applied to one or more output devices in a known manner. For purposes of this Application, a processing system includes any system having a Processor such as, for example, a Digital Signal Processor (DSP), a microcontroller, an Application Specific Integrated Circuit (ASIC), or a microprocessor.

The program code may be implemented in a high level procedural or object oriented programming language to communicate with a processing system. The program code can also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described in this application are not limited in scope to any particular programming language. In any case, the language may be a compiled or interpreted language.

In some cases, the disclosed embodiments may be implemented in hardware, firmware, software, or any combination thereof. The disclosed embodiments may also be implemented as instructions carried by or stored on one or more transitory or non-transitory machine-readable (e.g., computer-readable) storage media, which may be read and executed by one or more processors. For example, the instructions may be distributed via a network or via other computer readable media. Thus, a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer), including, but not limited to, floppy diskettes, optical disks, Read-Only memories (CD-ROMs), magneto-optical disks, Read-Only memories (ROMs), Random Access Memories (RAMs), Erasable Programmable Read-Only memories (EPROMs), Electrically Erasable Programmable Read-Only memories (EEPROMs), magnetic or optical cards, flash Memory, or tangible machine-readable memories for transmitting information (e.g., carrier waves, infrared digital signals, etc.) using the Internet to transmit information in an electrical, optical, acoustical or other form of propagated signals. Thus, a machine-readable medium includes any type of machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

In the drawings, some features of the structures or methods may be shown in a particular arrangement and/or order. However, it is to be understood that such specific arrangement and/or ordering may not be required. Rather, in some embodiments, the features may be arranged in a manner and/or order different from that shown in the illustrative figures. In addition, the inclusion of a structural or methodical feature in a particular figure is not meant to imply that such feature is required in all embodiments, and in some embodiments, may not be included or may be combined with other features.

It should be noted that, in the embodiments of the apparatuses in the present application, each unit/module is a logical unit/module, and physically, one logical unit/module may be one physical unit/module, or may be a part of one physical unit/module, and may also be implemented by a combination of multiple physical units/modules, where the physical implementation manner of the logical unit/module itself is not the most important, and the combination of the functions implemented by the logical unit/module is the key to solve the technical problem provided by the present application. Furthermore, in order to highlight the innovative part of the present application, the above-mentioned device embodiments of the present application do not introduce units/modules which are not so closely related to solve the technical problems presented in the present application, which does not indicate that no other units/modules exist in the above-mentioned device embodiments.

It is noted that, in the examples and descriptions of this patent, relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, the use of the verb "comprise a" to define an element does not exclude the presence of another, same element in a process, method, article, or apparatus that comprises the element.

While the present application has been shown and described with reference to certain preferred embodiments thereof, it will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present application.

Claims

1. An insurance document generation method is used for electronic equipment, and is characterized by comprising the following steps:

receiving a generation request of an insurance document; determining a target field required for calculating the premium of the insurance document;

calculating the premium based on the target field, and carrying out distinguishing signature on the target field and the premium to obtain a signature result;

and generating the insurance document, and associating the signature result with the insurance document, wherein the signature result is used for verifying the insurance document in a set business link.

2. The method of claim 1, wherein determining the target fields required to calculate the premium for the insurance document comprises:

3. The method according to claim 1 or 2, wherein said differentially signing the target field and the premium to obtain a signature result comprises:

storing the first signature result and the second signature result.

4. The method of claim 3, further comprising: verifying the insurance document by using the signature result in the following ways:

under the condition that the current set business link is determined, signing the character string obtained by arranging the target field according to the first arrangement rule by using the first signature algorithm to obtain a first verification result; and is

Signing the character string obtained by arranging the first verification result and the premium according to the second arrangement rule by using the second signature algorithm to obtain a second verification result;

and obtaining a verification result of the insurance document in the set business link based on the first verification result, the stored first signature result, the second verification result and the stored second signature result.

5. The method of claim 4, further comprising:

and determining the existing safety risk according to the verification result, and executing the operation corresponding to the safety risk.

6. The method of claim 5, wherein determining a risk level based on the verification result and performing a corresponding risk response based on the risk level comprises:

determining that a first risk exists under the condition that the first verification result and the first signature result are different, and recalculating the premium according to the determined first risk;

7. The method according to claim 3, wherein the first signature algorithm and/or the second signature algorithm comprises: HMAC-SHA256 algorithm.

8. The method of claim 1, wherein said calculating said premium based on said target field comprises:

determining a calculation rule of premium in the insurance document;

and calculating the premium based on the target field according to the calculation rule.

9. The method of claim 1, wherein the business setting step comprises at least one of a submission step and an audit step of the insurance document.

10. The method of claim 1, wherein the insurance document comprises at least one of an invoice, a policy, and a batch.

11. An apparatus for generating an insurance document, comprising:

the signature module is used for calculating the premium based on the target field and carrying out distinguishing signature on the target field and the premium to obtain a signature result;

and the generating module is used for generating the insurance document and associating the signature result with the insurance document, wherein the signature result is used for verifying the insurance document in a set business link.

12. A computer-readable storage medium having stored thereon instructions which, when executed on an electronic device, cause the electronic device to perform the method of generating an insurance document of any of claims 1 to 10.

13. A chip arrangement, the chip arrangement comprising:

a communication interface for inputting and/or outputting information;

a processor for executing a computer executable program for causing an electronic device in which the chip arrangement is installed to perform the method of generating an insurance document according to any one of claims 1 to 10.

14. A computer program product, characterized in that it comprises instructions which, when executed, implement the method of generating an insurance document according to any of claims 1 to 10.

15. An electronic device, comprising:

A processor for executing instructions stored in the memory to implement the method of generating an insurance document of any of claims 1 to 10 when the instructions are executed by one or more processors of the electronic device.