IT202100031529A1 - METHOD OF MANAGEMENT OF A CUSTOMER DATABASE OF A PLATFORM FOR THE PROVISION OF SERVICES AND RELATED PLATFORM - Google Patents

Description

DESCRIPTION

[0001] The present invention concerns the sector of web-based platforms for the provision of services and refers in particular to a platform, or portal, which includes software modules for the creation and management of pre-contractual documents by a subject provider of a service, by way of example and not limited to an insurance, financial or credit service. More? in detail, the invention concerns methods for managing customer databases containing customer data and pre-contractual documents.

[0002] How? known, one of the aspects that service providers must consider when managing databases is? compliance with privacy regulations. Compliance with privacy regulations? due in many cases, not only in the insurance sector but more? in general in all sectors in which ? It is essential to collect data and information from possible customers to offer services as much as possible. possible tailored to specific needs and to provide the relevant estimates. In these phases preceding customer acquisition, a possible option to guarantee respect for privacy? that of not storing the data exchanged with potential customers. The management of the databases containing the personal data of the subjects is implemented by storing not the clear information relating to the customer but encrypted information, for example through a hash function. In this way, even if an unauthorized person managed to access the database, he would not be able to obtain the data of the people present in the database.

[0003] Does this approach work? The search for information relating to a customer, for example a mobile phone number, is very poor performance since, since the data is not clear, all the hashes present must be verified one by one, thus making the search very slow. This problem also occurs when you want to verify the number of tax codes associated with the same telephone number.

[0004] Therefore, the use of hashes significantly limits the search within the database, making a complete scan of the database necessary.

[0005] An aim of the present invention? that of providing a method of managing a customer database of a platform as described above, which allows maintaining the anonymity of the data and at the same time allows rapid searches of the data.

[0006] Another purpose of the present invention? that of providing a database management method that allows the anonymity of the data to be maintained and at the same time allows the platform manager to modify pre-contractual documents.

[0007] A further purpose of the present invention? that of allowing the platform to certify the data of intermediaries who intend to use the platform to provide services.

[0008] These objectives are achieved with the methods and with the platform of the attached independent claims. The dependent claims describe preferred or advantageous embodiments of the invention.

[0009] The characteristics and advantages of the database management method and the related platform according to the invention will however be evident from the following description of its preferred implementation examples, given for indicative and non-limiting purposes, with reference to the attached figures , in which:

[0010] - Figure 1 illustrates a flowchart of the method of storing and searching customer data in a customer database;

[0011] - Figure 2 illustrates a flow diagram of a procedure for certifying the information of an intermediary subject who provides a service.

[0012] Examples of implementation of data and document management methods of a customer database of a server of a platform for the creation of pre-contractual documents will be described below.

[0013] In particular, will it be done? reference to software modules configured to manage the generation, compilation, signature, and possibly modification, of service sheets which include information on the potential customer who is the subject of the commercial proposal and on the commercial proposal itself. These service sheets are here defined as Demands & Needs, D&N, as they are formulated for the evaluation of customer requests and needs. The software module for managing the service cards will be? therefore also called D&N module.

[0014] ? However, it is clear to the technician in the sector that the technical solutions proposed here can be applied in other areas where products or services are supplied which in particular require the creation and exchange of pre-contractual documents with a potential customer.

[0015] In one embodiment, the platform allows the signing of pre-contractual forms using a simple OTP signature (?One Time Password?). Since? the pre-contractual documentation does not require an advanced electronic signature (FEA), ? A simple OTP signature has been implemented based on sending a disposable token to the mobile number of the customer for whom the D&N form is being filled out. AND? However, it is clear to the sector technician that the proposed method and platform can support both the Simple Electronic Signature (FES) and the FEA, for example for the brokerage mandate rather than for the credit mediation mandate.

[0016] Before being able to proceed with the OTP signature? necessary to verify the correctness as well as? the existence of the mobile number attributable to the counterparty who will have to receive the one-time token (OTP). To do this, an OTP code is sent to the mobile phone that you want to use for the signature, the customer will have to? dictate the code to the intermediary who will provide it to insert it into the system; if the code matches the mobile number is verified and considered valid for 180 days from the verification date. The system does not allow OTP signatures to be added to documents until the mobile number is not correctly verified.

[0017] Once the verification has been carried out, a new OTP code is generated which is also in this case sent via SMS to the customer who will take care of it. to dictate it to the intermediary who will be able to insert it into the portal for verification which, in the event of a positive outcome, will constitute? the electronic signature of the Customer. If the code is accepted the stamper system? documents in PDF format with the signature data printed. When verifying the OTP code provided, the system also verifies that the mobile number has not been used to sign documents relating to different customers; in general, however, the association between a mobile phone number and a limited number of tax codes is allowed, for example five.

[0018] In order not to store users' personal data in the platform database, only data relating to the hashes identifying the data used for the signature are saved. In particular, the following values are stored as hashes: customer tax code; mobile number used for signing; OTP code sent.

[0019] The D&N module uses an algorithm created to maintain data relating to OTP signature hashes and at the same time allow a quick search to verify the registration of a mobile number without the need to store personal data.

[0020] The D&N module ? configured to generate a policy template, i.e. a pre-contractual document, fill in a D&N form, perform the OTP signature.

[0021] With reference to the flow diagram of figure 1, in a first phase (10), a pre-contractual D&N form is created to be delivered to a potential customer.

[0022] For example, in the case of an insurance service, the service manager fills in a certain number of fields, such as: Title for the proposal (e.g. RCA, Accident and Illness, Life, Temporary Death Case TCM); Area of protection (e.g. life, car, accidents and illnesses, professions), Mandate, email address of the agency where you want to receive the pre-policy documents.

[0023] In a second phase (12) the ?Demands & Needs?, D&N form is filled in.

[0024] At this stage, an operator can? manually enter the potential customer's data into the form (name, surname, tax code, mobile number, address, profession, etc.).

[0025] Subsequently (step 14), a form is filled out in which the coverages requested by the potential customer and those proposed directly by the proponent or his intermediary, for example an insurance agent, are selected. A third column is then filled in which reports the customer's final choice.

[0026] Based on the customer's final choice, the module selects the most suitable product. suitable, what will it be? printed in the final documentation.

[0027] At this point, once the D&N form has been filled in, the module proceeds to have the customer sign the pre-contractual documentation using an OTP signature (?One Time Password?) (step 16).

[0028] As stated above, in one embodiment, the customer is identified with his/her social security number and cell phone number.

[0029] In the event that the recipient of the policy proposal has not yet been registered, the signature procedure involves carrying out a preliminary verification of the potential customer's telephone number. This verification procedure involves sending the potential customer a first SMS with a verification OTP code (step 18).

[0030] The potential customer, having received the OTP verification code on his mobile phone, returns it to the platform, for example by dictating the code (step 20).

[0031] This first verification code can? remain linked to the customer's profile for a pre-established period of time, for example 180 days, to allow the preparation and sending of any subsequent policy proposals without having to repeat the verification procedure each time.

[0032] Once you have entered the verification code on the D&N card, you can? proceed to the actual signing phase.

[0033] The signing phase involves sending a second SMS to the potential customer with an OTP signature code (step 22).

[0034] As for the first verification code, the recipient returns the signature code to the platform (step 24).

[0035] Upon entering the signature code in the appropriate field of the D&N form, a service form file is generated in PDF format with the pre-contractual set, fed in dynamics directly from the system (step 26). This file will report? on all pages the customer's OTP signature with relative OTP code.

[0036] Note that the service card file in PDF format will be automatically named with the customer's tax code and the initials based on the type of policy; furthermore, the agent's data may appear, for example with the digital signature uploaded to the portal.

[0037] As mentioned above, once a potential customer is been registered, your data is stored in a customer database in order to avoid further verification procedures in the event of any subsequent policy proposals. For this purpose, the platform stores hashes related to customer data (step 28), for example: signer's tax code, mobile number used to receive the OTP code, OTP code sent.

[0038] In this way, starting from the clear data relating to the tax code and mobile number? Is it possible to verify the validity? of the hashes generated without storing any personal data of the user in the database.

[0039] This mode? data storage makes for? the search for a mobile number among those already performs very poorly? verified because since the data is not clear, all the hashes present must be verified one by one, thus making the search very slow. This problem also occurs when you want to verify the number of tax codes associated with the same telephone number.

[0040] To overcome this problem, without however storing personal data, the platform includes a software module configured to store in an encrypted way partial information of the tax code and telephone number in order to then be able to find more information. quickly the requested information in the database.

[0041] In particular, for each entry into the customer database (for example for verifying a mobile number or storing a signature to track the number of tax codes associated with a specific mobile number) an encrypted information is stored pre-established portion of the mobile number and/or tax code (step 30).

[0042] In a preferred embodiment, four characters of the mobile phone number (for example from the fourth to the seventh character) and nine characters of the tax code (from the seventh to the fifteenth) are stored in encrypted form.

[0043] The choice of substring to store? was done by evaluating the information that this portion of the string contains: in the case of the tax code, for example, it only contains date and place of birth and therefore essentially anonymous or pseudonymized information.

[0044] The information like this? saved allow a significantly easier search? quickly (for example via a simple SQL query) within the database. Once the rows corresponding to the searched values have been identified, the complete hash is verified as follows. to be sure that the data like this? found correspond to what was searched for.

[0045] More? in detail, in one embodiment the encrypted portions of the tax code and/or mobile number are associated with the hashes of the tax code and mobile number (step 32).

[0046] Upon subsequent receipt (34), by the server, of a tax code and/or a mobile number of a customer to be verified, the same pre-established portion of the code is extracted by the server software module tax and/or mobile number to verify.

[0047] At this point, this pre-established portion of the tax code and/or mobile number to be verified is encrypted by the server software module (step 36).

[0048] A comparison is then made between the encrypted portions of the tax code and/or mobile number to be verified with corresponding encrypted portions of the tax code and/or mobile number previously stored in the database (step 38).

[0049] If the comparison is successful, the complete hash of the tax code and mobile number associated with the encrypted portions of the tax code and/or mobile number previously stored is extracted (step 40).

[0050] In accordance with another aspect of the invention, the service provider platform further comprises a software module for retrieving information from a D&N card.

[0051] How already? Remember, the customer data reported in the D&N sheets are not saved in clear text in the customer database to reduce the risk of violating the Privacy regulations.

[0052] Sometimes though? can? be useful to the person managing the service to modify and/or correct a card already? filled out. AND? therefore the possibility was introduced? to recover the card data by uploading the service card file in PDF generated by the latter to the platform as described above.

[0053] To allow the possibility? to modify and/or correct a card? A particular measure has been introduced in the process of generating the PDF file of the D&N form. In particular, all the information contained in the form is organized into an object suitable for being serialized as a JSON object (?JavaScript Object Notation?). Once transformed into a string in this format, the string is encrypted and transformed into text in BASE64.

[0054] This text, which in fact completely represents the data contained in the D&N card, is stored as a meta attribute of the Pdf file (more precisely it is stored in the meta-field: ?Keywords? of the Pdf file). In this way, if the file were to be reread by the portal, it will be it is sufficient to decode the data contained in the Keywords meta-field to be able to completely recreate the structure of the D&N form and allow the service provider to make the necessary corrections and/or modifications.

[0055] In accordance with another aspect of the invention, in the event that the platform is used by an intermediary, the platform includes a software module for certifying the intermediary's information.

[0056] How? known, the subjects authorized to provide an intermediation service, for example insurance agents, are registered in a register, for example in the insurance sector the ?Single Register of Intermediaries?, or RUI, which however? does not allow a mode? automated access to the information contained therein.

[0057] This certification module allows the verification of the data entered by the intermediary thanks to the query of the database (in this case, for example, the aforementioned RUI) and the login with the SPID of the operating intermediary.

[0058] The certification procedure is based on an initial verification of the intermediary's personal data carried out thanks to the login with SPID which guarantees the identity of the intermediary. of the person who accesses the platform.

[0059] Subsequently? It is necessary to verify the data automatically and securely on the RUI online search engine (in the example in question), as no modality is available on the latter. of access to automated information.

[0060] To allow this verification to be carried out on the RUI site (in the present example) automatically, two possible procedures have been envisaged.

[0061] A first procedure involves the use of a BOT for dynamic analysis of web pages to be able to automatically query the RUI site and read the requested information.

[0062] The second procedure instead involves loading the RUI site (in the present example) into a WEB IFRAME and with specific commands injected into it, navigation is performed, requiring the user to intervene only in the presence of CAPTCHA checks aimed at blocking of automatic BOTs.

[0063] The search on RUI (in the example in question) takes place using the personal data retrieved via SPID (Name, Surname, Tax Code, date and place of birth) so? the intermediary must be uniquely identified even in cases of homonymy.

[0064] This operation will happen? performed periodically by the portal in order to maintain the certification of validity? of the data entered by the intermediary and attached to each document produced by the portal which involves the use of such data.

[0065] An example of a procedure for certifying the intermediary's data? represented in the flow diagram of figure 2.

[0066] The intermediary who wishes to use the platform to provide the service fills out an intermediary information sheet on the platform (step 100).

[0067] The intermediary is invited to log in to the platform via SPID (step 110) or to update the SPID login if a certain number of months (for example six months) have passed since the last SPID login (step 120 ).

[0068] The intermediary performs SPID access on the platform (step 130).

[0069] The certification module checks whether the intermediary's data is already been verified on the RUI (step 140).

[0070] In case of a negative response, the certification module checks whether APIs for connection to the RUI exist (step 150).

[0071] If so, the intermediary's data is retrieved via the API and imported onto the platform (step 160).

[0072] If not, the certification module executes an automatic data extraction Robot (or BOT), as described above (step 170).

[0073] Subsequently, the certification module can? carry out a check whether the intermediary's email address, PEC and mobile phone have been verified by the platform (step 180).

[0074] If so, the certification module issues a certification accompanied by a QR-Code on the pre-contractual documentation generated by the platform (step 190).

[0075] If not, if you wish to proceed with this verification, a two-factor verification procedure with OTP of the intermediary's contacts entered in the platform is activated (step 200).

[0076] If the verification is successful, the certification is issued (step 190).

[0077] In one embodiment, the platform for providing the service is based on web cloud software.

[0078] For example, the platform ? developed in PHP and is based on the open source Laravel framework.

[0079] In one embodiment, the platform is implemented using the MVC pattern (Model View Controller), which provides a clear separation between the data model (Model), the application logic (Controller), and the data presentation (View).

[0080] Each module is implemented by a pair composed of Controllers and Views.

[0081] The server infrastructure that allows the correct execution of the platform? made up of two cloud servers: one server? dedicated to managing the system database while the other runs the application logic and acts as a real web server.

[0082] For example, the database ? relationship type (based on DBMS MySQL and MariaDB).

[0083] To the embodiments of the methods and the related platform according to the invention, a technician in the art, to satisfy contingent needs, will be able to make modifications, adaptations and replacements of elements with functionally equivalent ones, without departing from the scope of the following claims.

Each of the characteristics described as belonging to a possible embodiment can? be carried out independently of the other embodiments described.

Claims (8)

1. Method of archiving and searching customer data in a customer database of a server of a platform for creating and managing pre-contractual documents between a service provider and customers using the service, including the phases of: - transmit, from a customer to the server, the customer's tax code and a customer's mobile number; - apply, by a server software module, a hash function to the tax code and mobile number; - store the hashes of the tax code and mobile number in the customer database; - extract, by the server software module, a pre-established portion of the tax code and/or a portion of the mobile number; - encrypt, by the server software module, said pre-established portion of the tax code and/or mobile phone number; - memorize, by the server software module, said encrypted portions of the tax code and/or mobile number; - associate said encrypted portions of the tax code and/or mobile number with the hashes of the tax code and mobile number; - upon subsequent receipt by the server of a tax code and/or mobile number of a customer to be verified, the server software module extracts the same pre-established portion of the tax code and/or number cell phone to verify; - encrypt, by the server software module, said pre-established portion of the tax code and/or mobile number to be verified; - compare said encrypted portions of the tax code and/or mobile number to be verified with corresponding encrypted portions of the tax code and/or mobile number previously stored in the database; - if the comparison is successful, extract the complete hash of the tax code and mobile number associated with the encrypted portions of the tax code and/or mobile number previously stored. 2. Method according to claim 1, in which four characters of the mobile phone number, for example from the fourth to the seventh character, and nine characters of the tax code, for example from the seventh to the fifteenth, are stored in encrypted form. 3. Method according to claim 1 or 2, wherein the server comprises a service card creation module configured to create, compile, have the customer sign via OTP signature, and save a service card containing information in a service card file in PDF format on the service to be provided, the method including the phases of: - transform all the information contained in the service sheet into a string in JavaScript Object Notation, JSON format; - encrypt and transform said string into text in BASE64; - store said text as a meta-attribute of the service card file; - decode the data contained in the meta-attribute to be able to completely recreate the structure of the service sheet and possibly modify the information contained in the service sheet. 4. Method according to any of the previous claims, wherein the platform is? used by a company intermediary? service providers and includes a software module for certifying the intermediary's information, the method including the phases of: - access the platform, by the intermediary, by registering with SPID; - automatically query the website containing the register or public register of the professional or intermediary (for example, the Single Registry of Assocurative and Reinsurance Intermediaries, RUI), using a dynamic web page analysis robot and verify the correspondence between the information obtained from registration with SPID and the information contained in the RUI; or - load the aforementioned website into a WEB IFRAME and perform navigation to verify the correspondence between the information obtained from registration with SPID and the information contained in the aforementioned website, requesting the intermediary user to intervene only in the presence of CAPTCHA checks aimed at block automatic BOTs. 5. Method for creating and modifying service cards in a web cloud-based platform for the provision of a service to customers by a platform manager, where the platform includes a service card creation module configured to create, fill in, have the customer sign using an OTP signature, and save a service sheet containing information on the service to be provided in a service sheet file in PDF format, the method including the phases of: - transform all the information contained in the service sheet into a string in JavaScript Object Notation, JSON format; - encrypt and transform said string into text in BASE64; - store said text as a meta-attribute of the service card file; - decode the data contained in the meta-attribute to be able to completely recreate the structure of the service sheet and possibly modify the information contained in the service sheet. 6. Data certification method of an intermediary registered in a public professional register, for the use of a web-based platform for the provision of a service to customers, the method including the phases of: - access the platform, by the intermediary, by registering with SPID; - automatically query the aforementioned website (for example the RUI), using a dynamic web page analysis robot and verify the correspondence between the information obtained from registration with SPID and the information contained in the aforementioned site; or - load the aforementioned website into a WEB IFRAME and perform navigation to verify the correspondence between the information obtained from registration with SPID and the information contained in the aforementioned public site, requesting the intermediary user to intervene only in the presence of CAPTCHA checks aimed at block automatic BOTs. 7. Web cloud-based platform for the provision of a service to customers by a platform manager, comprising hardware and software modules configured to implement a method according to any of the previous claims. 8. IT product comprising portions of code which, when the code is ? executed by a platform according to the previous claim, implement a method according to any of claims 1-6.