METHOD FOR AUTOMATING CUSTOMER AND VEHICLE DATA INTAKE USING WEARABLE COMPUTING DEVICES

Systems and methods are provided for automating information intake process by generating intake instructions for display on a client computing device. A user may be directed to capture data that includes vehicle and owner information using a wearable computing device. Insurance claim information, including damage information, may be obtained based on the captured vehicle information. The damage information may be used to determine intake instructions for capturing the images or videos of the damage. The user may use the system in a handsfree manner by viewing intake instructions via a display of the wearable computing device which allows the user to view the intake instructions while capturing the intake information. Additionally, the user may use voice commands or gestures to control the display of intake instructions.

TECHNICAL FIELD

The present disclosure is generally related to automobiles. More particularly, the present disclosure is directed to automotive repair technology.

BACKGROUND

Conventional processing of insurance claims starts with a repair estimate which involves analyzing different aspects of the damage associated with the insured item (e.g., an automotive vehicle) in order to determine an estimate of the compensation for repairing the loss.

Existing technological tools used to assist the party performing the estimate are limited to software estimation tools. However, the use of these tools is predicated upon collecting a variety of data related to the vehicle, its owner, and the damage, which traditionally comes in various formats and must be gathered from different sources, thus making conventional tools ineffective. For example, the data collection process may include paperwork processing, telephone calls, and potentially face-to-face meetings between the party conducting the estimate, the claimant, and the insurance adjuster, further delaying the settlement of the claim. Accordingly, conventional repair estimate methods are time-consuming and susceptible to human error.

SUMMARY

In accordance with one or more embodiments, various features and functionality can be provided to enable the automation of information intake process when generating a repair estimate.

In some embodiments, a method for automating information intake may obtain vehicle identification information and owner information by processing images captured by a computing device operated by a user. In some embodiments, the computing device includes a wearable computing device worn by the user configured to facilitate hands-free intake of information associated with the owner and the damaged vehicle.

In some embodiments, the vehicle identification information and the owner information may be associated with a damaged vehicle which was damaged during an adverse incident.

In some embodiments, the method may extract Vehicle Identification Number (VIN) from a captured image of the vehicle identification information. In some embodiments, the method may obtain vehicle information associated with the damaged vehicle based on the extracted VIN. The vehicle information may include a year of manufacture, a make, a model, a sub-model, a configuration, an engine type, and a transmission type of the damaged vehicle. In some embodiments, the method may confirm vehicle identification information by receiving user input.

In some embodiments, the owner information may include a captured image of an owner driver's license card and an owner insurance card. The method may extract the owner's name from the captured image of the owner driver's license card, and extract the owner's insurance policy number from the captured image of the owner information.

In some embodiments, the method may obtain insurance claim information based on the vehicle identification information and the owner information. The insurance claim information may include damage information specifying one or more damaged parts of the damaged vehicle, and insurance intake parameters specifying one or more intake parameters. In some embodiments, obtaining insurance claim information is determined based on the extracted owner's name and the extracted owner's insurance policy number. In some embodiments, the one or more intake parameters include a number of images depicting the one or more damaged vehicle parts.

In some embodiments, the method may determine damage intake instruction information based on the damage information and insurance intake parameters associated with the insurance claim information. The damage intake instruction information may include user instructions for capturing the information associated with the one or more damaged parts of the damaged vehicle.

In some embodiments, the determined damage intake instruction information includes at least one of textual instructions and voice instructions directing the user to capture images of the one or more damaged vehicle parts associated with the damaged vehicle.

In some embodiments, the method may effectuate presentation of the damage intake instruction information for capturing the one or more damaged parts associated with the damaged vehicle using an image capture device of the computing device operated by the user. In some embodiments, effectuating the presentation of the damage intake instruction information includes displaying the textual instructions on a display of the computing device and transmitting the voice instructions via a speaker of the computing device.

DETAILED DESCRIPTION

Described herein are systems and methods for automating the intake of information used to prepare a repair estimate for a damaged vehicle. The details of some example embodiments of the systems and methods of the present disclosure are set forth in the description below. Other features, objects, and advantages of the disclosure will be apparent to one of skill in the art upon examination of the following description, drawings, examples and claims. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims.

As stated above, conventional insurance claims adjustment process is complex and requires a claim adjuster to analyze different aspects of the damage associated with the insured item in order to determine whether compensation for the loss is appropriate. The information is obtained during an intake process that relies on manual data entry from multiple sources. For example, an intake technician may manually obtaining a claim number (e.g., a number related to damage associated with an insured vehicle, etc.) by contacting an insurance company (e.g., by phone, by email, via a company website, etc.). Further, the technician may provide basic identifying and/or validating vehicle information, including the make, model, and year of manufacture, and owner information (e.g., name, age, address, insurance information etc.) Finally, the process also includes providing information related to the general areas of damage to the vehicle and any other relevant details (e.g., condition of glass, under carriage, engine, wheels, airbags, etc. associated with the vehicle).

Accordingly, the intake process relies on manual data entry performed multiple times (e.g., first using a paper form, then a computer platform) and requires the user to utilize multiple devices (e.g., a computer and digital camera). Because manual data entry is time-consuming and is prone to errors, it often causes delays in claim processing. By allowing a user to perform the information intake process in a guided, handsfree manner results in a significant reduction in intake time and user errors. Furthermore, currently available technology lacks analytics with respect to capturing damage data. By automatically verifying the accuracy of captured information results in improved claim processing time.

In accordance with various embodiments, an intake technician can obtain intake instructions for viewing on a display of a wearable computing device. For example, a technician can view intake instruction to capture vehicle information used to identify the type of vehicle and owner information associated with the damaged vehicle without entering the information, but rather by using input devices (e.g., a camera) on the wearable computing device, resulting in handsfree data entry. Vehicle information is used to obtain claim information (e.g., from an insurance carrier) which, along with the vehicle information, is then used to determine relevant intake instructions for capturing damage information. Because the repair technician can view intake instructions via a display of a handsfree computer wearable device, the technician is able to capture the intake information at the same time. Additionally, using voice commands to move from one information capture screen to the next further enhances the handsfree operation. Finally, the technician may obtain verification that the captured data was captured in accordance with image or video standards, resulting in greater accuracy and improved processing time.

Before describing the technology in detail, it is useful to describe an example environment in which the presently disclosed technology can be implemented.FIG. 1illustrates one such example environment100.

FIG. 1illustrates an example environment100which automates the intake of information used to prepare a repair estimate for a damaged vehicle. For example, a user conducting the intake process may collect information related to the damaged vehicle, its owner, and the damage sustained by the vehicle. The user may input the information by capturing images or by using voice commands without having to enter input via a graphical user interface (GUI) of a conventional damage estimation software, resulting in a handsfree intake process, as described herein. Furthermore, during the information intake process the user is guided by a set of intake instructions which are displayed in a client computing device104, further facilitating the handsfree intake. In some embodiments, the set of instructions guiding the user through the information intake process may be generated based on the specific requirements of an insurance carrier (e.g., number of images to be collected), the geographic location associated with the occurrence of the incident and the issuance of the insurance policy, and/or the damage itself, as further described herein.

In some embodiments, environment100may include a client computing device104, an information intake server120, a one or more vehicle information server(s)130, a one or more assignment information server(s)140, a one or more intake instruction server(s)160, and a network103. A user160may be associated with client computing device104as described in detail below. Additionally, environment100may include other network devices such as one or more routers and/or switches.

In some embodiments, client computing device104may include a variety of electronic computing devices, for example, a computer wearable device, such as smart glasses, or any other head mounted display devices that can be used by a user (e.g., an estimator). In some embodiments, the computer wearable device may include a transparent heads-up display (HUD) or an optical head-mounted display (OHMD). In other embodiments, client computing device104may include other types of electronic computing devices, such as, for example, a smartphone, tablet, laptop, virtual reality device, augmented reality device, display, mobile phone, or a combination of any two or more of these data processing devices, and/or other devices.

In some embodiments, client computing device104may include one or more components coupled together by a bus or other communication link, although other numbers and/or types of network devices could be used. For example, client computing device104may include a processor, a memory, a display (e.g., OHMD), an input device (e.g., a voice/gesture activated control input device), an output device (e.g., a speaker), an image capture device configured to capture still images and videos, and a communication interface.

In some embodiments, client computing device104may present content (e.g., intake instructions) to a user and receive user input (e.g., voice commands). For example, client computing device104may include a display device, as alluded to above, incorporated in a lens or lenses, and an input device(s), such as interactive buttons and/or a voice or gesture activated control system to detect and process voice/gesture commands. The display of wearable computing device104may be configured to display the instructions aimed at facilitating a handsfree and voice- and/or gesture-assisted intake of information. In some embodiments, client computing device104may communicate with information intake server120via network103and may be connected wirelessly or through a wired connection.

In some embodiments, client computing device104such as smart glasses, illustrated inFIGS. 3A-3B, may include a camera116, a display117(e.g., comprising an OHMD), a speaker118, and a microphone119, among other standard components.

In some embodiments and as will be described in detail inFIG. 2, information intake server120may include a processor, a memory, and network communication capabilities. In some embodiments, information intake server120may be a hardware server. In some implementations, information intake server120may be provided in a virtualized environment, e.g., information intake server120may be a virtual machine that is executed on a hardware server that may include one or more other virtual machines. Additionally, in one or more embodiments of this technology, virtual machine(s) running on information intake server120may be managed or supervised by a hypervisor. Information intake server120may be communicatively coupled to a network103.

In some embodiments, the memory of information intake server120can store application(s) that can include executable instructions that, when executed by information intake server120, cause information intake server120to perform actions or other operations as described and illustrated below with reference toFIG. 2. For example, information intake server120may include information intake application126. In some embodiments, information intake application126may be a distributed application implemented on one or more client computing devices104as client information intake viewer127. In some embodiments, distributed information intake application126may be implemented using a combination of hardware and software. In some embodiments, information intake application126may be a server application, a server module of a client-server application, or a distributed application (e.g., with a corresponding information intake viewer127running on one or more client computing devices104).

For example, user160may view the intake instructions displayed in a graphical user interface (GUI) of client information intake viewer127on a display of wearable device104while performing the intake process in a handsfree manner. Additionally, client computing device104may accept user input via microphone119which allows user160to navigate through the intake instructions by using voice commands or gesture control, again leaving the user's hands free.

As alluded to above, distributed applications (e.g., information intake application126) and client applications (e.g., information intake viewer127) of information intake server120may have access to microphone data included in client computing device104. As alluded to above, users will access, view, and listen to intake instructions when performing data intake via client computing device104using voice commands or gesture control. In some embodiments, the commands entered by user160via microphone119of client computing device104(illustrated inFIG. 3B) may be recognized by information intake application126. For example, a command entered by user160may include user160speaking “View Damage Intake Instructions” into microphone119. In some embodiments, information intake application126may have access to audio data collected by microphone119of client computing device104. That is, information intake application126may receive voice commands as input and trigger display events as output based on the voice commands of user160, as described in further detail below. In yet other embodiments, information intake application126may receive voice commands as input and trigger voice response events as output based on the voice commands of user160, as further described in detail below.

The application(s) can be implemented as modules, engines, or components of other application(s). Further, the application(s) can be implemented as operating system extensions, module, plugins, or the like.

Even further, the application(s) may be operative in a cloud-based computing environment. The application(s) can be executed within or as virtual machine(s) or virtual server(s) that may be managed in a cloud-based computing environment. Also, the application(s), and even the repair management computing device itself, may be located in virtual server(s) running in a cloud-based computing environment rather than being tied to one or more specific physical network computing devices. Also, the application(s) may be running in one or more virtual machines (VMs) executing on the repair management computing device.

In some embodiments, information intake server120can be a standalone device or integrated with one or more other devices or apparatuses, such as one or more of the storage devices, for example. For example, information intake server120may include or be hosted by one of the storage devices, and other arrangements are also possible.

In some embodiments, information intake server120may transmit and receive information to and from one or more of client computing devices104, one or more vehicle information servers130, one or more assignment servers140, one or more intake instruction servers150, and/or other servers via network103. For example, a communication interface of the information intake server120may be configured to operatively couple and communicate between client computing device104(e.g., a computer wearable device), vehicle information server130, assignment server140, intake instruction server150, which are all coupled together by the communication network(s)103.

In some embodiments, vehicle information server130may be configured to store and manage vehicle information associated with a damaged vehicle. For example, vehicle information may include vehicle identification information, such as VIN number, make, model, and optional modifications (e.g., sub-model and trim level), date and place of manufacture, and similar information related to a damaged vehicle. The vehicle information server130may include any type of computing device that can be used to interface with the information intake server120. For example, vehicle information server130may include a processor, a memory, and a communication interface, which are coupled together by a bus or other communication link, although other numbers and/or types of network devices could be used. In some embodiments, vehicle information server130may also include a database132. For example, database132may include a plurality databases configured to store content data associated with vehicle information, as indicated above. The vehicle information server130may run interface applications, such as standard web browsers or standalone client applications, which may provide an interface to communicate with the repair management computing device via the communication network(s). In some embodiments, vehicle information server130may further include a display device, such as a display screen or touchscreen, and/or an input device, such as a keyboard, for example.

In some embodiments, assignment server140may be configured to store and manage data related to an insurance carrier or other similar entity with respect to a damage incident (e.g., a collision accident). For example, the data related to an insurance carrier may include a claim number which was assigned by the insurance carrier upon submitting an insurance claim reporting a damage incident, information related to the insurance carrier, the owner of the damaged vehicle, the vehicle, the damage reported during claim submission for adjustment, policy information, and other similar data. In some embodiments, assignment server140may include any type of computing device that can be used to interface with the information intake server120to efficiently optimize handsfree guided intake of information related to a damaged vehicle for the purpose of generating a repair estimate. For example, assignment server140may include a processor, a memory, and a communication interface, which are coupled together by a bus or other communication link, although other numbers and/or types of network devices could be used. In some embodiments, assignment server140may also include a database142. For example, database142may include a plurality databases configured to store content data associated with insurance carrier policy and claim, as indicated above. In some embodiments, assignment server140may run interface applications, such as standard web browsers or standalone client applications, which may provide an interface to communicate with the information intake server120via the communication network(s)103. In some embodiments, assignment server140may further include a display device, such as a display screen or touchscreen, and/or an input device, such as a keyboard, for example.

In some embodiments, intake instruction server150may be configured to store and manage information associated with intake instructions. Intake instruction server150may include processor(s), a memory, and a communication interface, which are coupled together by a bus or other communication link, although other numbers and/or types of network devices could be used. In some embodiments, intake instruction server150may also include a database152. For example, database152may include a plurality databases configured to store content data associated with intake instructions (e.g., workflow intake instructions, including textual information, images, videos, with and without an audio guide, and/or animations, including 3D animations) demonstrating how to perform intake of various information fora variety of different types and models of vehicles with different types of damage, which are insured by different insurance carriers in different geographical locations that may have different image requirements.

In some embodiments, vehicle information server130, assignment servers140, and intake instruction servers150may be a single device. Alternatively, in some embodiments, vehicle information server130, assignment servers140, and intake instruction servers150may include a plurality of devices. For example, the plurality devices associated with vehicle information server130, assignment servers140, and intake instruction servers150may be distributed across one or more distinct network computing devices that together comprise one or more vehicle information server130, assignment servers140, and intake instruction servers150.

In some embodiments, vehicle information server130, assignment server140, and intake instruction server150, may not be limited to a particular configuration. Thus, in some embodiments, vehicle information server130, assignment server140, and intake instruction server150may contain a plurality of network devices that operate using a master/slave approach, whereby one of the network devices operate to manage and/or otherwise coordinate operations of the other network devices. Additionally, in some embodiments, vehicle information server130, assignment server140, and intake instruction server150may comprise different types of data at different locations.

In some embodiments, vehicle information server130, assignment server140, and intake instruction server150may operate as a plurality of network devices within a cluster architecture, a peer-to-peer architecture, virtual machines, or within a cloud architecture, for example. Thus, the technology disclosed herein is not to be construed as being limited to a single environment and other configurations and architectures are also envisaged.

Although the exemplary network environment100with computing device104, information intake server120, vehicle information server130, assignment server140, intake instruction server150, and network(s)103are described and illustrated herein, other types and/or numbers of systems, devices, components, and/or elements in other topologies can be used. It is to be understood that the systems of the examples described herein are for exemplary purposes, as many variations of the specific hardware and software used to implement the examples are possible, as will be appreciated by those skilled in the relevant art(s).

One or more of the devices depicted in the network environment, such as client computing device104, information intake server120, vehicle information server130, assignment server140, and/or intake instruction server150may be configured to operate as virtual instances on the same physical machine. In other words, one or more of computing device104, information intake server120, assignment server140, and/or intake instruction server150, may operate on the same physical device rather than as separate devices communicating through communication network(s). Additionally, there may be more or fewer devices than computing device104, information intake server120, vehicle information server130, assignment server140, and/or intake instruction server150.

In some embodiments, the various below-described components ofFIG. 2, including methods, and non-transitory computer readable media may be used to effectively and efficiently optimize handsfree guided repair management of a damaged vehicle.

FIG. 2illustrates an example information intake server120configured in accordance with one embodiment. In some embodiments, as alluded to above, information intake server120may include a distributed information intake application126configured to guide the user during the intake of information process, analyze the intake input (e.g., information related to the damaged vehicle and the owner) in order to determine vehicle information (e.g., VIN number and license plate number), determine carrier claim number associated with the vehicle based on the vehicle and/or owner information, if any, and generate intake instructions for capturing information related to the damage sustained by the vehicle in order to ensure compliance with specific carrier instructions. The intake instructions may be displayed on a display associated with client computing device104, as further described in detail below. In some embodiments, user160may view the intake instructions, the captured intake information, and any information determined by information intake server120via a GUI associated with information intake viewer127running on client computing device104.

In some embodiments, information intake server120may also include one or more database(s)122. For example, database122may include a database configured to store data associated with intake instructions generated by information intake server120which are accessed and used by user160when performing the intake. Additionally, database122may store intake information captured by user160, as further described in detail below. Additionally, one or more databases of information intake server120may include data related to user's160current and past interactions or operations with information intake server120, such as voice commands, gesture commands, and other input collected during the intake process.

In some embodiments, distributed information intake application126may be operable by one or more processor(s)124configured to execute one or more computer readable instructions105comprising one or more computer program components. In some embodiments, the computer program components may include one or more of an intake instruction component106, a vehicle information component108, an owner information component112, a claim assignment component112, a damage information component114, an intake analytics component116, and/or other such components.

In some embodiments, intake instruction component106may be configured to generate handsfree directional intake instructions for guiding user160during the intake process. The intake instructions may include instructions for capturing vehicle information, owner information, and information related to the damage sustained by the vehicle. In some embodiments, the directional instructions may be shown on a display of computer wearable device104.

In some embodiments, intake instruction component106may be configured to provide programmed instructions that instruct user160(e.g., a person performing a repair estimate) that is wearing client computing device104to capture vehicle owner information, such as owner's driver's license, insurance information, and other similar information. Further, intake instruction component106may be configured to provide programmed instructions that instruct user160to capture vehicle identification information, such as a vehicle identification number (VIN). Finally, intake instruction component106may be configured to provide programmed instructions that instruct user160to capture additional vehicle information (e.g., odometer reading, etc.) as well as damage information related to the damaged vehicle (e.g., images of damaged panels or parts), as will be described further below.

For example, user160may capture an image associated with a VIN and/or license plate of the damaged vehicle, owner's driver's license, owner's automobile insurance policy, and so on. In other embodiments, user160may provide vehicle identification information, such as audio data captured by a microphone (e.g., microphone119, illustrated inFIG. 3B) of client computing device104. Similarly, user160may capture an image associated with owner's driver's license or automobile insurance policy card.

In some embodiments, the intake instructions for capturing vehicle, owner, and damage information may include text and/or directional arrows showing where to locate particular information. With respect to vehicle information, the intake instructions may include text and/or directional arrows showing where the VIN is located or information indicating to user160when the VIN or license plate is in a view plane that is acceptable for image capture.

In some embodiments, user160may select what information is being captured (e.g., owner or vehicle). Upon selecting the capture of owner information, user160may be presented with instructions for capturing the information associated with the owner of damaged vehicle, as illustrated inFIGS. 4A-4D. For example, inFIG. 4A, user160may be presented with a contact method selection screen403within a display (e.g., OHMD) of computer wearable device104when capturing information pertaining to the owner of the damaged vehicle. User160may input the owner's preferred method of contact410(e.g., email, phone, or text) for receiving repair updates. User160may input the preferred method by voice entry, for example.

Upon selecting the preferred method of contact as phone or text, user160may be presented with a phone number entry screen405within the display of computer wearable device104, as illustrated inFIG. 4B. Phone number entry screen405may be used by user160to input owner's phone number420. User may input the phone number by voice entry, for example by selecting “Dictate” command425. Upon completing the entry of phone number420, user160may choose to save the information by speaking “Save” command427. Alternatively, user may choose to skip the entry of the phone number by speaking “Skip” command425.

In some embodiments, user160may input owner's driver's license information. For example, as illustrated inFIG. 4C, user160may be presented with a driver's license entry screen407within the display of computer wearable device104. Driver's license entry screen407may include instructions that guide user160to center the image capture device of client computing device104on a driver's license card430during the image capture process. During the capture of driver's license430, user160may choose to get additional instructions by speaking “Show Help” command435. Alternatively, user160may choose to skip the entry of driver's license information by speaking “Skip” command433.

In some embodiments, user160may input owner's insurance information. For example, as illustrated inFIG. 4D, user160may be presented with an insurance information entry screen409within the display of computer wearable device104. Insurance information entry screen409may include instructions that guide user160to center the image capture device of client computing device104on the insurance card440during the image capture process. As user160has centered the image capture device of client computing device104on the insurance card440, user160may speak “Capture” command443to complete the image capture. During the capture of insurance card440, user160may choose to get additional instructions by speaking “Show Help” command447. Alternatively, user160may choose to skip the entry of insurance card information by speaking “Skip” command445.

As alluded to above, user160may select the capture of the damaged vehicle information. Accordingly, user160may be presented with instructions for capturing the information associated with the damaged vehicle, as illustrated inFIGS. 5A-5D. For example, as illustrated inFIG. 5A, user160may be presented with VIN detection screen505within the display of computer wearable device104when capturing vehicle information of damaged vehicle512. VIN detection screen505may include instructions520that guide user160to center the image capture device of client computing device104on a VIN card430during the image capture process. For example, as illustrated inFIG. 5B, a field of view window510may focus on a VIN barcode535. In some embodiments, instructions520may appear under field of view window410within VIN detection screen505.

In some embodiments, directional instructions may include one or more voice commands transmitted to speaker118of client computing device104(illustrated inFIG. 3B) informing user160what and/or when to capture the image associated of the vehicle, owner, or damage information. Different types of directional instructions may include voice commands, visual prompts, such as written text and arrows, or some combination of the above.

For example, as illustrated inFIG. 5C, upon scanning VIN barcode535, directional instructions540may be presented to user160. Directional instructions540may be requesting confirmation of vehicle configuration. For example, user160may input that damaged vehicle's transmission is either automatic or manual. User160may confirm transmission555by either speaking the corresponding transmission types550,555or by speaking the menu number associated with each transmission type (e.g., 4 or 5).

In some embodiments, intake instruction component106may generate directional instructions based on the positional information of user160. For example, user160may obtain information associated with user's160location with respect to the vehicle. Next, intake instruction component106may determine that user160is not proximately positioned to the location or area corresponding to a part of the vehicle that displays the VIN number (e.g., windshield), and generate an audio command instructing the user160to move to the correct location. That is, upon determining that user160is not in the location or area corresponding to the part of the vehicle that displays the VIN number, the instructions may assist the user in located the correct area. In some embodiments, when determining user's160location with respect to the vehicle, intake instruction component106may use one or more of computer vision, device tracking, augmented reality, or similar technologies to identify user's location.

In some embodiments, intake instruction component106may be configured to generate a handsfree confirmation informing user160that the image capture process of vehicle information, owner information, and/or damage information was accomplished successfully. In some embodiments, the confirmation may include a message shown on the display of computer wearable device104. In yet other embodiments, confirmation may include one or more voice commands transmitted to speaker118of client computing device104(illustrated inFIG. 3B) informing user160that the image capture process was accomplished successfully.

In some embodiments, vehicle information component108may be configured to collect vehicle information that user160captured when being guided by intake instruction component106. For example, vehicle information component108may collect captured image data of the VIN, the license plate number, and other similar information related to the damaged vehicle.

In some embodiments, vehicle identification component108may process the captured image data to extract the VIN or license plate number from the captured image data. For example, vehicle identification component108may utilize stored optical character recognition programmed instructions to extract the VIN or license plate from the captured image data.

In some embodiments, vehicle identification component108may present all information related to the damaged vehicle upon user160capturing relevant data, as described herein. For example, as illustrated inFIG. 5D, upon scanning VIN barcode535(illustrated inFIG. 5B) and inputting additional information (illustrated inFIG. 5C), vehicle information screen507may present vehicle information460to user160. Vehicle information560may include year of manufacture (e.g., 1993), make (e.g., Mazda), model (e.g., RX7), configuration (e.g., base), style (e.g., 2 door coupe), engine type (e.g., a 1.3 L. 4 cylinder, gas injected turbocharged engine), and transmission type (e.g., 5 speed manual transmission).

In some embodiments, vehicle information component108may obtain vehicle information related to the damaged vehicle based on the extracted captured image data. For example, vehicle information component108may query database132of vehicle information server130(illustrated inFIG. 1) to obtain the make, model, and year of manufacturing of the vehicle by using the extracted VIN.

In some embodiments, owner information component110may be configured to collect vehicle owner information that user160captured when being guided by intake instruction component106. For example, owner information component110may collect captured image data of the owner's driver's license, the automobile insurance policy, and other similar information related to the owner of the damaged vehicle.

In some embodiments, owner information component110may process the captured image data to extract the owner's biographical information (e.g., name, address, phone number, and so on) and driver information (e.g., driver's license number, state, driver's license expiration date, and so on). Additionally, owner information component110may extract insurance carrier name, insurance policy name, number, and other carrier related information from the captured image data. Similar to the vehicle information component108, owner information component110may utilize stored optical character recognition programmed instructions to extract owner's name or driver's license number from the captured image data.

In some embodiments, claim assignment component112may obtain automobile insurance policy claim information associated with the vehicle by using the vehicle information obtained by vehicle information component108and/or owner information obtained by owner information110. For example, claim assignment component112may query database142of assignment server140(illustrated inFIG. 1) to obtain an insurance claim information (e.g., claim number) associated with the damaged vehicle having a particular VIN, belonging to a particular owner, whose vehicle is covered by a particular insurance carrier, and/or having a particular insurance policy name and number. The insurance policy claim information associated with the vehicle may include information related to the damage the vehicle sustained during the incident, as reported during claim submission. The damage information included in the insurance policy claim may be used to determine intake instructions for capturing the images or videos of the damage, as described further below. For example, the damage information may include wide shots of the damaged vehicle, pictures of an identification number associated with the damaged vehicle (e.g., a vehicle identification number (VIN), etc.), current odometer reading, and/or multiple angles/close-up shots of the damage associated with the insured vehicle. In some embodiments, intake instructions may be generated to require that user160captures image data related to at least two different angles of the damage for each panel (e.g., hood, fender, door, bumper, etc.) based on the claim description of the damage.

Notably, in some embodiments, claim assignment component112may not obtain a claim number and may proceed in providing user instructions on the types of image data that should be captured without receiving a claim number. The user may receive generic or non-specific intake instructions on capturing information related to the damaged vehicle, e.g., various photos/video of the damaged areas, including photos/video of the entire vehicle, photos of VIN door tag, current odometer reading, and so on.

Further, by obtaining the insurance claim information associated with the damaged vehicle, the information intake server120may prepare a corresponding repair estimate report populated by information captured during the intake process, as described herein.

In some embodiments, intake instruction component106may be configured to generate handsfree directional intake instructions for guiding user160during the intake of the information related to the damage sustained by the vehicle. For example, the damage information (e.g., photos and videos) that user160must capture in order to prepare a repair estimate for a damaged vehicle may be dependent on vehicle information previously determined by vehicle information component108, owner information component110and/or claim assignment component112.

As alluded to earlier, the intake instructions may be dependent on the geographic location (e.g., country or state) where the incident occurred, the insurance carrier, including its geographic location, or the type of owner's insurance policy. For example, different insurance carriers may have different requirements for the information being submitted when preparing a repair estimate, e.g., the requirements may specify the number, type of view (i.e., side, front, etc.), and/or content of images (i.e., damaged areas, undamaged areas, previously damaged areas, interior of the vehicle and other similar areas,). Thus, one insurance carrier may require only one image (e.g., only front view) depicting the damage, while other carriers may require multiple images of different views (i.e., front and side views) that depict the damage.

In some embodiments, intake instruction component106may query database152of intake instruction server150(illustrated inFIG. 1) to obtain intake instructions by using, for example, the extracted VIN information, the geographic location information associated with the occurrence of the incident and the issuance of the insurance policy, and/or other such information obtained by vehicle information component108, owner information component110and/or claim assignment component112.

Additionally, the intake instructions may be dependent on the type of damage, its severity, and/or other factors related to the damage. For example, capturing vehicle damage associated with a frontal grill may include instructions for capturing images depicting side fenders in addition to the frontal grill. Accordingly, intake instruction component106may be configured to generate intake instructions for gathering damage data based on the claim information obtained by claim assignment component112(e.g., insurance policy claim information may include information related to the damage the vehicle sustained during the incident, as reported during claim submission).

By using the damage information obtained by claim assignment component112, insures that user160automatically receives all relevant instructions for capturing intake information in a handsfree manner (i.e., without consulting additional documents) resulting in an efficient intake process.

As set forth above, a damaged vehicle may have more than one area that has been damaged during an incident. For example, in a collision accident, a vehicle may have damage to a front bumper, a windshield, and a front passenger door. Accordingly, intake instruction component106may obtain intake instructions based on a particular vehicle panel indicated by visual input, e.g., image data captured by user160wearing client computing device104. For example, a front fender of a damaged vehicle may be included in the visual input provided by client computing device104. Upon processing the captured image data and identifying one or more vehicle panels that have been damaged, intake instruction component106may automatically obtain intake instructions for capturing damage to those vehicle panels.

In some embodiments, damage information component114may be configured to collect damage information that user160captured when being guided by intake instruction component106. For example, damage information component114may collect captured image data associated with various panels and parts of the damaged vehicle.

In some embodiments, intake instruction component106may be configured to effectuate presentation of intake instructions via a GUI associated with information intake viewer127running on client computing device104operated by user160. For example, intake instruction component106may effectuate presentation of one or more screens that user160may navigate using voice commands or gesture control, as set forth above. In some embodiments, each screen may be identified via a corresponding label. For example, a screen associated with intake of vehicle information may be identified as “Vehicle Information” or a similar descriptive label. Similarly, the screen associated with intake of owner information may be identified as “Owner Information”, and so on. In some embodiments, vehicle information determined by vehicle component108(e.g., VIN) may be displayed in subsequent information intake screens.

In some embodiments, the first screen may include one or more options for additional information available for selection by user160. The one or more options may also be identified via a corresponding label. User160may select a particular option by using a voice command, a gesture control, or other command associated with the label. For example, user160may select between “customer check-in” or “vehicle check-in” workflows.

In some embodiments, intake instruction component106may be configured to determine one or more display parameters for displaying intake instructions in a GUI associated with information intake viewer127running on client computing device104. For example, intake instruction component106may adjust the display of intake instructions based on the type of the display associated with client computing device104(e.g., OHMD).

In some embodiments, intake instruction component106may obtain device information from client computing device104related to its type, size of display, functional specifications, and other such information. Further, intake instruction component106may use the device information to obtain one or more display rules associated with that device. In some embodiments, intake instruction component106may determine a set of display instructions for displaying intake instructions in a format for optimized display on client computing device104based on the one or more display rules associated with client computing device104.

In some embodiments, intake analytics component116may be configured to provide programmed instructions for executing one or more reporting operations associated with the intake process.

In some embodiments, intake analytics component116may be configured to generate a report based on the information captured by user160, i.e., information obtained by vehicle information component108, owner information component110claim assignment component112, and/or damage information component114. In some embodiments, intake analytics component116may transmit the report to another party or system. In some embodiments, the report generated by intake analytics component116may comprise an insurance claim that may be transmitted to an insurance carrier or another party. In some embodiments, intake analytics component116may be configured to effectuate presentation of the report in a GUI associated with information intake viewer127running on client computing device104so it can be accessed and viewed by user160.

In some embodiments, intake analytics component116may determine a level of completion and a level of success associated with individual intake instructions (e.g., performing vehicle, owner, and damage information intake) as they are followed by the intake technician and generate a report detailing this information, as described in detail below. Intake completion information may be obtained from client computing device104, including one or more captured images or other data related to particular information intake.

In some embodiments, intake analytics component116may be configured to determine if a particular information intake process has been completed based on user generated input. For example, user160may transmit a voice command via microphone119(illustrated inFIG. 3B) of client computing device104, or a gesture command indicating that a particular information intake process has been completed.

In other embodiments, intake analytics component116may be configured to determine if particular information has been captured based other information obtained from client computing device104. For example, the intake process of particular information may include information related to the time it normally takes to capture that information (e.g., average time). For example, upon determining that the time required to capture vehicle information has elapsed, intake analytics component116may ask user160to confirm the completion of vehicle information. In yet other embodiments, intake analytics component116may determine that information related to the vehicle has been captured upon receiving input that user160has started capturing owner information, and so on.

In some embodiments, intake analytics component116may be configured to request intake completion information from user160. For example, intake analytics component116may generate a request for additional information related to the intake and transmitting it to client computing device104. In some embodiments, the request may include an audio prompt outputted by speaker118(illustrated inFIG. 3B) of client computing device104.

In some embodiments, intake analytics component116may be configured to provide real time or near real time feedback based on the analysis of intake completion information. For example, upon determining that a particular information was not captured and/or not captured successfully, intake analytics component116may generate a message or a voice output indicating that user160must repeat the intake process or capture additional information.

In some embodiments, intake analytics component116may use the intake completion information to determine whether particular information was captured successfully. For example, the quality of images related to the vehicle damage captured by user160may be analyzed to determine if the images conform to one or more image quality standards, for example image standards mandated by an insurance carrier. In some embodiments, intake analytics component116may obtain one or more stored image quality attributes parameters (e.g., sharpness, noise, contrast, color accuracy, and so on) to analyze and confirm that the image meets these parameters, i.e., was captured correctly.

As alluded to above, a conventional intake information process is largely dependent on the intake technician entering data from multiple sources using a variety of input techniques (e.g., manually typing in VIN and owner information, uploading images from a digital camera). Because no verification process ensures quality of the data, traditional input methods are error-prone and time consuming, and may require the input technician to provide supplemental data, thus further prolonging the claim adjustment time. By automatically verifying the accuracy of captured information, improves the wait time associated with receiving a claim adjustment.

In some embodiments, intake analytics component116may obtain information related to the time taken to complete the entire intake process and/or to capture particular information. The actual time may then be compared to the estimated or target time for capturing particular information or completing the intake process. Next, the actual time may be analyzed with respect to the estimated time. The results of the analysis (e.g., performance analysis metric) may be used during future intake processes and/or during training. That is, analyzing the actual time with respect to the estimated time allows tracking individual employee performance, resulting in improved overall intake performance. Additionally, this data can be used for future training opportunities. In other embodiments, intake analytics component116may obtain information related to the information obtained during the intake by individual employees. For example, number of images taken, number of images of low quality that had to be retaken, instructional steps skipped, and so on. Similar to the time of completion data, the information related to the quality of the images may be used for performance tracking purposes, as described above.

FIG. 6illustrates a flow diagram depicting a method for automating the intake of information used to prepare a repair estimate for a damaged vehicle, in accordance with one embodiment. In some embodiments, method600can be implemented, for example, on a server system, e.g., information intake server120, as illustrated inFIGS. 1-2. At operation610, a user of a computer wearable device is directed to capture an image used to identify a damaged vehicle (e.g., VIN), and an owner of the damaged vehicle (e.g., driver's license), for example by intake capture component106. At operation620, vehicle information is extracted from the captured image, for example by vehicle information component108and owner information is extracted from the captured image, for example by owner information component110.

At operation630, claim information, including claim damage information is obtained using the vehicle information, for example by claim assignment component112. At operation640, intake instructions for capturing damage information are generated based on the claim damage information.

At operation650, the intake information captured at operation640is used to automatically update respective data fields of an estimate submission form. At operation650, upon capturing the intake information, a report including vehicle information, owner information, and damage information is generated, for example by intake analytics component116.

Where circuits are implemented in whole or in part using software, in one embodiment, these software elements can be implemented to operate with a computing or processing system capable of carrying out the functionality described with respect thereto. One such example computing system is shown inFIG. 7. Various embodiments are described in terms of this example-computing system700. After reading this description, it will become apparent to a person skilled in the relevant art how to implement the technology using other computing systems or architectures.

FIG. 7depicts a block diagram of an example computer system700in which various of the embodiments described herein may be implemented. The computer system700includes a bus702or other communication mechanism for communicating information, one or more hardware processors704coupled with bus702for processing information. Hardware processor(s)704may be, for example, one or more general purpose microprocessors.

The computer system700also includes a main memory706, such as a random access memory (RAM), cache and/or other dynamic storage devices, coupled to bus702for storing information and instructions to be executed by processor704. Main memory706also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor704. Such instructions, when stored in storage media accessible to processor704, render computer system700into a special-purpose machine that is customized to perform the operations specified in the instructions.

The computer system700further includes a read only memory (ROM)708or other static storage device coupled to bus702for storing static information and instructions for processor704. A storage device710, such as a magnetic disk, optical disk, or USB thumb drive (Flash drive), etc., is provided and coupled to bus702for storing information and instructions.

The computer system700may be coupled via bus702to a display712, such as a transparent heads-up display (HUD) or an optical head-mounted display (OHMD), for displaying information to a computer user. An input device714, including a microphone, is coupled to bus702for communicating information and command selections to processor704. An output device716, including a speaker, is coupled to bus702for communicating instructions and messages to processor704.

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 meaning “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. The terms “a” or “an” should be read as meaning “at least one,” “one or more” or the like. 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.