WO2023128860A2 - Procédé et système de gestion adaptative d'une demande d'assurance - Google Patents

Procédé et système de gestion adaptative d'une demande d'assurance Download PDF

Info

Publication number
WO2023128860A2
WO2023128860A2 PCT/SG2022/050908 SG2022050908W WO2023128860A2 WO 2023128860 A2 WO2023128860 A2 WO 2023128860A2 SG 2022050908 W SG2022050908 W SG 2022050908W WO 2023128860 A2 WO2023128860 A2 WO 2023128860A2
Authority
WO
WIPO (PCT)
Prior art keywords
service provider
request
provider servers
received
response
Prior art date
Application number
PCT/SG2022/050908
Other languages
English (en)
Other versions
WO2023128860A3 (fr
Inventor
Harshit Gupta
Harshit BHATTARAM
Original Assignee
Gp Network Asia Pte. Ltd.
Gshield Asia Pte. Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gp Network Asia Pte. Ltd., Gshield Asia Pte. Ltd. filed Critical Gp Network Asia Pte. Ltd.
Publication of WO2023128860A2 publication Critical patent/WO2023128860A2/fr
Publication of WO2023128860A3 publication Critical patent/WO2023128860A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0611—Request for offers or quotes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0613—Third-party assisted
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/08—Insurance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/14—Travel agencies
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry

Definitions

  • the present disclosure relates broadly, but not exclusively, to methods and systems for adaptively managing a request for insurance.
  • Common underwriting solutions for selling insurance digitally include, for example, a single underwriting system which sells one particular type of insurance product based on business contractual agreement, and an insurance arrangement in which multiple insurers have quota shares in generated revenue from sales of insurance policies.
  • both of these arrangements are heavily dependent on the service providers being technically available and stable.
  • a method for adaptively managing a request for insurance comprising: sending, by a switching server, the request to a first one of a plurality of service provider servers when the request for insurance is determined to be eligible; determining, by the switching server, whether a response is received from the first one of the plurality of service provider servers; sending, by the switching server, the request to a second one of the plurality of service provider servers based on the determination of whether a response is received from the first one of the plurality of service provider servers; determining, by the switching server, the first one of the plurality of service provider servers based on a weight assigned to each of the plurality of service provider servers, wherein determining whether a response is received from the first one of the plurality of service provider servers is in accordance with a predetermined threshold, the predetermined threshold being based on a service level agreement, the predetermined threshold being a maximum number of times that a response is not received, or a number of times that a response
  • a system for adaptively managing a request for insurance comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the system at least to: send the request to a first one of a plurality of service provider servers when the request for insurance is determined to be eligible; determine whether a response is received from the first one of the plurality of service provider servers, and send the request to a second one of a plurality of service provider servers based on the determination of whether a response is received from the first one of the plurality of service provider servers; determine the first one of the plurality of service provider servers based on a weight assigned to each of the plurality of service provider servers, wherein determining whether a response is received from the first one of the plurality of service provider servers is in accordance with the predetermined threshold, the predetermined threshold being based on a service level agreement, the predetermined threshold being a maximum number of times that
  • FIG. 1 illustrates a system for adaptively managing a request for insurance according to various embodiments of the present disclosure.
  • Fig. 2 is a schematic diagram of how an insurance product may be provided by more than one service provider, according to various embodiments of the present disclosure.
  • FIG. 3 is an overview of a process for adaptively managing a request for insurance, according to various embodiments.
  • FIG. 4 is an overview of a process when a service provider is not available, according to various embodiments.
  • FIG. 5 is an overview of a process for recovering a service provider that was not available, according to various embodiments.
  • FIG. 6 illustrates an example flow diagram for adaptively managing a request for insurance according to various embodiments.
  • Fig. 7 illustrates an example flow diagram of how a service provider may be reinstated after a response is not received according to various embodiments.
  • FIGs. 8A and 8B form a schematic block diagram of a general purpose computer system upon which the transaction processing server of Fig. 1 can be practiced.
  • Fig. 8C is a schematic block diagram of a general purpose computer system upon which the switching server of Fig. 1 can be practiced.
  • Fig. 8D is a schematic block diagram of a general purpose computer system upon which a combined transaction processing server and switching server of Fig. 1 can be practiced.
  • FIG. 9 shows an example of a computing device to realize the transaction processing server shown in Fig. 1.
  • Fig. 10 shows an example of a computing device to realize the switching server shown in Fig. 1 .
  • FIG. 11 shows an example of a computing device to realize a combined transaction processing and switching server shown in Fig. 1 .
  • the present specification also implicitly discloses a computer program, in that it would be apparent to the person skilled in the art that the individual steps of the method described herein may be put into effect by computer code.
  • the computer program is not intended to be limited to any particular programming language and implementation thereof. It will be appreciated that a variety of programming languages and coding thereof may be used to implement the teachings of the disclosure contained herein.
  • the computer program is not intended to be limited to any particular control flow. There are many other variants of the computer program, which can use different control flows without departing from the scope of the specification.
  • the computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a computer.
  • the computer readable medium may also include a hardwired medium such as exemplified in the Internet system, or wireless medium such as exemplified in the GSM mobile telephone system.
  • the computer program when loaded and executed on such a computer effectively results in an apparatus that implements the steps of the preferred method.
  • An insurance may be referred to as an arrangement by which a person or an entity such as company or state undertakes to provide a guarantee of compensation for specified loss, damage, illness, or death in return for payment of a specified premium.
  • An insurance plan or insurance product is accordingly referred to as a plan or product that provides such an arrangement.
  • Insurance may be purchased to protect against events such as accidents, illnesses, death, loss of luggage, damage to property, house fires and other similar events.
  • An insurance product may be provided by a service provider such as an insurer, underwriter, or other similar entity for providing an insurance product.
  • a booking application may provide services across different verticals such as travel, food, mart, insurance and other similar verticals. In some cases, booking applications can provide different insurance products from different service providers, and may be known as insurance aggregators.
  • a user may be any suitable type of entity, which may include a person, a consumer looking to purchase a good or service via a transaction processing server, a seller looking to sell a good or service via the transaction processing server, a motorcycle driver or pillion rider in a case of the user looking to book or provide a motorcycle ride via the transaction processing server, a car driver or passenger in a case of the user looking to book or provide a car ride via the transaction processing server, and other similar entity.
  • the user is also able to purchase an insurance product via the transaction processing server.
  • a user may be a regular customer of the concerned booking application who also decides to purchase an insurance product using the booking application via the transaction processing server.
  • the user may also be a seller or driver providing a good or service via the booking application and who decides to purchase an insurance product using the booking application via the transaction processing server.
  • a user who is registered to the transaction processing server or switching server will be called a registered user.
  • a user who is not registered to the transaction processing server or switching server will be called a non-registered user.
  • an unregistered user may or may not be able to enjoy certain services provided by the booking application, or may or may not be able to be a deliverer or driver of the concerned booking application, or other similar disadvantages.
  • the term user will be used to collectively refer to both registered and nonregistered users.
  • a user may at various places within this specification be referred to as a requestor (e.g. a person who requests for a good or service) or a provider (e.g. a person who provides the requested good or service to the requestor).
  • a switching server may be a server that hosts software application programs for adaptively managing a request for insurance.
  • the switching server may be implemented as shown in Figs. 10 or 11 for adaptively managing a request for insurance.
  • the transaction processing server may be a server that hosts software application programs for processing payment transactions for, for example, purchasing of an insurance product by a user.
  • the transaction processing server may communicate with one or more other servers (e.g., a switching server) concerning processing payment transactions for insurance products.
  • the transaction processing server may communicate with a switching server to facilitate purchase of an insurance product.
  • the transaction processing server may use a variety of different protocols and procedures in order to process the payment.
  • Transactions that may be performed via a transaction processing server further include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc.
  • Transaction processing servers may be configured to process transactions via cash-substitutes, which may include payment cards, letters of credit, checks, payment accounts, etc.
  • the transaction processing server is usually managed by a service provider that may be an entity (e.g. a company or organization) which operates to process user requests for insurance.
  • the transaction processing server may include one or more computing devices that are used for processing user requests for insurance.
  • a transaction account may be an account of a user who is registered at a transaction processing server.
  • the user can be a customer, a ride-hailing provider (e.g., a driver), or any third parties such as a delivery service provider (e.g., a courier) who want to use the transaction processing server. In certain circumstances, the transaction account is not required to use the switching server.
  • a transaction account includes details (e.g., name, address, vehicle, face image, etc.) of a user.
  • the transaction processing server manages the transaction accounts of users and the interactions between users and other external servers.
  • Fig. 1 illustrates a block diagram of an example system 100 for adaptively managing a request for insurance. Further, the system 100 enables a payment transaction for an insurance product.
  • the example system 100 comprises a requestor device 102, a provider device 104, an acquirer server 106, a transaction processing server 108, an issuer server 1 10, a switching server 140 and service provider servers 150A to 150N.
  • the requestor device 102 is in communication with a provider device 104 via a connection 1 12.
  • the connection 1 12 may be an ad hoc connection (e.g., via NFC communication, Bluetooth, etc.) or over a network (e.g., the Internet).
  • the requestor device 102 is also in communication with the switching server 140 via a connection 121 (e.g., the Internet).
  • the requestor device 102 may also be connected to a cloud that facilitates the system 100 for adaptively managing a request for insurance.
  • the requestor device 102 can send a signal or data to the cloud directly via an ad hoc connection (e.g., via NFC communication, Bluetooth, etc.) or over a network (e.g., the Internet).
  • the provider device 104 is in communication with the requestor device 102 as described above, usually via the transaction processing server 108.
  • the provider device 104 is, in turn, in communication with an acquirer server 106 via a connection 1 14.
  • the provider device 104 is also in communication with the switching server 140 via a connection 123.
  • the connections 1 14 and 123 may be network connections (e.g., the Internet).
  • the provider device 104 may also be connected to a cloud that facilitates the system 100 for adaptively managing a request for insurance.
  • the provider device 104 can send a signal or data to the cloud directly via an ad hoc connection (e.g., via NFC communication, Bluetooth, etc.) or over a network (e.g., the Internet).
  • the acquirer server 106 is in communication with the transaction processing server 108 via a connection 1 16.
  • the transaction processing server 108 is in communication with an issuer server 1 10 via a connection 1 18.
  • the connections 1 16 and 1 18 may each be a network connection (e.g., the Internet).
  • the transaction processing server 108 is further in communication with the switching server 140 via a connection 120.
  • the connection 120 may be over a network (e.g., a local area network, a wide area network, the Internet, etc.).
  • the transaction processing server 108 and the switching server 140 are combined and the connection 120 may be an interconnected bus.
  • the switching server 140 is in communication with the service provider servers 150A to 150N via respective connections 122A to 122N.
  • the connections 122A to 122N may each be network connections (e.g., the Internet).
  • the switching server 140 may also be connected to a cloud that facilitates the system 100 for adaptively managing a request for insurance.
  • the switching server 140 can send a signal or data to the cloud directly via an ad hoc connection (e.g., via NFC communication, Bluetooth, etc.) or over a network (e.g., the Internet).
  • the service provider servers 150A to 150N are collectively referred to herein as service provider servers 150.
  • the service provider server 150 may be one managed by a service provider such as an insurer, underwriter, or other similar entity for providing an insurance product and the switching server 140 is a server that adaptively manages user requests for insurance and decides which of the service provider servers 150 to forward a user request for insurance.
  • each of the devices 102, 104, and the servers 106, 108, 1 10, 140, and 150 provides an interface to enable communication with other connected devices 102, 104, 142 and/or servers 106, 108, 1 10, 140, and 150.
  • Such communication is facilitated by an application programming interface (“API”).
  • APIs may be part of a user interface that may include graphical user interfaces (GUIs), Webbased interfaces, programmatic interfaces such as application programming interfaces (APIs) and/or sets of remote procedure calls (RPCs) corresponding to interface elements, messaging interfaces in which the interface elements correspond to messages of a communication protocol, and/or suitable combinations thereof.
  • GUIs graphical user interfaces
  • APIs application programming interfaces
  • RPCs remote procedure calls
  • server can mean a single computing device or a plurality of interconnected computing devices which operate together to perform a particular function. That is, the server may be contained within a single hardware unit or be distributed among several or many different hardware units.
  • the switching server 140 is associated with an entity (e.g. a company or organization or moderator of the service). In one arrangement, the switching server 140 is owned and operated by the entity operating the transaction processing server 108. In such an arrangement, the switching server 140 may be implemented as a part (e.g., a computer program module, a computing device, etc.) of the transaction processing server 108.
  • entity e.g. a company or organization or moderator of the service.
  • the switching server 140 is owned and operated by the entity operating the transaction processing server 108.
  • the switching server 140 may be implemented as a part (e.g., a computer program module, a computing device, etc.) of the transaction processing server 108.
  • the transaction processing server 108 may also be configured to manage the registration of users.
  • a registered user has a transaction account (see the discussion above) which includes details of the user.
  • the registration step is called on-boarding.
  • a user may use either the requestor device 102 or the provider device 104 to perform onboarding to the transaction processing server 108.
  • an unregistered user may have access to only a subset of the functionality available to registered users. For example, an unregistered user may or may not be able to enjoy certain services provided by the booking application, or may or may not be able to be a deliverer or driver of the concerned booking application.
  • the on-boarding process for a user is typically performed by the user through one of the requestor device 102 or the provider device 104.
  • the user downloads an app (which includes, or otherwise provides access to, the API to interact with the transaction processing server 108) to the requestor device 102 or the provider device 104.
  • the user accesses a website (which includes, or otherwise provides access to, the API to interact with the transaction processing server 108) on the requestor device 102 or the provider device 104.
  • the user is then able to interact with the switching server 140.
  • the user may be a requestor or a provider associated with the requestor device 102 or the provider device 104, respectively.
  • Details of the registration may include, for example, name of the user, address of the user, emergency contact, blood type or other healthcare information, next-of-kin contact, permissions to retrieve data and information from the requestor device 102 and/or the provider device 104 for insurance purchase or underwriting purposes, such as permission to use a camera of the requestor device 102 and/or the provider device 104 to take a picture of the requestor’s or provider’s face, wherein the picture may be used for insurance purchase purposes.
  • another mobile device may be selected instead of the requestor device 102 and/or the provider device 104 for retrieving the picture. Once on-boarded, the user would have a transaction account that stores all the details.
  • the requestor device 102 is associated with a customer (or requestor) who is a party to a request (e.g. a ride-hailing request or a delivery request) that occurs between the requestor device 102 and the provider device 104.
  • the requestor device 102 may be a computing device such as a desktop computer, an interactive voice response (IVR) system, a smartphone, a laptop computer, a personal digital assistant computer (PDA), a mobile computer, a tablet computer, and the like.
  • IVR interactive voice response
  • PDA personal digital assistant computer
  • the requestor device 102 includes transaction credentials (e.g., a payment account) of a requestor to enable the requestor device 102 to be a party to a payment transaction, for example for purchasing an insurance product. If the requestor has a transaction account, the transaction account may also be included (i.e., stored) in the requestor device 102. For example, a mobile device (which is a requestor device 102) may have the transaction account of the requestor stored in the mobile device.
  • transaction credentials e.g., a payment account
  • the transaction account may also be included (i.e., stored) in the requestor device 102.
  • a mobile device which is a requestor device 102 may have the transaction account of the requestor stored in the mobile device.
  • the requestor device 102 is a computing device in the form of a watch or similar wearable and is fitted with a wireless communications interface (e.g., a NFC interface).
  • the requestor device 102 can then electronically communicate with the switching server 140 and the transaction processing server 108 regarding a user request for insurance, or electronically communicate with the provider device 104 for a transaction request for a good or service.
  • the requestor uses the watch or similar wearable to make a user request or a transaction request by pressing a button on the watch or wearable.
  • the provider device 104 is associated with a provider who is also a party to the transaction request that occurs between the requestor device 102 and the provider device 104.
  • the provider device 104 can also be party to a payment transaction for purchasing an insurance product.
  • the provider device 104 includes transaction credentials (e.g., a payment account) of a provider to enable the provider device 104 to be a party to a payment transaction, for example for purchasing an insurance product. If the provider has a transaction account, the transaction account may also be included (i.e., stored) in the provider device 104.
  • a mobile device (which is a provider device 104) may have the transaction account of the provider stored in the mobile device.
  • the provider device 104 may be a computing device such as a desktop computer, an interactive voice response (IVR) system, a smartphone, a laptop computer, a personal digital assistant computer (PDA), a mobile computer, a tablet computer, and the like.
  • the provider device 104 can then electronically communicate with the switching server 140 and the transaction processing server 108 regarding a user request for insurance, or electronically communicate with the requestor device 102 for a transaction request for a good or service.
  • the term “provider” refers to any third party associated with providing a good or service for purchase, or a travel or ride or delivery service via the provider device 104. Therefore, the transaction account of a provider refers to both the transaction account of a provider and the transaction account of a third party (e.g., a travel co-ordinator or merchant) associated with the provider.
  • a third party e.g., a travel co-ordinator or merchant
  • the transaction account may also be included (i.e., stored) in the provider device 104.
  • a mobile device which is a provider device 104 may have the transaction account of the provider stored in the mobile device.
  • the provider device 104 is a computing device in a watch or similar wearable and is fitted with a wireless communications interface (e.g., a NFC interface). The provider device 104 can then electronically communicate with the switching server 140 and the transaction processing server 108 regarding a user request for insurance, or electronically communicate with the requestor to make a transaction request by pressing a button on the watch or wearable.
  • a wireless communications interface e.g., a NFC interface
  • the acquirer server 106 is associated with an acquirer who may be an entity (e.g. a company or organization) which issues (e.g. establishes, manages, administers) a payment account (e.g. a financial bank account) of a provider or a service provider.
  • An acquirer may be a bank or other financial institution.
  • the acquirer server 106 may include one or more computing devices that are used to establish communication with another server (e.g., the transaction processing server 108) by exchanging messages with and/or passing information to the other server.
  • the acquirer server 106 forwards the payment transaction relating to a user request for insurance or relating to a transaction request to the transaction processing server 108.
  • the transaction processing server 108 is configured to carry out processes relating to a transaction account by, for example, forwarding data and information associated with the transaction to the other servers in the system 100 such as the switching server 140.
  • the transaction processing server 108 may provide confirmation of payment for a user request for insurance to the switching server 140.
  • the issuer server 1 10 is associated with an issuer and may include one or more computing devices that are used to perform a payment transaction.
  • the issuer may be an entity (e.g. a company or organization) which issues (e.g. establishes, manages, administers) a transaction credential or a payment account (e.g. a financial bank account) associated with the owner of the requestor device 102.
  • the issuer server 1 10 may include one or more computing devices that are used to establish communication with another server (e.g., the transaction processing server 108) by exchanging messages with and/or passing information to the other server.
  • the service provider server 150 is a server associated with an entity (e.g. a company or organization) which manages (e.g. establishes, administers) and provides insurance products for sale to a user.
  • entity e.g. a company or organization
  • the entity is a service provider such as an insurer or underwriter that sells insurance products.
  • Switching between service providers, or between servers thereof where a service provider maintains multiple servers increases the availability and resilience of systems providing insurance products. It remains a challenge to determine how the request distribution should be handled. To address this, in some embodiments, a weighted distribution of traffic and falling back to available servers in case of failures can be used. Possible benefits include the ability to provide customers with the best prices with support for discounts, to provide a better user experience to customers by increasing availability of service providers to process user requests for insurance, and to abstract customers from what is happening behind the scenes during an insurance purchase. For insurance aggregators, it can also help in better resilience of the system.
  • insurance of a same type from different service providers or underwriters will be merged into one insurance product, from the perspective of possible buyers of insurance, while configuring the insurance products into the system.
  • the system will determine which service provider the request should be routed to, for example based on the current state of service provider servers 150. Failures from service providers (e.g. a service provider server 150 failing to send a response to the switching server 140 to indicate that a user request for insurance is successfully received) will be taken into consideration for dynamically controlling the traffic distribution percentage.
  • Fig. 2 is a schematic diagram 200 of how an insurance product may be provided by more than one service provider, according to various embodiments of the present disclosure.
  • the process begins during configuration of insurance products in the system.
  • Each insurance product which a user can purchase may represent an insurance plan from each of a plurality of different service providers.
  • a service provider 202 may offer an insurance plan 204
  • another service provider 206 may offer an insurance plan 208.
  • the insurance plans 204 and 208 may be merged and presented in a booking application as a single insurance product for purchase.
  • the merging of insurance plans across different service providers may be based on factors such as coverage type, price, and other similar factors, and insurance plans that are merged into a single insurance product are similar to one another.
  • Each plan 204 and 208 has an associated cost (premium) which the user must pay during purchase. In this case, the price for the insurance product can be the same as the price of each of plan 204 and 208 (e.g. SGD 2).
  • each plan 204 and 208 may also have an identifier which can be used to recognize the same plan from different underwriters.
  • the insurance product that is created based on the merger of plans 204 and 208 may be titled as “Plan A” and may be associated with an identifier such as “djdfh1233”.
  • Table 210 depicts an example of how insurance product Plan A may be registered in a data store. For example, plans 204 and 208 can be input as two different rows in table 210, along with their corresponding description details in the middle column, and an indication of associated service providers 202 and 206 in the right column.
  • the table 210 may be used to show metadata (for example such as a name or title of the insurance product, details of insurance coverage provided by the insurance product such as what events are covered and the maximum cover for each event, price, etc) for each insurance product on a front end such as a user interface for purchasing the insurance product.
  • the metadata to be shown for each insurance product can be from any of the associated service providers (e.g. in the case of insurance product Plan A, it would be from associated service providers 202 and 204) which can be configuration based.
  • FIG. 3 is an illustration 300 of a process for adaptively managing a request for insurance, according to various embodiments.
  • a user 302 may decide on an insurance product to purchase from a booking application and send a request for insurance to the switching server 140 to purchase the insurance product.
  • the request may be sent via a user device 304, which may be the requestor device 102 or the provider device 104.
  • underwriting checks may be performed to check if the user is eligible for the insurance product.
  • an underwriting process may consider information relating to the user 302 such as age, gender, occupation, medical record, financial history, amount of credit stored with the booking application, and other similar information.
  • the switching server 140 sends the request to a first one of a plurality of service providers (the choice of service provider typically being determined according to selection logic as detailed below), and determines whether a response is received from the first one of the plurality of service providers.
  • the determination of whether a response is received may be in accordance with a predetermined threshold, the threshold being one that is determined based on a service level agreement (SLA).
  • SLA service level agreement
  • the threshold may be a maximum number of times that a response is not received from the first one of the plurality of service providers, a number of times that a response is not received within a predetermined period of time from the first one of the plurality of service providers, or other similar type of threshold that is configured based on the SLA between the concerned first one of the plurality of service providers and the entity that owns and/or operates the booking application.
  • the concerned insurance product may be a merger of three insurance plans from service providers A, B and C respectively which run service provider servers 306, 308 and 310 respectively.
  • the switching server 140 may determine a plurality of service provider servers (e.g.
  • the plurality of service provider servers 306, 308 and 310 run by service providers A, B and C respectively) for providing the insurance plan indicated in the request for insurance.
  • the plurality of service provider servers may be determined based on data identifying the insurance product, for example data in the form of table 210 which indicates the associated service providers that can provide the insurance plans that are merged into the concerned insurance product.
  • the switching server 140 may also be configured to determine an identifier associated with the insurance product based on the data, wherein determining the plurality of service provider servers is based on the identifier.
  • the request may indicate a title, name, ID number, or other similar type of identifier associated with the concerned insurance product, and the switching server may reference the data based on the identifier (e.g. referencing data wherein the identifier indicated in the left column of table 210 is the same as the identifier indicated in the request).
  • the switching server 140 has to select one of these service providers for sending the request.
  • the switching server 140 may determine the first one of the plurality of service provider servers based on a weight assigned to each of the plurality of service provider servers.
  • the assigned weight for each of the plurality of service provider servers designates a priority to each service provider server for selection by the switching server 140.
  • the priority may be based on factors such as service level agreements (SLAs) and/or contractual agreements between the entity that owns and/or operates the concerned booking application and the respective service providers, current availability of each service provider server for handling requests for insurance, and other similar factors.
  • SLAs service level agreements
  • a weighted distribution of requests wherein the weights can initially be manually configured in the system.
  • the weights can be configured such that service provider A serves 4 out of the 10 requests, service provider B serves 1 out of the 10 requests, and service provider C serves 5 out of the 10 requests respectively.
  • the configuration can be based on factors such as service level agreements (SLAs) and/or contractual agreements between the entity that owns and/or operates the concerned booking application and the respective service providers, current availability of each service provider server for handling requests for insurance, and other similar factors.
  • SLAs service level agreements
  • the operation of this weighted distribution system for 10 requests and 3 service provider servers may be represented in the following equation:
  • a random number may be generated between [1 , 10].
  • the generated number corresponds to one of the 3 service providers A, B and C which would serve the request for insurance.
  • a generated random number between [1 , 4] would mean that the request is to be served by service provider A, and the switching server 140 sends the request to the service provider server corresponding to service provider A (e.g. service provider server 306). If the generated random number is 5, service provider B will handle the request, and the switching server 140 sends the request to the service provider server corresponding to service provider B (e.g. service provider server 308).
  • service provider C will handle the request, and the switching server 140 sends the request to the service provider server corresponding to service provider C (e.g. service provider server 310).
  • Probability of each number generated from the random number generator becomes equal when implemented on a larger scale e.g. for a larger number of requests.
  • round-robin allocation to servers may be performed up until the point at which respective servers have received their full allocation for a given period. In the example above, a first round of allocations may occur, such that each of servers A, B, and C receive one request. In the next round, since B has already received its single request, only A and C receive requests, and so on.
  • Fig. 4 is an illustration 400 of a switching process that is carried out when a service provider server is not available, according to various embodiments.
  • the service provider server 306 may be unavailable to receive and serve any request for insurance that may be sent by the switching server 140, and accordingly is unable to provide any response to the switching server 140 to indicate that a request for insurance is received.
  • the switching server 140 determines whether a response is received from the service provider server 306 in accordance with a predetermined threshold, the threshold being one that is determined based on a service level agreement.
  • the threshold may be a maximum number of times that a response is not received from the concerned service provider server 306, a number of times that a response is not received within a predetermined period of time from the concerned service provider 306, or other similar type of threshold that is configured based on the SLA between the concerned service provider A that owns and/or operates service provider server 306 and the entity that owns and/or operates the booking application.
  • the switching server 140 may determine whether to send the request to a second one of the plurality of service provider servers based on the determination of whether a response is received from the first one of the plurality of service provider servers. Since no response has been received from the service provider server 306 to indicate that the request for insurance is duly received, the switching server 140 may send the request to either service provider server 308 or service provider server 310 instead. Further, the weights among the plurality of service provider servers may also be rebalanced or reassigned without the first one of the plurality of service provider servers (e.g. without service provider 306) if it is determined that the response is not received.
  • the determination may be based on the threshold, for example the reassignment of weights may be done after the number of times that no response was received from service provider server 306 has exceeded a threshold number. Thereafter, no requests will be sent to service provider server 306 and instead be distributed between service provider server 308 and service provider server 310 based on the reassigned weights.
  • the rebalanced or reassigned weights may be represented in the following equation:
  • the value for ‘Max’ may be 6 since weights associated with service provider server 306 are to be omitted.
  • the switching server 140 may determine whether service provider server 308 or 310 should receive the request based on the reassigned weights, and then send the request based on the determination. This advantageously ensures that even in the event of a disruption of service of any service provider server, there will still be an available service provider to handle a request for insurance.
  • Fig. 5 is an illustration 500 of a process for recovering a service provider server that was not available, according to various embodiments.
  • To bring back service provider server 306 to serve further requests for insurance it is possible to work along the lines of a circuit breaker pattern. For example, a duration may be kept from a last time that a response was not received from the service provider server 306 (this can be as per defined SLA between the concerned service provider A that owns and/or operates service provider server 306 and the entity that owns and/or operates the booking application), after which a certain number of requests that are subsequently received may be sent to service provider server 306. Accordingly, the switching server 140 may send one or more other requests to the first one of the plurality of service provider servers (e.g.
  • the switching server 140 may then determine whether a response is received for each of the one or more other requests from the service provider server 306 in accordance with the predetermined threshold. If, for example, a response is received for each of these one or more other requests indicating that these requests are successfully received by the service provider server 306, service provider server 306 may be reinstated to receive requests for insurance again.
  • Max Ratio(A) + Ratio(B) + Ratio(C).
  • Fig. 6 illustrates an example flow diagram for adaptively managing a request for insurance according to various embodiments.
  • a request for insurance is sent by a switching server to a first one of a plurality of service provider servers.
  • the switching server may determine whether the request is eligible based on an underwriting process, wherein the request is sent to the first one of the plurality of service provider servers when the request is determined to be eligible.
  • the determination may be in accordance with a predetermined threshold, the predetermined threshold being based on a service level agreement, the predetermined threshold being a maximum number of times that a response is not received, or a number of times that a response is not received within a predetermined period of time. It may be determined whether to send the request to a second one of the plurality of service provider servers based on the determination of whether a response is received from the first one of the plurality of service provider servers.
  • the plurality of service provider servers may be determined for providing an insurance plan indicated in the request, the plurality of service provider servers being based on data identifying the insurance plan. An identifier associated with the insurance plan based on the data may be determined, wherein determining the plurality of service provider servers is based on the identifier.
  • the request may be sent by the switching server to a second one of the plurality of service provider servers based on the determination of whether a response is received from the first one of the plurality of service provider servers.
  • Fig. 7 illustrates an example flow diagram of how a service provider server may be reinstated after a response is not received according to various embodiments.
  • the first one of the plurality of service provider servers is determined by the switching server based on a weight assigned to each of the plurality of service provider servers. Weights among the plurality of service provider servers may be reassigned without the first one of the plurality of service provider servers if it is determined that the response is not received.
  • one or more other requests are sent to the first one of the plurality of service provider servers at a predetermined period of time after the determination that the response is not received, the predetermined period of time being one that is determined based on the service level agreement.
  • a step 706 it is determined whether a response is received for each of the one or more other requests from the first one of the plurality of service provider servers in accordance with the predetermined threshold, the predetermined threshold further being a maximum number of times that a response is received, or a number of times that a response is received within a predetermined period of time.
  • weights among the plurality of service provider servers are reassigned with the first one of the plurality of service provider servers if it is determined that the response is received for each of the one or more other requests.
  • Figs. 8A and 8B form a schematic block diagram of a general purpose computer system upon which the transaction processing server of Fig. 1 can be practiced.
  • the computer system 1300 includes a computer module 1301 .
  • An external Modulator-Demodulator (Modem) transceiver device 1316 may be used by the computer module 1301 for communicating to and from a communications network 1320 via a connection 1321 .
  • the communications network 1320 may be a wide- area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN.
  • the connection 1321 is a telephone line
  • the modem 1316 may be a traditional “dial-up” modem.
  • the connection 1321 is a high capacity (e.g., cable) connection
  • the modem 1316 may be a broadband modem.
  • a wireless modem may also be used for wireless connection to the communications network 1320.
  • the computer module 1301 typically includes at least one processor unit 1305, and a memory unit 1306.
  • the memory unit 1306 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM).
  • the computer module 1301 also includes an interface 1308 for the external modem 1316.
  • the modem 1316 may be incorporated within the computer module 1301 , for example within the interface 1308.
  • the computer module 1301 also has a local network interface 131 1 , which permits coupling of the computer system 1300 via a connection 1323 to a local-area communications network 1322, known as a Local Area Network (LAN).
  • LAN Local Area Network
  • the local communications network 1322 may also couple to the wide network 1320 via a connection 1324, which would typically include a so-called “firewall” device or device of similar functionality.
  • the local network interface 131 1 may comprise an Ethernet circuit card, a Bluetooth® wireless arrangement or an IEEE 802.1 1 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 131 1.
  • the I/O interfaces 1308 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated).
  • Storage devices 1309 are provided and typically include a hard disk drive (HDD) 1310. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used.
  • An optical disk drive 1312 is typically provided to act as a non-volatile source of data.
  • Portable memory devices such optical disks, USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 1300.
  • the components 1305 to 1312 of the computer module 1301 typically communicate via an interconnected bus 1304 and in a manner that results in a conventional mode of operation of the computer system 1300 known to those in the relevant art.
  • the processor 1305 is coupled to the system bus 1304 using a connection 1318.
  • the memory 1306 and optical disk drive 1312 are coupled to the system bus 1304 by connections 1319. Examples of computers on which the described arrangements can be practised include IBM-PC’s and compatibles, Sun Sparcstations, Apple or like computer systems.
  • the steps of the methods 600 and 700 in Figs. 6 and 7 facilitated by the transaction processing server 108 may be implemented using the computer system 1300.
  • the steps of the methods 600 and 700 may be implemented as one or more software application programs 1333 executable within the computer system 1300.
  • the steps of the methods 600 and 700 as facilitated by the transaction processing server 108 are effected by instructions 1331 (see Fig. 6B) in the software 1333 that are carried out within the computer system 1300.
  • the software instructions 1331 may be formed as one or more code modules, each for performing one or more particular tasks.
  • the software may also be divided into two separate parts, in which a first part and the corresponding code modules facilitate the steps of the methods 600 and 700 and a second part and the corresponding code modules manage a user interface between the first part and the user.
  • the software may be stored in a computer readable medium, including the storage devices described below, for example.
  • the software is loaded into the computer system 1300 from the computer readable medium, and then executed by the computer system 1300.
  • a computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product.
  • the use of the computer program product in the computer system 1300 preferably effects an advantageous apparatus for a transaction processing server 108.
  • the software 1333 is typically stored in the HDD 1310 or the memory 1306.
  • the software is loaded into the computer system 1300 from a computer readable medium, and executed by the computer system 1300.
  • the software 1333 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 1325 that is read by the optical disk drive 1312.
  • a computer readable medium having such software or computer program recorded on it is a computer program product.
  • the use of the computer program product in the computer system 1300 preferably effects an apparatus for a transaction processing server 108.
  • the application programs 1333 may be supplied to the user encoded on one or more CD-ROMs 1325 and read via the corresponding drive 1312, or alternatively may be read by the user from the networks 1320 or 1322. Still further, the software can also be loaded into the computer system 1300 from other computer readable media.
  • Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the computer system 1300 for execution and/or processing.
  • Examples of such storage media include floppy disks, magnetic tape, optical disk, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1301.
  • Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computer module 1301 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.
  • Fig. 8B is a detailed schematic block diagram of the processor 1305 and a “memory” 1334.
  • the memory 1334 represents a logical aggregation of all the memory modules (including the HDD 1309 and semiconductor memory 1306) that can be accessed by the computer module 1301 in Fig. 8A.
  • a power-on self-test (POST) program 1350 executes.
  • the POST program 1350 is typically stored in a ROM 1349 of the semiconductor memory 1306 of Fig. 8A.
  • a hardware device such as the ROM 1349 storing software is sometimes referred to as firmware.
  • the POST program 1350 examines hardware within the computer module 1301 to ensure proper functioning and typically checks the processor 1305, the memory 1334 (1309, 1306), and a basic input-output systems software (BIOS) module 1351 , also typically stored in the ROM 1349, for correct operation. Once the POST program 1350 has run successfully, the BIOS 1351 activates the hard disk drive 1310 of Fig. 8A.
  • BIOS basic input-output systems software
  • Activation of the hard disk drive 1310 causes a bootstrap loader program 1352 that is resident on the hard disk drive 1310 to execute via the processor 1305.
  • the operating system 1353 is a system level application, executable by the processor 1305, to fulfil various high level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface.
  • the operating system 1353 manages the memory 1334 (1309, 1306) to ensure that each process or application running on the computer module 1301 has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the system 1300 of Fig. 8A must be used properly so that each process can run effectively. Accordingly, the aggregated memory 1334 is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system 1300 and how such is used.
  • the processor 1305 includes a number of functional modules including a control unit 1339, an arithmetic logic unit (ALU) 1340, and a local or internal memory 1348, sometimes called a cache memory.
  • the cache memory 1348 typically includes a number of storage registers 1344 - 1346 in a register section.
  • One or more internal busses 1341 functionally interconnect these functional modules.
  • the processor 1305 typically also has one or more interfaces 1342 for communicating with external devices via the system bus 1304, using a connection 1318.
  • the memory 1334 is coupled to the bus 1304 using a connection 1319.
  • the application program 1333 includes a sequence of instructions 1331 that may include conditional branch and loop instructions.
  • the program 1333 may also include data 1332 which is used in execution of the program 1333.
  • the instructions 1331 and the data 1332 are stored in memory locations 1328, 1329, 1330 and 1335, 1336, 1337, respectively.
  • a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 1330.
  • an instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 1328 and 1329.
  • the processor 1305 is given a set of instructions which are executed therein.
  • the processor 1305 waits for a subsequent input, to which the processor 1305 reacts to by executing another set of instructions.
  • Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices 1302, 1303, data received from an external source across one of the networks 1320, 1302, data retrieved from one of the storage devices 1306, 1309 or data retrieved from a storage medium 1325 inserted into the corresponding reader 1312, all depicted in Fig. 8A.
  • the execution of a set of the instructions may in some cases result in output of data. Execution may also involve storing data or variables to the memory 1334.
  • the disclosed transaction processing server 108 arrangements use input variables 1354, which are stored in the memory 1334 in corresponding memory locations 1355, 1356, 1357.
  • the transaction processing server 108 arrangements produce output variables 1361 , which are stored in the memory 1334 in corresponding memory locations 1362, 1363, 1364.
  • Intermediate variables 1358 may be stored in memory locations 1359, 1360, 1366 and 1367.
  • each fetch, decode, and execute cycle comprises: a fetch operation, which fetches or reads an instruction 1331 from a memory location 1328, 1329, 1330; a decode operation in which the control unit 1339 determines which instruction has been fetched; and an execute operation in which the control unit 1339 and/or the ALU 1340 execute the instruction.
  • Each step or sub-process in the processes as performed by the transaction processing server 108 is associated with one or more segments of the program 1333 and is performed by the register section 1344, 1345, 1347, the ALU 1340, and the control unit 1339 in the processor 1305 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program 1333.
  • the structural context of the computer system 1300 i.e., the transaction processing server 108 is presented merely by way of example. Therefore, in some arrangements, one or more features of the server 1300 may be omitted. Also, in some arrangements, one or more features of the server 1300 may be combined together. Additionally, in some arrangements, one or more features of the server 1300 may be split into one or more component parts.
  • Fig. 9 shows an alternative implementation of the transaction processing server 108 (i.e., the computer system 1300).
  • the transaction processing server 108 may be generally described as a physical device comprising at least one processor 802 and at least one memory 804 including computer program codes.
  • the at least one memory 804 and the computer program codes are configured to, with the at least one processor 802, cause the transaction processing server 108 to facilitate the operations described in the methods 600 and 700.
  • the transaction processing server 108 may also include a transaction processing module 806.
  • the memory 804 stores computer program code that the processor 802 compiles to have each of the modules 806 and 808 perform their respective functions.
  • the transaction processing module 806 performs the function of communicating with the requestor device 102 and the provider device 104; and the acquirer server 106 and the issuer server 1 10 to respectively receive and transmit a request for insurance, as well as a transaction or travel request message. Further, the transaction processing module 806 may provide data and information associated with the request for insurance that are used for adaptively managing the request for insurance by the switching server 140, for example providing a confirmation that payment has been made for the request for insurance, providing data and information relating to the user making the request for insurance for underwriting purposes, or other similar types of data and information.
  • Fig. 8C depicts a general-purpose computer system 1400, upon which the switching server 140 described can be practiced.
  • the computer system 1400 includes a computer module 1401.
  • An external Modulator-Demodulator (Modem) transceiver device 1416 may be used by the computer module 1401 for communicating to and from a communications network 1420 via a connection 1421.
  • the communications network 1420 may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN.
  • the modem 1416 may be a traditional “dial-up” modem.
  • the modem 1416 may be a broadband modem.
  • a wireless modem may also be used for wireless connection to the communications network 1420.
  • the computer module 1401 typically includes at least one processor unit 1405, and a memory unit 1406.
  • the memory unit 1406 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM).
  • the computer module 1401 also includes an interface 1408 for the external modem 1416.
  • the modem 1416 may be incorporated within the computer module 1401 , for example within the interface 1408.
  • the computer module 1401 also has a local network interface 141 1 , which permits coupling of the computer system 1400 via a connection 1423 to a local-area communications network 1422, known as a Local Area Network (LAN).
  • LAN Local Area Network
  • the local communications network 1422 may also couple to the wide network 1420 via a connection 1424, which would typically include a so-called “firewall” device or device of similar functionality.
  • the local network interface 141 1 may comprise an Ethernet circuit card, a Bluetooth® wireless arrangement or an IEEE 802.1 1 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 141 1.
  • the I/O interfaces 1408 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated).
  • Storage devices 1409 are provided and typically include a hard disk drive (HDD) 1410. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used.
  • An optical disk drive 1412 is typically provided to act as a non-volatile source of data.
  • Portable memory devices, such optical disks, USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 1400.
  • the components 1405 to 1412 of the computer module 1401 typically communicate via an interconnected bus 1404 and in a manner that results in a conventional mode of operation of the computer system 1400 known to those in the relevant art.
  • the processor 1405 is coupled to the system bus 1404 using a connection 1418.
  • the memory 1406 and optical disk drive 1412 are coupled to the system bus 1404 by connections 1419. Examples of computers on which the described arrangements can be practiced include IBM-PC’s and compatibles, Sun Sparcstations, Apple or like computer systems.
  • the methods 600 and 700, where performed by the switching server 140 may be implemented using the computer system 1400.
  • the processes may be implemented as one or more software application programs 1433 executable within the computer system 1400.
  • the methods 600 and 700 are effected by instructions (see corresponding component 1331 in Fig. 8B) in the software 1433 that are carried out within the computer system 1400.
  • the software instructions may be formed as one or more code modules, each for performing one or more particular tasks.
  • the software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the methods and a second part and the corresponding code modules manage a user interface between the first part and the user.
  • the software may be stored in a computer readable medium, including the storage devices described below, for example.
  • the software is loaded into the computer system 1400 from the computer readable medium, and then executed by the computer system 1400.
  • a computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product.
  • the use of the computer program product in the computer system 1400 preferably effects an advantageous apparatus for a switching server 140.
  • the software 1433 is typically stored in the HDD 1410 or the memory 1406.
  • the software is loaded into the computer system 1400 from a computer readable medium, and executed by the computer system 1400.
  • the software 1433 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 1425 that is read by the optical disk drive 1412.
  • a computer readable medium having such software or computer program recorded on it is a computer program product.
  • the use of the computer program product in the computer system 1400 preferably effects an apparatus for a switching server 140.
  • the application programs 1433 may be supplied to the user encoded on one or more CD-ROMs 1425 and read via the corresponding drive 1412, or alternatively may be read by the user from the networks 1420 or 1422. Still further, the software can also be loaded into the computer system 1400 from other computer readable media.
  • Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the computer system 1400 for execution and/or processing.
  • Examples of such storage media include floppy disks, magnetic tape, optical disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1401.
  • Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computer module 1401 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.
  • GUIs graphical user interfaces
  • a user of the computer system 1400 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s).
  • Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via loudspeakers and user voice commands input via a microphone.
  • the structural context of the computer system 1400 i.e., the switching server 140
  • the structural context of the computer system 1400 is presented merely by way of example. Therefore, in some arrangements, one or more features of the computer system 1400 may be omitted. Also, in some arrangements, one or more features of the computer system 1400 may be combined together. Additionally, in some arrangements, one or more features of the computer system 1400 may be split into one or more component parts.
  • Fig. 10 shows an alternative implementation of the switching server 140 (i.e., the computer system 1400).
  • switching server 140 may be generally described as a physical device comprising at least one processor 902 and at least one memory 904 including computer program codes.
  • the at least one memory 904 and the computer program codes are configured to, with the at least one processor 902, cause the switching server 140 to perform the operations described in the methods 600 and 700.
  • the switching server 140 may also include an underwriting module 906, a data module 908, an insurance plan module 910, a calculation module 912 and a SLA module 914.
  • the memory 904 stores computer program code that the processor 902 compiles to have each of the modules 906 to 914 perform their respective functions.
  • the SLA module 914 comprises information relating to SLAs for each of the plurality of service provider servers. This information can be utilized by the calculation module 912 for determining a threshold and/or assigned weights for use in adaptively managing a request for insurance.
  • the SLA module 914 facilitates the function of determining whether a response is received from a first one of the plurality of service provider servers in accordance with a predetermined threshold, the threshold being one that is determined based on a service level agreement.
  • the SLA module 914 further facilitates the function of sending one or more other requests to the first one of the plurality of service provider servers at a predetermined period of time after the determination that the response is not received, the predetermined period of time being one that is determined based on the service level agreement; and determining whether a response is received for each of the one or more other requests from the first one of the plurality of service provider servers in accordance with the predetermined threshold.
  • the underwriting module 906 performs the function of underwriting for a request for insurance based on data and information associated with the user making the request and the insurance product indicated in the request.
  • the switching server 140 may proceed with adaptively managing the request for insurance upon confirmation by the underwriting module 906 that the user is eligible for the insurance product indicated in the request for insurance.
  • the insurance plan module 910 comprises data and information relating to one or more insurance products, corresponding insurance plans that make up each insurance product, as well as corresponding unique ID, identifier and service provider for each insurance plan (for example in the form of table 210 of Fig. 2).
  • the insurance plan module facilitates the function of determining the plurality of service provider servers for providing an insurance product indicated in the request for insurance, the plurality of service provider servers being based on data identifying the insurance plan, as well as for determining an identifier associated with the insurance plan based on the data, wherein determining the plurality of service provider servers is based on the identifier.
  • the calculation module 912 performs the function of calculating a threshold and/or assigned weights for each service provider server 150 based on data and information relating to SLA agreements, contractual agreements, current status of each service provider server 150 and other similar types of data and information.
  • the calculation module 912 facilitates the functions of assigning and reassigning weights to each of the plurality of service provider servers 150, as well as facilitates the function of determining whether a response is received from a first one of the plurality of service provider servers in accordance with a predetermined threshold, the threshold being one that is determined based on a service level agreement.
  • the calculation module 912 further facilitates the function of sending one or more other requests to the first one of the plurality of service provider servers at a predetermined period of time after the determination that the response is not received, the predetermined period of time being one that is determined based on the service level agreement; and determining whether a response is received for each of the one or more other requests from the first one of the plurality of service provider servers in accordance with the predetermined threshold.
  • the data module 908 performs the functions of receiving data and information from the requestor device 102, provider device 104, transaction processing server 108, a cloud and other sources of information to facilitate the methods 600 and 700.
  • the data module 908 may be configured to receive a request for insurance and/or data and information thereof from the requestor device 102, the provider device 104, transaction processing server 108 or other sources of information.
  • the data module 908 may also be configured to receive a confirmation that payment has been made for the request for insurance, data and information relating to the user making the request for insurance for underwriting purposes, or other similar types of data and information from the transaction processing server 108, the requestor device 102, the provider device 104 or other sources of information.
  • Fig. 8D depicts a general-purpose computer system 1500, upon which a combined transaction processing server 108 and switching server 140 described can be practiced.
  • the computer system 1500 includes a computer module 1501.
  • An external Modulator- Demodulator (Modem) transceiver device 1516 may be used by the computer module 1501 for communicating to and from a communications network 1520 via a connection 1521.
  • the communications network 1520 may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN.
  • the modem 1516 may be a traditional “dialup” modem.
  • the modem 1516 may be a broadband modem.
  • a wireless modem may also be used for wireless connection to the communications network 1520.
  • the computer module 1501 typically includes at least one processor unit 1505, and a memory unit 1506.
  • the memory unit 1506 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM).
  • the computer module 1501 also includes an interface 1508 for the external modem 1516.
  • the modem 1516 may be incorporated within the computer module 1501 , for example within the interface 1508.
  • the computer module 1501 also has a local network interface 151 1 , which permits coupling of the computer system 1500 via a connection 1523 to a local-area communications network 1522, known as a Local Area Network (LAN). As illustrated in Fig. 8D, the local communications network 1522 may also couple to the wide network 1520 via a connection 1524, which would typically include a so-called “firewall” device or device of similar functionality.
  • the local network interface 151 1 may comprise an Ethernet circuit card, a Bluetooth® wireless arrangement or an IEEE 802.1 1 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 151 1.
  • the I/O interfaces 1508 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated).
  • Storage devices 1509 are provided and typically include a hard disk drive (HDD) 1510. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used.
  • An optical disk drive 1512 is typically provided to act as a non-volatile source of data.
  • Portable memory devices, such optical disks, USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 1500.
  • the components 1505 to 1512 of the computer module 1501 typically communicate via an interconnected bus 1504 and in a manner that results in a conventional mode of operation of the computer system 1500 known to those in the relevant art.
  • the processor 1505 is coupled to the system bus 1504 using a connection 1518.
  • the memory 1506 and optical disk drive 1512 are coupled to the system bus 1504 by connections 1519. Examples of computers on which the described arrangements can be practised include IBM-PC’s and compatibles, Sun Sparcstations, Apple or like computer systems.
  • the steps of the methods 600 and 700 performed by the switching 140 and facilitated by the transaction processing server 108 may be implemented using the computer system 1500.
  • the steps of the method 600 and 700 as performed by the switching server 140 may be implemented as one or more software application programs 1533 executable within the computer system 1500.
  • the steps of the methods 600 and 700 are effected by instructions (see corresponding component 1331 in Fig. 8B) in the software 1533 that are carried out within the computer system 1500.
  • the software instructions may be formed as one or more code modules, each for performing one or more particular tasks.
  • the software may also be divided into two separate parts, in which a first part and the corresponding code modules perform the steps of the methods 600 and 700 and a second part and the corresponding code modules manage a user interface between the first part and the user.
  • the software may be stored in a computer readable medium, including the storage devices described below, for example.
  • the software is loaded into the computer system 1500 from the computer readable medium, and then executed by the computer system 1500.
  • a computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product.
  • the use of the computer program product in the computer system 1500 preferably effects an advantageous apparatus for a combined transaction processing server 108 and switching server 140.
  • the software 1533 is typically stored in the HDD 1510 or the memory 1506.
  • the software is loaded into the computer system 1500 from a computer readable medium, and executed by the computer system 1500.
  • the software 1533 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 1525 that is read by the optical disk drive 1512.
  • a computer readable medium having such software or computer program recorded on it is a computer program product.
  • the use of the computer program product in the computer system 1500 preferably effects an apparatus for a combined transaction processing server 108 and switching server 140.
  • the application programs 1533 may be supplied to the user encoded on one or more CD-ROMs 1525 and read via the corresponding drive 1512, or alternatively may be read by the user from the networks 1520 or 1522. Still further, the software can also be loaded into the computer system 1500 from other computer readable media.
  • Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the computer system 1500 for execution and/or processing.
  • Examples of such storage media include floppy disks, magnetic tape, optical disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1501.
  • Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computer module 1501 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.
  • GUIs graphical user interfaces
  • a user of the computer system 1500 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s).
  • Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via loudspeakers and user voice commands input via a microphone.
  • Fig. 1 1 shows an alternative implementation of combined transaction processing server 108 and switching server 140 (i.e., the computer system 1500).
  • the combined transaction processing server 108 and switching server 140 may be generally described as a physical device comprising at least one processor 1002 and at least one memory 904 including computer program codes.
  • the at least one memory 1004 and the computer program codes are configured to, with the at least one processor 1002, cause the combined transaction processing server 108 and switching server 140 to perform the operations described in the steps of the methods 600 and 700.
  • the combined transaction processing server 108 and switching server 140 may also include a transaction request processing module 806, an ensemble module 906, a data module 908, a collection module 910, a retraining module 912, a lookup module 914 (e.g.
  • the memory 1004 stores computer program code that the processor 1002 compiles to have each of the modules 806 to 912 perform their respective functions.
  • the transaction processing module 806 performs the function of communicating with the requestor device 102 and the provider device 104; and the acquirer server 106 and the issuer server 1 10 to respectively receive and transmit a request for insurance, as well as a transaction or travel request message. Further, the transaction processing module 806 may provide data and information associated with the request for insurance that are used for adaptively managing the request for insurance by the switching server 140, for example providing a confirmation that payment has been made for the request for insurance, providing data and information relating to the user making the request for insurance for underwriting purposes, or other similar types of data and information.
  • SLA module 914 underwriting module 906, insurance plan module 910, calculation module 912 and data module 908 as shown in Figure 11 function in the same manner as their counterparts described in Figure 10.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Human Resources & Organizations (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La présente divulgation concerne des procédés et des systèmes pour gérer de manière adaptative une demande d'assurance. Dans certains exemples, la divulgation concerne un procédé de gestion adaptative d'une demande d'assurance, consistant à : envoyer, par un serveur de commutation, la demande à un premier serveur d'une pluralité de serveurs de fournisseur de services ; déterminer, par le serveur de commutation, si une réponse est reçue en provenance du premier serveur de fournisseur de service de la pluralité de serveurs de fournisseur de service, et envoyer, par le serveur de commutation, la demande à un second serveur de fournisseur de service de la pluralité de serveurs de fournisseur de service sur la base de la détermination du fait qu'une réponse est reçue en provenance du premier serveur de fournisseur de service de la pluralité de serveurs de fournisseur de service.
PCT/SG2022/050908 2021-12-28 2022-12-15 Procédé et système de gestion adaptative d'une demande d'assurance WO2023128860A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
SG10202114441T 2021-12-28
SG10202114441T 2021-12-28

Publications (2)

Publication Number Publication Date
WO2023128860A2 true WO2023128860A2 (fr) 2023-07-06
WO2023128860A3 WO2023128860A3 (fr) 2023-08-03

Family

ID=87000405

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2022/050908 WO2023128860A2 (fr) 2021-12-28 2022-12-15 Procédé et système de gestion adaptative d'une demande d'assurance

Country Status (1)

Country Link
WO (1) WO2023128860A2 (fr)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8200231B2 (en) * 2004-12-22 2012-06-12 Metro Enterprises, Inc. Process for dynamic routing of customer contacts to service providers in real time
EP1915732A4 (fr) * 2005-08-01 2010-07-14 Volt Inf Sciences Inc Systeme et procede de gestion de fourniture d'une convention sur le niveau de service imparti
US20090276247A1 (en) * 2008-03-10 2009-11-05 Roger Glenn Howell Systems and methods for web-based group insurance/benefits procurement and/or administration
US20110054978A1 (en) * 2009-09-03 2011-03-03 Rakshat Singh Mohil Method and system for providing marketplace calendaring
US20130117048A1 (en) * 2011-11-09 2013-05-09 Branch Banking & Trust Company System and Method for Online Automobile Insurance Quoting
WO2018060988A1 (fr) * 2016-09-28 2018-04-05 Leadr - Leads Innovation Ltd Procédé de détection et de transfert de besoins dans une conversation

Also Published As

Publication number Publication date
WO2023128860A3 (fr) 2023-08-03

Similar Documents

Publication Publication Date Title
US11687914B2 (en) Processing mobile payments when disconnected from payment servers
US10937023B2 (en) Crypto currency chargeback system
US11763276B2 (en) Systems and methods for establishing message routing paths through a computer network
KR101947629B1 (ko) 거래 검증 방법 및 시스템
US20160335624A1 (en) Mobile device nfc-based detection and merchant payment system
US20220138732A1 (en) Systems, Methods, and Interfaces for Smart Contract Based Exchanges Via a Blockchain
US8856043B2 (en) Method and system for managing data and enabling payment transactions between multiple entities
KR20170123290A (ko) 전자 화폐 거래 시스템 및 방법
US20110225067A1 (en) Fraud prevention using customer and agent facing devices
US20180276656A1 (en) Instant issuance of virtual payment account card to digital wallet
JP6412648B2 (ja) 発行者の代理としてのオンラインカード保有者認証サービスの提供
US10783509B2 (en) Message sizing and serialization optimization
US20140032392A1 (en) Financing systems integration
CN109829811A (zh) 贷款方法和贷款装置
US20120079087A1 (en) Online help system using session details
WO2023128860A2 (fr) Procédé et système de gestion adaptative d'une demande d'assurance
KR20200094532A (ko) 블록체인 기반 가상 지점을 이용한 개인 대상 디지털 자산 서비스 제공 시스템 및 방법
US20180165647A1 (en) Multicomputer Processing of Client Device Request Data Using Centralized Event Orchestrator
US11386422B2 (en) Passive management of multiple digital tokens for an electronic transaction
US20190325438A1 (en) System and method for completing a transaction initiated at a payment terminal
KR102407330B1 (ko) 아이템거래중개방법 및 아이템거래중개시스템
US20240070677A1 (en) Aggregated transaction accounts
US20200265414A1 (en) Methods, systems and computer program products for split payment card account transactions
US20230351353A1 (en) Systems and methods for frictionless payments in web3 and the metaverse
US20200036775A1 (en) Multicomputer processing of client device request data using centralized event orchestrator and dynamic endpoint engine