Patent Publication Number: US-9842370-B1

Title: Online benefit utilization

Description:
BACKGROUND 
     It has been reported that millions of Americans, aged 12 years and older, have visual impairment defined as distance visual acuity of 20/50 or worse. Among them, a significant percentage could improve their vision to 20/40 or better with eyeglasses or contacts. Among adults between the ages of 40-64 and 65+ that report having vision difficulties, approximately 58% and 77%, respectively, carry vision insurance. 
     Vision insurance typically comes in the form of either a vision benefits package or a discount vision plan. Typically, a vision benefits package provides eyewear within fixed dollar amounts and, in some cases, a co-pay each time a service is accessed or provided. A discount vision plan, on the other hand, provides eyewear at discounted rates. In some cases, a vision benefits package or discount vision plan may also include an out-of-pocket deductible before the insurance benefits take effect. Vision insurance can be custom-designed to meet the needs of a wide ranging population, including school districts, unions, and big and small companies. Insurance plans are as diverse as the patient population carrying such plans. 
     After an eye-exam, a patient carrying vision insurance must typically visit, select, and order his or her eyeglass frames, lenses, or contacts from a brick and mortar store. This inconvenient process must generally be completed in order for a patient to make an insurance claim and utilize any vision insurance benefits. Making an insurance claim and utilizing vision insurance benefits quickly becomes a time consuming process. In addition to traveling to the brick and mortar store, the patient must select the desired eyewear from a limited number of frames displayed on the store&#39;s shelves. The patient then requires the assistance of a store employee or doctor to determine whether vision insurance benefits are available, or the type of benefits available, for the selected frame and any potential lenses, coatings, or accessories. This lengthy process is then repeated each time a different pair of eyeglass frames are selected, thereby affecting the patient&#39;s buying experience. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings are incorporated herein and form a part of the specification. 
         FIG. 1  is an example block diagram illustrating the multiple systems of respective entities involved in providing and maintaining an online insurance benefit utilization system, according to an example embodiment. 
         FIG. 2  is a sequence diagram illustrating a process for an online insurance benefit utilization system across multiple systems in order to utilize an initial insurance benefit, according to an example embodiment. 
         FIG. 3  is a sequence diagram illustrating a process for an online insurance benefit utilization system in order to utilize insurance benefits for additional options and accessories, according to an example embodiment. 
         FIG. 4  is a flowchart illustrating steps for online insurance benefit utilization across multiple systems in order to process and authenticate a user&#39;s login information, according to an example embodiment. 
         FIG. 5  is a flowchart illustrating steps for online insurance benefit utilization across multiple systems in order to obtain or generate a benefits table, according to an example embodiment. 
         FIG. 6  is a flowchart illustrating steps for online insurance benefit utilization across multiple systems in order to normalize product identification numbers and map the normalized identification numbers to that of an insurance database, according to an example embodiment. 
         FIGS. 7-11  illustrate example implementations of webpages for an insurance benefit utilization system, according to example embodiments. 
         FIG. 12  is an example block diagram illustrating a process for submitting, tracking, and utilizing an insurance benefit claim, according to an example embodiment. 
         FIG. 13  is a sequence diagram illustrating a process for an online insurance benefit utilization system across multiple systems in order to utilize an initial insurance benefit for eyewear having a single price, according to an example embodiment. 
         FIG. 14  is another sequence diagram illustrating a process for an online insurance benefit utilization system across multiple systems in order to utilize an initial insurance benefit for eyewear having a single price, according to an example embodiment. 
         FIGS. 15-18  illustrate example implementations of webpages for an insurance benefit utilization system, according to example embodiments. 
     
    
    
     In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears. 
     DETAILED DESCRIPTION 
     Currently, there are a number of e-commerce websites that offer eyewear. But integrating vision insurance within an e-commerce solution provides numerous challenges. Such challenges include: creating a user-specific experience that reaches beyond the scope of a physical retailer; creating a solution that allows the customer to view an estimated price based on his or her own insurance benefits, in real time, thus allowing members to make more educated purchasing decisions before submitting a claim; preemptively addressing questions that a patient may have during the buying process, including itemized charges and claim totals for individual services; and providing sufficient online security to meet HIPAA regulations. 
     The present disclosure provides solutions for these problems. Provided herein are system, method, and/or computer program product embodiments, and/or combinations and sub-combinations thereof, for providing an enhanced user experience by efficiently accessing and applying insurance benefit data associated with a specific user. Embodiments may also include system, method, and/or computer program products stored in databases across multiple entities including a system server, an eyewear vendor, and an insurance company. 
       FIG. 1  illustrates a linked insurance benefit utilization system  100  for providing and maintaining access to data stored across multiple entities, according to an embodiment. Insurance benefit utilization system  100  includes network  112 , user interface  102  operated by an insured user, system server  104 , products database  106 , members database  108 , and insurance database  110 . Each of the systems, databases, and/or computers may be implemented using one or more processors and/or one or more data storage locations. Although the systems are depicted as remote systems connected via network  112 , one or more systems or databases may be operated by and/or maintained by one entity. For example, system server  104 , products database  106 , members database  108 , and insurance database  110  may be part of a single system operated by one entity. Additional configurations are also contemplated where any one entity may operate one or more of the system server  104 , products database  106 , members database  108 , and insurance database  110 . As used herein, an entity may include a processor, server, a network owner, an insurance company, an eyewear provider, a webhost, an individual, or an organization. Additionally, the term “user interface,” as used herein, may include any hardware or software with which a human may interact—including a display screen, touchscreen, keyboard, mouse, the appearance of a desktop, illuminated characters, and an application program or website with which a user may interact. The user interface may be a computer, laptop, tablet, smartphone, a mobile computing device, or any other device capable of rendering and displaying an electronic communication. 
     Network  112  may enable system server  104  to communicate, i.e. send and receive, data among the multiple systems, including: user interface  102 , products database  106 , members database  108 , and insurance database  110 . In an embodiment, user interface  102  may communicate with, view, or access product and insurance information stored on any of the entities connected to network  102 . Further, network  102  may include the Internet and may therefore be operable to communicate via TCP/IP, HTTP, or any other Internet protocol. Additionally, network  102  may be an enterprise wide area network (WAN) utilizing Ethernet communications, although other wired and/or wireless communication techniques and technologies may be used. 
     In an embodiment, a computer system may be used to implement aspects of the systems and may be specially programmed to implement aspects of the processes illustrated in  FIGS. 2-11 . The contemplated computer system may include one or more processors (also called central processing units, or CPUs). The processor may connect to a communication infrastructure or bus. 
     One or more processors may each be a graphics processing unit (GPU). In an embodiment, a GPU is a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, or any other intensive processing needs. 
     The contemplated computer system may also include user input/output device(s), such as monitors, keyboards, touchscreens, pointing devices, etc., that communicate with communication infrastructure through user input/output interface(s). 
     The contemplated computer system may also include a main or primary memory, such as random access memory (RAM). The disclosed main memory may include one or more levels of cache and may store therein control logic (i.e., computer software) and/or data. 
     The contemplated computer system may also include one or more secondary storage devices or memory. The secondary memory may include, for example, a hard disk drive and/or a removable storage device or drive. The removable storage drive may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive. 
     Further, the removable storage drive may interact with a removable storage unit, which includes a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. The contemplated removable storage unit may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/any other computer data storage device. Accordingly, the removable storage drive may read from and/or write to the removable storage unit in a well-known manner. 
     According to an example embodiment, a secondary memory may include other means, instrumentalities, or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by the computer system. Such means, instrumentalities, or other approaches may include, for example, a removable storage unit and an interface. Examples of the removable storage unit and the interface may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface. 
     The contemplated computer system may further include a communication or network interface. The communication interface enables the computer system to communicate and interact with any combination of remote devices, remote networks, remote entities, etc. For example, the communication interface may allow the computer system to communicate with remote devices or databases over a communications path, which may be wired and/or wireless, and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from the computer system via the communication path. 
     In an embodiment, a tangible apparatus or article of manufacture comprising a tangible computer useable or readable medium having control logic (software) stored thereon is also referred to herein as a computer program product or program storage device. This includes, but is not limited to, the computer system, main memory, secondary memory, and removable storage units, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as the computer system), causes such data processing devices to operate as described herein. 
     Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of the present disclosure using data processing devices, computer systems, memory systems, databases, and/or computer architectures. In particular, embodiments may operate with software, hardware, and/or operating system implementations other than those described herein. 
     Throughout this disclosure various methods are described wherein one or more entities sends/receives electronic data. Some embodiments may describe one entity transmitting data while another entity receives the data. It is also contemplated herein that the receiving entity may also initiate a transaction by polling and/or pulling the necessary data. Thus, the terms transmitting and receiving are not meant to limit the functionality of either entity. 
     Contemplated herein are processes for providing more accurate pricing and option information to an online user by determining and utilizing insurance benefits for all types of eyewear. As contemplated herein, eyewear products may include any items or accessories worn on or over the eyes, for fashion or adornment, protection against the environment, and to improve or enhance visual acuity. For example, eyewear products may include eyeglasses, frames, contact lenses (“contacts”), sunglasses, safety glasses, or goggles. In some embodiments, the disclosed insurance benefit utilization system may provide a benefit utilization process for eyewear having multiple options or accessories, as depicted and described in  FIGS. 2-11 . In additional embodiments, the disclosed insurance benefit utilization system may provide a benefit utilization process for eyewear having a single product price, as depicted and described in  FIGS. 13-17 . In some situations, the disclosed insurance benefit utilization system may determine, dynamically, which type of product the user needs or requires, causing the system to adjust or modify the required benefit utilization process. While one or more exemplary embodiments are disclosed for eyewear products having multiple options or accessories as well as eyewear having a single price, it should be noted that steps and principles may be shared between them. For example, when a step is described for utilizing an insurance benefit for eyewear having a single price, that step is not exclusively limited to products having a single price. Rather, any and all steps may be performed for either type of eyewear product and in any conceivable order or flow, unless explicitly stated to the contrary. Additionally, any and all of these steps may be performed in real-time, such as while the user is browsing through available products. More specifically, as the user/system performs the aforementioned steps, the pricing and options information may be updated to reflect the user&#39;s insurance benefit information, in real-time. 
       FIG. 2  illustrates an initial insurance benefit utilization process  200  for determining an available insurance benefit and/or claim generally provided as a monetary amount, according to an example embodiment. The multiple systems/databases may include user interface  202 , system server  204 , products database  206 , members database  208 , and insurance database  210 . Process  200  may be performed by processing logic that may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executable on the system server, at the user interface, or another processing device), or a combination thereof. It is not required that the steps depicted in  FIG. 2  be performed in the exact order shown, as one skilled in the art would understand. In an embodiment, initial insurance benefit utilization process  200  may be adjusted to enable updating information in any one of the databases associated with the user. Additionally, user interface  202  may provide administrative privileges, not shown, wherein a system administrator may access, modify, create, or duplicate the data. A system administrator may also perform other administrative functions in the databases and with the data stored therein, as one skilled in the art would understand. 
     In step  220 , when a user initially accesses a website associated with the insurance benefits utilization system, the products service component of system server  204  sends a products and pricing request to products database  206 . At step  222 , the products database sends the initial products and pricing information for a variety of eyewear products to the user interface. It is also contemplated that products database  206  may send the initial products and pricing information to system server  204 , before, after, or at the same time step  222  is completed. As contemplated herein, eyewear products may include any items or accessories worn on or over the eyes, for fashion or adornment, protection against the environment, and to improve or enhance visual acuity. For example, eyewear products may include eyeglasses, frames, contact lenses, sunglasses, safety glasses, or goggles. 
     Upon receiving the eyewear product and pricing information, the user interface may, at step  224 , render and display the product and pricing information. As depicted in  FIGS. 7-11  described below, the user interface may render and display the information on a webpage. In other embodiments the user interface may render and display the information using a web application, a mobile application, or any other means whereby a user may interact with data through an electronic device. 
     The user may be prompted by the user interface to provide his or her login information. To login, the user must provide a sufficient amount of personal information so the system may associate the user with his or her specific vision insurance plan. Accordingly the system may prompt the user for personal information, including: first and last name, address, date of birth, zip code, portions of his or her social security number (SSN), insurance group identification, insurance member identification, password, and/or any other identifying personal identification. At step  226  the user&#39;s login information is transmitted from the user interface to the system server. 
     Upon receiving the login information, the system server generates a member token at step  228 . As used herein, a member token is an identification used within the benefit utilization system to uniquely identify each member. The member token may act as a primary key used within the benefit utilization system, namely within system server  204 , member database  208 , and insurance database  210  to track and maintain the member&#39;s identifying information throughout the data schema. 
     At step  230 , the member token is passed from system server  204  to member database  208  in order to verify and authenticate the user&#39;s identity as an insurance member. This step may be completed using a system call to a getEligibility( ) application program interface (API) provided at system server  204 . 
     APIs such as the getEligibility( ) API and other similar APIs disclosed herein, may be developed in order to provide developers an easier and more efficient method for interfacing with external databases and systems. For example, if an insurance provider maintains its database in an AS400 system, the insurance provider may offer one or more external facing APIs to allow external applications to perform a variety of functions necessary for servicing an insurance order or claim. 
     In steps  232 ,  234 , and as illustrated in  FIG. 4 , described below, either member database  208  or insurance database  210  may verify and authenticate the user&#39;s member token. Steps  236  and  238  depict signals transmitted from the member and insurance databases to indicate that the member token is verified, i.e., that the user is an insured member. If, however, the user provided incorrect or insufficient identification information, the signal passed in steps  236  and  238  will indicate a failed verification and authentication. The verification and authentication result is sent to the user interface at step  204  and the result is rendered and displayed at step  242 . If the verification and authentication failed, the user may be provided with additional opportunities to correct or modify the entered login information. Alternatively, the user may be prompted to call or otherwise contact his or her insurance provider to remedy any errors, inconsistencies, or any other deficiencies that may prevent the user from verifying and authenticating his or her insurance membership. 
     Based on the verified and authenticated member token, the benefit component  244  of system server  204  may request member insurance benefit information from the member and insurance databases, respectively, shown at step  246 . As shown, the member insurance benefit information is requested from the respective databases in series. However, the request may alternatively be made in parallel. Further, the benefit component may request the member insurance benefit information exclusively from either the member database or the insurance database. Step  246  may be carried out by making one or more real-time system calls to a getBenefits( ) API. 
     Steps  248  and  250  retrieve and/or generate a benefits table populated with the user&#39;s vision insurance benefit information. In accordance with the present disclosure, a table may be generated according to one of several formats. For example, the table may be an HTML, table, a SQL table, a spreadsheet, a database table, a CSV file, a metadata file, or any other table or file commonly used to distribute categorized data. 
     At step  254 , the benefits table is transmitted from member database  208  to system server  204 . Upon receiving the benefits table, extractor  256  parses the data stored within the benefits table and collects specific insurance benefit information. For example, the extractor may collect data such as: an allowance amount, i.e., an amount that may be applied to any qualifying eyewear product; a discount value which is a percentage that may be deducted from the eyewear product price after the allowance amount has been deducted; or any other insurance benefit information specific to the member&#39;s insurance policy that may be necessary to determine and process an insurance claim. Additional information may include the date(s) of the user&#39;s most recent insurance claims, qualifying eyewear products, qualifying eyewear manufacturers and/or brands, employer-employee incentive program information, or any other user-specific discount information. 
     Upon parsing and collecting the information, system server  204  may retrieve the pricing information from products database  206  through steps  258  and  260 . In some embodiments, the pricing information may have already been sent from products database  206  to system server  204 , as described above with respect to step  222 . After system server  204  receives the initial products and pricing information, the system server then applies the insurance benefit information to the initial eyewear product and pricing information, as will be described further below. The resulting updated product prices are transmitted to the user interface at step  264 , and are rendered at the user interface at display  266 . In some embodiments, the updated price may be rendered and displayed on a new webpage or application page in a position next to or near the initial product price, so the user may compare the initial and updated prices. Alternatively, a scripting language may be used to replace the initial price with the updated price without posting back the entire page. 
     In an embodiment, process  200  may further include one or more retail integration adapters (RIA)  203 . In such embodiments, MA  203  may be implemented as a connectivity layer between user interface  202  and system server  204 , products database  206 , member database  208 , and/or insurance database  210 . The MA may provide additional point of sale functionality to a front-end user at the user interface. The RIA may additionally, or alternatively, provide functionality on the backend at either the system server, products database, member database, and/or insurance database. 
     In embodiments where multiple products databases, multiple member databases, and/or multiple insurance databases are being used, an RIA may be implemented to ensure data integrity and/or data security between the databases. In an instance where multiple insurance databases have been implemented, i.e., insurance database X (“IDBX”) and insurance database Y (“IDBY”), the RIA will provide access to, and communicate with, either IDBX or IDBY based on the characteristics of user interface  202 , the specific user, and/or input received at the user interface. For example, if the user interface is associated with, controlled by, or owned by entity X, the RIA may ensure data integrity and/or data security by facilitating data interactions between entity X users and IDBX and/or other databases associated with entity X. The RIA may additionally block entity X users from accessing IDBY and/or other databases associated with entity Y. In this manner, the RIA controls and facilitates the data interactions between system components. In an embodiment, the RIA will ensure that user interface  202  can only communicate with system servers, products databases, member databases, and insurance databases that it has permission to communicate with. Also, many companies may have their own access or communications protocols for systems wishing to access their data. The RIA may provide a consistent interface between the user interface/front end and databases operating under disparate protocols, storage structures, and/or communications requirements. In other words, the MA translates between the front end and, for example, disparate insurance databases that each have their own storage structure and protocol. 
     The RIA may be implemented using a plurality of communication protocols based on the specific design characteristics of the system. For example, the MA may be implemented over the Internet and may therefore be operable to communicate via TCP/IP, HTTP, or any other Internet protocol. Additionally, the RIA may be implemented on an enterprise wide area network (WAN) utilizing Ethernet communications, although other wired and/or wireless communication techniques and technologies may be used. 
       FIG. 3  illustrates an eyewear options insurance benefit utilization process  300  for determining an insurance benefit and/or claim as it relates to various eyewear options and accessories corresponding to a user-selected eyewear product, according to an example embodiment. The multiple systems/databases may include user interface  302 , system server  304 , products database  306 , members database  308 , and insurance database  310 . Eyewear options insurance benefit utilization process  300  may be performed by processing logic that may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executable on the system server, at the user interface, or another processing device), or a combination thereof. The steps in  FIG. 3  need not be performed in the exact order shown, as one skilled in the art would understand. Process  300  may be adjusted to enable updating information in any one of the databases associated with the user. Additionally, user interface  302  may provide administrative privileges wherein a system administrator may access, modify, create, and/or duplicate data. The administrator may also perform other administrative functions in the databases and with the data stored therein. As depicted in  FIG. 3 , the system comprises the same entities illustrated in  FIG. 2  and described above. It is contemplated herein that the eyewear options insurance benefit utilization process  300  may use the same or different processors and databases than those of the system illustrated in  FIG. 2 . Additionally, processors and databases may be operated by the same or different entities, as/than those illustrated in  FIG. 2 . Process  300  may further include an RIA. In process  300 , the RIA may be implemented as a connectivity layer between user interface  302  and system server  304 , products database  306 , member database  308 , and/or insurance database  310 , thereby facilitating data communications between the system components using the functionality described above. 
     It is known in the art that there are hundreds, if not thousands, of different eye and vision conditions, disorders, and diseases. Each condition may present a number of problems and an even larger number of solutions. Various forms of eyewear have been developed to help correct many of the eye and vision conditions. In order to meet the needs of its members, insurance companies have ranges of benefits for each eyewear solution, thereby presenting a challenge for software developers to provide a system capable of providing real-time benefits analysis and real-time discounts based on each user&#39;s individual insurance plan. 
     Eyewear options insurance benefit utilization process  300  determines insurance benefits in real-time, while the user mixes and matches compatible options and accessories for the selected eyewear. For example, at step  368  the user may interact with user interface  302  to select a pair of eyeglass frames from a previously provided list of eyewear products. That list may have included user-specific prices based on the user&#39;s insurance benefits, as described with respect to  FIG. 2 . User specific prices may be calculated by subtracting the user&#39;s allowance and any additional discounts from the original retail price of a selected product. The remaining amount is the user-specific price, or the price that the user will have to pay for the product after the user&#39;s vision insurance benefits have been applied (also referred to as the “out-of-pocket” price). At step  370 , the user&#39;s selection is transmitted to system server  304  and then to products database at step  372 . Based on the user&#39;s selection, products database  306  provides additional eyewear specifications at user interface  302 , which renders and displays the compatible options at display  375 . As mentioned above, in some embodiments the display may include a webpage, a web application, a mobile app, or another means by which a user may interact with the eyewear product information. Additional eyewear specifications include product size, weight, color(s), lens shape, style, manufacturer, accessories, user reviews, or other information that may assist the user&#39;s decision making process. Also included at step  374  and rendered in display  375  are any available options compatible with the selected eyewear. Compatible options include lens types, such as single vision, bi-focal, tri-focal, or progressive lenses; lens shapes, including round, square, oval, etc.; lens materials such as CR-39, polycarbonate, or high-index materials; lens coatings, including anti-reflection, anti-glare, or anti-smudge coatings; lens transitions; and more. 
     At step  376 , the products database provides the available options to pre-processing mapping layer  378  of the system server. 
     As mentioned above, insurance companies maintain ranges of benefits for the vast number of eyewear solutions. As a result, insurance companies generally maintain complex databases populated with identification numbers compatible with their respective data schema. Likewise eyewear providers generally maintain their own databases using their own identification numbers, also known as stock keeping units (SKUs), in a format that is compatible with their respective data schema. Because the identification numbers used by the insurance company to identify an eyewear product/solution are often different than those of an eyewear provider, the respective identification numbers must be normalized. 
     The eyewear options insurance benefit utilization process  300  provides a normalization process at pre-processing mapping layer  378 . Upon receiving the available options from the products database, the pre-processing mapping layer translates and normalizes the eyewear provider&#39;s product ID, SKU numbers, and product information, then maps the translated/normalized information to the corresponding ID, SKU, and information in the insurance database. 
     When a user is exploring the various options for his or her lenses, it can be time-consuming and inefficient for the system to make individual pricing calls only when a particular option is selected. Embodiments of the present invention overcome this inefficiency by pre-populating that information in the system, such that it can automatically be incorporated into the price—in real time and without delay—as a user explores and selects various combinations of options. As shown at step  380 , the pre-processing mapping layer makes one call to the insurance database, including the translated, normalized, and mapped identification numbers therein. Step  380  may be carried out by making one or more real-time system calls to a getPricing( ) API, for each possible option compatible with the specifications and frame selection chosen by the user. In response to the pre-processing mapping layer call, insurance database  310  provides benefit and pricing information for each of the compatible options 1-n in batch form, at step  382 . The compatible options include a plurality of alternative options, such as whether or not a particular coating is applied, or a variety of different coatings. At step  386 , upon receiving the benefit and pricing information for each of the compatible options, system server  304  creates and stores a data file or quote containing the retrieved pricing information. Accordingly, when the user selects one of the displayed available options at step  384 , user interface  302  transmits the selected option to the system server at step  388 . Using the stored quote, the system server may quickly and efficiently respond by transmitting the pricing information for the user selected option at step  390 . In order to provide more efficient quote information, at step  392 , the system server may cache, or store, the quoted pricing information in the user database along with the associated member token. Storing the quoted pricing information in member database  308  for all potential options provides a more efficient method for retrieving benefit pricing information. 
     At step  394 , the system server applies the final benefit amount to the price of the selected eyewear. As used herein, the final benefit amount is calculated based upon the user selected options combined with the allowances and discounts described above. For example, the final benefit amount may be calculated by subtracting the user&#39;s allowance and additional discounts from the original retail price of a selected product. Any additional discounts, including discounts for selected options compatible with the selected eyewear as mentioned above, may also be subtracted from the original retail price. The remaining amount is an out-of-pocket price, or the price that the user will have to pay for the product and the selected components after the user&#39;s vision insurance benefits have been applied. The resulting final out-of-pocket price is rendered and displayed at the user interface at display  396 . 
     As mentioned above, verifying and authenticating a member token associated with a user is one of the first steps in the disclosed insurance benefit utilization system. Generally, when interacting with an ecommerce website, a username, password, and other basic account information is maintained by the ecommerce provider. However, in 1996, U.S. Congress passed the Health Insurance Portability and Accountability Act of 1996 (HIPAA). The HIPAA Privacy Rule provides federal protections for individually identifiable health information held by covered entities and their business associates and gives patients an array of rights with respect to that information. At the same time, the Privacy Rule is balanced so that it permits the disclosure of health information needed for patient care and other important purposes. The Security Rule specifies a series of administrative, physical, and technical safeguards for covered entities and their business associates to use to assure the confidentiality, integrity, and availability of electronic protected health information. Accordingly, vision insurance providers are required by law to safeguard the health information of its insured members, only permitting a limited disclosure of health information needed for patient care. As provided by the disclosed insurance benefit utilization system, the system server may retrieve a limited amount of health information associated with a member token directly from the insurance database. However, requiring a direct link to the insurance database presents a significant problem. 
     As is known in the art, insurance database systems generally shut down at night for claim processing and database maintenance. Yet, most e-commerce shoppers do their online shopping at night during non-working hours. Thus, when the disclosed insurance benefit utilization system encounters its peak web traffic, and when it needs a direct link to the insurance database the most, the insurance platform/database may be down for claim processing and maintenance. In order to overcome this obstacle, the disclosed insurance benefit utilization system further includes a member database wherein member information may be cached or stored outside the insurance platform/database, and wherein the storage remains compliant with HIPAA regulations. For example, the current disclosure provides a HIPAA compliant storage solution whereby the system server caches, or stores, the quoted pricing information in the user database along with the associated member token. 
     The member database may store a member token, quoted pricing information, and a limited amount of health information so as to remain compliant with the HIPAA regulations. Additionally, the system may further provide an encoder, a decoder, an encryptor, and a decryptor in order to encode/decode and encrypt/decrypt, respectively, and thereby add another layer of security using conventional security methods. In an exemplary embodiment, the member database functions similar to a first-in-first-out (FIFO) queue, wherein the oldest data, or ‘head’ of the queue, is removed from the queue when the member database has reached its capacity. For example, consider an embodiment where the member database may store information for a maximum number of users, for example 1,000 users. When the member database is already at capacity and another entry is added to the database, the oldest entry is removed. Examples for how the system accounts for the first-in-first-out nature of the member database are provided in  FIGS. 4 and 5 . Additional steps may be taken to ensure data security such as providing an account time-out after a certain period of time, wherein the user may be prompted to again provide his or her login information. It is also contemplated that the system can save the information for an unlimited number of customers without requiring a limiting queue process. For example, if a user owns a membership to an online eyewear provider and has vision insurance through a third party insurance provider, it is contemplated that the eyewear provider may sync and store information for each of membership information, personal information, and insurance information, providing a more efficient process without encountering service disruptions caused by the insurance database shutting down for claim processing and database maintenance. 
       FIG. 4  provides an exemplary method for verifying or authenticating a user based on a member token previously generated by the system server. At step  430 , member database  408  receives a request to authenticate a member token. At step  433 A, the database determines whether or not the member token is stored thereon. If the received member token matches that of a cached entry, the member is authenticated at step  438  and additional processing is avoided. If, however, the received member token does not match that of a cached entry, at step  433 B the token is transmitted from the member database to insurance database  410 . At step  235 A, the insurance database determines whether the member token matches that of an insured member. If not, the authentication is denied at step  235 B. If the member token does match that of an insured member, the authentication is confirmed at step  438  and the disclosed insurance benefit utilization system proceeds to the next step. 
       FIG. 5  illustrates an exemplary embodiment for retrieving/obtaining the benefits table introduced above. At step  544 , the benefit component of the system server transmits a request to the member database with an accompanying member token. At step  546 , the member database receives the request and at step  547 A determines whether the requested benefits table is stored within the member database. If the member token matches that of a cached entry, the benefits table is retrieved at step  549  and is transmitted to the benefits component at step  554 . Upon receiving the benefits table, the system server&#39;s extractor may be configured to parse the information stored within the benefits table and extract the information, values, and insurance benefits relevant to the disclosed insurance benefit utilization system, as shown at step  556  and as discussed above. If, at step  547 A, it is found that the member token does not match that of a cached entry, the member token and request for a benefits table is transmitted from the member database and received by the insurance database. Upon receiving the member token and request for a benefits table associated therewith, the insurance database may generate a benefits table populated with the vision insurance benefit information associated with the member token. The generated benefits table is then transmitted to the benefits component at step  554  where the extractor may be configured to parse and extract the information, values, and insurance benefits relevant to the disclosed insurance benefit utilization system as discussed above. 
     As illustrated in  FIG. 5 , the request for a benefit table is completed among the member and insurance databases in series. However, it is also contemplated that the request may be made in parallel. Further, based on the data schema of the system, the benefit component may request the benefits table exclusively from either the member database or the insurance database, respectively. In an embodiment, the member token and request for benefit information may be carried out by making one or more real-time system calls to a getBenefits( ) API. 
     With limited guidance regarding out-of-pocket expenses, a customer visiting a brick-and-mortar store must also select prescription type, lens options, and additional upgrades without understanding how the user-specific insurance benefits will be applied to his or her order.  FIG. 6  provides a step-by-step description of an exemplary embodiment for retrieving pricing information for compatible options for a selected eyewear product, so that the e-commerce user can see the effects of such selections in real-time. Such an embodiment may be used for steps  376 ,  380 ,  382 , and  386  as described above with respect to  FIG. 3 . As mentioned above, because the identification numbers used by the insurance company to identify an eyewear product/solution are often different than those of an eyewear provider, the respective identification numbers must be normalized. In an embodiment, pre-processing mapping layer  678  performs this normalization process. At step  676 , the pre-processing mapping layer receives the options that are compatible with a particular eyewear product. Upon receiving the options, the pre-processing mapping layer determines the number of compatible options at step  677 A, normalizes the option IDs or SKUs at step  677 B, and maps them to corresponding IDs or SKUs found in the insurance database at step  677 C. If the number of compatible options is equal to zero, as determined at step  677 D, the pre-processing mapping component creates and stores, at step  686 , a data file or quote containing any retrieved pricing information, such as a user&#39;s insurance allowance or other discount information. If step  677 D reveals that the number of compatible options is greater than zero, pre-processing mapping layer  678  makes one call to insurance database  610 , wherein the call includes the translated, normalized, and mapped identification numbers as depicted at step  680 . Upon receiving the normalized compatible option IDs or SKUs, the insurance database determines the pricing information for each option based on the user&#39;s specific insurance benefit information, as per step  681 . The insurance database may then transmit the pricing information for each compatible option individually, at steps  382 A-N. It is also contemplated that the pricing information for each compatible option may be transmitted in a single batch, where the pre-processing mapping layer or system server may then parse the received batch and store the pricing information, or quote, in memory in step  686 . The retrieved compatible option pricing information may be rendered and displayed at user interface  602  in step  696 . 
     As disclosed herein, the user interface may render and display the information in the form of a webpage, while in other embodiments the user interface may render and display the information using a web application, a mobile application, or any other means whereby a user may interact with data through an electronic device. The rendered display may prompt users for information in the form of a pop-up window, a text box, text input boxes, or graphical user interfaces (GUI) that may be selected/manipulated using a pointer, mouse, or touchscreen. Additionally, the user may interact with the rendered display through radio buttons, check boxes, or by selecting an image. The rendering and displaying of user-specific pricing information may be performed, for example, through dynamic HTML coding referencing the retrieved pricing information, as would be understood by a person of skill in the art. 
       FIG. 7  illustrates an example implementation and display  724  of a webpage for an insurance benefit utilization system. More specifically,  FIG. 7  provides an example of a login page where the user is prompted to provide the requisite login information  727 , so that the system server may generate a member token and begin the verification and authentication process described above. As shown, the user may either A) enter personal information such a first name, last name, date of birth, and either the member&#39;s zip code or the last four digits of the member&#39;s SSN, or B) enter plan information such as the member ID number and the plan number. 
       FIG. 8  illustrates an example implementation and display  866  of a webpage providing both an original regular price for the eyewear product  867 A and the calculated out-of-pocket price  867 B. In this case eyewear product  867 A is an eyeglass frame. Out-of-pocket price  867 B has been determined by applying a user&#39;s insurance benefit information to the original regular prices for the eyewear using the methods described above. Also shown are methods for enhancing the user&#39;s shopping experience, wherein the user may sort the displayed eyewear by color, brand, shape, size, type, price, rating, or any other specification or measureable metric commonly used to discern between various types of eyewear. 
       FIG. 9  illustrates an example implementation and display  975  of a webpage providing a product display page. As shown, the page includes the original regular price for the eyewear product  997 A and the calculated after-insurance price  997 B. Additionally depicted are examples of compatible options  997 C that may be selected in order to complete the eyewear purchase. In this embodiment, frame color, prescription type, lens options, and additional upgrades are compatible with the selected eyeglass frames. As a user makes different selections, after-insurance price  997 B is calculated based on information obtained from the methods described with respect to  FIGS. 3 and 6 . Additional information may be displayed next to each option to let the user know how a particular selection will affect his or her total out-of-pocket price (e.g., “Add $29 out of pocket”). 
       FIG. 10  illustrates an example implementation and display  1096  of a webpage providing a shopping cart view, including detailed selection and pricing information. When a customer visits a brick and mortar eyewear store, he or she must select the frames they desire. With limited guidance regarding his or her out-of-pocket expenses, the customer must also select prescription type, lens options, and additional upgrades without understanding how his or her insurance benefits will be applied to the order. As shown in display  1096 , the disclosed insurance benefit utilization system may be configured to provide line item pricing  1099 A, insurance details  1099 B, and total benefits  1099 C, wherein the user may see detailed information about how his or her vision insurance has been applied to the purchase. By providing line item pricing, the user may make more informed purchase decisions and may be provided with final price  1099 D based on the summation of total benefits. 
       FIG. 11  illustrates an example implementation and display  1193  of a webpage prompting a user to input shipping information, review the order summary, and confirm his or her purchase. 
     After an order is placed, payment authorization begins and the eyewear provider may utilize an insurance provider&#39;s claim authorization API to claim a user&#39;s benefits. As such, if at any point in time an order is cancelled prior to shipping the ordered product, the eyewear provider may void the claim authorization and return the benefits and eligibility back to the user. 
     Following the user&#39;s payment and claim authorization, the user&#39;s eyewear order is processed by eyewear provider&#39;s order management system and communicated with the systems, applications, and products (SAP) management. The user&#39;s order is processed and fulfilled by the eyewear provider&#39;s distribution chain and shipped to the customer within a specified period of time. Once shipped, the order management system triggers the eyewear provider&#39;s insurance service to create a claim on behalf of the member. In an embodiment, the member&#39;s claim is generated within the eyewear provider&#39;s insurance service and sent via API to the insurance provider&#39;s claim service. The claim is received and processed through the insurance provider&#39;s system. 
     Processing a user&#39;s claim may take a predetermined length of time, at which point claim updates may provided via a digital 835 EDI file placed on the eyewear provider&#39;s server, according to an embodiment. The insurance provider&#39;s insurance service may retrieve these 835 EDI documents, parse pertinent information, and update claims within the eyewear provider&#39;s insurance service. Orders associated with these claims may be simultaneously updated to reflect status changes to the claim. 
       FIG. 12  illustrates an example process for submitting, tracking, and utilizing an insurance benefit claim  1200 . At step  1201 , when the user submits his or her eyewear order, the insurance database provides a membership authorization and locks the member&#39;s benefits so that the user cannot make a duplicate insurance claim at another location or with another eyewear provider. Order and checkout information is received at the eyewear provider&#39;s management system, GECO  1203 . The GECO management system then provides checkout and user information to an order verification portal  1205 , payment service  107 , systems, applications, and products system (SAP)  1209 , and insurance service  1209 . At verification portal  1205 , the order information and method of payment are verified. SAP system  1209  receives information being sent from the GECO management system, including discounts, reimbursements, and product details. Additionally, GECO management system  1203  sends queue information to insurance service  1209 , to inform the insurance service that an insurance order has been received through the eyewear provider. Further, after the ordered eyewear product has been made, assembled, and shipped to the user, the GECO management system transmits information to payment service  1207  to charge the order, which communicates to insurance service  1209  that the order has been charged and that the claim process should begin. When the insurance service has been notified that the order has been charged, it creates an insurance claim through a claim API, which engages with insurance claim service  1211  of insurance database  1210 . 
     At insurance database  1210 , reports may be transmitted to, entered, or uploaded to server  1215 . Over the course of the claim submission process, the reports may be updated with claim status information as it becomes available. Within a predetermined period of time, the claim system processes EDI  835  document  1225 , which may be a table, text file, metadata file or any other file that may transmit the EDI  835  document&#39;s information. The EDI  835  document is stored within reports  1217  file and is transmitted to the eyewear provider at update insurance record  1213 . Insurance service  1209  may parse through the EDI  835  document and collect information including reimbursement values, which is the monetary amount the eyewear provider may expect to receive from the insurance claim. 
     Methods and systems discussed above have referred to products having multiple components, with each component (such as frames, lenses, coatings, etc.) having a different insurance benefit (or no benefit). However, other types of vision products do not have the level of complexity required for an eyeglasses purchase. For example, a contact lens product cannot be customized according to different specifications or options preferred by the user, because such specifications and options result in a different product altogether, with a different price. Online utilization of vision insurance benefits may be effected for such products so that the user experience is optimized to the complexity of the product. For example,  FIG. 13  illustrates an initial insurance benefit utilization process  1300  for determining an available insurance benefit for a single priced product, according to an example embodiment. As contemplated herein, a single priced product is any stand-alone product that does not have additional accessories or options that may affect its cost or an available insurance benefit for that particular product. The cost of a single priced product may vary based on a number of factors, including quantity of product ordered. A single priced product may include, for example, a contact lens product. A contact lens product may be considered a single priced product because customized options such as coatings or tints cannot be added to a pre-existing, selected product, and thus the price of that particular product will not change due to customization. 
     The multiple systems/databases may include, for example, user interface  1302 , system server  1304 , products database  1306 , members database  1308 , and insurance database  1310 . Like the processes described above, process  1300  may be performed by processing logic that may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executable on the system server, at the user interface, or another processing device), or a combination thereof. It is not required that the steps depicted in  FIG. 13  be performed in the exact order shown, as one skilled in the art would understand. In an embodiment, initial insurance benefit utilization process  1300  may be adjusted to enable updating information in any one of the databases associated with the user. Additionally, user interface  1302  may provide administrative privileges, not shown, wherein a system administrator may access, modify, create, or duplicate the data. A system administrator may also perform other administrative functions in the databases and with the data stored therein, as one skilled in the art would understand. As described above regarding process  200  and process  300  in  FIGS. 2 and 3 , respectively, process  1300  may further include an MA. In process  1300 , the RIA may be implemented as a connectivity layer between user interface  1302  and system server  1304 , products database  1306 , member database  1308 , and/or insurance database  1310 , thereby facilitating data communications between the system components using the functionality described above. 
     In step  1319 , a user initially navigates to and accesses a website associated with the insurance benefits utilization system. In response, the system server provides the user interface with a prompt for login information, as depicted by step  1321 . At display  1324 , the user interface may render and display the received information using a web application, a mobile application, or any other means whereby a user may interact with data through an electronic device. 
     To login, the user must provide a sufficient amount of personal information so the system may associate the user with his or her specific vision insurance plan. Accordingly the system may prompt the user for personal information, including: first and last name, address, date of birth, zip code, portions of his or her social security number (SSN), insurance group identification, insurance member identification, password, and/or any other identifying personal identification. At step  1326  the user&#39;s login information is transmitted from the user interface to the system server. 
     Upon receiving the login information, the system server may generate a member token at step  1328 , as described above with respect to step  228  of  FIG. 2 . At step  1330 , the member token is passed from system server  1304  to member database  1308  in order to verify and authenticate the user&#39;s identity as an insurance member. This step may be complete using system call to a getEligibility( ) application program interface (API) provided at system server  204 . APIs such as the getEligibility( ) API, a findMember( ) API, getMemberEligibility API and other similar APIs disclosed herein may be developed in order to provide developers an easier and more efficient method for interfacing with external databases and systems. 
     In steps  1332  and  1334 , either member database  1308  or insurance database  1310  may verify and authenticate the user&#39;s member token. Steps  1336  and  1338  illustrate signals transmitted from the member and insurance databases to indicate that the member token is verified, i.e., that the user is an insured member. If, however, the user provided incorrect or insufficient identification information, the system may reattempt to authenticate the member token. Further, the signal passed in steps  1336  and  1338  will indicate a failed verification and authentication. The verification and authentication result is sent to the user interface at step  1304  and the result is rendered and displayed at step  1342 . If the verification and authentication failed, the user may be provided with additional opportunities to correct or modify the entered login information at display  1342 . Alternatively, display  1342  may prompt the user to call or otherwise contact his or her insurance provider to remedy any errors, inconsistencies, or any other deficiencies that may prevent the user from verifying and authenticating his or her insurance membership. In an additional embodiment, display  1342  may prompt the user to provide his or her insurance information in order to register an online account with the eyewear provider. In at least one embodiment, the system will not allow the user to access any insurance information or product and pricing information until his or her account has been verified and authenticated. 
     Also consistent with the present disclosure are embodiments where the member token and step  1328  are omitted. In such embodiments, a member ID may be passed directly to the insurance database in order to verify and authorize the user. This may occur, for example, when the provider is associated with the insurance company or has direct access to the insurance company database, rather than being a third party provider. Accordingly, any additional unnecessary steps, such as step  1332 , may become optional as per the desired process and data schema. 
     Based on the verified and authenticated member token, the benefit component  1344  of system server  1304  may request member insurance benefit information from the member and insurance databases, respectively, as per step  1346 . As shown in  FIG. 13 , and as described, the member insurance benefit information is requested from the respective databases in series. However, the request may alternatively be made in parallel. Further, the benefit component may request the member insurance benefit information exclusively from either the member database or the insurance database. Step  1346  may be carried out by making one or more real-time system calls to a getBenefits( ) API, a getClaimPricing( ) API, or another API created and configured to retrieved insurance benefit data and pricing from the insurance database. 
     Steps  1348  and  1350  retrieve and/or generate data, including the user&#39;s vision insurance benefit information. As mentioned above, the data may be generated and presented in one of several formats. For example, the data may be passed as an HTML table, an SQL table, a spreadsheet, a database table, a CSV file, a metadata file, or any other table or file commonly used to distribute categorized data. 
     At step  1353 , member database  1308  may optionally retain or cache a copy of the file containing the user&#39;s benefit information, where the file is stored with the verified and authenticated member token. At step  1355 , the benefits data is transmitted from member database  1308  to system server  1304 . Upon receiving the benefits table, extractor  1356  parses the data and collects specific insurance benefit information. More specifically, the extractor collects the user&#39;s allowance amount, i.e., an amount that may be applied to any qualifying eyewear product or any other insurance benefit information specific to the member&#39;s insurance policy that may be necessary to determine and process an insurance claim. In additional embodiments, the system may provide a notification or a webpage where the user may see his or her benefit amount. For example, the user may request his or her benefit information and the system will return the user&#39;s allowance and/or discount amounts as detailed in his or her insurance benefit package. In an embodiment, such information is automatically provided to the user upon login. 
     At step  1361 A, the user makes a product selection. Upon receiving the product selection, the system server may apply the benefits at step  1362 A, or wait for the user to provide a desired quantity, as per step  1361 B, before applying the benefits at step  1362 B. The resulting updated product price may be transmitted to the user interface. The product price may then be rendered and displayed at the user interface. As mentioned above, the updated price may be rendered and displayed on a new webpage or application page in a position next to or near the initial product price, so the user may compare the initial and updated prices. Alternatively, a scripting language may be used to replace the initial price with the updated price without posting back the entire page. At step  1365 , the user checks out or purchases the eyewear, and the eyewear provider fulfills the customer&#39;s eyewear order and begins preparing and filing the insurance benefit claim. In at least one embodiment, the system may determine whether the user has realized his or her full insurance benefit. If the user has not fully used his or her allowance, the system may generate a warning message to inform the user that he or she has a portion of his or her allowance remaining. Alternatively, if the user has fully used his or her allowance, such that insurance will not cover any or part of the selected product, the system may generate a warning message to that effect. 
       FIG. 14  illustrates an initial insurance benefit utilization process  1400  for determining an available insurance benefit for a single priced product, according to an example embodiment. The multiple systems/databases may include user interface  1402 , system server  1404 , products database  1406 , members database  1408 , and insurance database  1410 . Like the processes described above, process  1400  may be performed by processing logic that may include hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executable on the system server, at the user interface, or another processing device), or a combination thereof. It is not required that the steps depicted in  FIG. 14  be performed in the exact order shown, as one skilled in the art would understand. In an embodiment, initial insurance benefit utilization process  1400  may be adjusted to enable updating information in any one of the databases associated with the user. Additionally, user interface  1302  may provide administrative privileges, not shown, wherein a system administrator may access, modify, create, or duplicate the data. A system administrator may also perform other administrative functions in the databases and with the data stored therein, as one skilled in the art would understand. Process  1400  may further include an RIA. In process  1400 , the RIA may be implemented as a connectivity layer between user interface  1402  and system server  1404 , products database  1406 , member database  1408 , and/or insurance database  1410 , thereby facilitating data communications between the system components using the functionality described above. 
     In step  1419 , a user initially navigates to and accesses a website associated with the insurance benefits utilization system. In response, the system server provides the user interface with a prompt for login information, as depicted by step  1421 . At step  1424 , the user interface may render and display the received information using a web application, a mobile application, or any other means whereby a user may interact with data through an electronic device. 
     To log in, the user must provide a sufficient amount of personal information so that the system may associate the user with his or her specific vision insurance plan, as described above. Accordingly, the system may verify and authenticate the user using a member token and by following the same, or similar, steps provided above. The results of the authentication and updated product pricing information may be rendered and displayed at the user interface at display  1442 . Additionally at display  1442 , the user may make a product selection. 
     In response to the user&#39;s product selection, the benefit component  1444  of system server  1404  may request member insurance benefit information from the member and insurance databases, as per step  1446 , and as described above. Step  1446  may be carried out by making one or more real-time system calls to a getBenefits( ) API, a getClaimPricing( ) API, or another API created and configured to retrieved insurance benefit data and pricing from the insurance database. In an embodiment, such benefit information may be obtained when the user initially logs in instead of waiting for the product selection, if it is known or likely that the user will be selecting a single price product. 
     Steps  1448  and  1450  retrieve and/or generate data, including the user&#39;s vision insurance benefit information. As mentioned above, the data may be generated and presented in one of several formats. For example, the data may be passed as an HTML table, an SQL table, a spreadsheet, a database table, a CSV file, a metadata file, or any other table or file commonly used to distribute categorized data. 
     At step  1453 , member database  1408  may optionally retain or cache a copy of the file containing the user&#39;s benefit information, where the file is stored with the verified and authenticated member token. At step  1455 , the benefits data is transmitted from member database  1408  to system server  1404 . Upon receiving the benefits table, extractor  1456  parses the data and collects specific insurance benefit information. More specifically, the extractor collects the user&#39;s allowance amount, i.e., an amount that may be applied to any qualifying eyewear product or any other insurance benefit information specific to the member&#39;s insurance policy that may be necessary to determine and process an insurance claim. The system server may apply the benefits at step  1362 A, or wait for the user to provide a desired quantity, as per step  1361 B, before applying the benefits at step  1362 B. 
     An updated product price may be calculated at steps  1462 A and  1462 B by subtracting the user&#39;s allowance from the original retail price of a selected product. Any additional discounts may also be subtracted from the original retail price. The remaining amount is an out-of-pocket price, or the price that the user will have to pay for the product after the user&#39;s vision insurance benefits have been applied. This out-of-pocket price is the updated product price. The updated product price for each product may be transmitted to the user interface where they may be rendered and displayed at the user interface. As mentioned above, the updated price may be rendered and displayed on a new webpage or application page in a position next to or near the initial product price, so the user may compare the initial and updated prices. Alternatively, a scripting language may be used to replace the initial price with the updated price without posting back the entire page. At step  1465 , the user may checkout or purchase the eyewear and the eyewear provider may fulfill the customer&#39;s eyewear order and begin preparing and filing the insurance benefit claim. 
       FIG. 15  illustrates an example implementation and display  1524  of a webpage for an insurance benefit utilization system. More specifically,  FIG. 15  provides an example of a login page where the user is prompted to provide the requisite login information  1527  so that the system server may generate a member token and begin the verification and authentication process described above. 
       FIG. 16  illustrates example implementation and display  1666  of a webpage providing the product price  1667 A, determined by applying a user&#39;s insurance benefit information to the original regular price of single-priced eyewear. In some embodiments, since the user&#39;s insurance policy allowance has been provided to him or her upon login, the user can determine the out-of-pocket price based on the displayed product price. In additional embodiments, display  1666  may provide a calculated out-of-pocket price in addition to, or in place of, product price  1667 A. 
       FIG. 17  illustrates an example implementation and display  1775  of a webpage providing a product display page. As shown, the page includes text boxes  1797 , where the user may enter his or her prescription information as well as the desired quantity of eyewear products. 
       FIG. 18  illustrates an example implementation and display  1893  of a webpage providing a summary of the user-selected product. As shown, the user is provided with initial product price  1867 A, calculated savings  1867 B, calculated price  1867 C for the selected product, and total product price  1867 D based on the user-determined quantity. Calculated price  1867 C is determined by extracting the required information from the user&#39;s insurance benefit information, as mentioned above with respect to steps  1356  and  1456  in  FIGS. 13 and 14 , respectively. Calculated savings  1867 B may be calculated by subtracting calculated product price  1867 C from product price  1867 A, the result being the difference between the two prices. Total product price  1867 D may be calculated by multiplying calculated price  1867 C by the quantity provided by the user. Additionally shown is total shopping cart price  1867 E, which is calculated by adding the total product price for each item in the user&#39;s shopping cart. As shown,  FIG. 18  also prompts the user for any applicable discount codes and allows the user to either continue shopping for more eyewear products or begin the checkout process. 
     Currently, there are a number of e-commerce websites that offer eyewear, some of which may offer incentives or promotions to entice users to buy from its e-commerce platform. The disclosed insurance benefit utilization system may also offer incentives and/or promotions such as clearance items, buy one get one free, discounted items, discounted brands, or sales wherein the product price becomes a fraction of its regular price. Accordingly, the disclosed system may provide a method for users to apply his or her insurance benefits toward a promotional item. Alternatively, the system may block a user from applying his or her insurance benefits toward a promotional item or sale. In yet another embodiment, the system may provide a method wherein the user may compare a promotional price against an estimated out-of-pocket price after his or her insurance benefit has been applied to the original retail price of the eyewear product, thereby enhancing the user&#39;s buying experience. For example, if an eyewear provider is offering a 10% off sale on all OAKLEY brand glasses, the system may provide the user with both the reduced promotional price (10% off) and the estimated price after the insurance benefit has applied, so the user can determine whether to use his or her insurance benefits, or take advantage of the promotion. Further, the system may parse a user&#39;s insurance benefit information and compare the available benefits with the eyewear provider&#39;s inventory, calculate the most economical options, and thereby recommend products that would provide the lowest out-of-pocket price to the user. 
     The disclosed insurance benefit utilization system may further comprise a reporting layer, whereby financial analysts may track and reconcile claim payouts against both the original insurance pricing quotes as well as information provided within the filed claim documents. The reconciliation may then be facilitated between the eyewear provider and the insurance provider through traditional email or phone channels. 
     It is contemplated herein that the disclosed insurance benefit utilization system may be provided to webhosts, doctors, ophthalmologists, opticians, or any other third party eyewear provider, as a white label product or service. As such, the third party eyewear provider may “rebrand” the disclosed insurance benefit utilization system to make it appear as if it were the third party eyewear provider&#39;s own system. 
     It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections (if any), is intended to be used to interpret the claims. The Summary and Abstract sections (if any) may set forth one or more but not all exemplary embodiments of the invention as contemplated by the inventor(s), and thus, are not intended to limit the invention or the appended claims in any way. 
     While the invention has been described herein with reference to exemplary embodiments for exemplary fields and applications, it should be understood that the present disclosure is not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of the present disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein. 
     Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries may be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments may perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein. 
     References herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein. 
     The breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.