US20150073838A1

US20150073838A1 - Systems and methods for purchasing insurance

Info

Publication number: US20150073838A1
Application number: US14/294,025
Authority: US
Inventors: Jamie Reid
Original assignee: Oferta Inc
Current assignee: Oferta Inc
Priority date: 2011-02-02
Filing date: 2014-06-02
Publication date: 2015-03-12
Also published as: US8744881B2; US20120197668A1

Abstract

Systems and methods related to an online website wherein businesses seeking insurance can obtain quotations and be connected to a plurality of insurance providers are described herein. In some embodiments, the businesses are authenticated and verified by providing such details as, e.g., employer identification number (EIN) or tax identification number (TIN), and being registered with the system prior to requesting quotations. In some embodiments, the system has an online collaboration system where a business can ask or post questions and receive answers from insurance providers or agents who match their search criteria.

Description

BACKGROUND

1. Technical Field
The embodiments described herein are related to an online website where businesses seeking insurance can obtain quotations and be connected to a plurality of insurance providers.
2. Related Art
In recent years, electronic commerce has become increasingly popular with consumers. In line with this trend, the ease of accessing and reviewing insurance information online, and the speed of electronic processing of data, has attracted consumers to insurance providers having an online presence.
Some insurance providers have set up electronic sites, such as Internet Web sites, that enabled consumers to locate agents of the insurance providers. Consumers providing address information to an insurance provider's Web site would in return receive information identifying the closest agents of the insurance provider that were qualified for the type of insurance the consumers were seeking.
As time progressed, insurance providers began providing quotation services via the Internet. Insurance providers would calculate an estimated cost of insurance based on brief questionnaires provided to consumers regarding the insurability of the consumers' property or business and the desired insurance. The quoted cost was typically accompanied by an invitation to the consumer to contact the insurance provider or one of its agents offline to pursue the insurance coverage.
Recognizing that consumers were increasingly willing to provide information needed for insurance coverage via the Internet, especially as transmission security improved, insurance providers began providing insurance application processes online in which consumers were given user friendly interfaces that enabled them to provide information required for an insurance application. However, certain deficiencies remain that prevent consumers from completing an insurance application process entirely online. For example, insurance providers may further require confirmation of a customer's identification. Additionally, in transactions requiring significant expense, the consumer may require confirmation of the agents' identification.
Thus, the embodiments described herein are directed to a method and system that address the foregoing needs and deficiencies and provides better processing of insurance applications online.

SUMMARY

Systems and methods related to an online website where businesses seeking insurance can obtain quotations and be connected to a plurality of insurance providers are described herein. In some embodiments, the businesses are authenticated and verified by providing such details as, e.g., employer identification number (EIN) or tax identification number (TIN), and being registered with the system prior to requesting quotations. In some embodiments, the system has an online collaboration system where a business can ask or post questions and receive answers from insurance providers or agents who match their search criteria.
According to one aspect, a system for allowing a business inquire about insurance, comprising: a communication interface; a data storage system configured to store registration information for a plurality of business and a plurality of agents; a server coupled with the data storage system and the communication interface, the server configured to: receive registration requests from a plurality of agents through the communication interface; validate agent license information from one or more of the agents; receive product information from the one or more agents having validated license information; receive a registration request from a business through the communication interface; validate tax identification information from the business; allow the business to create a request for information defining certain product information; filter the plurality of agents based on the product information each agent provided and based on the content of the business request for information to identify potential agents that meet requirements of the business inquiry; and allow the potential agents and the business to post one or more messages related to inquiring about insurance, respond to posts, and request information on a message board.
According to another aspect, a method for allowing a business inquire about insurance, comprising: receiving registration requests from a plurality of agents through a communication interface; validating agent license information from one or more of the agents; receiving product information from the one or more agents having validated license information; receiving a registration request from a business through the communication interface; validating tax identification information from the business; allowing the business to create a request for information defining certain product information; filtering the plurality of agents based on the product information each agent provided and based on the content of the business request for information to identify potential agents that meet requirements of the business inquiry; and allowing the potential agents and the business to post one or more messages related to inquiring about insurance, respond to posts, and request information on a message board.
These and other features, aspects, and embodiments are described below in the section entitled “Detailed Description.”

BRIEF DESCRIPTION OF THE DRAWINGS

Features, aspects, and embodiments are described in conjunction with the attached drawings, in which:

FIG. 1 is a high level block diagram representation of a collection of computer systems which can interact with each other by a connection in accordance with one embodiment;

FIG. 2 is a high level block diagram representation of the modules or functionality which can be implemented by the system 12 of FIG. 1;

FIG. 3 is a flowchart illustrating the process by which an insurance provider or agent becomes a trusted provider in accordance with one embodiment;

FIGS. 4-9 are exemplary screen shots the insurance provider navigates when becoming a trusted provider in accordance with one embodiment;

FIG. 10 is a flowchart illustrating the process by which a business user becomes a trusted user in accordance with one embodiment;

FIGS. 11-16 are exemplary screen shots the business user navigates when becoming a trusted user in accordance with one embodiment;

FIG. 17 is a flowchart illustrating the process by which an insurance provider or business user logs into an insurance matching website in accordance with one embodiment;

FIG. 18 is a typical computing system that may be employed to implement processing functionality in accordance with one embodiment;

FIGS. 19-21 are exemplary screen shots of a message or bulletin board in accordance with one embodiment; and

FIG. 22 is an exemplary flowchart illustrating the process by which a business user obtains a quote from an insurance agent in accordance with one embodiment.

DETAILED DESCRIPTION

After reading this description, it will become apparent to one skilled in the art how to implement the embodiments described herein as well as various alternative embodiments and alternative applications. The following description sets forth numerous specific details, such as examples of specific systems, components and methods in order to provide a good understanding of the several embodiments disclosed. It will be apparent to one skilled in the art, however, that at least some embodiments may be practiced without these specific details. In other instances, well-known components or methods are not described in detail or are presented in simple block diagram format in order to avoid unnecessarily obscuring the described embodiments. Particular implementations may vary from these exemplary details and still be contemplated to be within the spirit and scope of the embodiments described.
Described herein are systems and methods for online insurance quotations that allow authenticated businesses to communicate with insurance providers or agents who match their search criteria. Additionally, the systems and methods described herein provide an online collaboration system where a business can ask or post questions and receive answers from insurance providers or agents.
Turning now to FIG. 1, a block diagram representation of a collection of computer systems which can interact with each other by a connection, such as the Internet, local area networks, wide area networks, virtual private networks, and direct connections is shown. A network 100 is shown providing the connection between the devices in FIG. 1. Each of the blocks shown in FIG. 1 represents a computer system, such as a server, a personal computer or other devices capable of communicating over the connections, or a collection of such devices and are generally referred to herein as devices.
In general, block 10 represents a device of a user or member insurance provider or agent of the system. The device 10 can be any network device. In general, the device 10 is a machine with the ability to communicate with one or more of the computer systems depicted in FIG. 1. For example, in one embodiment, the device 10 is a personal computer with a network connection such as an Internet connection or a wireless device, such as a mobile telephone or a personal digital assistant, with access to a wireless network. Similarly, devices 14 and 16 can be the same types of devices as device 10. As shown, block 14 represents a device of a user or member business of the system and block 16 represents a device (e.g., a Web server) hosting an insurance matching website.
An insurance matching website, as used in connection with certain embodiments herein, relies upon a collection of insurance providers and business users for building an online community for shopping and purchasing various types of business-related insurance. Business-related insurance may include the following types: auto, directors and officers, general, professional, property (e.g., theft, fire), employee benefits (e.g., dental, medical, practice liability, worker's compensation), etc.
In general, the insurance matching service allows both insurance providers or agents and business users to create a profile for themselves. The profiles of the insurance providers and business users are generally kept private until a match is made based on a number of criteria. In some embodiments, once a match is made, it is presented to one or both of the business user and insurance agent in their respective accounts (e.g., dashboards) or emailed directly to them.
Referring back to FIG. 1, in one embodiment, device 16 represents an insurance matching site for requesting insurance bids and matching with insurance providers with business users. Device 16 provides (serves) Web pages which can be visited by business users (e.g., members) and others (e.g., guests) to interact with the system as will be described in more detail below.
According to one aspect, block 12 represents a computer system or device that provides the back-end functionality for the insurance matching site 16. System 12 is in communication with a database 80. Database 80 allows system 12 to store necessary information that system 12 may need to access for performing the back-end functionality. Of course, other configurations of computers can also be used.
In one example, system 12 supports an insurance website for matching insurance providers or agents with business users. The system 12 provides insurance verification and matching services that are Web based and can include, for example, a variety of ways for users to interact, including allowing a business user to request insurance quotations from one or more insurance providers and allowing a business user to post or ask questions on a message board. In some embodiments, the message board includes a public section and a private or semi-private section.
FIG. 2 shows a block diagram representation of the modules or functionality which can be implemented by the system 12. These modules may hereinafter collectively be referred to as “service matching functionality”. In one embodiment, the modules or functionality implemented by system 12 includes a login module 32, an administrative module 34, a provider matching module 36, a messaging module 38, and a content module 40. Unless otherwise apparent from the context, the operations and actions described in connection with FIGS. 3-17 are implemented by modules 32, 34, 36, 38, and 40 of system 12.
When an insurance provider or agent accesses the insurance site 16, he is presented with a default home page. The insurance provider or agent is invited to open an account or register, thereby becoming a trusted insurance provider. In general, the operations and actions described in connection with FIGS. 3-7 and 10-14 are implemented by login module 32 and administrative module 34.
According to one aspect, login module 32 provides the features and tools that allow a user to register for an account and access the account. As used herein, registration refers to the creation of the account. In one embodiment, using login module 32, an account administrator controls, restricts, or approves the user for an account. For example, in some embodiments, the administrator may deny access to a user that has already had an account and was delinquent with the account.
According to one aspect, administrative module 34 provides the features and tools that allow an administrator to manage various types of users and their access permissions. For example, using administrative module 34, the account administrator may limit the viewing access of the user. For example, there may be a plurality of types of users: authenticated (e.g., has created an account), guest (e.g., has not created an account), and administrator. In general, the authenticated users participate in the insurance agent-to-business user matching process and messaging services. In general, guests can see the home page of the website which may be mainly advertising. In some embodiments, guests cannot log in as a “guest” that is not authenticated/registered. The administrator can manage the content of the Web sites and also manages the various users (e.g., can create, edit, and delete user accounts).
Referring now to FIG. 3, an example process by which an insurance provider or agent becomes a trusted provider in accordance with one embodiment is shown. In a first step 110, the insurance agent chooses to initiate the process. The agent must then create an agent account, as shown in step 120. The agent can create an agent account by providing information such as shown in the fields in FIG. 4.
FIG. 4 represents an exemplary screen shot 200 of a new account registration for an agent. Screen shot 200 includes the following fields for entering the agent's information: First name 210, Last name 220, Company 230, Email 240, and Insurance License # 250. Screen shot 200 also includes an Agreement box 260 for agreeing to the terms of service, provided in subpane 270. Screenshot 200 also includes an Entry button 280 that the agent selects in order to create the agent account.
Referring back to FIG. 3, a validation step is performed in step 130 after the agent has entered the information requested in FIG. 4. For example, if a bad email address was entered by the agent, an error message is created in step 132 and provided to the agent. FIG. 5 shows such an exemplary error message 310, which recites “The entered Email is not valid. Please try again.”
If, in other embodiments, a bad insurance license number was entered by the agent, an error message is created in step 134 and provided to the agent. The error message may be similar to the one shown in FIG. 5, but recite language to the effect: “The Insurance License # is not valid. Please try again.”
If, in still other embodiments, the agent fails to check Agreement box 260, thereby agreeing to the terms of service, an error message is created in step 136 and provided to the agent. The error message may be similar to the one shown in FIG. 5, but recite language to the effect: “You must agree to the terms of service to create an account. Please try again.”
If the system determines in validation step 130 that the agent information provided is correct, a create agent account confirmation is provided to the agent in step 140. A temporary password email with a link is provided to the agent in step 150.
For example, FIG. 6 represents an exemplary screen shot 400 of a new agent account confirmation. For purely exemplary purposes, the screen shot 400 may recite the following: “Thank you for creating a new Agent account. An Email has been sent with your temporary password and instructions to view your account. Note: This email will provide a temporary password plus a link the to Temporary Password page.” It should be appreciated that the text of screen shot 400 may vary, with the intent to inform the agent that an account has been created.
FIG. 7 represents an exemplary screen shot 500 of the email confirmation, referred to in FIG. 6. For purely exemplary purposes, the screen shot 500 may recite the following: “Dear [FirstName, LastName], Thank you for creating an Agent account. Here is a temporary password. Password: [Password] Please visit [URL Link to Temporary_Password] to log into your account. Thanks, Oferta Customer Service”. It should be appreciated that the text of screen shot 500 may vary, with the intent to inform the agent that an account has been created and that the agent may use a temporary password to access the account.
Referring back to FIG. 3, once an agent tries to access his account using his temporary password in step 160, a validation step is performed in step 170. If the temporary password entered by the agent is not correct, an error message is created in step 172 and provided to the agent. The error message may be similar to the one shown in FIG. 5, but recite language to the effect: “The password is not valid. Please try again.”
If the validation step in step 170 determines that the temporary password provided is correct, the agent will be directed to the agent dashboard in step 180. An exemplary agent dashboard is provided in FIG. 8.
Referring to FIG. 8, a screen shot 600 is shown that provides the agent with user navigation information, as well as substantive information. For example, listed as part of the Top Navigation 610 is Dashboard 612, My Account 614, and Logout 616. Primary Navigation 620 includes Leads 622 and Proposals 624. Dashboard 612 is shown in further detail, including Leads 622 and Proposals 624 on the lower half of screen shot 600.
As used herein, a Lead is a request-for-insurance or a request-for-information (RFI) record that has been submitted by a business user and has not yet been accepted by the agent. In some embodiments, agents cannot see the details of the Lead until after it has been accepted. In general, a Lead will be the result of using a Lead Filter, which may use certain criteria, such as business type, state, minimum number of employees, etc., that the agent may use in determining the type of business users he wishes to do business with.
Back in agent user navigation, Secondary Navigation (Leads) 630 includes Dashboard 632, Suggested 634, Search 636, Accepted 638 and Returned 640. Secondary Navigation (Proposals) 650 includes Dashboard 652, Preparing 654, Submitted 656, Accepted 658, Declined 660 and Canceled 662.
Referring to FIG. 9, a screen shot 700 is provided that shows what an agent's personal account (e.g., My Account 614) can look like. As shown, the agent's personal information is provided in the fields, and the agent has the ability to click on other screens, including Dashboard 612, Logout 616, Lead 622 and Proposals 624.
As discussed above, system 12 supports an insurance website for matching insurance providers or agents with business users. Therefore, in addition to agents creating an account, a business user wishing to request a quote from one or more agents, must also create an account.
Referring now to FIG. 10, an example process by which a business becomes a trusted user in accordance with one embodiment is shown. In a first step 810, the business user chooses to initiate the process. The user must then create a business account, as shown in step 820. The user can create a business user account by providing information such as shown in the fields in FIG. 11.
FIG. 11 represents an exemplary screen shot 900 of a new account registration for a business user. Screen shot 900 includes the following fields for entering the business user's information: First name 910, Last name 920, Company 930, Email 940, and Federal Tax ID (EIN) 950. Screen shot 900 also includes an Agreement box 960 for agreeing to the terms of service, provided in subpane 970. Screenshot 900 also includes an Entry button 980 that the user selects in order to create the business user account.
Referring back to FIG. 10, a validation step is performed in step 830 after the user has entered the information requested in FIG. 11. For example, if a bad email address was entered by the user, an error message is created in step 832 and provided to the user. FIG. 12 shows such an exemplary error message 1010, which recites “The entered Email is not valid. Please try again.”
If, in other embodiments, the user fails to check Agreement box 960, thereby agreeing to the terms of service, and error message is created in step 834 and provided to the user. The error message may be similar to the one shown in FIG. 12, but recite language to the effect: “You must agree to the terms of service to create an account. Please try again.”
If, in still other embodiments, a bad Federal Tax ID (EIN) number was entered by the user, an error message is created in step 836 and provided to the user. The error message may be similar to the one shown in FIG. 12, but recite language to the effect: “The entered Federal Tax ID (EIN) number is not valid. Please try again.” Additionally, the user may be provided with a reminder to the effect: “Notes: The federal tax ID must be in a ##-####### (or 2 digits plus 7 digits separated by a dash)”.
If the validation step in step 830 determines that the business user information provided is correct, a create business account confirmation is provided to the user in step 840. A temporary password email with a link is provided to the user in step 850.
For example, FIG. 13 represents an exemplary screen shot 1100 of a new business account confirmation. For purely exemplary purposes, the screen shot 1100 may recite the following: “Thank you for creating a new Business account. An Email has been sent with your password and instructions to view your account. Note: This email will provide a temporary password plus a link the to Temporary Password page.” It should be appreciated that the text of screen shot 1100 may vary, with the intent to inform the user that an account has been created.
FIG. 14 represents an exemplary screen shot 1200 of the email confirmation, referred to in FIG. 13. For purely exemplary purposes, the screen shot 1200 may recite the following: “Dear [FirstName, LastName], Thank you for creating a Business account. Here is a temporary password. Password: [Password] Please visit [URL Link to Temporary_Password] to log into your account. Thanks, Oferta Customer Service”. It should be appreciated that the text of screen shot 1200 may vary, with the intent to inform the user that an account has been created and that the user may use a temporary password to access the account.
Referring back to FIG. 10, once a user tries to access his account using his temporary password in step 860, a validation step is performed in step 870. If the temporary password entered by the user is not correct, an error message is created in step 872 and provided to the user. The error message may be similar to the one shown in FIG. 12, but recite language to the effect: “The password is not valid. Please try again.”
If the validation step in step 870 determines that the temporary password provided is correct, the user will be directed to the business dashboard in step 880. An exemplary business dashboard is provided in FIG. 15.
Referring to FIG. 15, a screen shot 1300 is shown that provides the business with user navigation information, as well as substantive information. For example, listed as part of the Top Navigation 1310 is Dashboard 1312, My Account 1314, and Logout 1316. Primary Navigation 1320 includes RFI 1322. Dashboard 1312 is shown in further detail on the lower half of screen shot 600.
As used herein, a request-for-insurance or request-for-information (RFI) is a record that has been submitted by a business user with the goal of receiving an insurance quote from one or more agents. The RFI is merely a request, that has not been approved by an agent.
Back in business user navigation, Secondary Navigation (RFIs) 630 includes Dashboard 1332, Preparing 1334, Submitted 1336, Accepted 1338, Expired 1340 and Canceled 1342.
Referring to FIG. 16, a screen shot 1400 is provided that shows what a business's personal account (e.g., My Account 1314) can look like. As shown, the business' personal information is provided in the fields, and the business has the ability to click on other screens, including Dashboard 1312, Logout 1316, and RFI 1322.
Referring back to FIG. 2, once a business user logs into his account (e.g., by following the process shown in FIG. 8), the user will have access to request an insurance quotation by submitting an RFI. In general, the operations and actions described in connection with submitting an insurance quotation and being matched up with one or more insurance agents are implemented by provider matching module 36.
In some embodiments, the business user is given the option of selecting the number of agents the business user wants to bid on the submitted RFI. For example, in some embodiments, a minimum limit is pre-set or predesignated by matching module 36. In other embodiments, the business user is able to designate a minimum or maximum number of bidders able to respond to the RFI.
A general login flowchart is shown in FIG. 17 for matching a business with an agent according to one embodiment. For example, the process can begin when a business user or insurance agent initiates the process in a first step 1410. In the next step 1420, the user or agent attempts to login. The login is validated at step 1430 or the user or agent can request help (e.g., if they forget their password) in step 1422. If the login is invalid, the user can be allowed up to 3 invalid password entries in step 1450. If there are fewer than 3 invalid password entries, a login account error is provided to the user or agent in step 1452 and the user or agent begins the login process again in step 1420. If, however, there are more than, e.g., 3 invalid password entries, the password is emailed to the user or agent in step 1452. If it is determined that the user or agent has a valid account in step 1454, then the password confirmation is sent to the user or agent in step 1456. If it is determined that the user or agent has an invalid account in step 1454, then the user or agent is sent an email password account error in step 1458.
If the login is valid at as determined in step 1430, then it is determined if the user is an agent or business user in step 1440. If the user is an agent, the agent is sent to an agent dashboard in step 1460. Optionally, in some embodiments, the agent's payment profile can be validated in step 1445. For example, in one embodiment, validating an agent's payment profile means requiring the agent to register a credit card on file that validates their contact information is who they say they are. If the user is a business user, the user is sent to a business dashboard in step 1470.
According to one aspect, provider matching module 36 provides the features and tools that allow a user to create a request for an insurance quote in step 2202 as illustrated in the flowchart of FIG. 22. In some embodiments, provider matching module 36 provides a user a simple template to fill out in order to start a request for insurance. For example, as described above, a business user may desire to purchase any number of insurance benefits including theft, fire, group benefits, etc.
In response to the request of step 2202, module 36 can then filter the request in step 2204 based on various filtering agents (e.g., Lead Filter), and a number of matching insurance agents can be provided to the business user in step 2206.
The filtering agents can filter the request based on numerous criteria including geography; type of insurance being requested; amount of insurance needed; other preferences indicated by the business including that the provider be minority-owned, qualify as a small business, be based in a certain city or geography, etc.; as well as such factors as when was the last time an agent received a lead, how many active requests the agent is handling, the status of the agent with the system, etc.
As discussed above, the business user may be able to designate a minimum or maximum number of bidders able to respond to the RFI. In such embodiments, the matching module 36 distributes the leads (e.g., RFIs) to the designated number of agents in step 2208, e.g., with a message informing the agents that they have a certain time period (e.g., 1 hour) to accept the bid invitation. If the agents decline to accept the bid invitation or fail to respond, the matching module 36, can in some embodiments, send out more invites in step 2210 to other agents until the number of participants selected by the business user has been met. This preselection of the number of agents that are able to respond to the RFI has the benefit of preventing the business users from being “harassed” by an overwhelming number of agents; essentially by limiting the number of agents able to respond to an RFI, the business user is able to control the bidding process. Additionally, this preselection of the number of agents keeps the competitive landscape marginally or somewhat restricted so that agents are not continuously failing in the bidding process.
In step 2212, the selected agents can respond to the request. Often, an agent will need more information in order to provide an actual quote. Accordingly, a message board or collaboration area can be provided through which the business can share information with the selected agents in step 2214. At a certain point, the business may need to share information with individual agents separately.
Accordingly, in step 2216, private message boards or collaboration areas can be created on site 16 that link a business with a single agent. Accordingly, in addition to the “public” message board where all selected agents can post and access information, there can also be a plurality of “private” message boards where only one agent can access and post information in relation to a specific RFI.
Accordingly, in step 2218, some sort of credentialing or validation can occur in order to establish access to a private message board. Once the business has all the information necessary to make a decision, the business can select an agent in step 2220. The business and selected agent can then create, or continue to use a private message board to finalize the process in step 2222. In other words, the selected agent can get any additional information needed to finalize the offering.
Referring back to FIG. 2, messaging module 38 provides the features and tools that allow a business user to post questions or messages to an online bulletin-type, messaging board or collaboration area. For example, in one embodiment, the messaging board could appear similar to the dashboards shown in FIGS. 8 and 15. In some embodiments, messaging module 38 provides a user a simple template to fill out in order to ask or post a question to the messaging board. For example, FIGS. 19-21 show exemplary screen shots of a messaging board in accordance with some embodiments. As is apparent from FIGS. 19-21, the messaging board portion can be located on the lower region of the user's dashboard.
In some embodiments, the messaging module 38 allows a user to post questions, such as text messages to a messaging screen or a collaborative workspace. The user, in some embodiments, can download or upload information into the post. As noted, the post can be visible for all insurance agents to see or may be private or semi-private, such that only certain insurance agents can see the post or that the insurance agents appear anonymous. Also, in other embodiments, messaging module 38 may support one-to-one messaging (e.g., text or email) or one-to-many messaging.
Still referring to FIG. 2, content module 40 preferably manages the information for items posted on the messaging screen and for items (e.g., RFIs) submitted in the insurance matching/bidding process. As explained above, in one embodiment, the user enters the information necessary to request an insurance bid, for example, and the content module 40 stores and makes available the insurance bid to the Web site. In some embodiments, the content module 40 is responsible for determining when an insurance bid becomes available to insurance agents (e.g., when certain matching criteria have been met).
In some embodiments, content module 40 also manages the information submitted in becoming a registered business user or insurance agent, and in the purchasing of insurance. For example, content module 40 can perform the validation steps in determining if an insurance provider's Insurance License # is legitimate (e.g., by checking against a database) and if the business user's Federal Tax ID # (EIN) is legitimate (e.g., by checking against a database). In another example, content module 40 may manage the purchasing of insurance between the business user and an insurance agent by validating the insurance agent's payment profile.
FIG. 18 illustrates a typical computing system 1500 that can be employed to implement processing functionality required, e.g., by the embodiment described herein. For example, computing system 1500 of this type may be used in clients and servers. Those skilled in the relevant art will also recognize how to implement the embodiments using other computer systems or architectures. Computing system 1500 may represent, for example, a desktop, laptop or notebook computer, hand-held computing device (PDA, cell phone, palmtop, and the like), mainframe, server, client, or any other type of special or general purpose computing device as may be desirable or appropriate for a given application or environment. Computing system 1500 can include one or more processors, such as a processor 1504. Processor 1504 can be implemented using a general or special purpose processing engine such as, for example, a microprocessor, microcontroller or other control logic. In this example, processor 1504 is connected to a bus 1502 or other communication medium.
Computing system 1500 can also include a main memory 1508, such as random access memory (RAM) or other dynamic memory, for storing information and instructions to be executed by processor 1504. Main memory 1508 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 1504. Computing system 1500 may likewise include a read only memory (“ROM”) or other static storage device coupled to bus 1502 for storing static information and instructions for processor 1504.
The computing system 1500 may also include information storage system 1510, which may include, for example, a media drive 1512 and a removable storage interface 1520. The media drive 1512 may include a drive or other mechanism to support fixed or removable storage media, such as a hard disk drive, a floppy disk drive, a magnetic tape drive, an optical disk drive, a CD or DVD drive (R or RW), or other removable or fixed media drive. Storage media 1518 may include, for example, a hard disk, floppy disk, magnetic tape, optical disk, CD or DVD, or other fixed or removable medium that is read by and written to by media drive 1512. As these examples illustrate, the storage media 1518 may include a computer-readable storage medium having stored therein particular computer software or data.
In alternative embodiments, information storage devices 1510 may include other similar components for allowing computer programs or other instructions or data to be loaded into computing system 1500. Such components may include, for example, a removable storage unit 1522 and a storage unit interface 1520, such as a program cartridge and cartridge interface, a removable memory (for example, a flash memory or other removable memory module) and memory slot, and other removable storage units 1522 and interfaces 1520 that allow software and data to be transferred from the removable storage unit 1518 to computing system 1500.
Computing system 1500 can also include a communications interface 1524. Communications interface 1524 can be used to allow software and data to be transferred between computing system 1500 and external devices. Examples of communications interface 1524 can include a modem, a network interface (such as an Ethernet or other NIC card), a communications port (such as for example, a USB port), a PCMCIA slot and card, and the like. Software and data transferred via communications interface 1524 are provided via a channel 1528. Some examples of a channel include a phone line, a cellular phone link, an RF link, a network interface, a local or wide area network, and other communications channels 1528 to perform features or functions of embodiments of the invention. Note that the code may directly cause the processor to perform specified operations, be compiled to do so, and/or be combined with other software, hardware, and/or firmware elements (e.g., libraries for performing standard functions) to do so.
While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not of limitation. Likewise, the various diagrams may depict an example architectural or other configuration for the disclosure, which is done to aid in understanding the features and functionality that can be included in the disclosure. The disclosure is not restricted to the illustrated example architectures or configurations, but can be implemented using a variety of alternative architectures and configurations. Additionally, although the disclosure is described above in terms of various exemplary embodiments and implementations, it should be understood that the various features and functionality described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment with which they are described, but instead can be applied, alone or in some combination, to one or more of the other embodiments of the disclosure, whether or not such embodiments are described and whether or not such features are presented as being a part of a described embodiment. Thus the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments.
In this document, the term “module” as used herein, refers to software, firmware, hardware, and any combination of these elements for performing the associated functions described herein. Additionally, for purpose of discussion, the various modules are described as discrete modules; however, as would be apparent to one of ordinary skilled in the art, two or more modules may be combined to form a single module that performs the associated functions according to embodiments of the invention.
In this document, the terms “computer program product,” “computer-readable medium,” and the like may be used generally to refer to media such as, for example, memory 1508, storage devices 1510, or storage unit 1522. These and other forms of computer-readable media may be involved in storing one or more instructions for use by processor 1504 to cause the processor 1504 to perform specified operations. Such instructions, generally referred to as “computer program code” (which may be grouped in the form of computer programs or other groupings), when executed, enable the computing system.
It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processors or domains may be used without detracting from the embodiments described herein. For example, functionality illustrated to be performed by separate processors or controllers may be performed by the same processor or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
Terms and phrases used in this document, and variations thereof, unless otherwise expressly stated, should be construed as open ended as opposed to limiting. As examples of the foregoing: the term “including” should be read as mean “including, without limitation” or the like; the term “example” is used to provide exemplary instances of the item in discussion, not an exhaustive or limiting list thereof; and adjectives such as “conventional,” “traditional,” “normal,” “standard,” “known” and terms of similar meaning should not be construed as limiting the item described to a given time period or to an item available as of a given time, but instead should be read to encompass conventional, traditional, normal, or standard technologies that may be available or known now or at any time in the future. Likewise, a group of items linked with the conjunction “and” should not be read as requiring that each and every one of those items be present in the grouping, but rather should be read as “and/or” unless expressly stated otherwise. Similarly, a group of items linked with the conjunction “or” should not be read as requiring mutual exclusivity among that group, but rather should also be read as “and/or” unless expressly stated otherwise. Furthermore, although items, elements or components of the disclosure may be described or claimed in the singular, the plural is contemplated to be within the scope thereof unless limitation to the singular is explicitly stated. The presence of broadening words and phrases such as “one or more,” “at least,” “but not limited to,” or other like phrases in some instances shall not be read to mean that the narrower case is intended or required in instances where such broadening phrases may be absent.
Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the invention. It will be appreciated that, for clarity purposes, the above description has described embodiments of the invention with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processing logic elements or domains may be used without detracting from the embodiments described herein. For example, functionality illustrated to be performed by separate processing logic elements or controllers may be performed by the same processing logic element or controller. Hence, references to specific functional units are only to be seen as references to suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
Furthermore, although individually listed, a plurality of means, elements or method steps may be implemented by, for example, a single unit or processing logic element.

Claims

What is claimed:

1. A system for allowing a business inquire about insurance, comprising:

a communication interface;

a data storage system configured to store registration information for a plurality of business and a plurality of agents;

a server coupled with the data storage system and the communication interface, the server configured to:

receive registration requests from a plurality of agents through the communication interface;

validate agent license information from one or more of the agents;

receive product information from the one or more agents having validated license information;

receive a registration request from a business through the communication interface;

validate tax identification information from the business;

allow the business to create a request for information defining certain product information;

filter the plurality of agents based on the product information each agent provided and based on the content of the business request for information to identify potential agents that meet requirements of the business inquiry; and

allow the potential agents and the business to post one or more messages related to inquiring about insurance, respond to posts, and request information on a message board.