Information processing device, information processing method, and program

Abstract

To implement a hub function for connecting a plurality of insurance-related service providers.SOLUTION: A service provider server 1 communicates with an insurance company existing system HS of an insurance company H and a staff terminal DT of an agency D. A customer information management unit 51 regards a policyholder or a policyholder candidate as a customer, and stores and manages information about the customer as first customer information in an insurance DB 71. In the insurance company existing system HS of the insurance company H, an insurance API that, in response to an input of prescribed information, outputs second customer information about a customer being managed by the insurance company existing system HS is constructed. An insurance API control unit 53 performs control to transmit the prescribed information to the insurance company existing system HS and acquire the second customer information.SELECTED DRAWING: Figure 7

Description

Technical Field

[0001] The present invention relates to an information processing apparatus, an information processing method, and a program.

Background Art

[0002] Conventionally, technologies for supporting providers of insurance-related services (such as insurance companies and agencies) have been proposed (see, for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, it is common for multiple persons to be involved as providers of insurance-related services, such as when an agency handles insurance products that combine insurances provided by multiple insurance companies. For this reason, the realization of a function serving as a hub that connects multiple providers of insurance-related services is required, but the conventional technologies including Patent Document 1 are in a situation where such a requirement cannot be met.

[0005] The present invention has been made in view of such a situation, and an object thereof is to realize a function serving as a hub that connects multiple providers of insurance-related services.

Means for Solving the Problems

[0006] To achieve the above object, an information processing apparatus according to one aspect of the present invention is an information processing apparatus that communicates with other information processing apparatuses that are providers of insurance-related services, A first-class customer information management means that manages information about the insured or prospective insured person of the aforementioned insurance as first-class customer information by storing it in a predetermined database, An API is constructed in the other information processing device that outputs Type 2 customer information relating to the customer, which is outside the management of the Type 1 customer information management device but is managed by the other information processing device, triggered by the input of predetermined information, and a Type 2 customer information acquisition means executes control to acquire the Type 2 customer information by transmitting the predetermined information to the other information processing device, It is equipped with.

[0007] Each of the information processing method and program according to one aspect of the present invention corresponds to the method and program corresponding to the information processing apparatus according to one aspect of the present invention described above. [Effects of the Invention]

[0008] According to the present invention, it is possible to realize a function that acts as a hub connecting multiple providers of insurance-related services. [Brief explanation of the drawing]

[0009] [Figure 1] This figure shows an overview of the service that can be realized by an information processing system to which one embodiment of the information processing device of the present invention is applied. [Figure 2] Figure 1 shows an example of how this service can be applied. [Figure 3] Figure 2 illustrates a specific application example of the insurance API provided as one of the services offered. [Figure 4] This diagram illustrates an example of how the differences in product features and operations between similar insurance products offered by two different insurance companies are defined in their respective documentation. [Figure 5] This figure shows an example of the configuration of an information processing system to which a service provider server according to one embodiment of the information processing device of the present invention is applied. [Figure 6] Figure 6 is a block diagram showing an example of the hardware configuration of the service provider server in the information processing system shown in Figure 5. [Figure 7] This is a functional block diagram showing an example of the functional configuration of the insurance system infrastructure HB, which is one of the functional configurations of the server in Figure 6, which is a component of the information processing system in Figure 5. [Modes for carrying out the invention]

[0010] Embodiments of the present invention will be described below with reference to the drawings.

[0011] First, with reference to Figure 1, an overview of a service (hereinafter referred to as "this service") that can be realized by an information processing system to which one embodiment of the information processing device of the present invention is applied will be described.

[0012] Figure 1 shows an overview of the service that can be realized by an information processing system to which one embodiment of the information processing device of the present invention is applied.

[0013] This service is provided by a service provider (for example, service provider SA in Figure 2 described below) to insurance companies H1 to HP with P (where P is an integer value of 1 or more, and in the example in Figure 1, P=3) and to agents D1 to DQ with Q (where Q is an integer value of 1 or more, and in the example in Figure 1, P=3). Furthermore, if there is no need to distinguish between insurance companies H1 through HP individually, they will be collectively referred to as "insurance company H." Similarly, if there is no need to distinguish between agencies D1 through DQ individually, they will be collectively referred to as "agency D."

[0014] Insurance companies H1 through HP under P are entities that provide services offering one or more types of insurance (life insurance or non-life insurance), such as life insurance companies, non-life insurance companies, and businesses that handle small-amount, short-term insurance products. The agents D1 to DQ of Q are those who contact customers and perform the service of providing insurance products (combinations of one or more insurances, etc.) on behalf of the customers, such as membership markets, e-commerce operators, travel agencies, corporate agents (workplace insurance), small and medium-sized enterprise employees, banks (those who manage the applications of the bank), etc. Note that at least some of the agents D1 to DQ of Q may be platforms without insurance agency qualifications.

[0015] The service provider manages the insurance system infrastructure HB by means of a service provider server (for example, the service provider server 1 in FIG. 3 described later), which is an embodiment of the information processing apparatus of the present invention. The insurance system infrastructure HB is connected to the insurance companies H1 to HP of P and the agents D1 to DQ of Q (precisely, various apparatuses managed by each of them). Thereby, the insurance system infrastructure HB functions as a SaaS system that serves as a hub for connecting each of the insurance companies H1 to HP of P and each of the agents D1 to DQ of Q. The insurance system infrastructure HB provides and enables various functions, such as insurance APIs, marketing functions, UX functions, insurance claim bot provision functions, application provision functions, etc., for each of the insurance companies H1 to HP of P. Also, the insurance system infrastructure HB provides and enables various functions, such as insurance certificate my page (product pages, application forms, etc. for predetermined insurance products) management functions, scraping functions, etc., for each of the agents D1 to DQ of Q.

[0016] FIG. 2 is a diagram showing an application example of the present service in FIG. 1. In the example of FIG. 2, a predetermined insurance company H among the insurance companies H1 to HP and a predetermined agent D among the agents D1 to DQ of Q are connected by the insurance system infrastructure HB. The insurance company H is a person who provides one or more insurances to customers, and manages a person-in-charge terminal HT such as a call center and an existing insurance company system HS. The existing insurance company system HS is composed of a mainframe system, an accounting system, etc. of the insurance company H. Agent D is a person who acts on behalf of providing insurance products (products consisting of combinations of one or more insurances, etc.) to customers, and manages a customer network CN, product pages, and application forms SF provided by service provider SA.

[0017] In this way, by connecting insurance company H and agent D to insurance system infrastructure HB, it becomes possible to provide, for example, the following services S1 to S6. Service S1 is for the insurance system infrastructure HB to synchronize with the existing insurance company system HS through batch processing - CSV linking, etc. Service S2 enables authorized personnel terminals HT to view and edit various types of information managed by the insurance system infrastructure HB through the admin portal. Service S3 is an engineering service for the insurance system infrastructure HB provided by service provider SA. Service S4 is an engineering, design, and marketing service for product pages and application forms SF provided by service provider SA. Service S5 is a service for constructing insurance APIs. Service S6 is a service for assisting customers managed by customer network CN to conclude insurance contracts while utilizing product pages & application forms SF.

[0018] Hereinafter, referring to Figure 3, service S5, that is, the service for constructing insurance APIs will be described in detail. Figure 3 is a diagram for explaining a specific application example of insurance APIs.

[0019] As shown in Figure 3, product pages SF and application forms SF present various types of information to customers regarding insurance products including insurance of insurance company H, and ultimately assist in concluding insurance contracts. When a customer is considering an insurance product or concluding an insurance contract, an immediate determination of whether the insurance product is applicable to the customer is required. However, the customer information necessary to make such immediate decisions is not managed in the insurance system infrastructure HB, but rather in the insurance company's existing system HS. For example, for insurance provided by insurance company H, the amount of insurance (compensation) that can be granted to each customer is determined by insurance company H's internal regulations and legal constraints. An immediate decision is needed to determine whether or not there is a violation of such internal rules, that is, whether the amount of insurance for the insurance product that the customer is considering or intends to contract exceeds the amount granted to that customer. Therefore, as shown in Figure 3, Service S5 enables the construction of an API on the insurance company's existing system HS, and the insurance system infrastructure HB and the insurance company's existing system HS are linked to enable such immediate decision-making. Furthermore, as mentioned above, the insurance system infrastructure HB and the insurance company's existing system HS are also linked through the batch processing_CSV linkage service S1 in Figure 2. However, since the frequency of batch processing_CSV linkage is only about once a week, there is a risk that it may not be fast enough for immediate decisions (there is a risk that information that should be updated may not be updated). For this reason, service S5, namely the service for building the insurance API, is provided. Specifically, for example, in the example shown in Figure 3, the insurance amount set for a customer at insurance company H is data that can be obtained via API. The data sent via API to obtain this data includes the customer's age, gender, date of birth, address, etc.

[0020] The insurance APIs that can be built using Service S5 are not limited to the example in Figure 3, and various types can be adopted. For example, some insurance companies H have an anti-social group check system as part of their existing insurance system HS. In such cases, it is possible to build an API that calls the anti-social group check system of the insurance company's existing system HS in order to check whether a customer is affiliated with an anti-social group. By building such an API, it becomes possible to instantly determine whether or not a customer is affiliated with an anti-social group. For example, it is possible to build an API that returns the subscription status and consideration status of other insurance products for a customer at insurance company H. If such an API is built and customer identity can be guaranteed, it will be possible to immediately suggest insurance options for that customer, such as if they have too much insurance, if they have insufficient insurance, or if they would like better insurance options, within the insurance system infrastructure HB (for example, the product page SF and application form SF connected to it). Furthermore, for example, it is possible to build an API that retrieves a customer's insurance performance (past insurance claim history) at insurance company H. By building such an API, it becomes possible to instantly determine, for example, whether a customer is ineligible for insurance due to being prone to frequent car accidents. For example, if an insurance company's existing system HS has a database for managing customer personal information, it becomes possible to build an API that returns the personal information necessary for insurance applications. This makes it possible to improve the user experience (UX) by providing input assistance in the insurance system infrastructure HB (for example, the product pages and application forms SF connected to it). Furthermore, the information called by these various insurance APIs is also linked between the insurance system infrastructure HB and the insurance company's existing system HS at a frequency of about once a week, through batch processing_CSV linkage of service S1 in Figure 2 as described above. However, as mentioned above, there is a risk that immediate decisions may not be made in time (there is a risk that information that should be updated may not have been updated), so it is preferable to have these various insurance APIs built.

[0021] In summary, service S5, that is, the service that builds the insurance API, can be realized because the insurance system platform HB has and performs the following functions. In other words, the insurance system infrastructure HB has the function of communicating with other information processing devices of providers of insurance-related services. Here, "providers of insurance services" is a collective term for P's insurance companies H1 through HP and Q's agents D1 through DQ. Furthermore, "other information processing devices" are devices managed by "providers of insurance services." The insurance system infrastructure HB has a Type 1 customer information management function that stores and manages information about insurance policyholders or prospective policyholders as Type 1 customer information in a predetermined database. The insurance system infrastructure HB has an API built into other information processing devices that outputs Type 2 customer information (for example, the insurance amount (compensation amount) assigned to the customer in the example of Figure 3) for customers that are outside the management of the Type 1 customer information management function and are managed by other information processing devices, triggered by the input of predetermined information (for example, the customer's name, age, gender, date of birth, address, etc.). The infrastructure HB has a Type 2 customer information acquisition function that executes control to acquire Type 2 customer information by sending predetermined information to the other information processing device.

[0022] In addition to services S1 through S6 shown in Figures 2 and 3 above, this service can provide a variety of other services as described below.

[0023] In other words, as described above in Figure 1, the insurance system infrastructure HB is connected to insurance companies H1 to HP of P and agents D1 to DQ of Q (more precisely, various devices managed by each of them). Here, P's insurance companies H1 through HP and Q's agents D1 through DQ are grouped together as "providers of insurance services." Therefore, if P + Q = N, there will be N "providers of insurance services." In other words, the insurance system infrastructure HB can perform the following functions by communicating with other information processing devices managed by each of the N "providers of insurance-related services". In other words, the insurance system infrastructure HB has an insurance information extraction function that extracts information for each predetermined unit for insurance or insurance products provided by M (where M is an integer less than or equal to N) providers out of N "providers of insurance-related services". The storage location of the extracted information is not particularly limited and may be within the insurance system infrastructure HB (for example, the storage unit 18 in Figure 4 described later), or within another information processing device (for example, within the insurance company's existing system HS), etc. The insurance system infrastructure HB has a parameter generation function that extracts one or more parameters necessary for performing predetermined functions related to insurance, based on information extracted for each predetermined unit by the insurance product information extraction function. The insurance system infrastructure HB has a means for performing functions that execute processes to perform predetermined functions within the scope of constraints, including regulations and laws set by the "provider of insurance-related services" (for example, the upper limit on the amount of insurance coverage for cancer insurance per insured person (customer)), based on one or more parameters.

[0024] Here, the prescribed functions related to insurance are not particularly limited and may include, for example, no-code tool functions, group portal functions, and insurance premium billing logic functions. Therefore, the details of each feature, such as the no-code tool function, the group portal function, and the insurance premium billing logic function, will be explained individually in that order below.

[0025] First, as an example of a standard function related to insurance, I will explain the no-code tool function. The no-code tool function allows you to generate product pages and application forms for insurance products without writing any code.

[0026] The insurance system infrastructure HB is connected to the existing insurance system HS of multiple insurance companies H. The existing insurance system HS stores and manages various types of information related to each insurance company H's insurance products. In other words, the insurance system infrastructure HB is connected to multiple insurance products from multiple insurance companies. Insurance products are complex and, in Japan, are defined by basic documents stipulated by law. These basic documents include terms and conditions, business plans, calculation methods, and other similar documents. The insurance system platform HB has a parameter generation function that automatically generates variables and parameters (collectively referred to as "parameters") necessary for performing specific insurance functions by reading complex, disparate basic documents (data) from each insurance company into predetermined units. Here, the parameter generation function not only generates parameters, but also, as an extension of that function, allows the necessary functionality to be implemented in the insurance system infrastructure HB itself when parameters are input.

[0027] Figure 4 shows an example of how the differences in product characteristics and operations of similar insurance products offered by two insurance companies are defined in their respective documentation. Figure 4 shows examples of basic documents for cancer insurance offered by insurance company H1 (Insurance Company X) and insurance company H2 (Insurance Company Y). Each designated line indicates the specified restrictions and other conditions for each cancer insurance policy of each insurance company H1 to H2. In the example shown in Figure 4, the parameter generation function extracts parameters in units of a predetermined row (a predetermined constraint item). For example, as a parameter called "special clause," for insurance company H1 (insurance company X), the parameter "a flat payment of [A] yen upon cancer diagnosis" is extracted, and for insurance company H2 (insurance company Y), the parameter "a daily hospitalization benefit of [B] yen for hospitalization due to cancer" is extracted. Here, as indicated in the notes, [A] and [B] are variables set for each customer. In the example shown in Figure 4, the insurance system platform HB uses an engine that analyzes basic documents and other materials to extract the characteristics of each insurance policy as one or more parameters for each item corresponding to a single row, and then reflects these characteristics in the various functions described later. In other words, the parameter generation function can be understood as a function that can read and output specifications and UIs that differ for each insurance company H into the insurance system infrastructure HB.

[0028] The insurance system platform HB has an insurance product creation function that uses one or more parameters extracted in this way to create insurance products with various combinations of insurance (combinations of special provisions, etc.). Here, the insurance system platform HB has a constraint verification function as part of its insurance product creation function that prevents the creation of insurance products that do not conform to the regulations within insurance company H, such as the aforementioned insurance amount, or to constraints imposed by laws and regulations (for example, the upper limit on the insurance amount for cancer insurance per insured person (customer)), or grays them out. Such constraints are identified by parameters extracted by the parameter generation function described above (for example, "upper limit on insurance amount" in Figure 4). The insurance system platform HB has a generation function that automatically generates product pages and application forms SF without coding for insurance products created using such insurance product creation functions, i.e., insurance products that meet these constraints. In other words, these insurance product creation functions (including constraint verification functions) and generation functions are what constitute no-code tool functionality.

[0029] Next, as an example of a prescribed function related to insurance, we will explain the portal function for organizations. The group portal function is a feature that generates product pages and application forms (SF) for insurance products intended for groups. For agents D1 through DQ (where Q may have several hundred agents), it is necessary to create product pages and application forms (SF) for similar insurance products, which is an extremely time-consuming process. In this case, the insurance system infrastructure HB, as an insurance product information extraction function, extracts information such as survey results and interview results regarding the characteristics of each agency D1 to DQ, as well as brand guidelines. Then, the insurance system infrastructure HB generates one or more parameters based on this extracted information using its parameter generation function. The insurance system platform HB has a generation function that automatically generates product pages and application forms SF without coding for each insurance product for each agency D1 to DQ generated by the insurance product creation function (including the constraint verification function) described above. In other words, these insurance product creation functions (including constraint verification functions) and generation functions constitute the portal function for organizations.

[0030] Next, as an example of a prescribed function related to insurance, we will explain the insurance premium billing logic function. The insurance premium billing logic function is a function that collects customer insurance premiums (hereinafter referred to as "insurance premiums") (provides such logic). Here, the insurance premium billing logic function may include a function to collect (or provide) at least a portion of the customer's insurance premium in points. This function will be referred to below as the "point billing logic function." Specifically, for example, the insurance system infrastructure HB can perform the processing of insurance collection on behalf of insurance company H. Here, each insurance company H has its own billing method (for example, billing on the 1st of each month, or pro-rata billing for the first month) and lapse method (for example, contract lapse after two failed billing attempts) specified in the basic documents such as the policy terms and conditions. Therefore, the insurance system infrastructure HB utilizes a parameter extraction method to read the basic documents (data) of insurance company H, generating one or more parameters related to billing methods and lapse methods. For example, in the example shown in Figure 4, one or more parameters are generated from items such as "insurance premium," "insurance premium payment method," "insurance premium lapse rules," and "treatment of insurance claims during the lapse grace period." The insurance system infrastructure H has the function of generating and providing logic for implementing insurance collection processing for insurance company H by using one or more such parameters. This function is the insurance premium billing logic function.

[0031] Next, I will explain the point-based billing logic function. The points-based billing logic function is a feature that charges monthly insurance premiums to customers by combining their points and their credit card information (by generating and providing such logic). Specifically, for example, the point-based billing logic function provides a mechanism to check the monthly point balance, charge the amount available from the points balance, and charge the remaining amount via credit card, as points may sometimes be insufficient.

[0032] In addition to providing services S1 to S6 as shown in Figures 2 and 3 above, as well as various specified functions such as no-code tool functionality, group portal functionality, and insurance premium billing logic functionality, this service can also provide a variety of other services as described below.

[0033] In other words, as described above, the insurance system infrastructure HB can perform the following functions by communicating with other information processing devices managed by each of the N "providers of insurance-related services," such as insurance companies H1 to HP and agents D1 to DQ of Q. In other words, the insurance system infrastructure HB has a function for providing Type 1 customer information that, when a request for provision of Type 1 customer information is received from another information processing device of a designated provider among N "providers of insurance-related services," permits the provision of said Type 1 customer information in relation to the provision of services by the designated provider, and prohibits the provision of said Type 1 customer information in relation to the provision of services by providers other than the designated provider. Here, "Type 1 customer information" refers to customer information managed by the Type 1 customer information management function of the insurance system infrastructure HB, as described above.

[0034] The insurance system infrastructure HB is connected to multiple insurance companies H and multiple agencies D (more precisely, the devices managed by each). Therefore, in principle, it is possible for the terminals on the agency D side (for example, the staff terminals DT1 to DSQ in Figure 5) to view (provide) information managed by the insurance system infrastructure HB (for example, Type 1 customer information). For example, suppose there is a customer C who has taken out an insurance policy with insurance company H1 (insurance company X) through agency D1 (agency A). The primary customer information of this customer C is permitted to be viewed (provided) both when agency D1 (agency A) accesses the insurance system platform HB and when insurance company H1 (insurance company X) accesses the insurance system platform HB. This is because, for both agency D1 (agency A) and insurance company H1 (insurance company X), the primary customer information of customer C relates to the provision of their respective services. In contrast, if customer C had purchased insurance directly from insurance company H1 (insurance company X) without going through agent D1 (agent A), then insurance company H1 (insurance company X) would naturally be permitted to view (provide) customer C's information when accessing the insurance system platform HB. This is because, for insurance company H1 (insurance company X), customer C's Type 1 customer information relates to the provision of its own services. However, when agent D1 (agent A) accesses the insurance system platform HB, viewing (providing) the information is prohibited. In other words, agent D1 (agent A) cannot view customer C's Type 1 customer information. This is because, for agent D1 (agent A), customer C's Type 1 customer information does not fall under the category of information related to the provision of its own services.

[0035] However, there may be information that should be shared even if it does not relate to the provision of one's own services. For such cases, the Type 1 customer information provision function may have a function to lift the prohibition on provision of Type 1 customer information relating to the provision of services by providers other than the designated provider, provided that it meets the prescribed conditions, or information obtained by processing such Type 1 customer information. In other words, since customer C is a single individual, the insurance system infrastructure HB may, based on the following considerations, provide (allow viewing) the following functions.

[0036] For example, regarding customer C information provided by insurance company H1 (insurance company X) to the insurance system platform HB, specifically the first-class customer information of customer C, such as KYC (My Number, driver's license, etc.) and AML (anti-social group check, etc.), it may be determined that sharing this information with other "providers of insurance-related services" such as agency D1 (agency A) can reduce the workload for customer C and "providers of insurance-related services." In other words, one example of a prescribed condition is that by sharing with other "providers of insurance services" such as agency D1 (Agency A), the effort of customer C and other "providers of insurance services" can be reduced, and there are cases where this prescribed condition is met. In such cases, the insurance system infrastructure HB will lift the restriction on other "providers of insurance services" from viewing (providing) (i.e., permit viewing (provision)) Type 1 customer information that meets the specified conditions, i.e., KYC and AML information for C customers.

[0037] For example, the probability of a person similar to customer C having a disease, calculated based on customer C's information or information managed by the insurance system infrastructure HB (such as customer C's age, gender, address, annual income, and family structure), is an example of information processed from customer C's Type 1 customer information. Therefore, the insurance system infrastructure HB will lift the prohibition on viewing (providing) such information to any "provider of insurance-related services" (i.e., grant permission for viewing (providing) it).

[0038] For example, if, based on customer C's insurance information from insurance company H1 (insurance company X), it is determined that another insurance policy should be offered, then another insurance company H2 (insurance company Y) may be automatically offered or a flag indicating that an offer should be made may be issued. In this case, one example of a predetermined condition is that it is determined that an alternative insurance plan should be offered, and there are times when this predetermined condition is met. In such a case, the insurance system infrastructure HB will lift the restriction on another insurance company H2 (insurance company Y) viewing (i.e., grant permission for viewing (provision)) of Type 1 customer information that meets the specified conditions, namely, information on insurance coverage of customer C by insurance company H1 (insurance company X).

[0039] For example, if customer C has been blacklisted by insurance company H1 (insurance company X) due to excessive claims or fraudulent claims, this fact may be shared with another insurance company, H2 (insurance company Y), etc. In this case, being on a blacklist is one example of a predetermined condition, and there are times when this condition is met. In such a case, the insurance system infrastructure HB will lift the ban on another insurance company H2 (insurance company Y) viewing (providing) (i.e., granting permission to view (provide)) information showing that a Type 1 customer who meets certain conditions, namely customer C, is on a blacklist at insurance company H1 (insurance company X).

[0040] The overview of this service has been explained above with reference to Figures 1 to 4.

[0041] Next, with reference to Figure 5, we will describe the configuration of an information processing system to which the service provider server of one embodiment of the information processing device of the present invention is applied, which enables the provision of the service described above. Figure 5 shows an example of the configuration of an information processing system to which a service provider server according to one embodiment of the information processing device of the present invention is applied.

[0042] The information processing system shown in Figure 5 is configured to include a service provider server 1, devices managed by insurance companies H1 through HP, and devices managed by agencies D1 through DQ. The service provider server 1, the devices managed by insurance companies H1 through HP, and the devices managed by agencies D1 through DQ are interconnected via a predetermined network such as the Internet.

[0043] Here, the devices managed by the insurance company HK (where K is any integer value between 1 and P) include the employee terminal HTK and the insurance company's existing system HSK. In the following, when "insurance company H" is referred to without the code K, the code K for each device will be omitted, and they will be referred to as "person in charge terminal HT" and "insurance company's existing system HS," respectively. Furthermore, the devices managed by the agency DL (where L is any integer value between 1 and Q) include the employee terminal DTL and the agency's existing system DSL. In the following, when "Agency D" is referred to without the code K, the code K will be omitted from the code of each device, and they will be referred to as "Person in Charge Terminal DT" and "Agency Existing System DS," respectively.

[0044] Service provider server 1 is an information processing device managed by service provider SA, and it constructs the insurance system infrastructure HB. Service provider server 1 (insurance system infrastructure HB) executes various processes necessary to realize this service while communicating as appropriate with the devices managed by insurance companies H1 through HP and the devices managed by agencies D1 through DQ.

[0045] Figure 6 is a block diagram showing an example of the hardware configuration of the service provider server in the information processing system shown in Figure 5.

[0046] The service provider server 1 comprises a CPU (Central Processing Unit) 11, a ROM (Read Only Memory) 12, a RAM (Random Access Memory) 13, a bus 14, an input / output interface 15, an input unit 16, an output unit 17, a storage unit 18, a communication unit 19, and a drive 20.

[0047] The CPU 11 executes various processes according to the program recorded in the ROM 12 or the program loaded from the storage unit 18 into the RAM 13. RAM13 also stores data and other information necessary for the CPU11 to perform various processes.

[0048] The CPU 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output interface 15 is also connected to this bus 14. An input / output interface 15 is connected to an input unit 16, an output unit 17, a storage unit 18, a communication unit 19, and a drive 20.

[0049] The input unit 16 is configured, for example, with a keyboard, and is used to input various types of information. The output unit 17 consists of a display such as an LCD and a speaker, and outputs various information as images and sounds. The memory unit 18 is composed of DRAM (Dynamic Random Access Memory) and stores various types of data. The communication unit 19 communicates with other devices (for example, the devices managed by insurance company H and agency D in Figure 5) via a network NW, including the Internet.

[0050] A removable media 40, such as a magnetic disk, optical disk, magneto-optical disk, or semiconductor memory, is appropriately mounted in the drive 20. Programs read from the removable media 40 by the drive 20 are installed in the storage unit 18 as needed. Furthermore, the removable media 40 can store various types of data stored in the storage unit 18, just as the storage unit 18 does.

[0051] Through the collaboration of various hardware and software components of the service provider server 1 shown in Figure 6, the insurance system infrastructure HB is constructed. As a result, the aforementioned service can be provided. The following describes the functional configuration of the insurance system infrastructure HB built on the service provider server 1 shown in Figure 6.

[0052] Figure 7 is a functional block diagram showing an example of the functional configuration of the insurance system infrastructure, which is one of the functional configurations of the server in Figure 6, which is a component of the information processing system in Figure 5.

[0053] As shown in Figure 7, the CPU 11 operates as follows: customer information management unit 51, product page / application form management unit 52, insurance API control unit 53, insurance information extraction unit 54, parameter generation unit 55, and function execution unit 56. The function execution unit 56 includes a no-code tool generation unit 61, an insurance fee logic generation unit 62, and a group portal generation unit 63.

[0054] Furthermore, an insurance database 71 is provided in one area of ​​the memory unit 18. Insurance DB71 stores data synchronized with insurance company H and agency D through batch processing_CSV linkage, etc. (service S1 in Figure 2). Insurance DB71 also stores various information generated or acquired by the insurance system infrastructure HB. For example, although not shown in the diagram, various information generated or acquired when various functions are activated, such as insurance API, marketing functions, UX functions, insurance claim bot provision functions, application provision functions, insurance policy My Page (product pages and application forms for specified insurance products, etc.) management functions, and scraping functions, is stored in Insurance DB71.

[0055] The Customer Information Management Department 51 stores and manages customer information as Type 1 customer information in the Insurance Database 71.

[0056] Here, we assume that an API (insurance API) is built into the existing insurance company system HS or the existing agency system DS that outputs Type 2 customer information for customers that are outside the management of insurance DB71 but are managed by the existing insurance company system HS or the existing agency system DS, triggered by the input of predetermined information. As described above using Figure 3, the insurance API control unit 53 controls the insurance API and transmits predetermined information to the insurance company's existing system HS or the agency's existing system DS to acquire Type 2 customer information. As mentioned above, insurance DB71 stores and manages data (such as insurance payments granted to customers) that has been synchronized with insurance company H and agency D through batch processing_CSV linkage, etc. (service S1 in Figure 2). However, this data is acquired from insurance company H and agency D at intervals such as one week, and although it may have been managed by insurance company H and agency D at the time of acquisition, it is subsequently updated and becomes out of their management. Therefore, data synchronized with insurance company H and agency D through batch processing_CSV linkage etc. (service S1 in Figure 2) (such as insurance payments granted to customers) is strictly Type 1 customer information and does not fall under Type 2 customer information. In other words, data managed in real time by insurance company H and agency D (such as insurance payments granted to customers) is Type 2 customer information.

[0057] The insurance information extraction unit 54 performs the insurance information extraction function described above and extracts information for each predetermined unit for insurance or insurance products provided by insurance company H and agency D, respectively. The parameter generation unit 55 performs the parameter generation function described above and extracts one or more parameters necessary for performing predetermined functions related to insurance based on the information extracted for each predetermined unit by the insurance information extraction unit 54. The function execution unit 56 performs a process to enable a predetermined function based on one or more parameters generated by the parameter generation unit 55, within the limits of constraints including regulations and laws set by the insurance company H and agency D (for example, the upper limit on the amount of insurance coverage for cancer insurance per insured person).

[0058] Specifically, for example, the no-code tool generation unit 61 of the function execution unit 56 performs the no-code tool function described above. In other words, the no-code tool generation unit 61 uses one or more parameters generated by the parameter generation unit 55 to create insurance products with various combinations of insurance (combinations of special provisions, etc.). Here, the no-code tool generation unit 61 prevents the generation of insurance products that do not conform to the regulations within insurance company H, such as the insurance amount, or to legal restrictions (for example, the upper limit on the insurance amount for cancer insurance per insured person (customer)), or grays them out. The no-code tool generation unit 61 automatically generates product pages and application forms (SF) without coding for the insurance products generated in this manner, i.e., insurance products that meet these constraints.

[0059] For example, the insurance premium logic generation unit 62 of the function execution unit 56 performs the insurance premium billing logic function described above. That is, the insurance premium logic generation unit 62 generates and provides logic for realizing the insurance collection agency processing of insurance for insurance company H by using one or more parameters generated by the parameter generation unit 55. Furthermore, the insurance premium logic generation unit 62 generates and provides logic to charge the customer a monthly insurance premium using a combination of points held by the customer and the customer's credit card.

[0060] For example, the group portal generation unit 63 within the function execution unit 56 performs the group portal function described above. That is, the group portal generation unit 63 uses one or more parameters generated by the parameter generation unit 55 to generate a product page and an application form SF for insurance products for groups.

[0061] The information viewing control unit 57, when requested to view (provide) Type 1 customer information from another information processing device of a designated provider among insurance companies H1 to HP and agents D1 to DQ, permits the viewing (provision) of said Type 1 customer information relating to the provision of services by said designated provider. On the other hand, the information viewing control unit 57 prohibits the viewing (provision) of said Type 1 customer information relating to the provision of services by providers other than said designated provider. Here, the information viewing control unit 57 lifts the prohibition on viewing (providing) (i.e., permits viewing (providing)) any Type 1 customer information relating to the provision of services by providers other than the designated provider that meets the prescribed conditions, or information that has been processed from such Type 1 customer information.

[0062] Although one embodiment of the present invention has been described above, the present invention is not limited to the embodiments described above, and any modifications, improvements, etc. that can achieve the objectives of the present invention are considered to be included in the present invention.

[0063] The following provides a more detailed explanation of each of the above-mentioned functions using examples. First, we will explain the insurance API used in this service for exchanging information between the insurance system infrastructure HB of the service provider server 1, the existing insurance company system HS of insurance company H, and the existing agency system DS, using specific usage examples.

[0064] For example, suppose a customer (subscriber or prospective subscriber) named "Yamada Taro" is submitted to the insurance system platform HB of this service as a new policyholder (i.e., a contract application has been submitted). At this time, the insurance system platform HB of this service stores customer data that includes not only the customer's name but also information generally required for insurance applications. Specifically, for example, customer data may include the customer's gender, date of birth, telephone number, address, and driver's license number.

[0065] That is, for example, if a customer decides to enter into a new insurance contract as a result of being introduced to an insurance product by an agent at agency D, the customer's data is entered into the agent's terminal DT at agency D. The Customer Information Management Department 51 stores and manages data such as the customer's name, gender, date of birth, telephone number, address, and driver's license number, obtained from the agent terminal DT of agency D, in the insurance DB 71.

[0066] Then, the insurance system infrastructure HB uses the insurance API to query the existing insurance company system HS, which it is connected to, for information about its customer, Yamada Taro. In other words, as described above, the existing insurance company system HS has an insurance API built in which, triggered by the input of predetermined information, it outputs customer information that is outside the management of insurance DB71 but is managed by the existing insurance company system HS or the existing agency system DS. Therefore, the insurance API control unit 53 of the insurance system infrastructure HB controls the insurance API and sends information about Yamada Taro to the insurance company's existing system HS and the agency's existing system DS to obtain and query Type 2 customer information. In this way, based on the information about customer Yamada Taro, the insurance system infrastructure HB obtains information on the insurance enrollment status of this customer from the insurance company's existing system HS.

[0067] However, in the insurance company's existing system HS, there are data registered by the insurance company H itself, such as notation variations and unupdated information as follows. Simply by querying, it may not be possible to obtain the customer data that should originally be included in the query results. For example, in the insurance company's existing system HS, there may be differences in full-width or half-width characters included in the address, misspellings of Chinese characters such as "山田太郎" (Yamada Taro) and "山田太朗" (Yamada Taro), changes in surnames due to marriage, etc., changes in addresses due to moving, and differences in the representation of birth dates between the Western calendar and the Japanese calendar.

[0068] Specifically, for example, regarding the same customer Yamada Taro (ヤマダタロウ), in the insurance company's existing system HS of insurance company H1, it may be registered as "Name: Yamada Taro, Kana: ヤマダタロウ, Address: Chuo-ku, Tokyo...", or in the insurance company's existing system HS of insurance company H2, it may be registered as "Name: Yamada Taro, Kana: ヤマダタロウ, Address: Chuo-ku, Tokyo...". In this case, due to the difference in the Chinese characters of the name, it may be determined as a different person (customer). Also, for example, in the insurance company's existing system of insurance company H3, there may be a case where an address different from the current address (for example, the address where the customer previously lived) is registered as "Yamada Taro, Kana: ヤマダタロウ, Address: Yokohama City, Kanagawa Prefecture...".

[0069] In this service, the above notation fluctuations are used to perform pseudo-name matching of data by an intermediate database (not shown) provided between the insurance system infrastructure HB and the insurance company's existing system HS. That is, for the same customer Yamada Taro (ヤマダタロウ) registered in each of insurance companies H1 to H3, name matching is performed. This makes it possible to determine whether information about Yamada Taro, registered in the insurance system infrastructure HB, already exists in the insurance company's existing system HS, and to obtain information such as the insurance amount necessary for the insurance business. Here, the intermediate database is a database that stores information used to link customer information recorded in the insurance system infrastructure HB and the insurance company's existing system HS, respectively.

[0070] As described above, traditionally, insurance company H has its own existing insurance company system HS. Furthermore, insurance company H may have separate systems for before and after updates to its existing insurance company system HS, such as before and after a specified year. In addition, insurance company H may also have existing insurance company systems HS of its group companies, etc. Thus, with multiple existing insurance company systems HS in place, insurance company H has traditionally reorganized its internal databases manually.

[0071] In contrast, the insurance system infrastructure HB of this service can perform pseudo-name matching as shown below. In other words, this explains the process of creating and using information to link the same customer (or, in the case of an insurance contract, the policyholder). Batch processing is one method for creating information that links identical customers. Specifically, the customer information management unit 51 first obtains predetermined information, including personally identifiable customer information, from the existing insurance company systems HS of multiple insurance companies H, and stores and manages it in the insurance DB 71. Here, personally identifiable customer information includes, for example, the kanji characters and phonetic spelling of the name, mobile phone number, and address. This links customer information contained in insurance DB71 with information on each insurance product in each insurance company H's existing insurance company system HS. Then, the Customer Information Management Department 51, based on the personally identifiable information of the customer obtained, performs data consolidation for the same customer across multiple insurance company existing systems HS of multiple insurance company existing systems HS (not across multiple insurance products in multiple insurance company existing systems HS, but across multiple insurance company existing systems HS). The customer information management department 51 stores and manages information linking insurance products in the insurance database 71. This allows customers of multiple insurance companies H to be consolidated. This consolidation can be performed by batch processing at night. This allows Taro Yamada of insurance company X and Taro Yamada of insurance company Y, who have the same mobile phone number and address, to be linked and managed as the same person.

[0072] Furthermore, a login process on the insurance system platform HB exists as a method for creating information that links the same customer. Specifically, for example, when a customer creates an account on the system infrastructure HB, the customer information management department 51 stores and manages the insurance database 71 the following information: personal identification information entered to create the account on the system infrastructure HB, the mobile phone number registered for SMS authentication, SSO authentication using SNS or portal sites, information linked to insurance company H through the customer's proactive registration on the insurance system infrastructure HB, and the Ministry of Health, Labour and Welfare's cancer diagnosis and outcome history information. The above information may be obtained by insurance company H as appropriate. Based on this login information and other data, an intermediate database is created for the purpose of simulating customer names.

[0073] Then, when "Yamada Taro" attempts to enter into a new contract with insurance company Z, the information viewing control unit 57 refers to the customer-linking information stored in the insurance DB 71 and executes control over the viewing of the information. Specifically, the information viewing control unit 57 obtains the latest customer information for "Yamada Taro" from insurance company X and executes control over the viewing of information for "Yamada Taro" from insurance company Y, making it available for retrieval. This makes it possible to obtain information on the latest insurance coverage status of customers at insurance companies X and Y.

[0074] Furthermore, while the above example involved a name matching based on a misspelling of Yamada Taro's name, a similar pseudo-name matching can be performed even when the name and mobile phone number are the same but the address is different. In other words, name matching is possible even for contracts with two different addresses, such as the above-mentioned "Name: Yamada Taro, Furigana: Yamada Taro, Address: Chuo-ku, Tokyo..." and "Name: Yamada Taro, Furigana: Yamada Taro, Address: Chuo-ku, Tokyo...". At this point, these two sets of data can also be used to inquire with other insurance companies, such as H. This makes it possible to obtain the latest insurance coverage status for the same customer (Yamada Taro) whose information has not yet been consolidated.

[0075] In addition, insurance contracts generally involve the registration of several types of individuals, including the policyholder (the subject of the contract and the person who pays the premiums), the insured (the subject of the insurance, and in the case of life insurance, the insurance payment occurs when the insured dies), and the beneficiary (the person to whom the insurance payment is made). Generally, customer information is considered the richest information, and it is stored in the insurance company's existing system HS database based on that customer. In other words, information on the insured and beneficiaries may be less detailed compared to the information on the policyholder. However, this service uses the aforementioned intermediate database to link insured and beneficiaries of the same insurance policy. Furthermore, the method for creating the intermediate database of insured persons and the method for controlling access to it can be implemented in essentially the same way as for customers (policyholders) as described above.

[0076] This makes it possible to query the databases of multiple insurance companies H for information on the insurance coverage status of a specific insured person or the insurance coverage status of a specific beneficiary. Specifically, for example, a life insurance policy at insurance company H1 where the policyholder is Taro Yamada and the insured is Hanako Yamada, and a life insurance policy at insurance company H2 where the policyholder is Jiro Yamada and the insured is Hanako Yamada, are combined and quoted. This kind of name matching ensures the identity of customers and insured persons, making it possible to offer suggestions to those customers regarding over-insurance, insufficient insurance coverage, and better insurance options. Furthermore, while data matching can be performed through batch processing, the aforementioned insurance API allows for queries to be made to the insurance company's existing system HS each time, enabling immediate decisions and proposals regarding eligibility for coverage.

[0077] In the above example, we used life insurance, which covers individuals (the insured), as an example. However, in the case of fire insurance and earthquake insurance, the same method of matching applies to houses, and in the case of damage insurance and theft insurance, it also applies to items. This makes it possible to immediately offer better insurance suggestions, such as identifying areas where insurance coverage is excessive or insufficient, for properties including fire and earthquake insurance, as well as property damage and theft insurance.

[0078] Furthermore, in the example described above, the insurance system infrastructure HB uses an insurance API to query the insurance company's existing system HS for various information, but it is also possible to query the agency's existing system DS for various information as appropriate.

[0079] Furthermore, in addition to obtaining data on insurance amounts via the API mentioned above, it becomes possible to predict the CVR (conversion rate) and profitability of the insurance business by obtaining information such as existing insurance policies and family structure from Yamada Taro's existing insurance company system HS. In other words, by referring customers like Yamada Taro to the insurance company's existing system HS, it becomes possible to consider the insurance information they already have, which can then be used to suggest policies that need review (e.g., too many policies) or policies that are lacking (e.g., policies that would be beneficial to have). Specifically, for example, if information obtained through an inquiry from the insurance company's existing system HS reveals that "Yamada Taro's dependent child is 22 years old, and although he has a large life insurance policy, he does not have medical insurance," then suggesting that he cancel his life insurance and enroll in medical insurance would be a proposal that aligns with Yamada Taro's needs.

[0080] The same applies to profitability, for example. In other words, given the insurance premium, the profitability of the insurance business can be predicted based on the probability of insurance payouts (for example, the probability of developing cancer in the case of cancer insurance). That is, if the information obtained by inquiry from the insurance company's existing system HS includes Yamada Taro's health checkup results and vaccination history, the possibility of developing cancer can be predicted with more precision than with information collected at the time of insurance enrollment (age, gender, whether or not there is a history of past hospital visits, etc.).

[0081] Next, we will explain the insurance premium billing logic function, which provides the logic for collecting customer insurance premiums as described above, using specific usage examples.

[0082] In other words, once an insurance contract is signed, it may be difficult to re-enroll in a similar insurance policy if circumstances change. This is especially true for health insurance, if the insured person's health deteriorates. Therefore, for example, suppose a policyholder has the will and financial means to continue the contract, but for some reason the monthly insurance premium (contribution) is not debited. In such a case, the contract does not immediately become invalid (lapse), and a grace period of one to two months is generally provided. This means that, for example, if a policyholder forgets to enter new credit card information when their current credit card for premium payments expires and they are required to do so, the contract may be remedied within its specified grace period. Furthermore, there are cases where a policy that has expired can be reactivated (reinstated) if the policyholder wishes. This is considered a requirement related to the importance and public nature of insurance contracts.

[0083] Because insurance products are complex financial instruments, the handling of lapse and reactivation (reinstatement) often differs from one insurance company to another. Furthermore, many similar terms have different meanings in life insurance and non-life insurance. For example, what is called lapse in life insurance (as described above) might be called cancellation due to non-payment of premiums in non-life insurance.

[0084] Specifically, for example, suppose that on August 10th, Customer 1 simultaneously entered into insurance contracts with insurance companies X and Y, each offering monthly premium payments. Let's assume that the premiums for August and September were successfully paid (collected) by both companies. Regarding the October premium, Company X attempted to charge (automatically debit, etc.) on October 1st, but failed to do so. In contrast, Company Y attempted to charge on October 10th, but also failed to do so. Furthermore, according to Company X's terms and conditions (which are based on insurance laws and administrative approvals, and the same applies hereafter), the policy will not lapse if payment for the October premium is confirmed between November 1st and November 30th. And according to Company Y's terms and conditions, the policy will not lapse if payment is confirmed between November 10th and December 9th. Thus, if the billing (automatic withdrawal, etc.) dates differ among multiple insurance companies, the period during which payment must be made to prevent lapse will also differ. Moreover, the length of the period during which payment must be made to prevent lapse, while one month in the above example, may differ between companies. Furthermore, even if both policies expire, it's possible that Company X handles reinstatement while Company Y does not. Moreover, while reinstatement might be possible with Company X, it might require submitting a health certificate and disclosures regarding one's health status again.

[0085] Thus, the insurance system infrastructure HB of this service can appropriately handle the processing of insurance billing failures in accordance with the terms and conditions of each company.

[0086] In the information sharing with the existing insurance company system HS mentioned above, the following processes are also performed. Specifically, let's assume there are two insurance companies, X and Y, connected to the insurance system platform HB of this service. And let's assume that a customer named Yamada Taro has already undergone KYC (Know Your Customer) and AML (Anti-Money Laundering) verification at insurance company X. Under these circumstances, when Yamada Taro comes to insurance company Y to apply for insurance, the insurance system platform HB can provide insurance company Y with information regarding KYC and AML that has been completed at insurance company X, via the insurance system platform HB. In other words, the information viewing control unit 57 can lift the restriction on viewing (provision) and provide to insurance company Y any information about Yamada Taro related to the provision of insurance by insurance company X that meets certain conditions, or information obtained by processing the said Type 1 customer information.

[0087] In this context, the insurance industry is a regulated industry, and the handling of personal information changes dynamically due to changes in laws and regulations. Therefore, this insurance company's existing system, HS, is designed to accommodate these changes. Furthermore, sensitive personal information, such as medical history specific to the insurance industry, may not be legally permitted to be shared between insurance companies, even with the customer's consent. Therefore, the insurance system platform HB of this service anonymizes information to the maximum extent possible while still allowing sharing. For example, assuming that the insurance system infrastructure HB contains all the information present in insurance company X's system, the information viewing control unit 57 can score the customer's specified medical history-related information, and when an inquiry for the customer's information is made from insurance company Y's system via this service, it can return only the scored medical history score to insurance company Y. In this way, insurance company Y is provided with the processed score of the customer, not the sensitive information itself. This allows insurance company Y to make proposals to the customer based on the score, rather than on sensitive information that may not be permitted by law.

[0088] Furthermore, this service can reduce the workload for customer C and insurance service providers by sharing customer C information provided by insurance company H1 (X Insurance Company) to the insurance system platform HB, specifically the customer C's primary customer information, including KYC (My Number, driver's license, etc.) and AML (Anti-social group check, etc.), with other "providers of insurance-related services" such as agency D1 (Agency A).

[0089] Furthermore, the insurance system infrastructure HB of this service can provide the following prediction result information to multiple insurance companies H. Specifically, as a premise, let's assume that there are two insurance companies, X and Y, connected to the insurance system infrastructure HB of this service. That is, let's assume that the insurance system infrastructure HB of this service is connected to the existing insurance system HS of insurance company X, and that the insurance system infrastructure HB is connected to the existing insurance system HS of insurance company Y. Under this premise, when Yamada Taro applies for insurance with insurance company Z, insurance company Z can return a prediction result based on information managed by insurance companies X and Y.

[0090] Here, there are two possible predictions. First, I will explain the accuracy of the information provided. For example, if Yamada Taro enters that the vehicle covered by the auto insurance application submitted to insurance company Z is a new car, it is possible that, based on information managed by insurance company X (for example, stored in insurance company X's existing insurance system HS), the vehicle may be determined to be a used car. In other words, in such a case, it is possible to determine that the insurance application submitted to insurance company Z is a false application. This will increase the profitability of insurance company Z.

[0091] For example, the address of Yamada Taro listed on the application form for automobile insurance submitted to insurance company Z may be his new address, but the address managed by insurance company Y (stored in insurance company Y's existing insurance system HS, etc.) may not have been updated. In such cases, the screen of the employee terminal HT at insurance company Z can prompt the employee to update the information managed by insurance company Y, which is provided through this service. This allows customers to update their information even if they have forgotten to update it with insurance company Y, and improves convenience by eliminating the need for repeated procedures.

[0092] For example, the insurance system infrastructure HB of this service can access information about customer Yamada Taro's family structure and existing insurance contracts, which are managed by insurance company X (stored in insurance company X's existing insurance system HS, etc.). This allows for the prediction of insurance information that Yamada Taro is missing (insurance products, elements protected by insurance products, etc.). Based on this, such missing insurance products are recommended on the screen of insurance company Z's employee terminal HT. This improves the conversion rate (CVR) of insurance contracts.

[0093] The second prediction is future profitability. In this context, "Profitability" refers to, for example, the probability that Yamada Taro will (or will not) become ill in the future, in the case of health insurance. First, at the time of application for an insurance product from insurance company Z, data useful for predicting health information, managed by insurance company X (stored in insurance company X's existing insurance system HS, etc.), is anonymized (or processed into scoring as described above). Then, the insurance system platform HB allows insurance company Z and other insurance companies H to propose (provide) appropriate insurance products and their premiums to the customer, Yamada Taro. Furthermore, for the customer, Yamada Taro, there is the benefit of being offered an appropriate amount of insurance premium, rather than an overly conservative (high) premium (due to insufficient data). Furthermore, the connections made by insurance company H with this intention also include public databases such as the Ministry of Health, Labour and Welfare database. Generally, the existing insurance systems HS of insurance companies X, Y, and Z are considered legacy systems. Therefore, securely connecting these existing systems HS to external databases is difficult. However, by using the insurance system infrastructure HB of this service, these existing systems HS can securely enjoy the benefits of external connectivity (such as information exchange).

[0094] Furthermore, the insurance system platform HB has a generation function that automatically generates product pages and application forms SF without coding for each insurance product for each agency D1 to DQ generated by the insurance product creation function (including the constraint verification function). In other words, this insurance product creation function (including the constraint verification function) and generation function for a given organization constitute the organization portal function. This will be explained in detail below using an example.

[0095] This service accumulates a database of what kind of insurance would be best (from both the perspective of conversion rate (CVR) and profitability) for the attributes of the individuals belonging to that organization (potential policyholders).

[0096] This service is connected to multiple insurance agencies (Agency A, Agency B, Agency C, etc.). When an agency is a B2C platform provider (for example, a platform provider that operates retail stores), it may be exchanging various data with customers as part of its core business. That is, for example, a platform provider has transaction information such as credit card information for the retail stores it operates. In addition, for example, it may acquire not only customer age and gender data but also purchase data, and loyalty marketing may acquire not only purchase data but also leisure behavior data through the point accrual status of other designated businesses.

[0097] Therefore, the insurance system infrastructure HB for this service may contain insurance product purchase data from many agencies, and in particular, data on which appeal methods and content are best suited to which agencies has been accumulated through various A / B tests. When a new agency D connects to this service, for example, by receiving the following data, it is possible to automatically reflect the experience of existing connected agencies A, B, and C to a certain extent.

[0098] If there are many women in their 40s, it would be better to use a red landing page, for example. Family structure can also be reflected. Specifically, for example, families with young children might use more pictures of their children, while families caring for elderly relatives might use more pictures of their grandparents. Furthermore, for example, the average household income (or something that implies it) is reflected. Specifically, for instance, if the income is high, a more luxurious and generous insurance plan can be offered. Furthermore, or perhaps more simply, it could be meaningful to qualitatively survey agency D about the customer trends of agency D. For example, it could reflect whether customers are "more stability-oriented" or "more risk-taking-oriented."

[0099] Based on the prior information described above, it is possible to build a landing page with optimized conversion rates (CVR) and profitability to a certain extent. However, as trends in the world change (for example, a new infectious disease is raging, or autonomous driving is becoming mainstream in automobiles), the optimal solution also changes. Therefore, this service integrates the CVR and profitability analysis results from multiple agencies, enabling us to provide a solution that is always optimal at any given time.

[0100] Furthermore, in the above embodiment, for example, the devices connected to the insurance system infrastructure HB were those managed by the insurance company H or the agency D, respectively, but the invention is not limited to this, and any other information processing device of a "provider of insurance-related services" is sufficient.

[0101] Furthermore, the system configuration shown in Figure 5 and the hardware configuration of the service provider server 1 shown in Figure 6 are merely illustrative examples for achieving the objectives of the present invention and are not particularly limited.

[0102] Furthermore, the functional block diagram shown in Figure 7 is merely illustrative and not particularly limiting. In other words, it is sufficient that each function that can be realized by the insurance system infrastructure HB described above is provided in a predetermined information processing device (e.g., service provider server 1), and the functional blocks and databases used to realize these functions are not particularly limited to the example in Figure 7. Furthermore, the location of the functional blocks and database is not limited to Figure 7, but can be any location.

[0103] Furthermore, the series of processes described above can be executed by hardware or by software. Furthermore, a single functional block may consist of hardware alone, software alone, or a combination of both.

[0104] When a series of processes are executed by software, the programs that make up that software are installed on a computer or other device from a network or storage medium. The computer may be a computer that is built into dedicated hardware. Furthermore, a computer can be any computer capable of performing various functions by installing various programs, such as a server, a general-purpose smartphone, or a personal computer.

[0105] Such recording media containing programs may consist not only of removable media (not shown) distributed separately from the main unit of the device to provide the program to the user, but also of recording media provided to the user in a state where they are pre-installed in the main unit of the device.

[0106] In this specification, the step of describing a program to be recorded on a recording medium includes not only processes that are performed chronologically in that order, but also processes that are not necessarily performed chronologically, but are executed in parallel or individually.

[0107] In summary, the information processing device to which the present invention applies only needs to have the following configuration, and can take various forms. In other words, the information processing device to which the present invention is applied (for example, the service provider server 1 in Figure 5) is: In an information processing device that communicates with other information processing devices of providers of insurance-related services (for example, the existing insurance system HS of insurance company H in Figure 7 or the employee terminal DT of agent D), A first-class customer information management means (e.g., customer information management unit 51 in Figure 7) manages information about the policyholder or prospective policyholder of the aforementioned insurance as first-class customer information by storing it in a predetermined database (e.g., insurance DB 71 in Figure 7), A second type of customer information acquisition means (for example, the insurance API in the statement) is constructed in the other information processing device that outputs second type of customer information (for example, the insurance amount assigned to the customer in Figure 3) related to the customer, which is outside the management of the first type of customer information management means and managed by the other information processing device (for example, the insurance system HS of insurance company H in Figure 7), triggered by the input of predetermined information (for example, the name and age of the customer in Figure 3), and a second type of customer information acquisition means (for example, the insurance API control unit 53 in Figure 7) executes control to acquire the second type of customer information by transmitting the predetermined information to the other information processing device, All you need to do is provide that.

[0108] Furthermore, the information processing device, There are N providers (where N is an integer of 2 or more) (for example, in the example in Figure 5, there are P insurance companies H1 to HP and Q agents D1 to DQ), and the information processing device communicates with the other N information processing devices. An insurance information extraction means (for example, the insurance information extraction unit 54 in Figure 7) extracts information for each predetermined unit (for example, the item unit of one row in Figure 4) for each insurance or insurance product provided by M (where M is an integer value less than or equal to N) provider out of the aforementioned N providers, A parameter extraction means (for example, the parameter generation unit 55 in Figure 7) extracts one or more parameters necessary for the performance of a predetermined function related to the insurance, based on the information extracted for each predetermined unit by the insurance information extraction means, A function-executing means (for example, the function-executing unit 56 in Figure 7) that performs a process to enable the predetermined function within the scope of constraints, including regulations and laws set by the provider (for example, the upper limit on the amount of insurance coverage for cancer insurance per insured person), based on the one or more parameters mentioned above, It can provide even more. For example, the predetermined function performed by the no-code tool generation unit 61 in Figure 7 can be a function that enables the generation of product LPs (product pages) or application forms for insurance products without coding. For example, the predetermined function performed by the insurance premium logic generation unit 62 in Figure 7 can be a function for collecting insurance premiums from customers. Furthermore, this predetermined function can be a function for collecting at least a portion of the insurance premiums from customers in the form of points. For example, the fixed function performed by the group portal generation unit 63 in Figure 7 can be set to generate product landing pages for groups.

[0109] Furthermore, the information processing device is There are N providers (where N is an integer of 2 or more) (for example, in the example in Figure 5, there are P insurance companies H1 to HP and Q agents D1 to DQ), and the information processing device communicates with the other N information processing devices. When a request for the provision of the Type 1 customer information is received from the other information processing device of a designated provider among the N providers, the Type 1 customer information provision means (for example, the information viewing control unit 57 in Figure 7) permits the provision of the Type 1 customer information in relation to the provision of services by the designated provider, and prohibits the provision of the Type 1 customer information in relation to the provision of services by providers other than the designated provider. It can be further enhanced to include these features. Furthermore, the aforementioned first type of customer information provision means is Regarding the Type 1 customer information relating to the provision of services by providers other than the aforementioned designated providers, the prohibition on provision may be lifted for information that meets the prescribed conditions, or for information obtained by processing such Type 1 customer information. [Explanation of Symbols]

[0110] 1...Service provider server, 11...CPU, 12...ROM, 13...RAM, 16...Input unit, 17...Output unit, 18...Storage unit, 19...Communication unit, 20...Drive, 40...Removable media, 51...Customer information management unit, 52...Product page / application form management unit, 53...Insurance API control unit 53, 54...Insurance information extraction unit, 55...Parameter generation unit, 56...Function execution unit 56, 61...Insurance DB, HB...Insurance system infrastructure, H, H1 to HP...Insurance company, HT, HT1 to HTP...Personnel terminal, HS1 to HSP...Insurance company existing system, D, D1 to DQ...Agency, DT, DT1 to DTQ...Personnel terminal, DS, DS1 to DSQ...Agency existing system

Claims

1. In an information processing apparatus that communicates with N other information processing apparatuses (where N is an integer value of 2 or more) respectively managed by providers of N services related to insurance, first type customer information management means for storing and managing information related to a customer, which is an insurance subscriber or a candidate for subscription, as first type customer information in a predetermined database; an application programming interface for outputting the second type customer information related to the predetermined information among the second type customer information related to the customer stored by the N other information processing apparatuses triggered by the input of the predetermined information is constructed on the N other information processing apparatuses, and second type customer information acquisition means for executing control to acquire the second type customer information by transmitting the predetermined information to the N other information processing apparatuses using the application programming interface; An information processing apparatus comprising the above.

2. Insurance information extraction means for extracting information of each item for each predetermined unit by setting predetermined items as a predetermined unit from the contents of basic documents related to insurance or insurance products respectively provided by M (where M is an integer value less than or equal to N) of the N providers; parameter extraction means for extracting one or more parameters used in determination processing in the exertion of a predetermined function for the provider related to the insurance from the information extracted for each predetermined unit by the insurance information extraction means; function exertion means for determining whether it is within the range of constraints including regulations and laws set by the provider using the one or more parameters, and executing processing for exerting the predetermined function when it is within the range of the constraints; The information processing apparatus according to claim 1, further comprising the above.

3. The predetermined function is a function of automatically generating a product page or an application form for an insurance product based on the parameter. The information processing apparatus according to claim 2.

4. The predetermined function is a function of collecting the insurance premium of the customer based on the parameter. The information processing apparatus according to claim 2.

5. The predetermined function is a function of collecting at least a part of the insurance premium with points held by the customer based on the parameter. The information processing apparatus according to claim 4.

6. The predetermined function is a function of generating a product page for an insurance product for customers of an agency based on the parameter and the customer layer characteristics of the agency related to the provision of the service. The information processing apparatus according to claim 2.

7. When a request for providing the first type of customer information is received from the other information processing device of a predetermined provider among the providers of N, with respect to the first type of customer information regarding the provision of services by the predetermined provider, information transmission to the predetermined provider is executed, and for the first type of customer information regarding the provision of services by providers other than the predetermined provider, information transmission to the predetermined provider is not executed. First type of customer information providing means The information processing device according to claim 1, further comprising the same.

8. The first type of customer information providing means Among the first type of customer information regarding the provision of services by providers other than the predetermined provider, for those that satisfy a predetermined condition or information obtained by processing the first type of customer information, information transmission to the predetermined provider is executed. The information processing device according to claim 7.

9. In an information processing method executed by an information processing device that communicates with each of N other information processing devices respectively managed by N (N is an integer value of 2 or more) providers of services related to insurance, A first type of customer information management step of storing and managing information regarding the customer as the first type of customer information in a predetermined database, with the insurance policyholder or candidate policyholder as the customer; An application programming interface for outputting the second type of customer information related to the predetermined information among the second type of customer information regarding the customer stored by the N other information processing devices is constructed on the N other information processing devices, triggered by the input of predetermined information, and control is executed to obtain the second type of customer information by transmitting the predetermined information to the N other information processing devices using the application programming interface. Second type of customer information acquisition step; An information processing method including the above.

10. In a computer that communicates with each of N other information processing devices respectively managed by N (N is an integer value of 2 or more) providers of services related to insurance, A first type of customer information management step of storing and managing information regarding the customer as the first type of customer information in a predetermined database, with the insurance policyholder or candidate policyholder as the customer; An application programming interface that outputs the second type of customer information related to the predetermined information among the second type of customer information about the customer stored by the other N information processing apparatuses using the input of the predetermined information as a trigger is constructed on the other N information processing apparatuses, and a second type of customer information acquisition step of executing control to acquire the second type of customer information by transmitting the predetermined information to the other N information processing apparatuses using the application programming interface; A program that causes a control process including this to be executed.

Images