CN111553801A - Insurance implementation method and device for electronic equipment - Google Patents

Abstract

The specification discloses a method and a device for realizing insurance of electronic equipment. The method comprises the following steps: responding to an electronic equipment application request initiated by a user, and acquiring behavior data of the user; determining the attribute of the target equipment of the application request according to the behavior data; and performing the underwriting on the application request according to the underwriting strategy corresponding to the attribute.

Description

Insurance realization method and device for electronic equipment

technical field

This specification relates to the field of Internet technologies, and in particular, to a method and device for implementing insurance for electronic equipment.

Background technique

With the rapid development of Internet technology, more and more insurance services can be realized through the Internet, such as online insurance application, online underwriting, and online claim settlement. How to improve the processing efficiency and processing accuracy of online insurance business has become an urgent problem to be solved.

SUMMARY OF THE INVENTION

In view of this, the present specification provides a method and device for implementing insurance for electronic equipment.

Specifically, this specification is achieved through the following technical solutions:

A method for realizing insurance of electronic equipment, applied to a server, the method includes:

In response to the electronic device insurance request initiated by the user, obtain the behavior data of the user;

Determine the attributes of the target device of the insurance request according to the behavior data;

The insurance application request is underwritten according to the underwriting policy corresponding to the attribute.

A device for realizing insurance for electronic equipment, applied to a server, the device includes:

A behavior data acquisition unit, in response to an electronic device insurance request initiated by a user, to acquire the behavior data of the user;

a device attribute determination unit, which determines the attribute of the target device of the insurance request according to the behavior data;

The electronic device underwriting unit underwrites the insurance application request according to the underwriting policy corresponding to the attribute.

A device for realizing insurance for electronic equipment, comprising:

processor;

memory for storing machine-executable instructions;

Wherein, by reading and executing the machine executable instructions stored in the memory corresponding to the insurance implementation logic of the electronic device, the processor is caused to:

In response to the electronic device insurance request initiated by the user, obtain the behavior data of the user;

Determine the attributes of the target device of the insurance request according to the behavior data;

The insurance application request is underwritten according to the underwriting policy corresponding to the attribute.

An embodiment of this specification realizes that after receiving the electronic device insurance request, the server can obtain the behavior data of the user, and then determine the properties of the electronic device according to the behavior data, and make the insurance request according to the underwriting policy corresponding to the properties. Underwriting and underwriting through differentiated underwriting strategies can not only ensure the accuracy of underwriting, but also improve the efficiency of underwriting, thereby improving the user's insurance experience.

Description of drawings

FIG. 1 is a schematic flowchart of a method for implementing insurance for an electronic device according to an exemplary embodiment of the present specification.

FIG. 2 is a schematic flowchart of a method for determining an attribute of a target device according to an exemplary embodiment of the present specification.

FIG. 3 is a schematic flowchart of another method for determining an attribute of a target device shown in an exemplary embodiment of the present specification.

FIG. 4 is a schematic diagram of an insurance application page shown in an exemplary embodiment of the present specification.

FIG. 5 is a schematic flowchart of a method for uploading verification data according to an exemplary embodiment of the present specification.

FIG. 6 is a schematic diagram of an insurance application method list page shown in an exemplary embodiment of the present specification.

FIG. 7 is a schematic diagram of an uploading method guidance page shown in an exemplary embodiment of the present specification.

FIG. 8 is a schematic diagram of a shooting countdown page according to an exemplary embodiment of the present specification.

FIG. 9 is a schematic diagram of another upload mode guidance page shown in an exemplary embodiment of the present specification.

FIG. 10 is a schematic flowchart of a method for realizing an electronic device insurance claim according to an exemplary embodiment of the present specification.

FIG. 11 is a schematic flowchart of a method for establishing a mapping relationship according to an exemplary embodiment of the present specification.

FIG. 12 is a schematic flowchart of another method for establishing a mapping relationship according to an exemplary embodiment of the present specification.

FIG. 13 is a schematic flowchart of another method for realizing an electronic device insurance claim according to an exemplary embodiment of the present specification.

FIG. 14 is a schematic flowchart of a method for determining an insurance parameter according to an exemplary embodiment of the present specification.

FIG. 15 is a schematic structural diagram of an apparatus for implementing insurance for electronic equipment according to an exemplary embodiment of the present specification.

Fig. 16 is a block diagram of an apparatus for realizing insurance of an electronic device according to an exemplary embodiment of the present specification.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. Where the following description refers to the drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the illustrative examples below are not intended to represent all implementations consistent with this specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of this specification as recited in the appended claims.

The terms used in this specification are for the purpose of describing particular embodiments only and are not intended to limit the specification. As used in this specification and the appended claims, the singular forms "a," "the," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information, without departing from the scope of the present specification. Depending on the context, the word "if" as used herein can be interpreted as "at the time of" or "when" or "in response to determining."

This specification provides an insurance implementation solution for electronic equipment.

The insurance for the above electronic equipment may be the screen insurance of the electronic equipment, or may be an insurance type that can be insured for the electronic equipment, such as the comprehensive protection insurance of the electronic equipment.

The above-mentioned electronic devices may be terminal devices such as mobile phones, tablet computers, and PDAs (Personal Digital Assistants), and the above-mentioned electronic devices may also be multimedia devices such as cameras and smart TVs, which are not particularly limited in this specification.

The insurance implementation solution of the above electronic device can be realized by the cooperation of the electronic device and the server. The server may be deployed by service providers that provide insurance services, such as insurance companies, third-party insurance sales platforms, and the like.

In the process of realizing the insurance business, the electronic device and the server can interact with each other through wired, wireless and other transmission methods. The interaction between the electronic device and the server usually refers to the interaction between the client software loaded in the electronic device and the server. For example, the user interacts with the server after logging in with the registered user account in the client, which can also be called a user. interaction with the server.

The specific implementation process of this specification will be described below through the following four aspects: insurance application, underwriting, claim settlement and insurance parameter determination of the electronic device.

1. Insurance of electronic equipment

FIG. 1 is a schematic flowchart of a method for implementing insurance for an electronic device according to an exemplary embodiment of the present specification.

Please refer to FIG. 1 , the method for realizing insurance of electronic equipment can be applied to a server, and includes the following steps:

Step 102, in response to an electronic device insurance request initiated by a user, acquire behavior data of the user.

In this embodiment, the user can initiate the electronic device insurance request through the electronic device insurance sales portal. For example, the client can send the electronic device insurance request after the user triggers the specified entry on the payment result page, and the electronic device The insurance request carries the user account number.

After receiving the electronic device insurance request, the server obtains the behavior data of the corresponding user according to the user account.

The behavior data may include: historical transaction data of the user, historical login data of the user, current login data of the user, and the like.

In other examples, after receiving the electronic device insurance request, the server may first determine whether the user hits the blacklist, and if not, the server may perform the step of acquiring user behavior data.

The blacklist can be preset.

For example, historically identified fraudulent users may be added to the blacklist.

For another example, practitioners in the electronic equipment repair industry can also be added to the blacklist.

For another example, practitioners in the 3C industry can also be added to the blacklist.

Through the filtering of the blacklist, it can effectively filter out the high-risk groups of fraudulent insurance, improve the security of online insurance, and reduce the risk of capital loss of the insurance provider.

Step 104: Determine the attribute of the target device of the insurance request according to the behavior data.

Based on the foregoing step 102, after acquiring the behavior data of the user, the server may determine the attributes of the target electronic device (hereinafter referred to as the target device) that the user applies for insurance this time according to the behavior data. For example, for different behavior data, the properties of the target device may be determined in different ways.

Wherein, the attributes of the target device may include: a new machine and an old machine.

Step 106 , underwrite the insurance application request according to the underwriting policy corresponding to the attribute.

In this embodiment, the mapping relationship between the attributes of different target devices and the corresponding insurance policies can be pre-configured and saved. After the attributes of the target device are determined in the aforementioned step 104, the corresponding core can be searched in the mapping relationship. An insurance policy is adopted, and then a corresponding underwriting policy is used to underwrite the electronic device insurance application request.

If the attribute of the target equipment is a new machine, the machine inspection process can be omitted, and the underwriting can be directly determined to be passed, thereby improving the underwriting efficiency and improving the user's insurance experience.

If the attribute of the target device is an old machine, the user can be prompted to upload the verification data of the target device, and the server can then perform verification and guarantee according to the verification data.

It can be seen from the above description that, after receiving the electronic device insurance request, the server in this embodiment can obtain the behavior data of the user, and then determine the attributes of the electronic device according to the behavior data, and make the corresponding underwriting policy according to the attributes. Underwriting insurance requests and underwriting through differentiated underwriting strategies can not only ensure the accuracy of underwriting, but also improve the efficiency of underwriting, thereby improving the user's insurance experience.

The method for determining the attribute of the target device will be described in detail below through several embodiments.

FIG. 2 is a schematic flowchart of a method for determining an attribute of a target device according to an exemplary embodiment of the present specification.

Referring to FIG. 2, the method for determining the attributes of the target device may include the following steps:

Step 202: Obtain historical transaction data of the user within a predetermined time period.

In this embodiment, after receiving the electronic device insurance request sent by the user, the server may obtain the user account of the initiating user, and then obtain historical transaction data of the corresponding user within a predetermined period of time from several e-commerce platforms based on the user account. .

For example, the server may determine the user's identity information based on the user account, and then acquire historical transaction data based on the identity information.

In this embodiment, each piece of historical transaction data may include: order number, order time, purchased item identification, item type, merchant identification and other information. The predetermined time period may be preset by the developer, for example, within 10 days, 15 days, and the like.

Step 204: Determine whether the historical transaction data includes purchase transaction data of the electronic device.

Step 206, if yes, determine that the attribute of the target device is a new device.

Based on the foregoing step 202, after acquiring the historical transaction data of the user within a predetermined time period, the server may determine whether the user has purchased an insurable electronic device within the predetermined time period according to the historical transaction data.

If so, it can be inferred that what the user wants to insure is a newly purchased electronic device, and then the attribute of the target device can be determined as a new device.

For example, Xiaobai logs in Xiaobai's account in the client loaded on his mobile phone, and then sends an insurance request for mobile phone screen insurance to the server. After receiving the insurance request, the server can determine Xiaobai according to Xiaobai's account number. identity information, such as unique identifiers, etc. Then, according to Xiaobai's identity information, the transaction data of Xiaobai in the last 15 days is obtained from the e-commerce platform, and based on the transaction data of the 15 days, it is judged whether Xiaobai has purchased a mobile phone. The purchased mobile phone can further determine the attribute of the target device of the insurance application as a new phone.

In other examples, if the historical transaction data includes purchase transaction data of multiple electronic devices, the server may send a list of corresponding electronic devices to the user, so that the user can select the target device to be insured. After receiving the selection instruction sent by the user based on the electronic device list, the server may determine the electronic device selected by the user as the target device for this insurance application.

Still taking Xiaobai as an example, if Xiaobai's transaction data in the last 15 days includes the purchase records of two mobile phones, you can send a list including the two mobile phones to Xiaobai. The list may include data such as mobile phone model, purchase date, purchase price, and merchant information. Xiaobai can select the mobile phone that he wants to apply for insurance in this list. After receiving Xiaobai's selection instruction, the server can determine the mobile phone selected by Xiaobai as the target device of this insurance request.

It is worth noting that, if it is determined according to the user's historical transaction data that the multiple electronic devices purchased by the user are of the same model, the electronic device list may not be sent to the user. For example, if Xiaobai buys two identical mobile phones, he does not need to send the list to Xiaobai, and the server can confirm that Xiaobai wants to insure a new mobile phone of this model.

In this embodiment, in addition to the e-commerce platform, the server can also obtain the historical transaction data of the user from other channels, for example, the offline transaction data of the user in the physical shopping mall can be obtained from the server of the physical shopping mall. There is no special restriction on this.

In this embodiment, the server can determine whether the property of the insurance subject device is a new device through the user's historical transaction data. It also breaks through the limitation that new phones can only be insured at the time of purchase, greatly improving the user's insurance experience.

FIG. 3 is a schematic flowchart of another method for determining an attribute of a target device shown in an exemplary embodiment of the present specification.

Referring to FIG. 3, the method for determining the attributes of the target device may include the following steps:

Step 302: Obtain the device identifier of the device initiating the insurance application request of the electronic device as the initiating identifier.

In this embodiment, after the user logs in to the server based on the user account in the client, the client can obtain the device identification of the electronic device used by the user, and report the device identification to the server. The device identification can be reported by the client alone, and the device identification can also be carried by the client and reported to the server in the service request. For example, the client can carry the device identification in the electronic device insurance request sent by the user and send it to the server. , this manual does not make any special restrictions.

The device identification may include: Android ID (Android ID), IDFV (IdentifierForVendor, application developer identification), IMEI (International Mobile Equipment Identity, International Mobile Equipment Identity) and the like.

In this embodiment, after receiving the electronic device insurance application request, the server can obtain the device identification of the initiating device that initiates the electronic device insurance application request through the client, and can use it as the initiating identification.

Step 304 , searching for the device identifier of the user's historical login device as the historical identifier.

In this embodiment, the server may also query the database based on the user account to obtain the device identifier of the historical login device corresponding to the user. The database stores the device identifiers of the electronic devices used by each user to log in to the server in the history.

In one example, the server may acquire, from the database, the device identifiers of the electronic devices used by the user when logging in to the server several times recently, as historical identifiers, where there are multiple historical identifiers.

In another example, considering that the user usually does not frequently replace the electronic device without any reason, the server may also obtain the device identification of the electronic device used by the user when logging in to the server most recently from the database, as a historical identification.

Step 306, judging whether the originating identifier and the historical identifier are the same.

Step 308, if they are not the same, determine that the attribute of the target device is a new device.

Based on the foregoing steps 302 and 304, the server may determine whether the originating identifier and the historical identifier are the same.

When the server obtains the device ID of the electronic device used by the user when logging into the server last time as the historical ID, if the originating ID and the historical ID are different, it can indicate the electronic device that the user has replaced, and it can be presumed that the user has insured the newly replaced electronic device. Further, the attribute of the target device can be determined as a new machine.

If the server obtains multiple historical identifiers, it can determine whether the originating identifier is the same as each historical identifier. If they are different, it can indicate that the user has replaced the electronic device, and it can be presumed that the user has insured the newly replaced electronic device. , and then the attribute of the target device can be determined as a new machine.

In other examples, when using the device identifier to determine the attributes of the target device, it is also possible to determine whether the user is a trusted user. The attribute is determined as a new machine, but the attribute of the target device is determined as an old machine, thereby improving the accuracy of the subsequent underwriting results and reducing the risk of fraudulent insurance caused by directly skipping the inspection machine and passing the underwriting.

If the user is a trusted user, when the originating identification and the historical identification are different, the attribute of the target device can be determined as a new device.

In this embodiment, whether the user is a trusted user may be determined according to the user's registration duration, login frequency, and the like.

In one example, it can be determined whether the user's registration duration is less than a duration threshold, and if it is less than the duration threshold, it can be determined that the user is not a trusted user.

The duration threshold can be preset, for example, 1 month, 3 months, and the like.

In another example, it can be determined whether the user has logged in the user account recently, and if not, it can be determined that the user is not a trusted user.

For example, it can be determined whether the user has logged into the user account in the past one month/three months.

On the contrary, if the user's registration duration is greater than or equal to the duration threshold, and the user has recently logged in to the user account, it can be determined that the user is a trusted user.

In this embodiment, the server can determine whether the target device insured by the user is a new device according to the device identifier of the user's login device, which can solve the problem of inaccurate identification of the new device's target device caused by incomplete acquisition of historical transaction data. Uploading the proof of purchase can greatly simplify the user's insurance application operation and improve the insurance application efficiency.

It is worth noting that this specification does not limit the execution order of the method for determining the device attribute of the embodiments shown in FIG. 2 and FIG. 3 . Moreover, in the above-mentioned implementation scheme for determining the attributes of the target device, if it is impossible to determine that the attribute of the target device is a new device through historical transaction data, device identification, etc., the attribute of the target device can be determined as the old device, and the follow-up is based on the user uploaded. The verification data is underwritten to ensure the accuracy of the underwriting.

In addition, after determining the properties of the target device, the server can also send the properties of the target device to the client for confirmation by the user, and the user can make adjustments according to the actual situation.

It is still assumed that Xiaobai has purchased a new mobile phone in the last 15 days. The server determines that the attribute of the target device is "new phone", and can then return "new phone" as the default attribute to the client. If Xiaobai wants to insure it is not a new phone. machine, other properties can be selected.

In the actual implementation, in order to facilitate the user's understanding, taking the mobile phone screen insurance as an example, the client can display the insurance application page shown in Figure 4. Whether the target mobile phone to be insured is this mobile phone.

If the user selects "new mobile phone purchase", the server can obtain the user's historical transaction data, and then determine whether the user has recently purchased a new mobile phone according to the historical transaction data. Confirm that the underwriting is approved.

If the user selects "this mobile phone", it means that the mobile phone that the user wants to insure is the mobile phone currently in use. The mobile phone that the user is currently using may be a new mobile phone purchased by the user, that is, the attribute of the target device is a new phone; the mobile phone that the user is currently using may also be the old mobile phone of the user, that is, the attribute of the target device is "old phone" . In this case, the server can obtain the historical identifier and the originating identifier to confirm the attribute of the target device, and can use the underwriting policy corresponding to the determined attribute to underwrite.

Of course, in other cases, if the electronic device insured by the user is a multimedia device such as a video camera and a smart TV, the user may still use a mobile phone to insure, but the "insured device" cannot be a mobile phone, and developers can develop other styles of user interfaces. This manual does not make any special restrictions on this.

2. Underwriting

When it is determined that the attribute of the target device is an old machine, the server sends a prompt message for uploading the verification data to the user. The verification data can be data such as photos and videos of the target device. After receiving the verification data, the server can pass the verification data. The verification data is checked to determine whether the target equipment is intact and undamaged, and then the underwriting result is determined.

This manual provides a variety of uploading methods for verification data, and users can choose according to the actual situation.

FIG. 5 is a schematic flowchart of a method for uploading verification data according to an exemplary embodiment of the present specification.

Please refer to FIG. 5, the method for uploading verification data can be applied to electronic equipment, including the following steps:

Step 502, when triggering the upload of the verification data for insurance application of the electronic device, display a list of uploading methods.

In this embodiment, after receiving the prompt information for uploading the verification data, the user can upload the verification data at a convenient time.

When the user triggers the upload of the verification data, the client of the electronic device can display the upload method list, and the upload method list can display the auxiliary equipment required for the corresponding upload method, and the user can select the upload method according to the actual situation.

Taking mobile phone screen insurance as an example, the verification data is a photo or video of the mobile phone screen. Please refer to the schematic diagram of the insurance method list page shown in Figure 6. Figure 6 provides two mobile phone screen shooting methods. One is to help others to shoot, and another mobile phone is required; if the user cannot find another mobile phone, he can also choose another mobile phone. A shooting method, that is, shooting in front of a mirror by yourself.

Among them, the auxiliary device required for the way others assisted shooting is another mobile phone; the auxiliary device required for self-shooting is a mirror.

Step 504, in response to the uploading method selected by the user, jump to a corresponding uploading method guidance page, where the uploading method guidance page displays a corresponding uploading entry for the user to use the uploading method after triggering the uploading entry. Realize the uploading of the verification data of the device.

Based on the list of uploading methods displayed in the foregoing step 502, the user can select an appropriate uploading method, and the client can then jump to a guide page corresponding to the uploading method. The guidance page displays a detailed introduction of the corresponding uploading method, and displays an uploading entry, and the user can trigger the uploading entry to photograph the verification data.

It can be seen from the above description that this embodiment provides a variety of uploading methods for verification data in the process of applying for insurance of electronic equipment. Users can choose an appropriate method to upload verification data according to the actual situation, so as to realize online uploading of verification data, which is convenient and convenient. It is fast, greatly improving the user's insurance experience.

The two uploading methods are described in detail below.

1. Shoot in the mirror

Still taking the mobile phone screen insurance as an example, if the user triggers the upload method of "shooting the camera in the mirror" on the page shown in Figure 6, the client can jump to the upload method guidance page shown in Figure 7. The method guide page displays the upload entry "Start Shooting", as well as sample images of the upload method and shooting requirements.

After triggering the uploading portal, the user can call the front camera of the electronic device, and collect pictures, videos and other images through the front camera, and upload the images to the server as verification data after the images are collected.

In other examples, after the user triggers the upload entry, the rear camera can also be called by default, and the user manually switches to the front camera for image capture, which is not limited in this specification.

In other examples, please refer to the user interface shown in FIG. 8 , since the user needs to turn the phone over to take a picture in front of the mirror, and turn the phone screen toward the mirror. The customer reserves the preparation time for flipping the mobile phone, and only starts to collect images when the time period is reached. The timing duration may be 3 seconds. In order to facilitate the user's understanding, the client terminal may display the timing duration in a countdown manner.

This embodiment provides the user with a way of uploading the verification data photographed in the mirror. On the one hand, the authenticity of the verification data can be ensured, and on the other hand, the implementation is simple and convenient, and the user experience is better.

2. Shooting with other mobile phones

Still taking the mobile phone screen insurance as an example, if the user triggers the upload method of "using other mobile phones to shoot this camera" on the page shown in Figure 6, the client can jump to the upload method guidance page shown in Figure 9, where the upload The method guide page displays the upload entry "Start Shooting", as well as sample images of the upload method and shooting requirements.

After the user triggers the upload portal, the client can display the verification graphic code for uploading verification data, such as verification QR code. The verification two-dimensional code can carry data such as verification identification, user account, insurance information, and equipment identification.

The user or the person assisting the user can use other mobile phones to scan the verification QR code, and parse the verification QR code. After the collection is completed, the collected image and the user account number, insurance information, equipment identification and other data obtained by parsing the QR code can be sent to the server, and the server can determine the corresponding insurance request according to the information, and carry out underwriting.

In this embodiment, the verification graphic code is a dynamic graphic code, for example, it can be refreshed once per minute. The use of dynamic graphic coding can effectively prevent users from cheating. For example, users can save the verification graphic coding by taking screenshots, etc., and send the verification image coding to the mobile phone of the same model, and then collect the image of the mobile phone of the same model as verification. data etc.

In the above two uploading methods, non-sensing shooting can be used, that is, the user does not need to manually trigger the shooting start/shooting end button, and the camera is automatically shot and uploaded after calling the camera, which simplifies the user operation and improves the user experience.

In addition, the above two methods are described by taking the mobile phone screen insurance as an example. If the user is insured with other types of insurance such as comprehensive protection insurance, the verification data may also include the images on the side and back of the mobile phone. The client can output corresponding guidance. The manual will not repeat them one by one here.

In other examples, since the auxiliary devices required for the above two uploading methods are different, the server may pre-store the mapping relationship between the uploading method and the uploading time period.

On the one hand, when determining that the attribute of the target device is an old machine, the server may search for the uploading method corresponding to the current moment based on the mapping relationship, and send the uploading method to the user in the prompt information for uploading the verification data. The server can also carry all the uploading methods in the prompt information and send it to the user, and recommend the uploading method corresponding to the current moment first, which is not limited in this specification.

On the other hand, when the user triggers the upload of the verification data, the server can also look up the upload method corresponding to the current moment according to the mapping relationship, and then return the upload method to the client, and the client can display it differently in the upload method list For the uploading method, for example, marking the uploading method as recommended, etc.

Of course, in this example, the mapping relationship can also be stored locally on the electronic device. When the user triggers the upload of the verification data, the client obtains the mapping relationship locally, and searches for the upload method corresponding to the current moment. There is no special restriction on this.

upload period upload method 8:00-18:00 Shot with another phone 18:00-8:00 Shooting in the mirror

Table 1

Please refer to Table 1 for an example of the mapping relationship between upload time period and upload method. Among them, during the period of 8:00-18:00, the user is likely to be at work, and other uploading methods for shooting with mobile phones can be recommended first. For example, users can ask colleagues to help with shooting. During the period from 18:00 to 8:00 the next day, the user is most likely at home, and the uploading method of using the mirror image can be recommended as a priority.

Of course, the mapping relationship shown in Table 1 is just an example, and in practical applications, more complex mapping relationships can be set, such as distinguishing working days and rest days, etc., which are not specially limited in this specification.

3. Claims

FIG. 10 is a schematic flowchart of a method for realizing an electronic device insurance claim according to an exemplary embodiment of the present specification.

Please refer to FIG. 10 , the method for realizing the claim can be applied to the server, including the following steps:

Step 1002: Receive a claim confirmation application sent by the accident equipment, the claim confirmation application is sent by the accident equipment after scanning the designated graphic code, and the claim confirmation application carries several identification factors of the accident equipment.

In this embodiment, after determining that the underwriting is passed, the server may save the mapping relationship between the policy and several identification factors of the electronic device insured by the user.

When making a claim, the user can use the electronic device that needs to settle the claim (hereinafter referred to as the accident device) to scan the graphic code used for claim settlement, such as the claim QR code, and the electronic device can then obtain several identification factors of the device, and then based on the The identification factor constructs a claim confirmation application, and sends the claim confirmation application to the server.

For example, after obtaining the electronic equipment that needs to be repaired and claimed, the maintenance personnel of electronic equipment can log in to the server with their user account in the client, and then scan the QR code for claim settlement, and the client parses the QR code for claim settlement. Obtain the specified claim settlement identification from the analysis, then obtain several identification factors of the device, and execute the steps of constructing the claim settlement confirmation application.

In this embodiment, the identification factor of the electronic device may include device identifications such as IDFA (Identifier For Advertising, advertising identifier), IDFV, and Android ID.

Step 1004: According to the mapping relationship, it is judged whether the insurance policies corresponding to several identification factors of the equipment in danger can be found.

Step 1006 , if the corresponding insurance policy is found, return a message allowing claim settlement to the insurance device.

After receiving the claim settlement confirmation application, the server may search the mapping relationship for insurance policies corresponding to several identification factors carried in the claim settlement confirmation application.

If the corresponding insurance policy is found, it can indicate that the electronic device in danger has purchased insurance before, and can return a message that allows the claim settlement, and the follow-up maintenance personnel can directly find the insurance company to pay the maintenance cost.

If the corresponding insurance policy is not found, there may be two situations, one is that the device has not purchased insurance, and the other is that the user has not used the device to purchase insurance, and further judgment is required.

It can be seen from the above description that the server in this embodiment can save the mapping relationship between several identification factors of the target device and the insurance policy, and subsequently judge whether the device has been insured according to the identification factor of the device in danger, so as to verify the claim. On the one hand, the combination of several identification factors such as IDFA is used to identify electronic devices, which can effectively solve the problem that application providers cannot obtain UDID (Unique Device Identifier) to identify electronic devices; on the other hand, the whole process does not require users to manually upload UDIDs, etc. Device identification greatly simplifies user operations and improves user insurance experience.

The following is a detailed description from the establishment of the mapping relationship and the realization of the claim settlement process.

1. Establishment of mapping relationship

Please refer to FIG. 11 , the process of establishing the above-mentioned mapping relationship may include the following steps:

Step 1102 , after the insurance application request of the electronic device is underwritten, it is determined whether the target device of the insurance application request is the initiating device of the electronic device insurance application request.

Step 1104, if yes, acquire several identification factors of the initiator device, and establish a mapping relationship between the several identification factors and the initiating device insurance policy.

In this embodiment, after determining that the insurance application request of the electronic device is underwritten, the server may determine whether the target device of the insurance application request is the initiating device of the electronic device insurance application request. That is, the server determines whether the user insured is a local device.

If so, the server may obtain several identification factors of the initiating device through the client, and establish a mapping relationship between the several identification factors and the corresponding insurance policies. For example, a mapping relationship between the several identification factors and policy identifications is established.

serial number IDFA IDFV policy 1 15dfa35g4 h41f6afg 123 2 4d5adffs5 Ghrte15f3 124 3 D4f3ad4fc Er5tjkb88 125

Table 2

Table 2 shows an example of the mapping relationship between equipment identification factors and insurance policies. It should be noted that Table 2 is only an example. In actual implementation, such a table may not be organized, and this specification does not make any special limit.

In the above process, the server can determine whether the target device is the initiating device of the electronic device insurance request through the following method.

Method 1: Judgment based on the properties of the target device

When determining that the attribute of the target device is an old machine, the server may determine that the target device is the initiating device of the electronic device insurance request. That is, the insured user has not recently purchased a new electronic device, and the user has also logged in using the initiating device.

When the server determines that the attribute of the target device is a new device, the server can obtain the judgment method of the attribute of the new device.

If the judgment path is the device identification judgment path, it can also be determined that the target device is the initiating device of the electronic equipment insurance request.

For the method of determining the attributes of the new machine, reference may be made to the embodiments shown in FIG. 2 to FIG. 3 , which will not be repeated in this specification.

Method 2: Judgment based on the user's choice

Please refer to the insurance application page shown in Figure 4 again. If the user applies for insurance through the insurance application page shown in Figure 4, the server can directly obtain the insured mobile phone selected by the user. If the user selects "this mobile phone", the target device can be directly determined. The device that initiated the insurance request for the electronic device.

In other examples, if the target device is not the initiating device of the electronic device insurance request, the server may save the mapping relationship between the insurance policy and the target device purchase order for verification in subsequent claims.

For example, if the method for judging the attribute "new machine" of the target device is the historical transaction data method, it can be determined that the target device is not the initiating device of the insurance request.

For another example, still taking FIG. 4 as an example, if the user selects "newly purchased mobile phone", it can also be determined that the target device is not the initiating device of the insurance request.

In this case, the server can obtain the order ID of the target device from the user's historical transaction data, and establish a mapping relationship between the order ID and the policy ID for verification and use in subsequent claims settlement.

Generally speaking, when the target device is not the initiating device of the electronic device insurance request, there are usually two cases, and the following is an example of a mobile phone for description.

The first scenario is when the user buys a new phone for himself, but uses the old phone to insure the new phone.

Please refer to FIG. 12. In this case, the process of establishing the aforementioned mapping relationship may include the following steps:

Step 1202, when it is detected that the new machine is logged in, it is determined whether there is an electronic device insurance policy corresponding to the logged in user.

In this case, after the user uses a new mobile phone, he usually uses the new mobile phone to log in to the server. After the user logs in, the server can obtain the logon of the logged-in mobile phone, and then determine whether the user logs in with the mobile phone for the first time, that is, whether it is a new phone login. .

If so, it can be determined whether there is an electronic device insurance policy corresponding to the logged-in user according to the user account, that is, to find out whether the user has purchased mobile phone insurance.

Step 1204, if it exists, determine whether the model of the new machine matches the model of the target device.

Step 1206, if there is a match, obtain several identification factors of the new device, and establish a mapping relationship between the several identification factors and the electronic device insurance policy of the logged-in user.

Based on the judgment result of the foregoing step 1102, if the user has purchased mobile phone insurance, the model of the target device can be searched according to the policy identifier.

In this embodiment, the server may determine whether the model of the new mobile phone used by the user is the model of the target device.

If it matches, it means that the new mobile phone currently used by the user is the mobile phone that the user has insured before, and then several identification factors of the new mobile phone can be obtained through the client, and a mapping relationship between the several identification factors and the insurance policy can be established.

When the subsequent server receives a claim settlement request for the new mobile phone, it can verify the claim settlement according to the mapping relationship between several identification factors and the insurance policy, thereby improving the accuracy of the claim settlement verification.

The second scenario is when a user buys a new phone for someone else and then uses their own phone to insure the new phone.

In this case, the probability that the user uses the purchased new mobile phone to log in to his user account is extremely low, and it is difficult for the server to automatically obtain several identification factors of the new mobile phone. The user can be prompted to log in with the new mobile phone, and the user can also be prompted to actively upload the identification factor of the new mobile phone.

2. Claims Process

In the aforementioned embodiment shown in FIG. 10 , when the user needs to settle a claim for damage to the electronic equipment, he can go directly to the designated maintenance center, and the maintenance personnel log in to the server with the emergency equipment and scan the QR code for verification.

Optionally, in other examples, when a claim needs to be settled for damage to an electronic device, the user may also submit a claim request online first. For example, the user may first use the insured electronic device to send a claim application, and after receiving the claim application, the server will The status of the corresponding policy is marked as In Claims and a list of designated repair centers can be returned to the user.

Users can send the equipment in danger to the designated maintenance center by face-to-face delivery, express delivery, etc., and the maintenance personnel of the designated maintenance center can log in to the server with their user account and scan the QR code for verification.

In such an implementation manner, after receiving the claim confirmation application, the server can look up the insurance policy corresponding to the insurance device in the mapping relationship between the insurance policy in the status of claim settlement and the identification factor, which can greatly reduce the number of comparisons and improve the claim settlement verification. s efficiency.

In other examples, after receiving the claim confirmation application sent by the accident device, if the corresponding insurance policy is not found according to several identification factors of the accident device, the server can obtain the log data of the accident device, such as the historical use of the accident device. The time point of the first login, and then the duration from the time point of the first login to the present is calculated, as the first duration, the first duration may represent the use duration of the emergency equipment that can be determined by the server.

The server can also obtain the order corresponding to the policy whose status is in claim settlement according to the mapping relationship between the order identifier and the policy identifier, and then calculate the time period from the time point when the order was generated to the present, as the second time period, which represents the second time period. Length of purchase of electronic equipment with a policy.

Then, the server may determine the magnitude relationship between the first duration and each of the second durations. If the first duration is longer than all the second durations, it means that the out-of-risk device has been used for longer than the purchase duration of each electronic device with insurance, and there is suspicion of insurance fraud, and a claim prohibition message can be returned to the out-of-risk device.

If the first duration is less than all of the second durations, a message allowing the claim settlement may be returned to the accident device.

It is worth noting that, in the process of judging the duration, it is also possible to judge whether the model of the target device matches the model of the device in danger, etc., which will not be repeated here in this manual.

It can be seen from the above description that the claim settlement scheme provided in this embodiment can save the mapping relationship between the purchase order of the new mobile phone and the insurance policy when the user applies for insurance for the new mobile phone, and then can follow the purchase duration of the new mobile phone and the use of the mobile phone in danger. It can also ensure the accuracy of claim verification while simplifying the operation of insurance/claims.

FIG. 13 is a schematic flowchart of another method for realizing an electronic device insurance claim according to an exemplary embodiment of the present specification.

Please refer to FIG. 13 , the method for realizing the claim can be applied to an electronic device, including the following steps:

Step 1302, after scanning the graphic code, determine whether the graphic code carries the specified claim settlement identifier.

Step 1304, if it is carried, obtain several identification factors of the device.

Step 1306: Construct a claim confirmation application based on the identification factors, and send the claim confirmation application to the server, so that the server can find the insurance policies corresponding to the identification factors.

Step 1308: Receive a message allowing claims settlement sent by the server after finding the insurance policies corresponding to the several identification factors.

For the implementation method of claim settlement in this embodiment, reference may be made to the foregoing embodiments, which will not be repeated here in this specification.

Fourth, the determination of insurance parameters

This manual provides a solution for determining dynamic insurance parameters, which can flexibly determine the insurance parameters of different users, is simple and convenient to implement, and can effectively improve the user's insurance experience.

The insurance parameters may include one or more of the insured amount, the insured period, the insured scope, and the insured type of insurance.

FIG. 14 is a schematic flowchart of a method for determining an insurance parameter according to an exemplary embodiment of the present specification.

Referring to FIG. 14, the insurance parameter determination method can be applied to the server, including the following steps:

Step 1402: After the underwriting is passed, several accumulated insurance parameters of the user are acquired.

In this embodiment, after it is determined that the insurance underwriting of the electronic device has passed, it can be determined whether the user has the corresponding accumulated insurance parameter based on the mapping relationship between the user and the accumulated insurance parameter.

If it exists, the accumulated insurance parameters corresponding to the user can be acquired.

If it does not exist, the insurance parameter that the user applies for this time can be determined as the default insurance parameter.

Step 1404: Determine the current insurance parameters for the current insurance application based on the accumulated insurance parameters and the default insurance parameters of the same type.

Based on the foregoing step 1402, after the accumulated insurance parameters of the user are acquired, the accumulated insurance parameters and the default insurance parameters of the same type may be added to obtain the insurance parameters of the corresponding type of the current insurance application.

Taking the screen insurance of electronic equipment as an example, suppose the default insurance amount is 1,000 yuan, and the default guarantee period is 1 year.

If the user's corresponding accumulated insurance amount is 20 yuan, and the accumulated insurance period is 1 month, the user's insurance amount this time can be determined as 1020 yuan, and the protection period is determined as 1 year and 1 month.

If the user's corresponding cumulative insurance amount is 10 yuan, and there is no corresponding cumulative insurance period, the user's insured amount can be determined as 1010 yuan this time, and the protection period is determined as 1 year.

If there is no accumulated insurance amount and accumulated guarantee period corresponding to the user, the insured amount of the user's insurance this time can be determined as the default insurance amount of 1,000 yuan, and the guarantee period is determined as the default guarantee period of 1 year.

In this embodiment, the server may send a message for acquiring the accumulated insurance parameters to the user after successfully executing the user's payment request. That is, the server sends the message to the user after the user successfully completes the payment. After acquiring the message, the client can display the entry for acquiring the accumulated insurance parameters on the payment result page.

The type of accumulated insurance parameter may be specified by the server and may be carried in the message by the server.

For example, the server can specify the type of the accumulated insurance parameter as the guarantee period, and the client can then display the entry for obtaining the accumulated guarantee period on the payment result page.

For another example, the server may specify that the types of accumulated insurance parameters are the amount of insurance and the period of guarantee, and the client may then display the entry for acquiring the accumulated amount of insurance and the entry for acquiring the accumulated guarantee period on the payment result page.

In this embodiment, the user can trigger the acquisition entry through the payment result page, and the client can send a corresponding type of cumulative insurance parameter acquisition request to the server.

Taking the request for obtaining the accumulated insurance amount as an example, after receiving the request for obtaining the accumulated insurance amount, the server may determine whether the user has a corresponding electronic device insurance policy.

If it exists, it means that the user has purchased electronic equipment insurance, and the server can obtain the current insurance amount of the corresponding insurance policy, then calculate the sum of the accumulated insurance amount and the current insurance amount, and update the current insurance amount of the insurance policy with the sum value.

Among them, the specific value of the accumulated insurance amount of different users can be the same, for example, the accumulated insurance amount of all users is 10 yuan;

The specific value of the accumulated insurance amount of different users may also be different. The server may determine the specific value of the accumulated insurance amount according to the user's payment amount. For example, the user with a higher payment amount has a higher specific value of the accumulated insurance amount, or the payment amount The cumulative insured amount for users whose payment amount is greater than or equal to the threshold is 20 yuan, and the cumulative insured amount for users whose payment amount is less than the threshold is 10 yuan, etc. This specification does not impose special restrictions on this.

If there is no electronic equipment insurance policy corresponding to the user, it means that the user has not taken out electronic equipment insurance, and the server can save the mapping relationship between the user and the accumulated insurance amount and its value. The mapping relationship determines the sum assured of the policy.

In this embodiment, the accumulated insurance parameter may have a valid duration.

Taking the insured amount as an example, the effective period can be preset, and is less than or equal to the guarantee period. Assuming that the effective period is 6 months, when the effective period of 6 months is reached, if the policy has not exceeded the guarantee period, the insured amount of the policy can be restored, for example, the current insured amount and the corresponding accumulated insured amount of the policy can be calculated The difference between the specified value and the difference is updated to the current sum assured of the policy.

Taking the guarantee period as an example, the effective period of the guarantee period is often for uninsured users. When the effective period reaches the effective period, if the user has not taken out electronic equipment insurance, it can be determined that the guarantee period is invalid.

In other examples, the cumulative insurance parameters may also be provided only for users who have purchased electronic equipment insurance.

For example, after the user's payment request is successfully executed, it can be determined whether there is an insurance policy corresponding to the user, and if so, a message for obtaining the accumulated insurance parameters can be sent to the user, and the client will then display the insurance policy on the payment result page. Access to the accumulated insurance parameters.

When the user triggers the acquisition entry, the server performs the update of the insurance parameters.

If there is no insurance policy corresponding to the user, the server will not send a message to the user to obtain the cumulative insurance parameters, and the client will not display the entry for obtaining the cumulative insurance parameters.

It can be seen from the above description that in this embodiment, the acquisition entry of the accumulated insurance parameters can be displayed on the payment result page, and the user can trigger the update of the insurance parameters based on the acquisition entry. Fast and convenient insurance service recommendation, reducing the complexity of user operation and saving user operation time.

Corresponding to the foregoing embodiments of the method for implementing insurance for electronic equipment, the present specification also provides embodiments of an apparatus for implementing insurance for electronic equipment.

The embodiments of the apparatus for implementing insurance for electronic equipment in this specification can be applied to a server. The apparatus embodiment may be implemented by software, or may be implemented by hardware or a combination of software and hardware. Taking software implementation as an example, a device in a logical sense is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory for operation by the processor of the server where it is located. From the perspective of hardware, as shown in FIG. 15, it is a hardware structure diagram of the server where the insurance implementation device of the electronic equipment of this specification is located, except for the processor, memory, network interface, and non-volatile memory shown in FIG. 15 In addition, the server where the device is located in the embodiment generally may also include other hardware according to the actual function of the server, which will not be repeated here.

Fig. 16 is a block diagram of an apparatus for realizing insurance of an electronic device according to an exemplary embodiment of the present specification.

Please refer to FIG. 16 , the insurance implementation device 1500 for electronic equipment can be applied to the server shown in FIG. 15 , including: a behavior data acquisition unit 1501 , a device attribute determination unit 1502 , an electronic equipment underwriting unit 1503 , a blacklist Judgment unit 1504 and insurance parameter determination unit 1505 .

Wherein, the behavior data acquisition unit 1501, in response to the electronic device insurance request initiated by the user, acquires the behavior data of the user;

A device attribute determining unit 1502, for determining the attribute of the target device of the insurance request according to the behavior data;

The electronic device underwriting unit 1503 underwrites the insurance application request according to the underwriting policy corresponding to the attribute.

Optionally, the electronic device underwriting unit 1503:

When the attribute of the target device is a new machine, it is determined that the underwriting is passed.

Optionally, the electronic device underwriting unit 1503:

When the attribute of the target device is an old machine, send a prompt message for uploading the verification data to the user;

In response to the verification data sent by the user, the insurance application request is underwritten according to the verification data.

Optionally, the electronic device underwriting unit 1503:

According to the mapping relationship between the upload period and the upload method, determine the upload method corresponding to the current moment;

The uploading method is carried in the prompt information and sent to the user.

Optionally, the behavior data acquisition unit 1501:

Obtain the historical transaction data of the user within a predetermined time period;

The device attribute determination unit 1502:

judging whether the historical transaction data includes purchase transaction data of the electronic device;

If so, it is determined that the attribute of the target device is a new machine.

Optionally, the device attribute determination unit 1502:

When the historical transaction data includes purchase transaction data of multiple electronic devices, sending the corresponding electronic device list to the user;

Receive a selection instruction sent by the user based on the electronic device list;

The electronic device specified in the user's selection instruction is determined as the target device.

Optionally, the behavior data acquisition unit 1501:

Obtain the device identification of the initiating device of the electronic device insurance request as the initiating identification;

Find the device identifier of the user's historical login device as a historical identifier;

The device attribute determination unit 1502:

Judging whether the originating identifier is the same as the historical identifier;

If not, it is determined that the attribute of the target device is a new machine.

Optionally, the device attribute determination unit 1502:

Determine whether the user is a trusted user according to the behavior data;

If the user is a trusted user, and the originating identifier is different from the historical identifier, it is determined that the attribute of the target device is a new device.

Optionally, the device attribute determination unit 1502:

When it cannot be determined that the attribute of the target device is a new machine, it is determined that the attribute of the target device is an old machine.

The blacklist judging unit 1504, in response to the electronic device insurance request initiated by the user, judges whether the user is on the blacklist;

If not, notify the behavior data acquisition unit 1501 to execute the step of acquiring the behavior data of the user.

The insurance parameter determination unit 1505 obtains several accumulated insurance parameters of the user after the underwriting is passed;

Determine the current insurance parameters for the current insurance application based on the accumulated insurance parameters and the default insurance parameters of the same type;

Wherein, the accumulated insurance parameter is acquired by the user based on the payment result page.

Optionally, the insurance parameter determination unit 1505:

After the user's payment request is successfully executed, a message for acquiring the accumulated insurance parameters is sent to the user, so that the electronic device displays the entry for acquiring the accumulated insurance parameters on the payment result page.

Optionally, the insurance parameter determination unit 1505:

In response to a request for acquiring the accumulated insurance parameters sent by the user based on the acquisition portal, determining whether there is an electronic device insurance policy corresponding to the user;

If it exists, acquiring the current insurance parameters of the electronic device insurance policy corresponding to the user;

The current insurance parameters of the electronic device policy are updated based on the accumulated insurance parameters and current insurance parameters of the same type.

Optionally, the insurance parameter determination unit 1505:

If there is no electronic device insurance policy corresponding to the user, the mapping relationship between the user and the accumulated insurance parameters is saved.

Optionally, the cumulative insurance parameter has a valid duration;

The insurance parameter determination unit 1505:

After the validity period of the accumulated insurance parameters is reached, the insurance parameters of the insurance policy are restored.

For details of the implementation process of the functions and functions of each unit in the above device, please refer to the implementation process of the corresponding steps in the above method, which will not be repeated here.

For the apparatus embodiments, since they basically correspond to the method embodiments, reference may be made to the partial descriptions of the method embodiments for related parts. The device embodiments described above are only illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in One place, or it can be distributed over multiple network elements. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this specification. Those of ordinary skill in the art can understand and implement it without creative effort.

The systems, devices, modules or units described in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, email sending and receiving device, game control desktop, tablet, wearable device, or a combination of any of these devices.

Corresponding to the foregoing embodiments of the method for implementing insurance for electronic equipment, the present specification further provides a device for implementing insurance for electronic equipment, the device comprising: a processor and a memory for storing machine-executable instructions. Among them, the processor and the memory are usually connected to each other by means of an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.

In this embodiment, the processor is caused to:

In response to the electronic device insurance request initiated by the user, obtain the behavior data of the user;

Determine the attributes of the target device of the insurance request according to the behavior data;

The insurance application request is underwritten according to the underwriting policy corresponding to the attribute.

Optionally, underwriting the insurance application request according to the underwriting policy corresponding to the attribute includes:

When the attribute of the target device is a new machine, it is determined that the underwriting is passed.

Optionally, underwriting the insurance application request according to the underwriting policy corresponding to the attribute includes:

When the attribute of the target device is an old machine, send a prompt message for uploading the verification data to the user;

In response to the verification data sent by the user, the insurance application request is underwritten according to the verification data.

Optionally, the sending prompt information for uploading the verification data to the user includes:

According to the mapping relationship between the upload period and the upload method, determine the upload method corresponding to the current moment;

The uploading method is carried in the prompt information and sent to the user.

Optionally, the acquiring the behavior data of the user includes:

Obtain the historical transaction data of the user within a predetermined time period;

The determining the attributes of the target device according to the behavior data includes:

judging whether the historical transaction data includes purchase transaction data of the electronic device;

If so, it is determined that the attribute of the target device is a new machine.

Optionally, also include:

When the historical transaction data includes purchase transaction data of multiple electronic devices, sending the corresponding electronic device list to the user;

Receive a selection instruction sent by the user based on the electronic device list;

The electronic device specified in the user's selection instruction is determined as the target device.

Optionally, the acquiring the behavior data of the user includes:

Obtain the device identification of the initiating device of the electronic device insurance request as the initiating identification;

Find the device identifier of the user's historical login device as a historical identifier;

The determining the attribute of the target device according to the behavior data includes:

Judging whether the originating identifier is the same as the historical identifier;

If not, it is determined that the attribute of the target device is a new machine.

Optionally, the determining the attribute of the target device according to the behavior data includes:

Determine whether the user is a trusted user according to the behavior data;

If the user is a trusted user, and the originating identifier is different from the historical identifier, it is determined that the attribute of the target device is a new device.

Optionally, the determining the attribute of the target device according to the behavior data includes:

When it cannot be determined that the attribute of the target device is a new machine, it is determined that the attribute of the target device is an old machine.

Optionally, also include:

In response to the electronic device insurance request initiated by the user, determine whether the user hits the blacklist;

If not, execute the step of acquiring the behavior data of the user.

Optionally, the electronic device insurance application request is a screen insurance application request of the electronic device.

Optionally, after the underwriting is passed, obtain several accumulated insurance parameters of the user;

Determine the current insurance parameters for the current insurance application based on the accumulated insurance parameters and the default insurance parameters of the same type;

Wherein, the accumulated insurance parameter is acquired by the user based on the payment result page.

Optionally, also include:

After the user's payment request is successfully executed, a message for acquiring the accumulated insurance parameters is sent to the user, so that the electronic device displays the entry for acquiring the accumulated insurance parameters on the payment result page.

Optionally, also include:

In response to a request for acquiring the accumulated insurance parameters sent by the user based on the acquisition portal, determining whether there is an electronic device insurance policy corresponding to the user;

If it exists, acquiring the current insurance parameters of the electronic device insurance policy corresponding to the user;

The current insurance parameters of the electronic device policy are updated based on the accumulated insurance parameters and current insurance parameters of the same type.

Optionally, also include:

If there is no electronic device insurance policy corresponding to the user, the mapping relationship between the user and the accumulated insurance parameters is saved.

Optionally, the cumulative insurance parameter has a valid duration;

The method also includes:

After the validity period of the accumulated insurance parameters is reached, the insurance parameters of the insurance policy are restored.

Optionally, the insurance parameters include: an insured amount and a guarantee period.

Optionally, the electronic device insurance application request is sent after the user triggers a designated entry on the payment result interface.

Corresponding to the foregoing embodiments of the insurance implementation method for electronic equipment, this specification also provides a computer-readable storage medium, where a computer program is stored on the computer-readable storage medium, and the program is executed by a processor to implement the following steps:

In response to the electronic device insurance request initiated by the user, obtain the behavior data of the user;

Determine the attributes of the target device of the insurance request according to the behavior data;

The insurance application request is underwritten according to the underwriting policy corresponding to the attribute.

Optionally, underwriting the insurance application request according to the underwriting policy corresponding to the attribute includes:

When the attribute of the target device is a new machine, it is determined that the underwriting is passed.

Optionally, underwriting the insurance application request according to the underwriting policy corresponding to the attribute includes:

When the attribute of the target device is an old machine, send a prompt message for uploading the verification data to the user;

In response to the verification data sent by the user, the insurance application request is underwritten according to the verification data.

Optionally, the sending prompt information for uploading the verification data to the user includes:

According to the mapping relationship between the upload period and the upload method, determine the upload method corresponding to the current moment;

The uploading method is carried in the prompt information and sent to the user.

Optionally, the acquiring the behavior data of the user includes:

Obtain the historical transaction data of the user within a predetermined time period;

The determining the attributes of the target device according to the behavior data includes:

judging whether the historical transaction data includes purchase transaction data of the electronic device;

If so, it is determined that the attribute of the target device is a new machine.

Optionally, also include:

When the historical transaction data includes purchase transaction data of multiple electronic devices, sending the corresponding electronic device list to the user;

Receive a selection instruction sent by the user based on the electronic device list;

The electronic device specified in the user's selection instruction is determined as the target device.

Optionally, the acquiring the behavior data of the user includes:

Obtain the device identification of the initiating device of the electronic device insurance request as the initiating identification;

Find the device identifier of the user's historical login device as a historical identifier;

The determining the attribute of the target device according to the behavior data includes:

Judging whether the originating identifier is the same as the historical identifier;

If not, it is determined that the attribute of the target device is a new machine.

Optionally, the determining the attribute of the target device according to the behavior data includes:

Determine whether the user is a trusted user according to the behavior data;

If the user is a trusted user, and the originating identifier is different from the historical identifier, it is determined that the attribute of the target device is a new device.

Optionally, the determining the attribute of the target device according to the behavior data includes:

When it cannot be determined that the attribute of the target device is a new machine, it is determined that the attribute of the target device is an old machine.

Optionally, also include:

In response to the electronic device insurance request initiated by the user, determine whether the user hits the blacklist;

If not, execute the step of acquiring the behavior data of the user.

Optionally, the electronic device insurance application request is a screen insurance application request of the electronic device.

Optionally, after the underwriting is passed, obtain several accumulated insurance parameters of the user;

Determine the current insurance parameters for the current insurance application based on the accumulated insurance parameters and the default insurance parameters of the same type;

Wherein, the accumulated insurance parameter is acquired by the user based on the payment result page.

Optionally, also include:

After the user's payment request is successfully executed, a message for acquiring the accumulated insurance parameters is sent to the user, so that the electronic device displays the entry for acquiring the accumulated insurance parameters on the payment result page.

Optionally, also include:

In response to a request for acquiring the accumulated insurance parameters sent by the user based on the acquisition portal, determining whether there is an electronic device insurance policy corresponding to the user;

If it exists, acquiring the current insurance parameters of the electronic device insurance policy corresponding to the user;

The current insurance parameters of the electronic device policy are updated based on the accumulated insurance parameters and current insurance parameters of the same type.

Optionally, also include:

If there is no electronic device insurance policy corresponding to the user, the mapping relationship between the user and the accumulated insurance parameters is saved.

Optionally, the cumulative insurance parameter has a valid duration;

The method also includes:

After the validity period of the accumulated insurance parameters is reached, the insurance parameters of the insurance policy are restored.

Optionally, the insurance parameters include: an insured amount and a guarantee period.

Optionally, the electronic device insurance application request is sent after the user triggers a designated entry on the payment result interface.

The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The above descriptions are only preferred embodiments of this specification, and are not intended to limit this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included in this specification. within the scope of protection.

Claims (34)

1. An insurance implementation method for electronic equipment, applied to a server, the method comprising: In response to the electronic device insurance request initiated by the user, obtain the behavior data of the user; Determine the attributes of the target device of the insurance request according to the behavior data; The insurance application request is underwritten according to the underwriting policy corresponding to the attribute. 2. The method according to claim 1, wherein underwriting the insurance request according to an underwriting policy corresponding to the attribute, comprising: When the attribute of the target device is a new machine, it is determined that the underwriting is passed. 3. The method according to claim 1, wherein underwriting the insurance request according to an underwriting strategy corresponding to the attribute, comprising: When the attribute of the target device is an old machine, send a prompt message for uploading the verification data to the user; In response to the verification data sent by the user, the insurance application request is underwritten according to the verification data. 4. The method according to claim 3, wherein the sending prompt information for uploading the verification data to the user comprises: According to the mapping relationship between the upload period and the upload method, determine the upload method corresponding to the current moment; The uploading method is carried in the prompt information and sent to the user. 5. The method according to claim 1, wherein the acquiring behavior data of the user comprises: Obtain the historical transaction data of the user within a predetermined time period; The determining the attributes of the target device according to the behavior data includes: judging whether the historical transaction data includes purchase transaction data of the electronic device; If so, it is determined that the attribute of the target device is a new machine. 6. The method of claim 5, further comprising: When the historical transaction data includes purchase transaction data of multiple electronic devices, sending the corresponding electronic device list to the user; Receive a selection instruction sent by the user based on the electronic device list; The electronic device specified in the user's selection instruction is determined as the target device. 7. The method according to claim 1, wherein the acquiring behavior data of the user comprises: Obtain the device identification of the initiating device of the electronic device insurance request as the initiating identification; Find the device identifier of the user's historical login device as a historical identifier; The determining the attribute of the target device according to the behavior data includes: Judging whether the originating identifier is the same as the historical identifier; If not, it is determined that the attribute of the target device is a new machine. 8. The method according to claim 7, wherein the determining the attribute of the target device according to the behavior data comprises: Determine whether the user is a trusted user according to the behavior data; If the user is a trusted user, and the originating identifier is different from the historical identifier, it is determined that the attribute of the target device is a new device. 9. The method according to any one of claims 5-8, wherein the determining the attribute of the target device according to the behavior data comprises: When it cannot be determined that the attribute of the target device is a new machine, it is determined that the attribute of the target device is an old machine. 10. The method of claim 1, further comprising: In response to the electronic device insurance request initiated by the user, determine whether the user hits the blacklist; If not, execute the step of acquiring the behavior data of the user. 11. The method of claim 1, further comprising: After the underwriting is passed, obtain several accumulated insurance parameters of the user; Determine the current insurance parameters for the current insurance application based on the accumulated insurance parameters and the default insurance parameters of the same type; Wherein, the accumulated insurance parameter is acquired by the user based on the payment result page. 12. The method of claim 11, further comprising: After the user's payment request is successfully executed, a message for acquiring the accumulated insurance parameters is sent to the user, so that the electronic device displays the entry for acquiring the accumulated insurance parameters on the payment result page. 13. The method of claim 12, further comprising: In response to a request for acquiring the accumulated insurance parameters sent by the user based on the acquisition portal, determining whether there is an electronic device insurance policy corresponding to the user; If it exists, acquiring the current insurance parameters of the electronic device insurance policy corresponding to the user; The current insurance parameters of the electronic device policy are updated based on the accumulated insurance parameters and current insurance parameters of the same type. 14. The method of claim 13, further comprising: If there is no electronic device insurance policy corresponding to the user, the mapping relationship between the user and the accumulated insurance parameters is saved. 15. The method of claim 11, the cumulative insurance parameter having a valid duration; The method also includes: After the validity period of the accumulated insurance parameters is reached, the insurance parameters of the insurance policy are restored. 16. The method of claim 11, the insurance parameters comprising: an amount of coverage and a term of coverage. 17. The method of claim 1, The electronic device insurance request is sent after the user triggers a designated entry on the payment result interface. 18. The method of claim 1, The electronic device insurance application request is a screen insurance application request for the electronic device. 19. A device for realizing insurance for electronic equipment, applied to a server, the device comprising: A behavior data acquisition unit, in response to an electronic device insurance request initiated by a user, to acquire the behavior data of the user; a device attribute determination unit, which determines the attribute of the target device of the insurance request according to the behavior data; The electronic device underwriting unit underwrites the insurance application request according to the underwriting policy corresponding to the attribute. 20. The apparatus according to claim 19, the electronic equipment underwriting unit: When the attribute of the target device is a new machine, it is determined that the underwriting is passed. 21. The apparatus of claim 19, the electronic equipment underwriting unit: When the attribute of the target device is an old machine, send a prompt message for uploading the verification data to the user; In response to the verification data sent by the user, the insurance application request is underwritten according to the verification data. 22. The apparatus according to claim 21, the electronic equipment underwriting unit: According to the mapping relationship between the upload period and the upload method, determine the upload method corresponding to the current moment; The uploading method is carried in the prompt information and sent to the user. 23. The apparatus according to claim 19, the behavior data acquisition unit: Obtain historical transaction data of the user within a predetermined time period; The device attribute determination unit: judging whether the historical transaction data includes purchase transaction data of electronic equipment; If so, it is determined that the attribute of the target device is a new machine. 24. The apparatus according to claim 23, the device attribute determination unit: When the historical transaction data includes purchase transaction data of multiple electronic devices, sending the corresponding electronic device list to the user; Receive a selection instruction sent by the user based on the electronic device list; The electronic device specified in the user's selection instruction is determined as the target device. 25. The apparatus according to claim 19, the behavior data acquisition unit: Obtain the device identification of the initiating device of the electronic device insurance request as the initiating identification; Find the device identifier of the user's historical login device as a historical identifier; The device attribute determination unit: Judging whether the originating identifier is the same as the historical identifier; If not, it is determined that the attribute of the target device is a new machine. 26. The apparatus according to claim 25, the device attribute determination unit: Determine whether the user is a trusted user according to the behavior data; If the user is a trusted user, and the originating identifier is different from the historical identifier, it is determined that the attribute of the target device is a new device. 27. The apparatus according to any one of claims 23-26, wherein the device attribute determination unit: When it cannot be determined that the attribute of the target device is a new machine, it is determined that the attribute of the target device is an old machine. 28. The apparatus of claim 19, further comprising: The blacklist judgment unit, in response to the electronic device insurance request initiated by the user, judges whether the user is on the blacklist; If not, notify the behavior data acquisition unit to execute the step of acquiring the behavior data of the user. 29. The apparatus of claim 19, further comprising: The insurance parameter determination unit, after passing the underwriting, obtains several accumulated insurance parameters of the user; Determine the current insurance parameters for the current insurance application based on the accumulated insurance parameters and the default insurance parameters of the same type; Wherein, the accumulated insurance parameter is acquired by the user based on the payment result page. 30. The apparatus according to claim 29, the insurance parameter determination unit: After the user's payment request is successfully executed, a message for acquiring the accumulated insurance parameters is sent to the user, so that the electronic device displays the entry for acquiring the accumulated insurance parameters on the payment result page. 31. The apparatus according to claim 30, the insurance parameter determination unit: In response to a request for acquiring the accumulated insurance parameters sent by the user based on the acquisition portal, determining whether there is an electronic device insurance policy corresponding to the user; If it exists, acquiring the current insurance parameters of the electronic device insurance policy corresponding to the user; The current insurance parameters of the electronic device policy are updated based on the accumulated insurance parameters and current insurance parameters of the same type. 32. The apparatus according to claim 30, the insurance parameter determination unit: If there is no electronic device insurance policy corresponding to the user, the mapping relationship between the user and the accumulated insurance parameters is saved. 33. The apparatus of claim 29, the cumulative insurance parameter having a duration of validity; The insurance parameter determination unit: After the validity period of the accumulated insurance parameters is reached, the insurance parameters of the insurance policy are restored. 34. A device for realizing insurance for electronic equipment, comprising: processor; memory for storing machine-executable instructions; Wherein, by reading and executing the machine executable instructions stored in the memory corresponding to the insurance implementation logic of the electronic device, the processor is caused to: In response to the electronic device insurance request initiated by the user, obtain the behavior data of the user; Determine the attributes of the target device of the insurance request according to the behavior data; The insurance application request is underwritten according to the underwriting policy corresponding to the attribute.

Images