WO2021228133A1 - 电子设备的保险实现 - Google Patents

电子设备的保险实现 Download PDF

Info

Publication number
WO2021228133A1
WO2021228133A1 PCT/CN2021/093296 CN2021093296W WO2021228133A1 WO 2021228133 A1 WO2021228133 A1 WO 2021228133A1 CN 2021093296 W CN2021093296 W CN 2021093296W WO 2021228133 A1 WO2021228133 A1 WO 2021228133A1
Authority
WO
WIPO (PCT)
Prior art keywords
insurance
user
attribute
electronic device
request
Prior art date
Application number
PCT/CN2021/093296
Other languages
English (en)
French (fr)
Inventor
李晓瑞
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2021228133A1 publication Critical patent/WO2021228133A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08—Insurance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K17/00—Methods or arrangements for effecting co-operative working between equipments covered by two or more of main groups G06K1/00 - G06K15/00, e.g. automatic card files incorporating conveying and reading operations
    • G06K17/0022—Methods or arrangements for effecting co-operative working between equipments covered by two or more of main groups G06K1/00 - G06K15/00, e.g. automatic card files incorporating conveying and reading operations arrangements or provisious for transferring data to distant stations, e.g. from a sensing device
    • G06K17/0025—Methods or arrangements for effecting co-operative working between equipments covered by two or more of main groups G06K1/00 - G06K15/00, e.g. automatic card files incorporating conveying and reading operations arrangements or provisious for transferring data to distant stations, e.g. from a sensing device the arrangement consisting of a wireless interrogation device in combination with a device for optically marking the record carrier
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/01—Customer relationship services
    • G06Q30/012—Providing warranty services

Definitions

  • This manual relates to the field of Internet technology, and in particular to a method and device for realizing insurance for electronic equipment.
  • this specification provides a method and device for implementing insurance for electronic equipment.
  • a method for implementing insurance for electronic equipment applied to a server, the method comprising: in response to an electronic equipment insurance request initiated by a user, acquiring behavior data of the user; The behavior data determines the attributes of the equipment subject to the insurance application; and underwrites the insurance application according to the underwriting policy corresponding to the attributes.
  • An insurance implementation device for electronic equipment applied to a server, the device includes: a behavior data acquisition unit, which acquires behavior data of the user in response to an electronic equipment insurance request initiated by a user; and an equipment attribute determination unit, according to the behavior The data determines the attribute of the target device of the insurance request; the electronic equipment underwriting unit underwrites the insurance request according to the underwriting policy corresponding to the attribute.
  • An insurance realization device for electronic equipment includes: a processor; a memory for storing machine executable instructions; wherein, by reading and executing the machine executable instructions corresponding to the insurance realization logic of the electronic equipment stored in the memory, The processor is prompted to: in response to a user-initiated electronic device insurance request, obtain the user's behavior data; determine the attributes of the target device of the insurance request according to the behavior data; and according to the underwriting policy corresponding to the attributes Underwrite the insurance request.
  • An embodiment of this specification realizes that after receiving the electronic device insurance request, the server can obtain the user's behavior data, and then determine the attribute of the electronic device according to the behavior data, and make the insurance request according to the underwriting policy corresponding to the attribute Underwriting and underwriting through differentiated underwriting strategies can improve underwriting efficiency while ensuring the accuracy of underwriting, thereby enhancing the user's insurance experience.
  • Fig. 1 is a schematic flowchart of a method for implementing insurance of an electronic device according to an exemplary embodiment of the present specification.
  • Fig. 2 is a schematic flowchart of a method for determining attributes of a target device according to an exemplary embodiment of this 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 shown in 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 implementing insurance for electronic equipment according to an exemplary embodiment of the present specification.
  • 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.
  • first information may also be referred to as second information, and similarly, the second information may also be referred to as first information.
  • 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 Assistants), 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.
  • 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.
  • 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.
  • Fig. 1 is a schematic flowchart of a method for implementing insurance of an electronic device according to an exemplary embodiment of the present specification.
  • the insurance implementation method of the electronic device can be applied to the server, including the following steps:
  • Step 102 In response to an electronic device insurance request initiated by the user, obtain behavior data of the user.
  • the user can initiate the electronic device insurance request through the electronic device insurance sales portal.
  • 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 number is carried in the insurance application request.
  • the server 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.
  • 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 capital loss for insurance providers.
  • Step 104 Determine the attributes of the target device of the insurance application request according to the 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.
  • the target device For example, for different behavior data, different methods can be used to determine the attributes of the target device.
  • 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.
  • 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 found in the mapping relationship. And then use the corresponding underwriting policy to underwrite the electronic equipment insurance request. If the attribute of the target device is a new machine, the inspection process can be eliminated, and the underwriting process can be determined directly, 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 machine verification and assurance based on the verification data.
  • the server of this embodiment can obtain the user's behavior data, and then determine the attribute of the electronic device according to the behavior data, and check the underwriting policy corresponding to the attribute.
  • the underwriting request is underwritten, and underwriting through a differentiated underwriting strategy can improve the underwriting efficiency while ensuring the accuracy of the underwriting, thereby enhancing the user’s insurance experience.
  • 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.
  • 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.
  • 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. .
  • 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.
  • 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.
  • the server can 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 attributes of the target device can be determined as a new machine.
  • Xiaobai logs into Xiaobai’s account in the client loaded in his mobile phone, and then sends an insurance request for mobile phone screen insurance to the server.
  • the server can determine Xiaobai based on Xiaobai’s account.
  • the identity information such as unique identification, etc.
  • 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 purchased 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.
  • 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.
  • 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 of these 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.
  • 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 that model.
  • the server in addition to the e-commerce platform, 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.
  • the server can determine whether the attribute of the insurance subject device is a new machine based on the user's historical transaction data.
  • 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 restriction that the new machine 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 attributes of a target device according to an exemplary embodiment of the present specification.
  • 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.
  • 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.
  • 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 identifier may include: Android ID (Android ID), IDFV (Identifier For Vendor, application developer identification), IMEI (International Mobile Equipment Identity, International Mobile Equipment Identity), etc.
  • 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.
  • 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.
  • 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.
  • 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.
  • step 308 if they are not the same, it is determined that the attribute of the target device is a new machine.
  • the server can determine whether the initiation identifier and the historical identifier are the same.
  • 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. Furthermore, the attributes of the target device can be determined as a new machine.
  • the server 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.
  • the device identification when 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 originating identifier and the historical identifier are not the same, the attributes of the target device can be determined as a new machine.
  • 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.
  • 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 logged-in 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.
  • this specification does not limit the execution sequence of the device attribute determination method of the embodiment shown in FIG. 2 and FIG. 3.
  • 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.
  • the server can also send the attributes of the target device to the client for the user to confirm, 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.
  • the client can display the insurance application 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 mobile phone to be insured this 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.
  • 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 user's original old phone, that is, the attribute of the target device is "old phone” .
  • 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.
  • 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.
  • the server sends a prompt message to the user to upload verification data.
  • the verification data can 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 to determine the underwriting result.
  • This manual provides a variety of ways to upload the verification data, and the user can choose according to the actual situation.
  • Fig. 5 is a schematic flowchart of a method for uploading verification data shown in an exemplary embodiment of the present specification.
  • the method of uploading verification data can be applied to an electronic device, and includes the following steps: Step 502, when the verification data for insuring of the electronic device is triggered to upload, a list of uploading methods is displayed.
  • the user can upload the verification data at a convenient time.
  • 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.
  • the verification data is a photo or video on the mobile phone screen.
  • Figure 6 provides two mobile phone screen shooting methods. One is for others to assist in the shooting and requires another mobile phone; 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.
  • 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 shoot the verification data.
  • 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 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.
  • 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.
  • the rear camera can also be called by default, and the user can manually switch to the front camera for image collection. This manual does not impose special restrictions on this.
  • the timer can also be started to start timing.
  • the customer sets aside the preparation time for turning over the mobile phone, and starts to collect the image when the timing period is reached.
  • the timing duration may be 3 seconds.
  • 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.
  • 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.
  • the client can display a verification graphic code used to upload verification data, such as a verification QR code.
  • the verification QR code can carry data such as verification identification, user account number, 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 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.
  • the verification graphic code is a dynamic graphic code, for example, it can be refreshed once per minute.
  • dynamic graphic coding can effectively prevent users from cheating. For example, users can save the check graphic code by taking screenshots, and send the check image code to the same model of mobile phone, and subsequently collect the image of the same model of mobile phone as verification Data etc.
  • 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.
  • 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.
  • the server may pre-store the mapping relationship between the uploading method and the uploading time period.
  • the server 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 uploading methods in the prompt message and send it to the user, and preferentially recommend the corresponding uploading method at the current moment. This manual does not make special restrictions on this.
  • the server can also find the corresponding upload method at 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.
  • mapping relationship can also be stored locally in the electronic device.
  • 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.
  • Table 1 an example of the mapping relationship between upload period and upload method.
  • the user is most likely to be at work, and the upload method of using other mobile phones can be recommended first.
  • the user can ask a colleague to help with the shooting.
  • the upload method of contrast mirror shooting can be recommended first.
  • 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.
  • 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.
  • 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, the claim confirmation request being 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.
  • the server may save the mapping relationship between the insurance policy and several identification factors of the electronic device insured by the user.
  • the user can use the electronic device that needs to settle the claim (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.
  • the maintenance personnel of electronic equipment 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. From the analysis to obtain the designated claim identification, several identification factors of the device can be obtained, and the steps of constructing a claim confirmation application can be executed.
  • 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.
  • step 1006 if the corresponding insurance policy is found, a message that allows claims settlement is returned to the insurance outlet.
  • the server may search the mapping relationship for insurance policies corresponding to several identification factors carried in the claim confirmation application.
  • 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.
  • the server of 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 has been insured according to the identification factor of the out-of-risk device, so as to verify the claims.
  • 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 devices such as UDIDs.
  • UDID Unique Device Identifier
  • mapping relationship establishment process may include the following steps:
  • Step 1102 After the electronic device insurance request is underwritten, it is determined whether the subject device of the insurance request is the originating 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.
  • the server determines whether the target device of the insurance request is the device that initiated the electronic device insurance request. That is, the server determines whether the user insured is a local device.
  • 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 insurance policy identification is established.
  • 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.
  • 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 equipment
  • the server may determine that the target device is the initiator 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.
  • 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 for judging the attributes of the new machine can refer to the embodiments shown in FIGS. 2 to 3, and the description will not be repeated here.
  • Method 2 Judge based on user's choice
  • 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.
  • 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 subject equipment is the historical transaction data route, it can be determined that the subject equipment is not the initiator 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.
  • 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.
  • 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 the user buys a new mobile phone for himself, but uses the old mobile phone to insure the new mobile phone.
  • 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.
  • the user after using a new mobile phone, the user usually uses the new mobile phone to log in to the server.
  • 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, acquire a number of identification factors of the new machine, and establish a mapping relationship between the number of identification factors and the electronic equipment insurance policy of the logged-in user.
  • the model of the target device can be searched for according to the insurance policy identifier.
  • 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.
  • 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 mobile phone to insure the new mobile phone.
  • the probability of a user logging in to his user account using a new phone purchased is extremely low.
  • the user 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 scan the QR code for verification after logging in to the server using the out-of-risk equipment.
  • the user can also submit a claim online first.
  • the user can first use the insured electronic device to send a claim application.
  • the server After receiving the claim application, the server will 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 by personal delivery, express delivery, etc.
  • 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.
  • the server after the server receives the claim confirmation application, it can find the insurance policy corresponding to the insurance device in the mapping relationship between the insurance policy and the identification factor in the status of claiming, which can greatly reduce the number of comparisons and improve the verification of the claim. s efficiency.
  • the server 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 can also obtain the order corresponding to the insurance policy whose status is in the claim status according to the mapping relationship between the order ID and the policy ID, and then calculate the length of time since the point of generation of the order as the second length of time, which represents The length of time to purchase electronic equipment 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 second durations, it may 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 can 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 dangerous equipment, etc., and this manual will not repeat them one by one here.
  • 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 ensure the accuracy of the claims verification while simplifying the operation of insurance/claims.
  • 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.
  • the implementation method of claim settlement can be applied to electronic equipment, including 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.
  • 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 duration of the insurance, the scope of the insurance, and the insurance types of insurance.
  • Fig. 14 is a schematic flowchart of a method for determining insurance parameters according to an exemplary embodiment of the present specification.
  • 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.
  • the accumulated insurance parameter corresponding to the user can be obtained.
  • 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.
  • 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.
  • the screen insurance of an electronic device 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 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 insurance sum is 10 yuan and there is no corresponding cumulative insurance period, the user’s current insurance sum can be determined as 1010 yuan, and the insurance period is determined to be 1 year. If there is no accumulated sum assured and accumulative guarantee period corresponding to the user, the sum insured of the user can be determined as the default sum assured of 1,000 yuan this time, and the guarantee period is determined as the default guarantee period of 1 year.
  • 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.
  • 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.
  • the server may specify the type of cumulative insurance parameters as the sum assured and the guarantee period, and the client can then display the access to the cumulative sum assured and the access to the cumulative guarantee period on the payment result page.
  • 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.
  • 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 for 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.
  • 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.
  • the server can save the mapping relationship between the user and the cumulative insured amount and its value. When the user subsequently applies for electronic equipment insurance, it can be based on the above The mapping relationship determines the insured amount of the policy.
  • the cumulative insurance parameter may have a valid duration.
  • 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 the specific values, and update the difference as the current insured amount of the policy.
  • 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 for electronic equipment insurance, the guarantee period can be determined to be invalid.
  • the cumulative insurance parameters may also be provided only for users who have insured for electronic equipment.
  • 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 cumulative insurance parameter, and the client does not display the entry for obtaining the cumulative insurance parameter.
  • 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 application through technological innovation, and provide users with fast , Convenient insurance service recommendation, reduce the cumbersome operation of users, and save users' operating time.
  • this specification also provides an embodiment of the insurance realization apparatus for electronic equipment.
  • the embodiments of the insurance realization device of the electronic equipment in this specification can be applied on the server.
  • 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 server where it is located.
  • 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 Figure 15
  • the server where the device is located in the embodiment usually may include other hardware according to the actual function of the server, which will not be repeated here.
  • Fig. 16 is a block diagram of a device for implementing insurance for electronic equipment according to an exemplary embodiment of the present specification.
  • the insurance implementation device 1500 of the electronic device can be applied to the server shown in FIG.
  • the behavior data obtaining unit 1501 obtains the user's behavior data in response to the electronic device insurance request initiated by the user; the device attribute determining unit 1502 determines the attributes 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.
  • 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.
  • the electronic device underwriting unit 1503 when the attribute of the target device is an old device, send a prompt message for uploading verification data to the user; in response to the verification data sent by the user, according to the verification The data underwrites the insurance request.
  • the electronic device underwriting unit 1503 determines the upload mode corresponding to the current moment according to the mapping relationship between the upload period and the upload mode; carries the upload mode in the prompt information and sends it to the user.
  • the behavior data acquiring unit 1501 acquiring historical transaction data of the user within a predetermined time period; the device attribute determining unit 1502: determining whether the historical transaction data includes electronic device purchase transaction data; If it is, it is determined that the attribute of the target device is a new machine.
  • the device attribute determining unit 1502 when the historical transaction data includes purchase transaction data of multiple electronic devices, send a corresponding electronic device list to the user; receive a selection sent by the user based on the electronic device list Instruction; the electronic device specified in the user's selection instruction is determined as the target device.
  • the behavior data obtaining unit 1501 obtains the device ID of the initiating device of the electronic device insurance request as the initiation ID; finds the device ID of the user's historical login device as the history ID; the device attribute is determined
  • Unit 1502 Determine whether the initiation identifier and the historical identifier are the same; if they are not the same, determine that the attribute of the target device is a new machine.
  • the device attribute determining unit 1502 judges whether the user is a trusted user according to the behavior data; if the user is a trusted user, and the initiation identifier is different from the historical identifier, It is determined that the attribute of the target device is a new machine.
  • the device attribute determining unit 1502 when it cannot be determined that the attribute of the target device is a new device, determine that the attribute of the target device is an old device.
  • the blacklist determining unit 1504 in response to the electronic device insurance request initiated by the user, determines whether the user hits the blacklist; if not, the behavior data acquiring unit 1501 is notified to perform the step of acquiring behavior data of the user.
  • the insurance parameter determination unit 1505 obtains a number of accumulated insurance parameters of the user after the underwriting is passed; determines the current insurance parameters for this insurance based on the accumulated insurance parameters and the same type of default insurance parameters; wherein, the accumulated insurance parameters The insurance parameters are obtained by the user based on the payment result page.
  • the insurance parameter determination unit 1505 after successfully executing the user's payment request, send a message to the user to obtain accumulated insurance parameters, so that the electronic device can display the accumulated insurance parameters on the payment result page. Access to insurance parameters.
  • the insurance parameter determination unit 1505 in response to a request for acquiring an accumulated insurance parameter sent by the user based on the acquisition portal, determine whether there is an electronic device insurance policy corresponding to the user; Current insurance parameters of the electronic equipment insurance policy; updating the current insurance parameters of the electronic equipment insurance policy according to the accumulated insurance parameters and the current insurance parameters of the same type.
  • the insurance parameter determination unit 1505 if there is no electronic device insurance policy corresponding to the user, save the mapping relationship between the user and the accumulated insurance parameters.
  • the accumulated insurance parameter has a valid duration; the insurance parameter determining unit 1505:
  • the insurance parameter of the insurance policy is restored.
  • the relevant part can refer to the part of the description of the method embodiment.
  • the device embodiments described above are merely illustrative, and 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 without creative work.
  • 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.
  • this specification also provides an insurance implementation device for electronic equipment.
  • the device includes a processor and a memory for storing machine executable instructions.
  • the processor and the memory are usually connected to each other via an internal bus.
  • the device may also include an external interface to be able to communicate with other devices or components.
  • the processor is prompted to: in response to the electronic device insurance request initiated by the user, obtain the User behavior data; determine the attributes of the target device of the insurance request according to the behavior data; underwrite the insurance request according to the underwriting policy corresponding to the attributes.
  • the underwriting of the insurance application request according to the underwriting policy corresponding to the attribute includes: determining that the underwriting is passed when the attribute of the target device is a new machine.
  • the underwriting of the insurance request according to the underwriting policy corresponding to the attribute includes: when the attribute of the target device is an old phone, sending a prompt message for uploading verification data to the user; responding Based on the verification data sent by the user, the insurance request is underwritten according to the verification data.
  • the sending the prompt information for uploading verification data to the user includes: determining the upload mode corresponding to the current moment according to the mapping relationship between the upload period and the upload mode; and carrying the upload mode in the prompt The message is sent to the user.
  • said acquiring behavior data of said user includes: acquiring historical transaction data of said user within a predetermined time period; said determining an attribute of a target device according to said behavior data includes: determining said historical transaction data Whether the purchase transaction data of the electronic device is included in the data; if so, it is determined that the attribute of the target device is a new machine.
  • the method further includes: when the historical transaction data includes purchase transaction data of multiple electronic devices, sending a corresponding electronic device list to the user; receiving a selection instruction sent by the user based on the electronic device list; The electronic device specified in the selection instruction is determined to be the target device.
  • the obtaining the user's behavior data includes: obtaining the device identifier of the initiating device of the electronic device insurance request as the initiating identifier; searching for the device identifier of the user's historical login device as the historical identifier; Determining the attribute of the target device according to the behavior data includes: determining whether the initiation identifier is the same as the historical identifier; if not, determining that the attribute of the target device is a new machine.
  • the determining the attribute of the target device according to the behavior data includes: judging whether the user is a trusted user according to the behavior data; if the user is a trusted user, and the initiation identifier If it is different from the historical identifier, it is determined that the attribute of the target device is a new machine.
  • 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 device, determining that the attribute of the target device is an old device.
  • the method further includes: in response to an electronic device insurance request initiated by the user, determining whether the user hits the blacklist; if not, executing the step of obtaining behavior data of the user.
  • the electronic device insurance request is a screen insurance insurance request of the electronic device.
  • the underwriting after the underwriting is passed, obtain several cumulative insurance parameters of the user; determine the current insurance parameters for this insurance based on the cumulative insurance parameters and the same type of default insurance parameters; wherein, the cumulative insurance parameters Obtained by the user based on the payment result page.
  • the method further includes: after the user's payment request is successfully executed, sending a message for acquiring accumulated insurance parameters to the user, so that the electronic device can display the access to the accumulated insurance parameters in the payment result page .
  • the method further includes: in response to a request for obtaining accumulated insurance parameters sent by the user based on the obtaining portal, determining whether there is an electronic device insurance policy corresponding to the user; if so, obtaining the current electronic device insurance policy corresponding to the user Insurance parameters: update the current insurance parameters of the electronic equipment insurance policy according to the accumulated insurance parameters and the current insurance parameters of the same type.
  • the method further includes: if there is no electronic device insurance policy corresponding to the user, saving the mapping relationship between the user and accumulated insurance parameters.
  • the cumulative insurance parameter has a valid duration; the method further includes: restoring the insurance parameters of the policy after the valid duration of the cumulative insurance parameter is reached.
  • the insurance parameters include: an insured amount and a guarantee period.
  • the electronic device insurance request is sent after the user triggers a designated entry on the payment result interface.
  • 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: In response to an electronic device insurance request initiated by a user, the user's behavior data is obtained; the attributes of the subject equipment of the insurance request are determined according to the behavior data; the insurance request is verified according to the underwriting policy corresponding to the attributes Save.
  • the underwriting of the insurance application request according to the underwriting policy corresponding to the attribute includes:
  • the underwriting of the insurance application request according to the underwriting policy corresponding to the attribute includes:
  • a prompt message for uploading verification data is sent to the user; in response to the verification data sent by the user, the insurance request is underwritten according to the verification data.
  • the sending the prompt information for uploading verification data to the user includes: determining the upload mode corresponding to the current moment according to the mapping relationship between the upload period and the upload mode; and carrying the upload mode in the prompt The message is sent to the user.
  • said acquiring behavior data of said user includes: acquiring historical transaction data of said user within a predetermined time period; said determining an attribute of a target device according to said behavior data includes: determining said historical transaction data Whether the purchase transaction data of the electronic device is included in the data; if so, it is determined that the attribute of the target device is a new machine.
  • the method further includes: when the historical transaction data includes purchase transaction data of multiple electronic devices, sending a corresponding electronic device list to the user; receiving a selection instruction sent by the user based on the electronic device list; The electronic device specified in the selection instruction is determined to be the target device.
  • the obtaining the user's behavior data includes: obtaining the device identifier of the initiating device of the electronic device insurance request as the initiating identifier; searching for the device identifier of the user's historical login device as the historical identifier; Determining the attribute of the target device according to the behavior data includes: determining whether the initiation identifier is the same as the historical identifier; if not, determining that the attribute of the target device is a new machine.
  • the determining the attribute of the target device according to the behavior data includes: judging whether the user is a trusted user according to the behavior data; if the user is a trusted user, and the initiation identifier If it is different from the historical identifier, it is determined that the attribute of the target device is a new machine.
  • 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 device, determining that the attribute of the target device is an old device.
  • the method further includes: in response to an electronic device insurance request initiated by the user, determining whether the user hits the blacklist; if not, executing the step of obtaining behavior data of the user.
  • the electronic device insurance request is a screen insurance insurance request of the electronic device.
  • the underwriting after the underwriting is passed, obtain several cumulative insurance parameters of the user; determine the current insurance parameters for this insurance based on the cumulative insurance parameters and the same type of default insurance parameters; wherein, the cumulative insurance parameters Obtained by the user based on the payment result page.
  • the method further includes: after the user's payment request is successfully executed, sending a message for acquiring accumulated insurance parameters to the user, so that the electronic device can display the access to the accumulated insurance parameters in the payment result page .
  • the method further includes: in response to a request for obtaining accumulated insurance parameters sent by the user based on the obtaining portal, determining whether there is an electronic device insurance policy corresponding to the user; if so, obtaining the current electronic device insurance policy corresponding to the user Insurance parameters: update the current insurance parameters of the electronic equipment insurance policy according to the accumulated insurance parameters and the current insurance parameters of the same type.
  • the method further includes: if there is no electronic device insurance policy corresponding to the user, saving the mapping relationship between the user and accumulated insurance parameters.
  • the cumulative insurance parameter has a valid duration; the method further includes: restoring the insurance parameters of the policy after the valid duration of the cumulative insurance parameter is reached.
  • the insurance parameters include: an insured amount and a guarantee period.
  • the electronic device insurance request is sent after the user triggers a designated entry on the payment result interface.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种电子设备的保险实现方法和装置。该方法包括：响应于用户发起的电子设备投保请求, 获取所述用户的行为数据（S102）；根据所述行为数据确定所述投保请求的标的设备的属性（S104）；根据所述属性对应的核保策略对所述投保请求进行核保（S106）。

Description

电子设备的保险实现 技术领域
本说明书涉及互联网技术领域，尤其涉及一种电子设备的保险实现方法和装置。
背景技术
随着互联网技术的快速发展，越来越多的保险业务可通过网络实现，例如，线上投保、线上核保、线上理赔等。如何提升线上保险业务的处理效率、处理准确度已成为亟待解决的问题。
发明内容
有鉴于此，本说明书提供一种电子设备的保险实现方法和装置。
具体地，本说明书是通过如下技术方案实现的：一种电子设备的保险实现方法，应用于服务器，所述方法包括：响应于用户发起的电子设备投保请求，获取所述用户的行为数据；根据所述行为数据确定所述投保请求的标的设备的属性；根据所述属性对应的核保策略对所述投保请求进行核保。
一种电子设备的保险实现装置，应用于服务器，所述装置包括：行为数据获取单元，响应于用户发起的电子设备投保请求，获取所述用户的行为数据；设备属性确定单元，根据所述行为数据确定所述投保请求的标的设备的属性；电子设备核保单元，根据所述属性对应的核保策略对所述投保请求进行核保。
一种电子设备的保险实现装置，包括：处理器；用于存储机器可执行指令的存储器；其中，通过读取并执行所述存储器存储的与电子设备的保险实现逻辑对应的机器可执行指令，所述处理器被促使：响应于用户发起的电子设备投保请求，获取所述用户的行为数据；根据所述行为数据确定所述投保请求的标的设备的属性；根据所述属性对应的核保策略对所述投保请求进行核保。
本说明书一个实施例实现了，服务器在接收到电子设备投保请求后，可获取用户的行为数据，进而根据所述行为数据确定电子设备的属性，并根据所述属性对应的核保策略对投保请求进行核保，通过差异化的核保策略进行核保，可在确保核保准确性的同时，提高核保效率，进而提升用户的投保体验。
附图说明
图1是本说明书一示例性实施例示出的一种电子设备的保险实现方法的流程示意图。
图2是本说明书一示例性实施例示出的一种标的设备属性确定方法的流程示意图。
图3是本说明书一示例性实施例示出的另一种标的设备属性确定方法的流程示意图。
图4是本说明书一示例性实施例示出的一种投保页面的示意图。
图5是本说明书一示例性实施例示出的一种上传校验数据的方法的流程示意图。
图6是本说明书一示例性实施例示出的一种投保方式列表页面示意图。
图7是本说明书一示例性实施例示出的一种上传方式指导页面示意图。
图8是本说明书一示例性实施例示出的一种拍摄倒计时页面示意图。
图9是本说明书一示例性实施例示出的另一种上传方式指导页面示意图。
图10是本说明书一示例性实施例示出的一种电子设备保险理赔的实现方法的流程示意图。
图11是本说明书一示例性实施例示出的一种映射关系建立方法的流程示意图。
图12是本说明书一示例性实施例示出的另一种映射关系建立方法的流程示意图。
图13是本说明书一示例性实施例示出的另一种电子设备保险理赔的实现方法的流程示意图。
图14是本说明书一示例性实施例示出的一种保险参数确定方法的流程示意图。
图15是本说明书一示例性实施例示出的一种用于电子设备的保险实现装置的一结构示意图。
图16是本说明书一示例性实施例示出的一种电子设备的保险实现装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。
在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可被称为第二信息，类似地，第二信息也可被称为第一信息。取决于语境，如在此所使用的词语“如果”可被解释成为“在……时”或“当……时”或“响应于确定”。
本说明书提供一种电子设备的保险实现方案。
上述电子设备的保险可为电子设备的屏幕保险，也可为电子设备的全面保障险等电子设备可投保的险种。
上述电子设备可为手机、平板电脑、PDA(Personal Digital Assistant，掌上电脑)等终端设备，上述电子设备也可为摄像机、智能电视等多媒体设备，本说明书对此不作特殊限制。
上述电子设备的保险实现方案可由电子设备和服务器配合实现。所述服务器可由提供保险服务的服务提供商部署，例如保险公司、第三方保险销售平台等。
在实现保险业务的过程中，电子设备和服务器可通过有线、无线等传输方式进行交互。电子设备和服务器之间的交互通常指电子设备中装载的客户端软件和服务器之间的交互，例如用户在客户端中使用已注册的用户账号登录后和服务器进行交互，也可称之为用户和服务器之间的交互。
下面分别通过电子设备的投保、核保、理赔和保险参数确定四个方面来描述本说明书的具体实现过程。
一、电子设备的投保
图1是本说明书一示例性实施例示出的一种电子设备的保险实现方法的流程示意图。
请参考图1，所述电子设备的保险实现方法可应用于服务器，包括有以下步骤：
步骤102，响应于用户发起的电子设备投保请求，获取所述用户的行为数据。
在本实施例中，用户可通过电子设备保险的售卖入口发起所述电子设备投保请求，例如，客户端可在用户触发支付结果页面的指定入口后发送所述电子设备投保请求，所述电子设备投保请求中携带有用户账号。
服务器在接收到所述电子设备投保请求后，根据所述用户账号获取对应用户的行为数据。所述行为数据可包括：用户的历史交易数据、用户的历史登录数据、用户的当前登录数据等。
在其他例子中，服务器在接收到电子设备投保请求后，可先判断用户是否命中黑名单，若未命中，则可执行获取用户行为数据的步骤。所述黑名单可预先设置。例如，可将历史上识别出的骗保用户添加到所述黑名单中。再例如，也可将电子设备维修行业的从业人员添加到黑名单中。又例如，还可将3C行业的从业人员添加到黑名单中。通过黑名单的过滤，可有效过滤掉骗保高风险人群，提高线上投保的安全性，降低保险提供方的资损风险。
步骤104，根据所述行为数据确定所述投保请求的标的设备的属性。
基于前述步骤102，服务器在获取到用户的行为数据后，可根据所述行为数据确定用户本次投保的标的电子设备(后续简称标的设备)的属性。例如，针对不同的行为数据，可采用不同的方式确定所述标的设备的属性。其中，所述标的设备的属性可包括：新机和老机。
步骤106，根据所述属性对应的核保策略对所述投保请求进行核保。
在本实施例中，可预先配置并保存不同标的设备属性和对应投保策略之间的映射关系，在前述步骤104中确定所述标的设备的属性之后，可在所述映射关系中查找对应的核保策略，然后采用对应的核保策略对所述电子设备投保请求进行核保。若标的设备的属性是新机，可免去验机流程，直接确定核保通过，进而提高核保效率，提升用户的投保体验。若标的设备的属性是老机，则可提示用户上传标的设备的校验数据，服务器进而可根据校验数据进行验机核保。
由以上描述可看出，本实施例服务器在接收到电子设备投保请求后，可获取用户的行为数据，进而根据所述行为数据确定电子设备的属性，并根据所述属性对应的核保策略对投保请求进行核保，通过差异化的核保策略进行核保，可在确保核保准确性的同时，提高核保效率，进而提升用户的投保体验。
下面通过若干实施例详细介绍标的设备属性的确定方式。
图2是本说明书一示例性实施例示出的一种标的设备属性的确定方法的流程示意图。请参考图2，所述标的设备属性的确定方法可包括以下步骤：步骤202，获取用户在预定时间段内的历史交易数据。
在本实施例中，服务器在接收到用户发送的电子设备投保请求后，可获取发起用户的用户账号，然后基于所述用户账号从若干电商平台获取对应用户在预定时间段内的历史交易数据。例如，服务器可基于所述用户账号确定用户的身份信息，然后基于该身份信息进行历史交易数据的获取。
在本实施例中，每条历史交易数据均可包括：订单号、订单时间、所购买的物品标识、物品类型、商家标识等信息。所述预定时间段可由开发人员预先设置，例如10天内、15天内等。
步骤204，判断所述历史交易数据中是否包括电子设备的购买交易数据。
步骤206，若是，则确定标的设备的属性是新机。
基于前述步骤202，服务器在获取到用户在预定时间段内的历史交易数据后，可根据所述历史交易数据判断用户在所述预定时间段内是否购买过可投保的电子设备。若是，则可推测用户想要投保的是新购买的电子设备，进而可将标的设备的属性确定为新机。
举例来说，小白在其手机中装载的客户端中登录小白的账号，然后向服务器发送手机屏幕保险的投保请求，服务器在接收到该投保请求后，可根据小白的账号确定小白的身份信息，例如唯一身份标识等。然后根据小白的身份信息从电商平台获取小白最近15天的交易数据，并基于这15天的交易数据判断小白是否购买过手机，若是，则可推测小白想要投保的是新购买的手机，进而可将所述投保请求的标的设备的属性确定为新机。
在其他例子中，若所述历史交易数据中包括多个电子设备的购买交易数据时，服务器可发送对应的电子设备列表给用户，以让用户选择想要投保的标的设备。服务器在接收到用户基于所述电子设备列表发送的选择指令后，可将用户选择的电子设备确定为本次投保的标的设备。
仍以小白为例，假设小白最近15天的交易数据中包括两部手机的购买记录，则可发送包括这两部手机的列表给小白。所述列表中可包括手机型号、购买日期、购买价格、商家信息等数据。小白可在该列表中选择想要投保的手机，服务器在接收到小白的选择指令后，可将小白选择的手机确定为本次投保请求的标的设备。
值得注意的是，若根据用户的历史交易数据确定用户购买的多个电子设备型号均相同时，也可不发送电子设备列表给用户。例如，小白购买了两部相同的手机，则可不发送列表给小白，服务器可确认小白想要投保的是该型号的新手机。
在本实施例中，除电商平台之外，服务器也可从其他途径获取用户的历史交易数据，例如，可从实体商场的服务器获取用户在该实体商场内的线下交易数据等，本说明书对此不作特殊限制。
在本实施例中，服务器可通过用户的历史交易数据确定保险标的设备的属性是否为新机，一方面无需用户上传购买证明，可大大简化用户的投保操作，进而提高投保效率；另一方面，也突破了新机只能在购买的时候投保的限制，大大提升了用户的投保体验。
图3是本说明书一示例性实施例示出的另一种标的设备属性的确定方法的流程示意图。请参考图3，所述标的设备属性的确定方法可包括以下步骤：步骤302，获取电子设备投保请求发起设备的设备标识，作为发起标识。
在本实施例中，用户在客户端中基于用户账号登录服务器后，客户端可获取用户使用的电子设备的设备标识，并将所述设备标识上报给服务器。所述设备标识可由客户端单独上报，所述设备标识也可由客户端携带在业务请求中上报给服务器，例如，客户端可将所述设备标识携带在用户发送的电子设备投保请求中发送给服务器，本说明书对此不作特殊限制。
所述设备标识可包括：Android ID(安卓ID)、IDFV(IdentifierForVendor，应用开发商标识)、IMEI(International Mobile Equipment Identity，国际移动设备识别码)等。
在本实施例中，服务器在接收到电子设备投保请求后，可通过客户端获取到发起所述电子设备投保请求的发起设备的设备标识，并可将其作为发起标识。
步骤304，查找用户历史登录设备的设备标识，作为历史标识。
在本实施例中，服务器还可基于用户账号查询数据库，获取对应用户的历史登录设备的设备标识。所述数据库中存储有各用户历史上登录服务器时使用的电子设备的设备标识。在一个例子中，服务器可从数据库中获取所述用户最近若干次登录服务器时使用的电子设备的设备标识，作为历史标识，所述历史标识有多个。在另一个例子中，考虑到用户通常不会无故频繁更换电子设备，服务器也可从数据库中获取用户最近一次登录服务器时使用的电子设备的设备标识，作为历史标识。
步骤306，判断所述发起标识与所述历史标识是否相同。
步骤308，若不相同，则确定所述标的设备的属性是新机。
基于前述步骤302和304，服务器可判断所述发起标识和所述历史标识是否相同。
当服务器获取用户最近一次登录服务器时使用的电子设备的设备标识作为历史标识时，若发起标识和历史标识不同，则可说明用户更换了的电子设备，可推测用户为新更换的电子设备投保，进而可将标的设备的属性确定为新机。
若服务器获取多个历史标识时，则可分别判断所述发起标识与每个历史标识是否相同，若均不相同，则可说明用户更换了的电子设备，可推测用户为新更换的电子设备投保，进而可将标的设备的属性确定为新机。
在其他例子中，在采用设备标识进行标的设备属性的确定时，还可判断用户是否为可信用户，若用户不是可信用户，即便发起标识和历史标识不相同，也不会将标的设备 的属性确定为新机，而是将标的设备的属性确定为老机，进而提高后续核保结果的准确性，降低直接跳过验机通过核保所带来的骗保风险。若用户是可信用户，当发起标识和历史标识不相同时，可将标的设备的属性确定为新机。
在本实施例中，可根据用户的注册时长、登录频率等确定用户是否为可信用户。在一个例子中，可判断用户的注册时长是否小于时长阈值，若小于时长阈值，则可确定所述用户不是可信用户。所述时长阈值可预先设置，例如，1个月、3个月等。在另一个例子中，可判断用户是否在近期登录过用户账号，若未登录过，则可确定用户不是可信用户。例如，可判断用户是否在近1个月/3个月登录过用户账号等。与之相反，若用户的注册时长大于等于时长阈值，并且近期登录过用户账号，则可确定用户是可信用户。
在本实施例中，服务器可根据用户登录设备的设备标识确定用户投保的标的设备是否为新机，可解决历史交易数据获取不全面所导致的新机标的设备识别不准确的问题，同时无需用户上传购买证明，可大大简化用户的投保操作，提高投保效率。
值得注意的是，在本说明书并不限制图2和图3所示实施例标的设备属性确定方法的执行顺序。并且，在上述标的设备属性确定的实现方案中，若通过历史交易数据、设备标识等途径无法确定标的设备的属性是新机时，可将标的设备的属性确定为老机，后续基于用户上传的校验数据进行核保，进而确保核保的准确性。
此外，服务器在确定标的设备的属性后，还可将标的设备的属性发送给客户端，以供用户确认，用户可根据实际情况进行调整。仍假设小白最近15天的购买过新手机，服务器确定标的设备的属性是“新机”，进而可将“新机”作为默认的属性返回给客户端，若小白想要投保的不是新机，则可选择其他属性。
在实际实现中，为便于用户理解，以手机屏幕保险为例，客户端可展示图4所示的投保页面，其中保障手机项目中的“新购手机”和“本手机”指的是用户想要投保的标的手机是不是本手机。
若用户选择“新购手机”，服务器可获取用户的历史交易数据，进而根据所述历史交易数据判断用户近期是否购买过新手机，若是，则可确定标的设备的属性是新机，进而可直接确定核保通过。
若用户选择“本手机”，说明用户想要投保的是当前正在使用的手机。而用户当前正在使用的手机，可能是用户购买的新手机，即标的设备的属性是新机；用户当前正在使用的手机也可能是用户原来的旧手机，即标的设备的属性是“老机”。在这种情况下，服务器可获取历史标识和发起标识，以确认标的设备的属性，并可采用确定的属性对应的核保策略进行核保。
当然，在其他例子中，若用户投保的电子设备是摄像机、智能电视等多媒体设备，用户可能仍会使用手机投保，但“保障设备”不可能是手机，开发人员可开发其他样式的用户界面，本说明书对此不作特殊限制。
二、核保
在确定标的设备的属性是老机时，服务器向用户发送上传校验数据的提示信息，所述校验数据可是标的设备的照片、视频等数据，服务器在接收到校验数据之后，可通过 所述校验数据进行验机，确定标的设备是否完好、无损坏，进而确定核保结果。
本说明书提供多种校验数据的上传方式，用户可根据实际情况进行选择。
图5是本说明书一示例性实施例示出的一种上传校验数据的方法的流程示意图。请参考图5，上传校验数据的方法可应用在电子设备中，包括有以下步骤：步骤502，在触发电子设备投保的校验数据上传时，展示上传方式列表。
在本实施例中，用户在接收到上传校验数据的提示信息后，可在方便的时候上传校验数据。当用户触发校验数据上传时，电子设备的客户端可展示上传方式列表，所述上传方式列表中可展示对应上传方式所需的辅助设备，用户可根据实际情况选择上传方式。
以手机屏幕保险为例，校验数据为手机屏幕的照片或视频。请参考图6所示的投保方式列表页面示意图，图6提供两种手机屏幕拍摄方式，一种是他人协助拍摄，需要另一部手机；若用户无法找到另一部手机，也可选择另一种拍摄方式，即自行对着镜子拍摄。其中，他人协助拍摄的方式所需的辅助设备是另一部手机；自行拍摄所需的辅助设备是一面镜子。
步骤504，响应于用户选择的上传方式，跳转到对应的上传方式指导页面，所述上传方式指导页面中展示有对应的上传入口，以供用户在触发所述上传入口后基于所述上传方式实现本设备校验数据的上传。
基于前述步骤502中展示的上传方式列表，用户可选择合适的上传方式，客户端进而可跳转到对应上传方式的指导页面。所述指导页面中展示有对应上传方式的详情介绍，并展示有上传入口，用户可触发该上传入口，进行校验数据的拍摄。
由以上描述可看出，本实施例提供多种电子设备投保过程中校验数据的上传方式，用户可根据实际情况选择合适的方式上传校验数据，实现校验数据的线上上传，方便、快捷，大大提升了用户的投保体验。
下面分别对这两种上传方式进行详细说明。
1、对着镜子拍摄
仍以手机屏幕保险为例，若用户在图6所示的页面中触发“对着镜子拍摄本机”的上传方式，客户端可跳转到图7所示的上传方式指导页面，所述上传方式指导页面中展示有上传入口“开始拍摄”，还展示有该上传方式的示例图像以及拍摄要求。
用户触发该上传入口后可调用电子设备的前置摄像头，通过前置摄像头进行图片、视频等图像采集，并可在采集到图像后将所述图像作为校验数据上传至服务器。在其他例子中，用户触发该上传入口后，也可默认调用后置摄像头，由用户手动切换到前置摄像头进行图像采集，本说明书对此不作特殊限制。
在其他例子中，请参考图8所示的用户界面，由于对着镜子拍摄需要用户翻转手机，将手机屏幕对着镜子，当用户触发所述上传入口后，还可启动定时器开始计时，给客户留出翻转手机的准备时间，在到达定时时长时，才开始进行图像的采集。所述定时时长可为3秒钟。为便于用户理解，客户端可通过倒计时的方式显示所述定时时长。
本实施例为用户提供对着镜子拍摄的校验数据上传方式，一方面可确保校验数据的 真实性，另一方面实现简单、便捷，用户体验较好。
2、使用其他手机拍摄
仍以手机屏幕保险为例，若用户在图6所示的页面中触发“使用其他手机拍摄本机”的上传方式，客户端可跳转到图9所示的上传方式指导页面，所述上传方式指导页面中展示有上传入口“开始拍摄”，也展示有该上传方式的示例图像以及拍摄要求。
用户触发该上传入口后客户端可展示用于上传校验数据的校验图形编码，例如校验二维码。校验二维码中可携带校验标识、用户账号、投保信息、设备标识等数据。
用户或者协助用户的人可使用其他手机扫码所述校验二维码，并对所述校验二维码进行解析，若解析得到校验标识，则可调用本机摄像头进行图像采集，并可在完成采集后，将采集到的图像以及二维码中解析得到的用户账号、投保信息、设备标识等数据发送给服务器，服务器可根据这些信息确定对应的投保请求，并进行核保。
在本实施例中，所述校验图形编码为动态的图形编码，例如，可每分钟刷新1次。采用动态的图形编码，可有效防止用户作弊，例如用户通过截屏等方式保留该校验图形编码，并将该校验图像编码发送至相同型号的手机，后续采集该相同型号手机的图像作为校验数据等。
在上述两种上传方式中，均可采用无感拍摄，即无需用户手动触发拍摄开始/拍摄结束的按钮，调用摄像头之后自动拍摄上传，简化用户操作，提升用户的使用体验。
此外，上述两种方式均以手机屏幕保险为例进行描述，若用户投保的是全面保障险等其他险种，校验数据可能还需包括手机侧面、背面的图像，客户端可输出相应引导，本说明书在此不再一一赘述。
在其他例子中，由于上述两种上传方式所需的辅助设备不同，服务器可预先存储上传方式和上传时段之间的映射关系。一方面，服务器可在确定标的设备的属性是老机时，基于所述映射关系查找当前时刻对应的上传方式，并将所述上传方式携带在上传校验数据的提示信息中发送给用户。服务器也可将所有上传方式携带在该提示信息中发送给用户，并优先推荐当前时刻对应的上传方式，本说明书对此不作特殊限制。另一方面，在用户触发校验数据上传时，服务器也可根据所述映射关系查找当前时刻对应的上传方式，然后将所述上传方式返回给客户端，客户端可在上传方式列表中区别显示所述上传方式，例如将所述上传方式标注为推荐等。
当然，在这个例子中，所述映射关系也可保存在电子设备本地，当用户触发校验数据上传时，客户端从本地获取所述映射关系，并进行当前时刻对应上传方式的查找，本说明书对此不作特殊限制。
上传时段 上传方式
8:00-18:00 使用其他手机拍摄
18:00-8:00 对照镜子拍摄
表1
请参考表1，一种上传时段和上传方式之间映射关系的示例。其中，8:00-18:00这个时段，用户大概率是在上班，可优先推荐使用其他手机拍摄的上传方式，例如，用户可让同事帮忙拍摄。18:00至第二天8:00这个时段，用户大概率是在家中，可优先推荐使用对照镜子拍摄的上传方式。
当然，表1所示的映射关系只是一种示例，在实际应用中，还可设置更复杂的映射关系，例如区分工作日和休息日等，本说明书对此不作特殊限制。
三、理赔
图10是本说明书一示例性实施例示出的一种电子设备保险理赔的实现方法的流程示意图。
请参考图10，所述理赔的实现方法可应用于服务器，包括以下步骤：步骤1002，接收出险设备发送的理赔确认申请，所述理赔确认申请由所述出险设备在扫描指定图形编码后发送，所述理赔确认申请中携带所述出险设备的若干标识因子。
在本实施例中，服务器在确定核保通过后，可保存保单和用户投保的电子设备的若干标识因子之间的映射关系。
用户在理赔时，可使用需要理赔的电子设备(后续称为出险设备)扫描用于理赔的图形编码，例如理赔二维码，电子设备进而可获取本设备的若干标识因子，然后基于所述若干标识因子构造理赔确认申请，并将该理赔确认申请发送至服务器。
例如，电子设备的维修人员在拿到需要维修及理赔的电子设备后，可在客户端中使用自己的用户账号登录服务器，然后扫描理赔二维码，客户端解析所述理赔二维码，若从解析得到指定的理赔标识，则可获取本设备的若干标识因子，并执行构造理赔确认申请的步骤。
在本实施例中，所述电子设备的标识因子可包括IDFA(Identifier For Advertising，广告标识符)、IDFV、Android ID等设备标识。
步骤1004，根据所述映射关系，判断能否查找到所述出险设备的若干标识因子对应的保单。
步骤1006，若查找到对应的保单，则向所述出险设备返回允许理赔的消息。
服务器在接收到所述理赔确认申请后，可在所述映射关系中查找理赔确认申请中携带的若干标识因子对应的保单。
若查找到对应的保单，则可说明出险的电子设备之前购买过保险，可返回允许理赔的消息，后续维修人员可直接找保险公司来支付维修费用。
若未查找到对应的保单，可能存在两种情况，一种是出险设备未购买过保险，另一种是用户未使用出险设备购买保险，需要进行进一步判断。
由以上描述可看出，本实施例服务器可保存标的设备若干标识因子和保单之间的映射关系，后续根据出险设备的标识因子判断出险设备是否投过保险，以对理赔进行验证。一方面采用IDFA等若干标识因子组合的方式标识电子设备，可有效解决应用提 供方无法获取UDID(Unique Device Identifier)来标识电子设备的问题；另一方面，整个过程也无需用户手动上传UDID等设备标识，大大简化用户操作，提升用户投保体验。
下面分别从映射关系的建立、理赔流程的实现来进行详细描述。
1、映射关系的建立
请参考图11，上述映射关系的建立过程可包括以下步骤：
步骤1102，当电子设备投保请求核保通过后，判断所述投保请求的标的设备是否为所述电子设备投保请求的发起设备。
步骤1104，若是，则获取所述发起设备的若干标识因子，并建立所述若干标识因子和所述发起设备保单之间的映射关系。
在本实施例中，服务器在确定电子设备投保请求核保通过后，可判断投保请求的标的设备是否为电子设备投保请求的发起设备。即，服务器判断用户投保的是否为本机设备。
若是，服务器可通过客户端获取所述发起设备的若干标识因子，并建立所述若干标识因子和对应保单之间的映射关系。例如，建立所述若干标识因子和保单标识之间的映射关系。
序号 IDFA IDFV 保单
1 15dfa35g4 h41f6afg 123
2 4d5adffs5 Ghrte15f3 124
3 D4f3ad4fc Er5tjkb88 125
表2
表2示出了一种设备标识因子和保单之间映射关系的示例，需要说明的是，表2仅仅是一种示例，在实际实现中，也可不组织这样的表格，本说明书对此不作特殊限制。
上述过程中，服务器可通过以下方法确定标的设备是否为电子设备投保请求的发起设备。
方法一：基于标的设备属性进行判断
服务器可在确定标的设备的属性是老机时，确定标的设备为电子设备投保请求的发起设备。即，投保用户最近未购买过新的电子设备，并且用户曾经也使用过发起设备登录。服务器在确定标的设备的属性是新机时，可获取新机属性的判断途径。若判断途径是设备标识判断途径时，也可确定标的设备为电子设备投保请求的发起设备。
所述新机属性的判断途径可参考前述图2-图3所示的实施例，本说明书在此不再一一赘述。
方法二：基于用户的选择进行判断
请再次参考图4所示的投保页面，若用户通过图4所示的投保页面进行投保， 服务器可直接获取用户选择的保障手机，若用户选择的是“本手机”，则可直接确定标的设备为电子设备投保请求的发起设备。
在其他例子中，若标的设备不是电子设备投保请求的发起设备，则服务器可保存保单和标的设备购买订单之间的映射关系，以便后续理赔时进行验证。例如，若标的设备属性“新机”的判断途径是历史交易数据途径时，可确定标的设备不是投保请求的发起设备。再例如，仍以图4为例，若用户选择的是“新购手机”，则也可确定标的设备不是投保请求的发起设备。
在这种情况下，服务器可在用户的历史交易数据中获取标的设备的订单标识，并建立订单标识和保单标识之间的映射关系，以供后续理赔时验证使用。
一般而言，当标的设备不是电子设备投保请求的发起设备时，通常包括两种情况，下面以手机为例进行说明。
第一种情况是用户为自己购买新手机，但使用旧手机为新手机投保。请参考图12，在这种情况下，前述映射关系的建立过程可包括以下步骤：步骤1202，在检测到新机登录时，判断是否存在登录用户对应的电子设备保单。
在这种情况下，用户在使用新手机后，通常会使用新手机登录服务器，服务器可在用户登录后，获取登录手机的标识，然后判断用户是否首次使用该手机登录，即是否为新机登录。若是，则可根据用户账号判断是否存在登录用户对应的电子设备保单，即查找用户是否购买过手机保险。
步骤1204，若存在，则判断所述新机的型号是否匹配标的设备型号。
步骤1206，若匹配，则获取所述新机的若干标识因子，并建立所述若干标识因子和所述登录用户的电子设备保单之间的映射关系。
基于前述步骤1102的判断结果，若用户购买过手机保险，则可根据保单标识查找标的设备的型号。
在本实施例中，服务器可判断用户使用的新手机的型号是否标的设备的型号。若匹配，则可说明用户当前使用的新手机就是用户之前投保的手机，进而可通过客户端获取所述新手机的若干标识因子，并建立所述若干标识因子和保单之间的映射关系。后续服务器在接收到针对该新手机的理赔请求时，就可根据若干标识因子和保单之间的映射关系来进行理赔验证，进而提高理赔验证准确性。
第二种情况是用户为他人购买新手机，然后使用自己的手机为新手机投保。在这种情况下，用户使用购买的新手机登录自身用户账号的概率极低，服务器较难自动获取到该新手机的若干标识因子，可仅建立订单标识和保单标识之间的映射关系，也可提示用户使用新手机登录，还可提示用户主动上传新手机的标识因子。
2、理赔流程
在前述图10所示的实施例中，用户电子设备损坏需要理赔时，可直接到指定的维修中心，由维修人员使用出险设备登录服务器之后扫描二维码进行验证。
可选的，在其他例子中，在电子设备损坏需要理赔时，用户也可先在线提交理 赔请求，例如，用户可先使用投保的电子设备发送理赔申请，服务器在接收到该理赔申请后，将对应保单的状态标记为理赔中，并可向用户返回指定的维修中心列表。
用户可通过面交、快递等方式将出险设备送至指定维修中心，指定维修中心的维修人员可使用自己的用户账号登录服务器之后扫描二维码以进行验证。
在这样的实现方式中，服务器在接收到理赔确认申请后，可在状态为理赔中的保单与标识因子之间的映射关系中查找出险设备对应的保单，可大大减少比对数量，提高理赔验证的效率。
在其他例子中，服务器在接收到出险设备发送的理赔确认申请后，若根据出险设备的若干标识因子未查找到对应的保单，则可获取出险设备的登录数据，例如历史上使用所述出险设备第一次登录的时间点，然后计算所述第一次登录的时间点距今的时长，作为第一时长，该第一时长可表示服务器可确定的所述出险设备的使用时长。
服务器还可根据订单标识和保单标识之间的映射关系，获取状态为理赔中的保单对应的订单，然后计算所述订单的生成时间点距今的时长，作为第二时长，该第二时长表示具有保单的电子设备的购买时长。然后，服务器可判断第一时长和各第二时长的大小关系。若第一时长大于所有第二时长，则可说明出险设备使用的时长大于各具有保险的电子设备的购买时长，存在骗保嫌疑，可向所述出险设备返回禁止理赔的消息。若第一时长小于所有第二时长，则可向出险设备返回允许理赔的消息。值得注意的是，在时长判断的过程中，还可判断标的设备型号与出险设备型号是否匹配等，本说明书在此不再一一赘述。
由以上描述可看出，本实施例提供的理赔方案，在用户为新手机投保时，可保存新手机购买订单和保单之间的映射关系，后续可根据新手机的购买时长和出险手机的使用时长来进行理赔验证，在简化投保/理赔的操作时，还可确保理赔验证的准确性。
图13是本说明书一示例性实施例示出的另一种电子设备保险理赔的实现方法的流程示意图。
请参考图13，所述理赔的实现方法可应用于电子设备，包括以下步骤：
步骤1302，在扫描图形编码后，判断所述图形编码中是否携带指定的理赔标识。
步骤1304，若携带，则获取本设备的若干标识因子。
步骤1306，基于所述标识因子构造理赔确认申请，并将所述理赔确认申请发送给服务器，以供服务器查找所述若干标识因子对应的保单。
步骤1308，接收服务器在查找到所述若干标识因子对应的保单后发送的允许理赔的消息。
本实施例中理赔的实现方法可参考前述实施例，本说明书在此不再一一赘述。
四、保险参数的确定
本说明书提供一种动态保险参数的确定方案，可灵活确定不同用户的保险参数，实现简单、便捷，还可有效提升用户的投保体验。
所述保险参数可包括保额、保障期限、保障范围、保障险种中的一种或多种。
图14是本说明书一示例性实施例示出的一种保险参数确定方法的流程示意图。
请参考图14，所述保险参数确定方法可应用于服务器，包括以下步骤：
步骤1402，在核保通过后，获取所述用户的若干累加保险参数。
在本实施例中，在确定电子设备保险核保通过后，可基于用户和累加保险参数之间的映射关系，判断所述用户是否存在对应的累加保险参数。
若存在，则可获取所述用户对应的累加保险参数。
若不存在，则可将用户本次投保的保险参数确定为缺省保险参数。
步骤1404，基于所述累加保险参数和相同类型的缺省保险参数确定本次投保的当前保险参数。
基于前述步骤1402，在获取到用户的累加保险参数之后，可将累加保险参数和相同类型的缺省保险参数相加，得到本次投保对应类型的保险参数。
以电子设备的屏幕保险为例，假设缺省保额是1000元，缺省保证期限是1年。若用户对应的累加保额是20元，累加保障期限是1个月，则可将用户本次投保的保额确定为1020元，保障期限确定为1年零1个月。若用户对应的累加保额是10元，无对应的累加保障期限，则可将用户本次投保的保额确定为1010元，保障期限确定为1年。若不存在用户对应的累加保额和累加保障期限，则可将用户本次投保的保额确定为缺省保额1000元，保障期限确定为缺省保障期限1年。
在本实施例中，服务器可在成功执行用户的支付请求后，向所述用户发送获取累加保险参数的消息。即服务器在用户成功完成支付后，向其发送所述消息。客户端在获取到该消息后，可在支付结果页面中展示所述累加保险参数的获取入口。
累加保险参数的类型可由服务器指定，并可由服务器携带在所述消息中。例如，服务器可指定累加保险参数的类型为保障期限，客户端进而可在支付结果页面中展示累加保障期限的获取入口。再例如，服务器可指定累加保险参数的类型为保额和保障期限，客户端进而可在支付结果页面中展示累加保额的获取入口和累加保障期限的获取入口。
在本实施例中，用户可通过所述支付结果页面触发所述获取入口，客户端可发送对应类型的累加保险参数获取请求至服务器。
以累加保额获取请求为例，服务器在接收到所述累加保额获取请求后，可判断所述用户是否存在对应的电子设备保单。若存在，可说明用户投保过电子设备保险，服务器可获取对应保单的当前保额，然后计算累加保额和当前保额的和值，并用所述和值更新所述保单的当前保额。
其中，不同用户的累加保额的具体数值可相同，例如所有用户的累加保额都是10元；不同用户的累加保额的具体数值也可不同，服务器可根据用户的支付金额确定其累加保额的具体数值，例如，支付金额越高的用户的累加保额的具体数值越高，或者支付金额大于等于阈值的用户的累加保额是20元，而支付金额小于所述阈值的用户的累 加保额是10元等，本说明书对此不作特殊限制。
若不存在用户对应的电子设备保单，则可说明用户尚未投保过电子设备保险，服务器可保存用户和累加保额及其数值之间的映射关系，后续用户投保电子设备保险时，可基于所述映射关系确定保单的保额。
在本实施例中，所述累加保险参数可具有有效时长。以保额为例，所述有效时长可预先设置，小于等于保障期限。假设所述有效时长是6个月，则在到达6个月的有效时长时，若保单尚未超过保障期限，则可还原保单的保额，例如计算所述保单的当前保额和对应累加保额具体数值的差值，并将该差值更新为所述保单的当前保额。以保障期限为例，保障期限的有效时长往往是针对未投保的用户，在到达所述有效时长时，如果用户仍未投保电子设备保险，则可确定所述保障期限无效。在其他例子中，所述累加保险参数也可仅为投保过电子设备保险的用户提供。
例如，在成功执行用户的支付请求后，可判断是否存在所述用户对应的保单，若存在，则可向所述用户发送获取累加保险参数的消息，客户端进而在支付结果页面中展示所述累加保险参数的获取入口。
当用户触发所述获取入口时，服务器执行保险参数的更新。若不存在用户对应的保单，服务器不向用户发送获取累加保险参数的消息，客户端也不会展示累加保险参数的获取入口。
由以上描述可看出，本实施例可在支付结果页面展示累加保险参数的获取入口，用户可基于该获取入口触发保险参数的更新，通过技术创新实现保险的投保简单、便捷，为用户提供快捷、便利的保险服务推荐，降低用户操作的繁琐度，节省用户的操作时间。
与前述电子设备的保险实现方法的实施例相对应，本说明书还提供了电子设备的保险实现装置的实施例。
本说明书电子设备的保险实现装置的实施例可应用在服务器上。装置实施例可通过软件实现，也可通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在服务器的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图15所示，为本说明书电子设备的保险实现装置所在服务器的一种硬件结构图，除了图15所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的服务器通常根据该服务器的实际功能，还可包括其他硬件，对此不再赘述。
图16是本说明书一示例性实施例示出的一种电子设备的保险实现装置的框图。
请参考图16，所述电子设备的保险实现装置1500可应用在前述图15所示的服务器中，包括有：行为数据获取单元1501、设备属性确定单元1502、电子设备核保单元1503、黑名单判断单元1504和保险参数确定单元1505。
其中，行为数据获取单元1501，响应于用户发起的电子设备投保请求，获取所述用户的行为数据；设备属性确定单元1502，根据所述行为数据确定所述投保请求的标的设备的属性。电子设备核保单元1503，根据所述属性对应的核保策略对所述投保请求进行核保。
可选的，所述电子设备核保单元1503：当标的设备的属性是新机时，确定核保通过。
可选的，所述电子设备核保单元1503：当标的设备的属性是老机时，向所述用户发送上传校验数据的提示信息；响应于用户发送的校验数据，根据所述校验数据对所述投保请求进行核保。
可选的，所述电子设备核保单元1503：根据上传时段与上传方式之间的映射关系，确定当前时刻对应的上传方式；将所述上传方式携带在所述提示信息中发送给用户。
可选的，所述行为数据获取单元1501：获取所述用户在预定时间段内的历史交易数据；所述设备属性确定单元1502：判断所述历史交易数据中是否包括电子设备的购买交易数据；若是，则确定标的设备的属性是新机。
可选的，所述设备属性确定单元1502：当所述历史交易数据中包括多个电子设备的购买交易数据时，发送对应的电子设备列表给用户；接收用户基于所述电子设备列表发送的选择指令；将用户所述选择指令中指定的电子设备确定为所述标的设备。
可选的，所述行为数据获取单元1501：获取所述电子设备投保请求的发起设备的设备标识，作为发起标识；查找所述用户历史登录设备的设备标识，作为历史标识；所述设备属性确定单元1502：判断所述发起标识与所述历史标识是否相同；若不相同，则确定所述标的设备的属性是新机。
可选的，所述设备属性确定单元1502：根据所述行为数据判断所述用户是否为可信用户；若所述用户是可信用户，且所述发起标识与所述历史标识不相同，则确定所述标的设备的属性是新机。
可选的，所述设备属性确定单元1502：当无法确定所述标的设备的属性是新机时，确定所述标的设备的属性是老机。
黑名单判断单元1504，响应于用户发起的电子设备投保请求，判断所述用户是否命中黑名单；若否，则通知行为数据获取单元1501执行获取所述用户的行为数据的步骤。
保险参数确定单元1505，在核保通过后，获取所述用户的若干累加保险参数；基于所述累加保险参数和相同类型的缺省保险参数确定本次投保的当前保险参数；其中，所述累加保险参数由所述用户基于支付结果页面获取。
可选的，所述保险参数确定单元1505：在成功执行所述用户的支付请求后，向所述用户发送获取累加保险参数的消息，以供所述电子设备在支付结果页面中展示所述累加保险参数的获取入口。
可选的，所述保险参数确定单元1505：响应于用户基于所述获取入口发送的累加保险参数获取请求，判断是否存在所述用户对应的电子设备保单；若存在，则获取所述用户对应的电子设备保单的当前保险参数；根据所述累加保险参数和相同类型的当前保险参数更新所述电子设备保单的当前保险参数。
可选的，所述保险参数确定单元1505：若不存在所述用户对应的电子设备保单， 则保存所述用户和累加保险参数之间的映射关系。
可选的，所述累加保险参数具有有效时长；所述保险参数确定单元1505：
在到达所述累加保险参数的有效时长后，还原保单的保险参数。
上述装置中各个单元的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可是或者也可不是物理上分开的，作为单元显示的部件可是或者也可不是物理单元，即可位于一个地方，或者也可分布到多个网络单元上。可根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可理解并实施。
上述实施例阐明的系统、装置、模块或单元，具体可由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
与前述电子设备的保险实现方法的实施例相对应，本说明书还提供一种电子设备的保险实现装置，该装置包括：处理器以及用于存储机器可执行指令的存储器。其中，处理器和存储器通常借由内部总线相互连接。在其他可能的实现方式中，所述设备还可能包括外部接口，以能够与其他设备或者部件进行通信。
在本实施例中，通过读取并执行所述存储器存储的与电子设备的保险实现逻辑对应的机器可执行指令，所述处理器被促使：响应于用户发起的电子设备投保请求，获取所述用户的行为数据；根据所述行为数据确定所述投保请求的标的设备的属性；根据所述属性对应的核保策略对所述投保请求进行核保。
可选的，所述根据所述属性对应的核保策略对所述投保请求进行核保，包括：当标的设备的属性是新机时，确定核保通过。
可选的，所述根据所述属性对应的核保策略对所述投保请求进行核保，包括：当标的设备的属性是老机时，向所述用户发送上传校验数据的提示信息；响应于用户发送的校验数据，根据所述校验数据对所述投保请求进行核保。
可选的，所述向所述用户发送上传校验数据的提示信息包括：根据上传时段与上传方式之间的映射关系，确定当前时刻对应的上传方式；将所述上传方式携带在所述提示信息中发送给用户。
可选的，所述获取所述用户的行为数据包括：获取所述用户在预定时间段内的历史交易数据；所述根据所述行为数据确定标的设备的属性，包括：判断所述历史交易数据中是否包括电子设备的购买交易数据；若是，则确定标的设备的属性是新机。
可选的，还包括：当所述历史交易数据中包括多个电子设备的购买交易数据时， 发送对应的电子设备列表给用户；接收用户基于所述电子设备列表发送的选择指令；将用户所述选择指令中指定的电子设备确定为所述标的设备。
可选的，所述获取所述用户的行为数据包括：获取所述电子设备投保请求的发起设备的设备标识，作为发起标识；查找所述用户历史登录设备的设备标识，作为历史标识；所述根据所述行为数据确定所述标的设备的属性，包括：判断所述发起标识与所述历史标识是否相同；若不相同，则确定所述标的设备的属性是新机。
可选的，所述根据所述行为数据确定所述标的设备的属性，包括：根据所述行为数据判断所述用户是否为可信用户；若所述用户是可信用户，且所述发起标识与所述历史标识不相同，则确定所述标的设备的属性是新机。
可选的，所述根据所述行为数据确定所述标的设备的属性，包括：当无法确定所述标的设备的属性是新机时，确定所述标的设备的属性是老机。
可选的，还包括：响应于用户发起的电子设备投保请求，判断所述用户是否命中黑名单；若否，则执行获取所述用户的行为数据的步骤。
可选的，所述电子设备投保请求为电子设备的屏幕保险投保请求。
可选的，在核保通过后，获取所述用户的若干累加保险参数；基于所述累加保险参数和相同类型的缺省保险参数确定本次投保的当前保险参数；其中，所述累加保险参数由所述用户基于支付结果页面获取。
可选的，还包括：在成功执行所述用户的支付请求后，向所述用户发送获取累加保险参数的消息，以供所述电子设备在支付结果页面中展示所述累加保险参数的获取入口。
可选的，还包括：响应于用户基于所述获取入口发送的累加保险参数获取请求，判断是否存在所述用户对应的电子设备保单；若存在，则获取所述用户对应的电子设备保单的当前保险参数；根据所述累加保险参数和相同类型的当前保险参数更新所述电子设备保单的当前保险参数。
可选的，还包括：若不存在所述用户对应的电子设备保单，则保存所述用户和累加保险参数之间的映射关系。
可选的，所述累加保险参数具有有效时长；所述方法还包括：在到达所述累加保险参数的有效时长后，还原保单的保险参数。
可选的，所述保险参数包括：保额和保障期限。
可选的，所述电子设备投保请求由用户触发支付结果界面的指定入口后发送。
与前述电子设备的保险实现方法的实施例相对应，本说明书还提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该程序被处理器执行时实现以下步骤：响应于用户发起的电子设备投保请求，获取所述用户的行为数据；根据所述行为数据确定所述投保请求的标的设备的属性；根据所述属性对应的核保策略对所述投保请求进行核保。
可选的，所述根据所述属性对应的核保策略对所述投保请求进行核保，包括：
当标的设备的属性是新机时，确定核保通过。
可选的，所述根据所述属性对应的核保策略对所述投保请求进行核保，包括：
当标的设备的属性是老机时，向所述用户发送上传校验数据的提示信息；响应于用户发送的校验数据，根据所述校验数据对所述投保请求进行核保。
可选的，所述向所述用户发送上传校验数据的提示信息包括：根据上传时段与上传方式之间的映射关系，确定当前时刻对应的上传方式；将所述上传方式携带在所述提示信息中发送给用户。
可选的，所述获取所述用户的行为数据包括：获取所述用户在预定时间段内的历史交易数据；所述根据所述行为数据确定标的设备的属性，包括：判断所述历史交易数据中是否包括电子设备的购买交易数据；若是，则确定标的设备的属性是新机。
可选的，还包括：当所述历史交易数据中包括多个电子设备的购买交易数据时，发送对应的电子设备列表给用户；接收用户基于所述电子设备列表发送的选择指令；将用户所述选择指令中指定的电子设备确定为所述标的设备。
可选的，所述获取所述用户的行为数据包括：获取所述电子设备投保请求的发起设备的设备标识，作为发起标识；查找所述用户历史登录设备的设备标识，作为历史标识；所述根据所述行为数据确定所述标的设备的属性，包括：判断所述发起标识与所述历史标识是否相同；若不相同，则确定所述标的设备的属性是新机。
可选的，所述根据所述行为数据确定所述标的设备的属性，包括：根据所述行为数据判断所述用户是否为可信用户；若所述用户是可信用户，且所述发起标识与所述历史标识不相同，则确定所述标的设备的属性是新机。
可选的，所述根据所述行为数据确定所述标的设备的属性，包括：当无法确定所述标的设备的属性是新机时，确定所述标的设备的属性是老机。
可选的，还包括：响应于用户发起的电子设备投保请求，判断所述用户是否命中黑名单；若否，则执行获取所述用户的行为数据的步骤。
可选的，所述电子设备投保请求为电子设备的屏幕保险投保请求。
可选的，在核保通过后，获取所述用户的若干累加保险参数；基于所述累加保险参数和相同类型的缺省保险参数确定本次投保的当前保险参数；其中，所述累加保险参数由所述用户基于支付结果页面获取。
可选的，还包括：在成功执行所述用户的支付请求后，向所述用户发送获取累加保险参数的消息，以供所述电子设备在支付结果页面中展示所述累加保险参数的获取入口。
可选的，还包括：响应于用户基于所述获取入口发送的累加保险参数获取请求，判断是否存在所述用户对应的电子设备保单；若存在，则获取所述用户对应的电子设备保单的当前保险参数；根据所述累加保险参数和相同类型的当前保险参数更新所述电子 设备保单的当前保险参数。
可选的，还包括：若不存在所述用户对应的电子设备保单，则保存所述用户和累加保险参数之间的映射关系。
可选的，所述累加保险参数具有有效时长；所述方法还包括：在到达所述累加保险参数的有效时长后，还原保单的保险参数。
可选的，所述保险参数包括：保额和保障期限。
可选的，所述电子设备投保请求由用户触发支付结果界面的指定入口后发送。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可按照不同于实施例中的顺序来执行并且仍然可实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可的或者可能是有利的。
以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (34)

  1. 一种电子设备的保险实现方法，应用于服务器，所述方法包括：
    响应于用户发起的电子设备投保请求，获取所述用户的行为数据；
    根据所述行为数据确定所述投保请求的标的设备的属性；
    根据所述属性对应的核保策略对所述投保请求进行核保。
  2. 根据权利要求1所述的方法，所述根据所述属性对应的核保策略对所述投保请求进行核保，包括：
    当标的设备的属性是新机时，确定核保通过。
  3. 根据权利要求1所述的方法，所述根据所述属性对应的核保策略对所述投保请求进行核保，包括：
    当标的设备的属性是老机时，向所述用户发送上传校验数据的提示信息；
    响应于用户发送的校验数据，根据所述校验数据对所述投保请求进行核保。
  4. 根据权利要求3所述的方法，所述向所述用户发送上传校验数据的提示信息包括：
    根据上传时段与上传方式之间的映射关系，确定当前时刻对应的上传方式；
    将所述上传方式携带在所述提示信息中发送给用户。
  5. 根据权利要求1所述的方法，所述获取所述用户的行为数据包括：
    获取所述用户在预定时间段内的历史交易数据；
    所述根据所述行为数据确定标的设备的属性，包括：
    判断所述历史交易数据中是否包括电子设备的购买交易数据；
    若是，则确定标的设备的属性是新机。
  6. 根据权利要求5所述的方法，还包括：
    当所述历史交易数据中包括多个电子设备的购买交易数据时，发送对应的电子设备列表给用户；
    接收用户基于所述电子设备列表发送的选择指令；
    将用户所述选择指令中指定的电子设备确定为所述标的设备。
  7. 根据权利要求1所述的方法，所述获取所述用户的行为数据包括：
    获取所述电子设备投保请求的发起设备的设备标识，作为发起标识；
    查找所述用户历史登录设备的设备标识，作为历史标识；
    所述根据所述行为数据确定所述标的设备的属性，包括：
    判断所述发起标识与所述历史标识是否相同；
    若不相同，则确定所述标的设备的属性是新机。
  8. 根据权利要求7所述的方法，所述根据所述行为数据确定所述标的设备的属性，包括：
    根据所述行为数据判断所述用户是否为可信用户；
    若所述用户是可信用户，且所述发起标识与所述历史标识不相同，则确定所述标的设备的属性是新机。
  9. 根据权利要求5-8任意一项所述的方法，所述根据所述行为数据确定所述标的设备的属性，包括：
    当无法确定所述标的设备的属性是新机时，确定所述标的设备的属性是老机。
  10. 根据权利要求1所述的方法，还包括：
    响应于用户发起的电子设备投保请求，判断所述用户是否命中黑名单；
    若否，则执行获取所述用户的行为数据的步骤。
  11. 根据权利要求1所述的方法，还包括：
    在核保通过后，获取所述用户的若干累加保险参数；
    基于所述累加保险参数和相同类型的缺省保险参数确定本次投保的当前保险参数；
    其中，所述累加保险参数由所述用户基于支付结果页面获取。
  12. 根据权利要求11所述的方法，还包括：
    在成功执行所述用户的支付请求后，向所述用户发送获取累加保险参数的消息，以供所述电子设备在支付结果页面中展示所述累加保险参数的获取入口。
  13. 根据权利要求12所述的方法，还包括：
    响应于用户基于所述获取入口发送的累加保险参数获取请求，判断是否存在所述用户对应的电子设备保单；
    若存在，则获取所述用户对应的电子设备保单的当前保险参数；
    根据所述累加保险参数和相同类型的当前保险参数更新所述电子设备保单的当前保险参数。
  14. 根据权利要求13所述的方法，还包括：
    若不存在所述用户对应的电子设备保单，则保存所述用户和累加保险参数之间的映射关系。
  15. 根据权利要求11所述的方法，所述累加保险参数具有有效时长；
    所述方法还包括：
    在到达所述累加保险参数的有效时长后，还原保单的保险参数。
  16. 根据权利要求11所述的方法，所述保险参数包括：保额和保障期限。
  17. 根据权利要求1所述的方法，
    所述电子设备投保请求由用户触发支付结果界面的指定入口后发送。
  18. 根据权利要求1所述的方法，
    所述电子设备投保请求为电子设备的屏幕保险投保请求。
  19. 一种电子设备的保险实现装置，应用于服务器，所述装置包括：
    行为数据获取单元，响应于用户发起的电子设备投保请求，获取所述用户的行为数据；
    设备属性确定单元，根据所述行为数据确定所述投保请求的标的设备的属性；
    电子设备核保单元，根据所述属性对应的核保策略对所述投保请求进行核保。
  20. 根据权利要求19所述的装置，所述电子设备核保单元：
    当标的设备的属性是新机时，确定核保通过。
  21. 根据权利要求19所述的装置，所述电子设备核保单元：
    当标的设备的属性是老机时，向所述用户发送上传校验数据的提示信息；
    响应于用户发送的校验数据，根据所述校验数据对所述投保请求进行核保。
  22. 根据权利要求21所述的装置，所述电子设备核保单元：
    根据上传时段与上传方式之间的映射关系，确定当前时刻对应的上传方式；
    将所述上传方式携带在所述提示信息中发送给用户。
  23. 根据权利要求19所述的装置，所述行为数据获取单元：
    获取所述用户在预定时间段内的历史交易数据；
    所述设备属性确定单元：
    判断所述历史交易数据中是否包括电子设备的购买交易数据；
    若是，则确定标的设备的属性是新机。
  24. 根据权利要求23所述的装置，所述设备属性确定单元：
    当所述历史交易数据中包括多个电子设备的购买交易数据时，发送对应的电子设备列表给用户；
    接收用户基于所述电子设备列表发送的选择指令；
    将用户所述选择指令中指定的电子设备确定为所述标的设备。
  25. 根据权利要求19所述的装置，所述行为数据获取单元：
    获取所述电子设备投保请求的发起设备的设备标识，作为发起标识；
    查找所述用户历史登录设备的设备标识，作为历史标识；
    所述设备属性确定单元：
    判断所述发起标识与所述历史标识是否相同；
    若不相同，则确定所述标的设备的属性是新机。
  26. 根据权利要求25所述的装置，所述设备属性确定单元：
    根据所述行为数据判断所述用户是否为可信用户；
    若所述用户是可信用户，且所述发起标识与所述历史标识不相同，则确定所述标的设备的属性是新机。
  27. 根据权利要求23-26任意一项所述的装置，所述设备属性确定单元：
    当无法确定所述标的设备的属性是新机时，确定所述标的设备的属性是老机。
  28. 根据权利要求19所述的装置，还包括：
    黑名单判断单元，响应于用户发起的电子设备投保请求，判断所述用户是否命中黑名单；
    若否，则通知行为数据获取单元执行获取所述用户的行为数据的步骤。
  29. 根据权利要求19所述的装置，还包括：
    保险参数确定单元，在核保通过后，获取所述用户的若干累加保险参数；
    基于所述累加保险参数和相同类型的缺省保险参数确定本次投保的当前保险参数；
    其中，所述累加保险参数由所述用户基于支付结果页面获取。
  30. 根据权利要求29所述的装置，所述保险参数确定单元：
    在成功执行所述用户的支付请求后，向所述用户发送获取累加保险参数的消息，以供所述电子设备在支付结果页面中展示所述累加保险参数的获取入口。
  31. 根据权利要求30所述的装置，所述保险参数确定单元：
    响应于用户基于所述获取入口发送的累加保险参数获取请求，判断是否存在所述用户对应的电子设备保单；
    若存在，则获取所述用户对应的电子设备保单的当前保险参数；
    根据所述累加保险参数和相同类型的当前保险参数更新所述电子设备保单的当前保险参数。
  32. 根据权利要求30所述的装置，所述保险参数确定单元：
    若不存在所述用户对应的电子设备保单，则保存所述用户和累加保险参数之间的映射关系。
  33. 根据权利要求29所述的装置，所述累加保险参数具有有效时长；
    所述保险参数确定单元：
    在到达所述累加保险参数的有效时长后，还原保单的保险参数。
  34. 一种电子设备的保险实现装置，包括：
    处理器；
    用于存储机器可执行指令的存储器；
    其中，通过读取并执行所述存储器存储的与电子设备的保险实现逻辑对应的机器可执行指令，所述处理器被促使：
    响应于用户发起的电子设备投保请求，获取所述用户的行为数据；
    根据所述行为数据确定所述投保请求的标的设备的属性；
    根据所述属性对应的核保策略对所述投保请求进行核保。
PCT/CN2021/093296 2020-05-15 2021-05-12 电子设备的保险实现 WO2021228133A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010412541.0 2020-05-15
CN202010412541.0A CN111553801A (zh) 2020-05-15 2020-05-15 电子设备的保险实现方法和装置

Publications (1)

Publication Number Publication Date
WO2021228133A1 true WO2021228133A1 (zh) 2021-11-18

Family

ID=72006372

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/093296 WO2021228133A1 (zh) 2020-05-15 2021-05-12 电子设备的保险实现

Country Status (2)

Country Link
CN (1) CN111553801A (zh)
WO (1) WO2021228133A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111553801A (zh) * 2020-05-15 2020-08-18 支付宝(杭州)信息技术有限公司 电子设备的保险实现方法和装置
CN112268912A (zh) * 2020-10-09 2021-01-26 支付宝(杭州)信息技术有限公司 基于镜面拍摄的屏幕损伤验证方法和装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070299700A1 (en) * 2004-10-29 2007-12-27 Milemeter, Inc. System and Method for Assessing Earned Premium for Distance-Based Vehicle Insurance
CN105956865A (zh) * 2016-05-04 2016-09-21 深圳市万普拉斯科技有限公司 电子保修卡的生成方法、服务器、查询方法和装置
CN107545447A (zh) * 2016-06-23 2018-01-05 斑马网络技术有限公司 获取残值的方法、装置、终端设备和用户界面系统
CN107730391A (zh) * 2017-11-02 2018-02-23 泰康保险集团股份有限公司 电子设备远程自动投保方法、装置、介质和电子设备
CN109285079A (zh) * 2018-08-31 2019-01-29 阿里巴巴集团控股有限公司 终端屏幕保险的数据处理方法、装置、客户端及服务器
CN111553801A (zh) * 2020-05-15 2020-08-18 支付宝(杭州)信息技术有限公司 电子设备的保险实现方法和装置

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070299700A1 (en) * 2004-10-29 2007-12-27 Milemeter, Inc. System and Method for Assessing Earned Premium for Distance-Based Vehicle Insurance
CN105956865A (zh) * 2016-05-04 2016-09-21 深圳市万普拉斯科技有限公司 电子保修卡的生成方法、服务器、查询方法和装置
CN107545447A (zh) * 2016-06-23 2018-01-05 斑马网络技术有限公司 获取残值的方法、装置、终端设备和用户界面系统
CN107730391A (zh) * 2017-11-02 2018-02-23 泰康保险集团股份有限公司 电子设备远程自动投保方法、装置、介质和电子设备
CN109285079A (zh) * 2018-08-31 2019-01-29 阿里巴巴集团控股有限公司 终端屏幕保险的数据处理方法、装置、客户端及服务器
CN111553801A (zh) * 2020-05-15 2020-08-18 支付宝(杭州)信息技术有限公司 电子设备的保险实现方法和装置

Also Published As

Publication number Publication date
CN111553801A (zh) 2020-08-18

Similar Documents

Publication Publication Date Title
WO2021228229A1 (zh) 电子设备的保险实现
TWI777520B (zh) 電子設備投保的校驗方法和裝置
US9509840B2 (en) Method and system for marking a phone number
WO2019100854A1 (zh) 基于信用实现理赔的方法和装置
US20130066757A1 (en) System and method for identifying, locating and recovering collateralized assets
US11068862B2 (en) Intelligent authentication process
WO2021228133A1 (zh) 电子设备的保险实现
US11468508B2 (en) Capturable code for automatically formatting and addressing a text message to apply for an offer
US8655773B1 (en) Geo-location based underwriting
US20200167861A1 (en) Secure data acquisition and processing system
WO2002039337A1 (fr) Procede pour traiter des informations dans le marche a caractere contributif
JP2015069404A (ja) 調査システム、調査方法、サーバ、ユーザ端末、プログラム、記録媒体
KR101609336B1 (ko) 상품 관리 방법 및 장치
KR102327711B1 (ko) 용역 제공자 중개 플랫폼 시스템
US10650354B2 (en) System and method for transacting lead and scheduled appointment records
WO2023093224A1 (zh) 目标对象的提报方法、装置及设备
CN110796436B (zh) 针对共享办公的进程管理系统、方法、设备及可读介质
AU2019101233A4 (en) Searchable system for registered items, and a method for searching a searchable system
CN111047341B (zh) 信息处理方法、装置、服务器及终端设备
CN108346056A (zh) 团体状况的认证方法及装置
CN111553802A (zh) 电子设备的保险实现方法和装置
CN112632391A (zh) 数据处理方法、设备及存储介质
KR101799043B1 (ko) 명함을 이용한 대출 서비스 제공 방법 및 시스템
US20160307266A1 (en) System and method for matching in social-networking platform
US20190156341A1 (en) Method and web server for providing card payment simple authentication service

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21803003

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21803003

Country of ref document: EP

Kind code of ref document: A1