WO2021228229A1

WO2021228229A1 - Insurance implementation for electronic devices

Info

Publication number: WO2021228229A1
Application number: PCT/CN2021/093837
Authority: WO
Inventors: 李晓瑞
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2020-05-15
Filing date: 2021-05-14
Publication date: 2021-11-18
Also published as: TW202145123A; CN111612637B; CN114648412A; CN111612637A

Abstract

Provided are an insurance implementation method and apparatus for electronic devices. Said method comprises: upon triggering the uploading of verification data for insuring by means of an electronic device, displaying an upload mode list (S502); and in response to an upload mode selected by a user, jumping to a corresponding upload mode guide page, wherein the upload mode guide page displays a corresponding upload entry for the user to upload, after triggering the upload entry, verification data of the current device on the basis of the upload mode (S504).

Description

Insurance realization of electronic equipment

Technical field

This manual relates to the field of Internet technology, and in particular to a method and device for realizing insurance for electronic equipment.

Background technique

With the rapid development of Internet technology, more and more insurance businesses can be realized through the Internet, for example, online insurance, online underwriting, online claims, etc. 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, this specification provides a method and device for implementing insurance for electronic equipment.

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

An electronic device insurance implementation method, applied to an electronic device, the method includes: displaying a list of uploading methods when triggering the uploading of verification data for electronic device insurance; A method guidance page, where a corresponding upload entry is displayed on the upload method guidance page, so that the user can upload the verification data of the device based on the upload method after triggering the upload entry.

An insurance realization device for electronic equipment, applied to electronic equipment, the device includes: a list display unit, which displays a list of uploading methods when the verification data for insuring of the electronic equipment is triggered to upload; a data upload unit, which responds to the upload selected by the user Mode, jump to the corresponding upload method guidance page, where the corresponding upload entry is displayed on the upload method guidance page, so that the user can upload the verification data of the device based on the upload method after triggering the upload entry.

An insurance implementation device for electronic equipment includes: a processor; a memory for storing machine executable instructions; wherein, by reading and executing the machine executable instructions stored in the memory and corresponding to the insurance logic of the electronic equipment, The processor is prompted: when triggering the upload of verification data for electronic equipment insuring, display a list of upload methods; in response to the upload method selected by the user, jump to the corresponding upload method guidance page, where the upload method guidance page displays The corresponding upload entry is for the user to upload the verification data of the device based on the upload mode after triggering the upload entry.

An embodiment of this specification implements it, providing a variety of methods for uploading verification data in the insurance process of electronic equipment. Users can choose a suitable method to upload verification data according to the actual situation, and realize online uploading of verification data, which is convenient and fast. Greatly enhance the user's insurance experience.

Description of the drawings

Fig. 1 is a schematic flowchart of a method for implementing insurance of an electronic device according to an exemplary embodiment of this specification.

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

Fig. 3 is a schematic flowchart of another method for determining attributes of a target device according to 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 shown in an exemplary embodiment of the present specification.

Fig. 6 is a schematic diagram of a list page of an insurance application method according to an exemplary embodiment of the present specification.

Fig. 7 is a schematic diagram of a guide page for an uploading method according to 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 a guide page for another upload method according to an exemplary embodiment of the present specification.

Fig. 10 is a schematic flowchart of a method for implementing insurance claims for electronic equipment 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 implementing insurance claims for electronic equipment according to an exemplary embodiment of the present specification.

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

Fig. 15 is a schematic structural diagram of an insurance realization device for electronic equipment according to an exemplary embodiment of the present specification.

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

Detailed ways

The exemplary embodiments will be described in detail here, and examples thereof are shown in the accompanying drawings. When the following description refers to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with this specification. Rather, they are merely examples of devices and methods consistent with some aspects of this specification as detailed in the appended claims.

The terms used in this specification are only for the purpose of describing specific embodiments, and are not intended to limit the specification. The singular forms of "a", "said" and "the" used in this specification and appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and/or" as used herein refers to and includes any or all possible combinations of one or more 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, the 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, without departing from the scope of this specification, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "when" or "in response to a certainty".

This manual provides an insurance implementation scheme for electronic equipment.

The above-mentioned electronic equipment insurance can be the screen insurance of the electronic equipment, or the comprehensive insurance insurance of the electronic equipment and other types of insurance that can be insured for the electronic equipment.

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

The insurance implementation scheme of the above electronic device can be implemented by the cooperation of the electronic device and the server. The server can be deployed by a service provider that provides insurance services, such as an insurance company, a third-party insurance sales platform, and so on.

In the process of realizing insurance business, electronic devices and servers can interact through wired or wireless 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 a registered user account in the client, which can also be called a user Interaction with the server.

The following describes the specific implementation process of this manual through four aspects of electronic equipment insurance, underwriting, claim settlement, and insurance parameter determination.

1. Insurance of electronic equipment

Please refer to FIG. 1, the insurance implementation method of the electronic device 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, obtain 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 designated portal of the payment result page, and the electronic device The user account is carried in the insurance request.

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 it is not hit, the server may perform the step of obtaining user behavior data.

The blacklist can be preset. For example, fraudulent users identified in history may be added to the blacklist. For another example, practitioners in the electronic equipment maintenance industry can also be added to the blacklist. For another example, practitioners in the 3C industry can also be added to the blacklist. The filtering of the blacklist can effectively filter out high-risk groups of fraudulent insurance, improve the security of online insurance, and reduce the risk of asset loss of insurance providers.

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

Based on the foregoing step 102, after obtaining the user's behavior data, the server can determine the attributes of the target electronic device (hereinafter referred to as the target device) that the user has insured for this time according to the behavior data. For example, for different behavior data, different methods can be used to determine the attributes of the target device.

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

Step 106, underwriting 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 foregoing step 104, the corresponding core can be searched for in the mapping relationship. And then adopt the corresponding underwriting policy to underwrite the electronic equipment insurance request.

If the attribute of the target equipment is a new machine, the inspection process can be eliminated, and the underwriting can be confirmed directly, thereby improving the efficiency of underwriting and enhancing 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 machine verification and assurance based on the verification data.

It can be seen from the above description that after receiving the electronic device insurance request, the server of this embodiment can obtain the user's behavior data, and then determine the attributes of the electronic device according to the behavior data, and check the underwriting policy corresponding to the attributes. Underwriting requests for insurance, and underwriting through differentiated underwriting strategies can improve the efficiency of underwriting while ensuring the accuracy of underwriting, thereby enhancing the user’s insurance experience.

The following describes in detail the method for determining the attributes of the target device through several embodiments.

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 can 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 obtain historical transaction data based on the identity information.

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

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

Step 206, if yes, it is determined that the attribute of the target device is a new machine.

Based on the foregoing step 202, after obtaining the historical transaction data of the user within a predetermined period of time, the server can determine whether the user has purchased an insurable electronic device within the predetermined period of time 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 attributes of the target device can be determined as a new machine.

For example, Xiaobai logs into Xiaobai’s account in the client loaded in his mobile phone, and then sends a mobile phone screen insurance application request to the server. After receiving the insurance request, the server can determine Xiaobai based on Xiaobai’s account. The identity information, such as unique identification, etc. Then, according to Xiaobai’s identity information, he obtains Xiaobai’s transaction data for the last 15 days from the e-commerce platform, and determines whether Xiaobai has bought a mobile phone based on the 15 days’ transaction data. If so, it can be inferred that Xiaobai wants to insure new For the purchased mobile phone, the attributes of the target device of the insurance application request may be determined 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 purchase.

Still taking Xiaobai as an example, assuming Xiaobai’s transaction data for the last 15 days includes the purchase records of two mobile phones, he can send a list including the two mobile phones to Xiaobai. The list may include mobile phone model, purchase date, purchase price, business information and other data. Xiaobai can select the mobile phone he wants to insure from the list. After receiving Xiaobai's selection instruction, the server can determine the mobile phone selected by Xiaobai as the target device for 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 that it is a new phone of this model.

In this embodiment, in addition to the e-commerce platform, the server can also obtain the user's historical transaction data from other channels. For example, it can obtain the user's offline transaction data in the physical shopping mall from the server of the physical shopping mall. There are no special restrictions on this.

In this embodiment, the server can determine whether the attribute of the insurance subject device is a new machine based on the user's historical transaction data. On the one hand, the user does not need to upload a purchase certificate, which can greatly simplify the user's insurance operation and improve the efficiency of insurance; on the other hand, It also breaks through the limitation that the new machine can only be insured at the time of purchase, greatly improving the user's insurance experience.

Referring to FIG. 3, the method for determining the attributes of the target device may include the following steps: Step 302: Obtain the device ID of the device that initiates the electronic device insurance request as the initiation ID.

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 separately by the client, and the device identification can also be carried by the client in the service request and reported to the server. 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 special restrictions on this.

The device identification may include: Android ID (Android ID), IDFV (Identifier For Vendor, application developer identification), IMEI (International Mobile Equipment Identity, International Mobile Equipment Identity), etc.

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

Step 304: Look up 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 identification of the historically logged-in device corresponding to the user. The database stores the device identification of the electronic device used when each user logs in to the server in the history.

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

In another example, considering that users usually do not frequently replace electronic devices without reason, the server may also obtain the device identification of the electronic device used by the user when logging in to the server last time from the database as a historical identification.

Step 306: Determine whether the initiation identifier is the same as the historical identifier.

In step 308, if they are not the same, it is determined that the attribute of the target device is a new machine.

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

When the server obtains the device identifier of the electronic device used by the user when logging in to the server last time as the historical identifier, if the initiation identifier is different from the historical identifier, it can indicate the electronic device that the user has replaced, and it can be inferred that the user has insured for the newly replaced electronic device. In turn, the attributes of the target device can be determined as a new machine.

If the server obtains multiple historical identifiers, it can respectively determine whether the initiation identifier is the same as each historical identifier. If they are not the same, it can indicate the electronic device that the user has replaced, and it can be inferred that the user has insured the newly replaced electronic device , And then the attributes of the target device can be determined as a new machine.

In other examples, when the device identification is used to determine the attributes of the target device, it can also be judged whether the user is a trusted user. The attribute is determined as the new machine, but the attribute of the target equipment is determined as the old machine, thereby improving the accuracy of the subsequent underwriting results and reducing the risk of fraud caused by skipping the inspection machine and passing the underwriting.

If the user is a trusted user, when the origination ID and the historical ID are not the same, the attributes of the target device can be determined as a new machine.

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

In an example, it can be determined whether the user's registration duration is less than the 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, etc.

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

For example, it can be judged whether the user has logged in to the user account in the past 1 month/3 months, etc.

On the contrary, if the user's registration duration is greater than or equal to the duration threshold, and the user account has been logged in recently, 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 identification of the user's login device, which can solve the problem of inaccurate identification of the new target device caused by incomplete acquisition of historical transaction data, without requiring the user Uploading the proof of purchase can greatly simplify the user's insurance operation and improve the efficiency of insurance.

It should be noted that this specification does not limit the execution sequence of the device attribute determination method of the embodiment shown in FIG. 2 and FIG. 3. In addition, in the above-mentioned implementation scheme for determining the attributes of the target device, if the attributes of the target device cannot be determined as a new device through historical transaction data, device identification, etc., the attributes of the target device can be determined as the old device, and subsequently based on user uploads. The verification data is underwritten to ensure the accuracy of the underwriting.

In addition, after the server determines the attributes of the target device, it can also send the attributes 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, and 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 new Machine, you can select other attributes.

In 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 page shown in Figure 4, where the "newly purchased mobile phone" and "this mobile phone" in the mobile phone protection item refer to the user's desire Is the target cell phone to be insured this cell phone?

If the user selects "Buy a new mobile phone", the server can obtain the user's historical transaction data, and then determine whether the user has recently purchased a new mobile phone based on the historical transaction data. Confirm that the underwriting is passed.

If the user selects "this phone", it means that the user wants to insure the phone currently in use. The mobile phone currently being used by the user 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 currently being used by the user may also be the user’s original old phone, that is, the attribute of the target device is "old phone" . In this case, the server may obtain the historical identification and the initiation identification to confirm the attributes of the target device, and may adopt the underwriting strategy corresponding to the determined attributes for underwriting.

Of course, in other examples, if the electronic device insured by the user is a multimedia device such as a video camera or smart TV, the user may still use a mobile phone to insure, but the "guaranteed device" cannot be a mobile phone. 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 the old machine, the server sends a prompt message to the user to upload verification data. The verification data may be data such as photos and videos of the target device. After the server receives the verification data, it can pass all The verification data is used to inspect the machine to determine whether the target equipment is intact and undamaged, and then the underwriting result is determined.

This manual provides a variety of ways to upload the verification data, and the user can choose according to the actual situation.

Please refer to FIG. 5, the method of uploading verification data can be applied to electronic devices, and includes the following steps: Step 502, when the verification data of the electronic device insured is triggered to upload, a list of uploading methods is displayed.

In this embodiment, after the user receives the prompt message 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 terminal of the electronic device can display a list of uploading methods, and the auxiliary equipment required for the corresponding uploading method can be displayed in the uploading method list, and the user can select the uploading method according to the actual situation.

Taking mobile phone screen insurance as an example, the verification data is a photo or video on 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 for others to assist in the shooting, and another mobile phone is needed; if the user cannot find another mobile phone, he can also choose another This kind of shooting method is to shoot yourself in the mirror.

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

Step 504, in response to the upload method selected by the user, jump to a corresponding upload method guidance page, where the upload method guidance page displays a corresponding upload entry for the user to trigger the upload entry based on the upload method Realize the upload of verification data of this device.

Based on the uploading method list shown in the foregoing step 502, the user can select a suitable uploading method, and the client can then jump to the guidance page of the corresponding uploading method. The guide page displays a detailed introduction of the corresponding upload method, and displays an upload entry, and the user can trigger the upload entry to take a photo of the verification data.

As can be seen from the above description, this embodiment provides a variety of methods for uploading verification data during the insuring process of electronic equipment. The user can choose a suitable method to upload verification data according to the actual situation to realize online upload of verification data, which is convenient and convenient. It is fast and greatly improves the user's insurance experience.

The two upload 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 and 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 entry, the front camera of the electronic device can be called, and images, videos, etc. can be collected through the front camera, and the image can be uploaded to the server as verification data after the image is 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 collection. This manual does not impose special restrictions on this.

In other examples, please refer to the user interface shown in Figure 8. Since shooting in the mirror requires the user to flip the phone and face the phone screen to the mirror, when the user triggers the upload portal, the timer can also be started to start timing. The customer sets aside the preparation time for turning the mobile phone, and only starts to collect the image when the timing period is reached. The timing duration may be 3 seconds. To facilitate the user's understanding, the client terminal may display the timing duration in a countdown manner.

This embodiment provides users with a way of uploading verification data photographed against a 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. Use other mobile phones to shoot

Still taking the mobile phone screen insurance as an example, if the user triggers the upload method of "using another mobile phone 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 and 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 entry, the client can display a verification graphic code used to upload verification data, such as a verification QR code. The verification two-dimensional code may carry data such as verification identification, user account, insurance information, and equipment identification.

The user or the person who assists the user can use another mobile phone to scan the verification QR code and analyze the verification QR code. If the verification identification is obtained by the analysis, the camera of the machine can be called for image collection, and After the collection is completed, the collected images and the data such as the user account number, insurance application information, and equipment identification obtained from the analysis of the two-dimensional code can be sent to the server, and the server can determine the corresponding insurance request based on the information and perform 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, the user retains the check graphic code through screenshots, etc., and sends the check image code to the same model of mobile phone, and subsequently collects the image of the same model of mobile phone 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 the camera is called, which simplifies user operations and improves user experience.

In addition, the above two methods are described using mobile phone screen insurance as an example. If the user is insured by other types of insurance such as comprehensive insurance, the verification data may also need to include the images on the side and back of the mobile phone. The client can output corresponding guidance. The instructions will not be repeated here.

In other examples, since the auxiliary equipment 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 the old device, the server can search for the upload mode corresponding to the current moment based on the mapping relationship, and carry the upload mode in the prompt message for uploading verification data and send it to the user. The server can also carry all the upload methods in the prompt message and send it to the user, and preferentially recommend the upload method corresponding to the current moment. This manual does not make special restrictions on this.

On the other hand, when the user triggers the upload of verification data, the server can also search for 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 in the upload method list. The uploading method, for example, marking the uploading method as recommended.

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

上传时段Upload period	上传方式Upload method
8:00-18:008:00-18:00	使用其他手机拍摄Use another phone to shoot
18:00-8:0018:00-8:00	对照镜子拍摄Shoot against the mirror

Table 1

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

Of course, the mapping relationship shown in Table 1 is just an example. In practical applications, more complicated mapping relationships can be set, such as distinguishing between working days and rest days, and this specification does not make special restrictions on this.

3. Settlement of claims

Please refer to FIG. 10, the implementation method of claim settlement can be applied to the server, and includes the following steps: Step 1002, receiving a claim confirmation application sent by an out-of-risk device, where the claim confirmation request is sent by the out-of-risk device after scanning a designated graphic code, The claim confirmation application carries several identification factors of the dangerous equipment.

In this embodiment, after the server determines that the underwriting is passed, the server may save the mapping relationship between the insurance 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 be settled (hereinafter referred to as the insurance device) to scan the graphic code for the claim, such as the two-dimensional code of the claim. The electronic device can then obtain several identification factors of the device, and then based The identification factor constructs a claim confirmation application, and sends the claim confirmation application to the server.

For example, after the maintenance personnel of electronic equipment get the electronic equipment that needs to be repaired and settled, they can log in to the server with their user account in the client, and then scan the two-dimensional code for claims, and the client parses the two-dimensional code for claims. If the designated claim identification is obtained from the analysis, several identification factors of the device can be obtained, and the steps of constructing a claim confirmation application can be executed.

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

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

In step 1006, if the corresponding insurance policy is found, a message that allows claims settlement is returned to the insurance equipment.

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

If the corresponding insurance policy is found, it can be stated that the electronic equipment in danger has been insured before, and a message that allows claims to be returned can be returned. Follow-up maintenance personnel can directly find the insurance company to pay for the maintenance costs.

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

It can be seen from the above description that the server in this embodiment can store the mapping relationship between several identification factors of the target device and the insurance policy, and subsequently determine whether the in-risk device is insured according to the identification factor of the out-of-risk device to verify the claim. On the one hand, IDFA and other identification factors are 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 entire process does not require users to manually upload device identifications such as UDID , Which greatly simplifies user operations and enhances user insurance experience.

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

1. The establishment of the mapping relationship

Referring to FIG. 11, the above-mentioned mapping relationship establishment process may include the following steps: Step 1102: After the electronic device insurance application request is underwritten, it is determined whether the subject device of the insurance application request is the initiating device of the electronic device insurance request.

Step 1104: If yes, obtain several identification factors of the initiating device, and establish a mapping relationship between the several identification factors and the initiating device insurance policy.

In this embodiment, the server can determine whether the target device of the insurance application request is the originating device of the electronic equipment insurance request after determining that the electronic device insurance request is underwritten. 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 policy. For example, the mapping relationship between the several identification factors and the policy identification is established.

序号Serial number	IDFAIDFA	IDFVIDFV	保单Insurance policy
11	15dfa35g415dfa35g4	h41f6afgh41f6afg	123123
22	4d5adffs54d5adffs5	Ghrte15f3Ghrte15f3	124124
33	D4f3ad4fcD4f3ad4fc	Er5tjkb88Er5tjkb88	125125

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. This specification does not make any special mentions. limit.

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

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

When the server determines that the attribute of the target device is the old machine, it can 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 used the initiating device to log in.

When the server determines that the attribute of the target device is a new machine, it can obtain a way to determine the attribute of the new machine.

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

The method of judging the attributes of the new machine can refer to the embodiments shown in FIGS. 2 to 3, which will not be repeated in this specification.

Method 2: Judge 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 protected 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 judgment method of the "new machine" attribute of the target device is the historical transaction data channel, 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 insurance policy ID for subsequent verification and use in claim settlement.

Generally speaking, when the target device is not the initiating device of the electronic device insurance request, there are usually two situations. The following takes a mobile phone as an example for illustration.

The first situation is that users buy new phones for themselves, but use old phones to insure the new phones.

Please refer to FIG. 12, in this case, the foregoing mapping relationship establishment process may include the following steps: Step 1202, when a new machine login is detected, it is determined whether there is an electronic device insurance policy corresponding to the logged-in user.

In this case, after using a new mobile phone, the user usually uses the new mobile phone to log in to the server. After the user logs in, the server can obtain the identification 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 machine login .

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

Step 1204: If it exists, it is determined whether the model of the new machine matches the model of the target device.

Step 1206: If they match, obtain several identification factors of the new machine, and establish a mapping relationship between the several identification factors and the electronic equipment 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 for according to the insurance policy identifier.

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

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

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

The second situation is that the user buys a new mobile phone for others, and then uses his own mobile phone to insure the new mobile phone.

In this case, the probability that the user logs in to his user account with the purchased new mobile phone is extremely low, and it is difficult for the server to automatically obtain several identification factors of the new mobile phone. Only the mapping relationship between the order identification and the insurance policy identification can be established. The user can be prompted to log in with a new mobile phone, and the user can also be prompted to actively upload the identification factor of the new mobile phone.

2. Claim process

In the embodiment shown in FIG. 10, when the user's electronic equipment is damaged and needs to be compensated, the user can go directly to the designated repair center, and the repairer can log in to the server with the out-of-risk equipment and scan the QR code for verification.

Optionally, in other examples, when an electronic device is damaged and requires compensation, the user can also submit a claim online first. For example, the user can first use the insured electronic device to send a claim application. The status of the corresponding insurance policy is marked as claiming, and the list of designated repair centers can be returned to the user.

The user can send the in-risk equipment to the designated repair center through personal delivery, express delivery, etc., and the repair personnel of the designated repair center can log in to the server with their user account and scan the QR code for verification.

In such an implementation manner, after the server receives the claim confirmation application, it can find the insurance policy corresponding to the insured equipment in the mapping relationship between the insurance policy in the claim status and the identification factor, which can greatly reduce the number of comparisons and improve the verification of the claim. s efficiency.

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

The server may also obtain the order corresponding to the insurance policy whose status is the claim according to the mapping relationship between the order identifier and the insurance policy identifier, and then calculate the length of time since the generation time of the order as the second time length, which represents The length of time to purchase electronic devices with insurance policies.

Then, the server can determine the magnitude relationship between the first duration and each second duration. If the first duration is greater than all the second durations, it can indicate that the duration of use of the insured device is greater than the purchase duration of each insured electronic device, and there is a suspicion of insurance fraud, and a message prohibiting claims settlement can be returned to the insured device.

If the first time duration is less than all the second time durations, a message allowing claims settlement may be returned to the emergency device.

It is worth noting that in the process of judging the duration, it can also be judged whether the model of the target equipment matches the model of the at-risk equipment, etc. This manual will not repeat them one by one here.

It can be seen from the above description that the claim settlement solution 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 insures the new mobile phone, and the subsequent purchase time of the new mobile phone and the use of the out-of-risk mobile phone Time is required to verify the claims, which can also ensure the accuracy of the claims verification when simplifying the operation of insurance/claims.

Please refer to FIG. 13, the implementation method of claim settlement can be applied to an electronic device, and includes the following steps: Step 1302, after scanning the graphic code, it is determined whether the graphic code carries a designated 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 factor, and send the claim confirmation application to the server, so that the server can find the insurance policies corresponding to the several identification factors.

Step 1308: Receive a claim permission message 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 embodiment, which will not be repeated in this specification.

Fourth, the determination of insurance parameters

This manual provides a dynamic insurance parameter determination scheme, which can flexibly determine the insurance parameters of different users, which is simple and convenient, and can effectively improve the user's insurance experience.

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

Please refer to FIG. 14, the method for determining insurance parameters can be applied to a server and includes the following steps: Step 1402, after the underwriting is passed, obtain a number of accumulated insurance parameters of the user.

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

If it exists, the accumulated insurance parameter corresponding to the user can be obtained.

If it does not exist, the insurance parameters that the user has insured for this time can be determined as the default insurance parameters.

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 user's accumulated insurance parameters are obtained, the accumulated insurance parameters and the default insurance parameters of the same type can be added to obtain the insurance parameters of the corresponding type of insurance this time.

Take the screen insurance of an electronic device as an example. Assume that the default insured amount is 1,000 yuan and the default guarantee period is 1 year. If the user’s corresponding cumulative sum assured is 20 yuan and the cumulative guarantee period is 1 month, the user’s current insurance sum can be determined as 1,020 yuan, and the guarantee period is determined to be 1 year and 1 month. If the user’s corresponding cumulative sum assured is 10 yuan and there is no corresponding cumulative guarantee period, the user’s current insurance sum can be determined as 1010 yuan, and the guarantee period is determined to be 1 year. If there is no cumulative sum assured and cumulative coverage period corresponding to the user, the user’s current insured amount can be determined as the default insured amount of 1,000 yuan, and the coverage period is determined as the default coverage period of 1 year.

In this embodiment, the server may send a message to the user to obtain accumulated insurance parameters 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 obtaining the message, the client can display the obtaining entry of the accumulated insurance parameter on the payment result page.

The type of the accumulated insurance parameter can be specified by the server, and can be carried in the message by the server. For example, the server may designate the type of the accumulated insurance parameter as the guarantee period, and the client may then display an entry for obtaining the accumulated guarantee period on the payment result page. For another example, the server may specify the type of the accumulated insurance parameter as the sum assured and the guarantee period, and the client can then display the access to the accumulated insurance amount and the access to the accumulated insurance period on the payment result page.

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

Taking the cumulative sum assured acquisition request as an example, after receiving the cumulative sum assured acquisition request, the server can determine whether the user has a corresponding electronic device insurance policy.

If it exists, it can indicate that the user has insured electronic equipment insurance. The server can obtain the current insured amount of the corresponding insurance policy, then calculate the sum of the accumulated insured amount and the current insured amount, and use the sum to update the current insured amount of the policy. Among them, the specific value of the cumulative sum assured of different users can be the same, for example, the cumulative sum assured of all users is 10 yuan; the specific value of the cumulative sum assured of different users can also be different, and the server can determine its cumulative insurance according to the user's payment amount. The specific value of the amount, for example, the higher the specific value of the cumulative insured amount of the user with the higher the payment amount, or the cumulative insured amount of the user whose payment amount is greater than or equal to the threshold is 20 yuan, and the cumulative amount of the user whose payment amount is less than the threshold The insured amount is 10 yuan, etc. This manual does not make special restrictions on this.

If there is no electronic device insurance policy corresponding to the user, it can indicate that the user has not yet insured electronic device insurance. The server can save the mapping relationship between the user and the cumulative insured amount and its value. When the user subsequently insures electronic device insurance, it can be based on the above The mapping relationship determines the insured amount of the policy.

In this embodiment, the cumulative insurance parameter may have a valid duration. Taking the amount of insurance as an example, the effective duration can be preset, which is less than or equal to the coverage period. Assuming that the validity period is 6 months, when the validity period of 6 months is reached, if the policy has not exceeded the coverage period, the coverage of the policy can be restored, such as calculating the current coverage of the policy and the corresponding cumulative coverage The difference between specific values, and update the difference as the current insured amount of the policy. Taking the guarantee period as an example, the effective duration of the guarantee period is usually for users who are not insured. When the effective period is reached, if the user has not yet insured the electronic device insurance, the guarantee period can be determined to be invalid.

In other examples, the cumulative insurance parameters may also be provided only for users who have insured for electronic equipment. 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 to obtain accumulated insurance parameters can be sent to the user, and the client can then display the insurance policy on the payment result page. Access to accumulate insurance parameters.

When the user triggers the acquisition portal, the server executes the update of insurance parameters. If there is no insurance policy corresponding to the user, the server does not send a message to the user to obtain the accumulated insurance parameter, and the client does not display an entry for obtaining the accumulated insurance parameter.

As can be seen from the above description, this embodiment can display the acquisition portal of accumulated insurance parameters on the payment result page, and the user can trigger the update of insurance parameters based on the acquisition portal, and realize simple and convenient insurance purchase through technological innovation, and provide users with fast , Convenient insurance service recommendation, reduce the cumbersome operation of users, and save users' operating time.

Corresponding to the foregoing embodiments of the insurance realization method for electronic equipment, this specification also provides an embodiment of the insurance realization apparatus for electronic equipment.

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

Please refer to FIG. 16, the insurance implementation device 1500 of the electronic device can be applied to the electronic device shown in FIG. 15, and includes: a list display unit 1501 and a data upload unit 1502. Among them, the list display unit 1501 displays the upload method list when triggering the upload of verification data for electronic equipment insured; the data upload unit 1502, in response to the upload method selected by the user, jumps to the corresponding upload method guidance page, the upload A corresponding upload entry is displayed on the method guidance page, so that the user can upload the verification data of the device based on the upload method after triggering the upload entry.

Optionally, the data upload unit 1502: when the upload entry of the first upload mode is triggered by the user, call the front camera of the device to collect images, and upload the collected images to the server as verification data of the device .

Optionally, the data uploading unit 1502: after calling the front camera of the device, start a timer to start timing; when the timing duration is reached, start to collect images.

Optionally, the data upload unit 1502: when the upload entry of the second upload mode is triggered by the user, generate a verification pattern code for other electronic devices to call their own camera to collect images after scanning the verification pattern code, And upload the collected image to the server as the verification data of the device.

Optionally, the list display unit 1501: when triggering the upload of verification data for electronic equipment insuring, search for the upload method corresponding to the current moment according to the preset mapping relationship between the upload period and the upload method; The found upload methods are displayed in the method list in a differentiated manner.

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

For the device embodiment, since it basically corresponds to the method embodiment, the relevant part can refer to the part of the description of the method embodiment. The device embodiments described above are merely illustrative, where the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, which can be located in one place. , Or it can be distributed to multiple network units. 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 work.

The systems, devices, modules, or units explained in the above embodiments may be specifically implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. The specific form of the computer can be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game console. , Tablet computers, wearable devices, or a combination of any of these devices.

Corresponding to the foregoing embodiment of the insurance implementation method for electronic equipment, this specification also provides an insurance implementation device for electronic equipment. The device includes a processor and a memory for storing machine executable instructions. Among them, the processor and the memory are usually connected to each other via an internal bus. In other possible implementation manners, the device may also include an external interface to be able to communicate with other devices or components.

In this embodiment, by reading and executing the machine executable instructions corresponding to the insurance implementation logic of the electronic device stored in the memory, the processor is prompted: Upload method list; in response to the upload method selected by the user, jump to the corresponding upload method guidance page, the upload method guidance page displays the corresponding upload entry, for the user to trigger the upload entry based on the upload Ways to upload the verification data of the device.

Optionally, when the upload entry of the first upload mode is triggered by the user, the front camera of the device is called to collect an image, and the collected image is uploaded to the server as the verification data of the device.

Optionally, the invoking the front camera of the device to collect images includes: starting a timer to start timing after invoking the front camera of the device; and starting to collect images when the timing period is reached.

Optionally, when the upload entry of the second upload mode is triggered by the user, a check pattern code is generated, so that other electronic devices can call their own camera to collect an image after scanning the check pattern code, and use the collected image as The verification data of this device is uploaded to the server.

Optionally, it also includes: when triggering the upload of verification data for electronic equipment insuring, searching for the corresponding uploading method at the current moment according to the mapping relationship between the preset upload period and the uploading method; distinguishing in the uploading method list Show the found upload method.

Optionally, auxiliary equipment required by the corresponding upload method is displayed in the upload method list.

Optionally, the insurance for the electronic device is a screen insurance for the electronic device.

Corresponding to the foregoing embodiment of the insurance implementation method for electronic equipment, this specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the following steps are implemented: When triggering the upload of verification data for electronic equipment insuring, the upload method list is displayed; in response to the upload method selected by the user, the user jumps to the corresponding upload method guidance page, and the corresponding upload entry is displayed on the upload method guidance page. This allows the user to upload the verification data of the device based on the upload mode after triggering the upload entry.

The foregoing describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or sequential order shown in order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The above are only the preferred embodiments of this specification and are not intended to limit this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in this specification. Within the scope of protection.

Claims

An insurance realization method for electronic equipment, applied to the electronic equipment, the method comprising:

When triggering the upload of verification data for electronic equipment insuring, display a list of upload methods;

In response to the upload method selected by the user, jump to the corresponding upload method guidance page. The upload method guidance page displays the corresponding upload entry for the user to implement the device based on the upload method after triggering the upload entry. Upload of verification data.
The method according to claim 1,

When the upload entry of the first upload mode is triggered by the user, the front camera of the device is called to collect an image, and the collected image is uploaded to the server as the verification data of the device.
The method according to claim 2, wherein the invoking the front camera of the device to collect images includes:

After calling the front camera of this device, start the timer to start timing;

When the timing period is reached, start to collect images.
The method according to claim 1,

When the upload entry of the second upload mode is triggered by the user, a check pattern code is generated for other electronic devices to call their own camera to collect images after scanning the check pattern code, and use the collected image as the check mark of the device. Upload the verification data to the server.
The method according to claim 1, further comprising:

When triggering the upload of verification data for electronic equipment insuring, according to the preset mapping relationship between the upload period and the upload method, search for the upload method corresponding to the current moment;

The found upload methods are displayed differently in the upload method list.
According to the method of any one of claims 1 to 3, the uploading method list displays auxiliary equipment required for the corresponding uploading method.
The method according to claim 1,

The insurance for the electronic device is the screen insurance of the electronic device.
An insurance realization device for electronic equipment, which is applied to electronic equipment, and includes:

The list display unit displays the upload method list when triggering the upload of verification data for electronic equipment insuring;

The data upload unit, in response to the upload method selected by the user, jumps to a corresponding upload method guidance page, and the upload method guidance page displays a corresponding upload entry for the user to trigger the upload entry based on the upload Ways to upload the verification data of the device.
The device according to claim 8, wherein the data uploading unit:

When the upload entry of the first upload mode is triggered by the user, the front camera of the device is called to collect an image, and the collected image is uploaded to the server as the verification data of the device.
The device according to claim 9, wherein the data uploading unit:

After calling the front camera of this device, start the timer to start timing;

When the timing period is reached, start to collect images.
The device according to claim 8, wherein the data uploading unit:

When the upload entry of the second upload mode is triggered by the user, a check pattern code is generated for other electronic devices to call their own camera to collect images after scanning the check pattern code, and use the collected image as the check mark of the device. Upload the verification data to the server.
8. The device according to claim 8, wherein the list display unit:

When triggering the upload of verification data for electronic equipment insuring, according to the preset mapping relationship between the upload period and the upload method, search for the upload method corresponding to the current moment;

The found upload methods are displayed differently in the upload method list.
An insurance realization device for electronic equipment, including:

processor;

Memory used to store machine executable instructions;

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

When triggering the upload of verification data for electronic equipment insuring, display a list of upload methods;

In response to the upload method selected by the user, jump to the corresponding upload method guidance page. The upload method guidance page displays the corresponding upload entry for the user to implement the device based on the upload method after triggering the upload entry. Upload of verification data.