Patent Grant
11449831
Embodiments relate generally to user interface displays. More particularly, embodiments relate to systems and methods having improved interfaces and computer functionality for Internet-based real-time agriculture data processing.
Certain industries, such as crop insurance, have traditionally implemented complex software interfaces. For example, insurance-focused software systems were traditionally designed as an underwriting tool for Approved Insurance Providers (AIPs). As such, existing software is still provider-focused and generally includes clumsy and outdated display and functionality.
Each crop insurance company uses cumbersome drop downs or file tab interfaces such that the user is the one driving what needs to be done. Anyone using such systems needs to be trained and/or refer to a manual to understand where to enter acres, sales renewal, production reports and claims. For example,
Similarly,
In another example, referring to
In another example, complex spreadsheet-type interfaces are provided. Referring to
In another example, referring to
As shown by the above examples, very limited software system options exist for the farmer on the insured side. Existing provider-focused software presents an overwhelming number of insurance and crop-related information, very little of which is actually applicable to the particular farmer at a particular time of year. For example, the 2018 Approved Appendix III/M-13 Handbook provided by the U.S. Department of Agriculture, herein incorporated by reference, details this type of information. Existing systems rely on provider tribal knowledge of applicable menus, data, and selection options. Moreover, the complex displays and selection options presented by the existing provider-focused software are undesirable to insured farmers. An insured user would be required to search through complex menu systems to find the appropriate data. This is burdensome and hinders the user's ability to operate such systems.
There presently are no keying options for a farmer user. The only users that can key changes in the AIP programs are insurance agent users. Farmer access is limited to an online farmer portal simply to view their policy—a farmer user can't make any changes.
Further, industry software is not intuitive to the user, season, or location; existing industry software presents the same format regardless of whether citrus is insured on the West Coast or tobacco is insured on the East Coast and certainly includes no measure of location or time of year. This challenge is exacerbated as the industry has become Internet-based and distributed.
Farmers report their acres to two different agencies: the Farm Service Agency (FSA), which is part of the USDA, and the farmer's crop insurance agency, which is an independent insurance broker. Since there is no electronic platform for the farmer to use, reporting acres to both agencies is a manual, time-intensive process; the farmer manually writes acreage information onto field maps and then must provide hard copies of the field maps to the FSA office and an insurance agent working for the farmer's insurance agency. Upon receiving the field maps, the FSA office and the insurance agent independently enter the acreage report into their respective software. Eventually the acreage information is synchronized between the FSA and AIP, but the synchronization process takes a minimum of three weeks.
AIP's software often has a farmer portal. The farmer portal allows the farmer to view crop insurance information but does not allow the farmer to enter data or electronically upload information—which is instead done by the crop insurance agent—causing a delay in data synchronization between the farmer, the crop insurance agent, the crop insurance company, and FSA.
AIPs verify that the acres reported at the FSA are within 3% of the acres that are reported to the crop insurance agent. To accomplish this verification, the AIP submits a records request to the Risk Management Agency (RMA) on each policy. The AIP can only ask for a limited amount of records at one time, and the records request for a single policy can be very large, potentially exceeding 200 records. If the AIP must request more records than the record request limit, the AIP must get back in line behind other AIPs to request more. There are 15 AIPs, which means they are constantly in queue. Because the records take a long time to retrieve, the FSA data is not in real time for the farmer or AIP. Additionally, each crop has an acreage reporting deadline. If the AIP has not pulled the farmer's data into the AIP's software by the deadline, the farmer must manually report his acres to the insurance agent. Should this happen, the agent will ask the farmer to submit his FSA papers with the acreage report and will cross check the FSA papers when entering the acreage report. In practice, the farmer must manually report his acres to the insurance agent in most instances due to the delay caused in part by the records request limit and queue. If the FSA data does not match what the farmer wrote on his crop insurance acreage report, the agent contacts the farmer to figure out what numbers are correct. This discrepancy occurs roughly half of the time, and if the data is incorrect at the FSA office, the farmer must return to the FSA to correct the data.
Another problem of traditional systems is that a farmer cannot work his claim until the insurance company has received the acreage report from the insurance agent and has verified the FSA papers for the claim. Waiting for the FSA data to be synchronized with the AIP's system delays the claim at least three weeks, as previously mentioned. This delay prevents the farmer from working his claim and can be especially costly if the farmer has a claim in the spring.
Currently, if a farmer needs to submit a claim, it must be done manually by calling an insurance agent. The insurance agent must then cross check the yields to see if there is a possible claim. If the agent doesn't review the yields in time, the farmer may have a declined claim as it was submitted too late.
The RMA has introduced ACRSI (acreage crop reporting streamlining initiative). ACRSI gives the farmer the option to manually report their acres in person to either the FSA or the insurance agent, and then the receiving party of the report will enter the farmer's acres and electronically submit the data. If the farmer reports to the FSA, then the FSA needs to synchronize the farmer's acres with the RMA. The RMA then further synchronizes the farmer's acres with the AIP when the AIP requests the report. If the farmer reports their acres to the insurance agent, the insurance agent enters the acres into the AIP's software and then the AIP sends the farmer's acres to the RMA, who then additionally sends the farmer's acres to the FSA. Even if there was not a delay in retrieving the FSA records, the farmer still needs to sign a crop insurance acreage report which involves mailing or dropping off a hard copy to the insurance agent. This cumbersome process is summarized in
Therefore, there is a need for systems and methods that can guide insured users through the complex process of crop insurance in real time over a distributed Internet-based architecture.
Embodiments solve the technological problem of how to meaningfully display large and unique data sets on a user device to geographically and communicatively-distributed users. In particular, systems and methods described herein provide a specific solution to existing technological problems in computers and display technologies. This improvement allows computers, for the first time, to provide rapid access to and process information for which they had not been previously available, specifically, insured user-focused data.
This technological improvement is necessarily rooted in computer technology in order to overcome a problem specifically arising in the realm of computer networks. Specifically, large sets of geographically-specific and user-specific data across computer networks are displayed and hidden as appropriate. Likewise, end-user functionality is similarly enabled or disabled as appropriate.
More particularly, embodiments are directed to a particular manner of summarizing and presenting information in electronic devices. As described herein, specific features disclose a specific manner of displaying a limited set of information to the user, rather than using conventional user interface methods to display all provider-accessible data. The disclosed invention improves the efficiency of using an electronic device by bringing together a limited list of common functions and commonly accessed stored data. Specifically, the majority of farmers insure a limited number of types of crops with a limited number of coverage options, but in order to access such data, traditional systems require an agent with tribal knowledge of the data to navigate large data sets. Embodiments described herein solve that problem.
In an embodiment, a system for selective and real-time data display comprises a computing platform including computing hardware of at least one processor, a memory operably coupled to the at least one processor, and configured to store instructions invoked by the at least one processor; instructions that, when executed on the computing platform, cause the computing platform to implement: a graphical user interface configured to display, in real-time, data to a user; and a dynamically-guided subsystem including: a task engine configured to manage task data related to the user, the task data comprising a plurality of tasks, a timing engine configured to determine timing data related to each of the plurality of tasks, the timing data being specific to the user, a location engine configured to determine location data related to each task, the location data being specific to the user, a data integration engine configured to integrate selected task data, from at least one database, and based on a set of decision criteria based on at least the timing data and the location data, and a display engine configured to populate the selected task data to the graphical user interface, and receive user-inputted crop data based on the selected task data from the graphical user interface.
In an embodiment, a method for selective and real-time data display comprises providing a computing platform including computing hardware of at least one processor, a memory operably coupled to the at least one processor, and configured to store instructions invoked by the at least one processor, the computing platform having a graphical user interface configured to display, in real-time, crop data to a user; managing task data related to the user, the task data comprising a plurality of tasks; determining timing data related to each of the plurality of tasks, the timing data being specific to the user; determining location data related to each task, the location data being specific to the user; integrating selected task data, from at least one database, and based on a set of decision criteria based on at least the timing data and the location data; populating the selected task data to the graphical user interface; and receiving user-inputted crop data based on the selected task data from the graphical user interface.
In an embodiment, a system for selective and real-time data display comprises means for presenting a graphical user interface configured to display, in real-time, crop data to a user; means for managing task data related to the user, the task data comprising a plurality of tasks; means for determining timing data related to each of the plurality of tasks, the timing data being specific to the user; means for determining location data related to each task, the location data being specific to the user; means for integrating selected task data, from at least one database, and based on a set of decision criteria based on at least the timing data and the location data; means for populating the selected task data to the graphical user interface; and means for receiving user-inputted crop data based on the selected task data from the graphical user interface.
In a feature and advantage of embodiments, a dynamically-guided presentation subsystem presents data to users in real time. For example, agriculture insurance data can be selectively displayed based on the timing of the season and/or the location of the farmer. Embodiments therefore only include applicable data and/or actions. Icons and the associated computer functionality can be removed from selection. In embodiments, icons are not grayed-out, but removed when an action has been completed. Accordingly, the system eliminates the need for cumbersome tabs and drop-downs.
In another feature and advantage of embodiments, the system guides an insured user through the process with selectively chosen data. In an embodiment, once an action has been completed related to a particular policy for a season, completed components are flagged or segmented so that they are no longer accessed and a subsequent season's components are instead operated on, including display and data retrieval. From the user side, for example, if a farmer has renewed his policy and the timing is after the sales closing date, the farmer can still view quotes but only if selected from a higher level access menu at the top of page. In another example, if farmer has reported acres, the system no longer prompts to enter the acres and instead displays total acres insured and liability. If the timing is before the acreage report due date, the farmer can still revise acres by selecting the icon displayed on the screen. To enable this functionality, interfaces, data, and icons can be semaphored, mutexed, or otherwise locked from access based on timing, location, and task data.
In another feature and advantage of embodiments, a transparency page display generates a sub-display screen into a current display screen instead of loading an entirely new display page. This ensures a consistent, efficient user experience so that the user does not need to leave one screen to get to data on another.
In another feature and advantage of embodiments, quick entry screens allow for efficient entry of commonly used data. For example, a “quick plant” sub-display allows the option to import planting intentions year-over-year as well as add or revise crop hail on the same display page.
In another feature and advantage of embodiments, an intuitive sales renewal user interface immediately shows current coverage, updated coverage, and premium costs, as well as multiple options to select in a compact user interface. In contrast, existing displays require multiple pages of printed quotes. Moreover, after sales season, display interfaces automatically and in real-time depict the coverage elected and liability but no longer encourages a user to renew coverages. As a result, the display screens are more intuitive, less busy, as all of the quoting options for the crop no longer need to be displayed. The back-end algorithms disclosed herein allow for this efficient display.
In another feature and advantage of embodiments, various interfaces allow for acreage reporting. For example, user interfaces allow a farmer user to determine prevent plant, rotate acres functionality, and to report prevent plant and replant claims on the same page.
In another feature and advantage of embodiments, various interfaces allow for intuitive billing interfaces. For example, once a user has paid a bill, the bill pay feature is no longer displayed. In certain embodiments, billing info and documentation can still be accessed by certain menus. In an embodiment, timing data is used to send SMS text and/or email alerts to the user.
In another feature and advantage of embodiments, various interfaces allow for efficient and intuitive production reporting. For example, once a user has entered yields, display screens automatically and in real-time no longer offer the option to enter production but will change to display the next year's coverage options. In an embodiment, the ability to revise yields is available if the user has indicated that crop is stored on the farm and has not been sold. Revise yield interfaces can be available until the production report deadline and then are no longer an option. In embodiments, user interfaces allow for the submission of claims on the same screen as production reporting. Embodiments further allow for unrelated but user-based data to be entered, such as adding or revising hail coverage.
In another feature and advantage of embodiments, if a user has fields that are certified organic, a quote for all organic crops that are insurable for their county is provided by embodiments. The quote can rank the highest revenue crop down to the lowest. This provides the organic farmer an opportunity to determine which crops would be the most profitable to grow in his area.
In another feature and advantage of embodiments, for users who have precision AG, harvest numbers can be automatically linked to a production report. This can determine if there is a payable indemnity as well as complete the requirement to report production. This is beneficial compared to current solutions, which are a manual process in which the farmer has to upload his data, send to agent, who sends it to the AIP. The AIP thus has to manually manipulate the data to get it to import correctly.
In another feature and advantage of embodiments, a dynamically-guided presentation subsystem can comprise a sensor or input engine. For example, a rain sensor or sun sensor can help determine if there is replant or prevent plant prominent in the area which will prompt an adjuster to contact the farmer. Replant acres are extremely time sensitive as a farmer needs to talk to an adjuster prior to replanting. Embodiments can further incorporate weather data from, for example, National Weather Service inputs.
In another feature and advantage of embodiments, planting or harvesting status or data can trigger notifications to the farmer. For example, if 80% of the planting is completed within a county, the users can be asynchronously notified within that county that acreage reports are due. If 80% of the production is completed in the county, the users can be asynchronously notified that production reports are due.
In an embodiment, data analysis algorithms determine a breakdown of a revenue portion compared to a production portion if there is a paid claim.
In another feature and advantage of embodiments, a farmer user can electronically update and enter crop data specific to each FSA common land unit (CLU) without the assistant of a FSA employee or crop insurance agent. The crop-specific data is then uploaded in real time to the RMA (USDA office), the FSA (USDA office), and the ALP (crop insurance company), thereby bypassing direct users of those separate databases (i.e. crop insurance agent and FSA office users).
In another feature and advantage of embodiments, a farmer user can electronically indicate who should receive his crop insurance data electronically as opposed to calling his insurance agent and requesting that the info be sent. Specified recipients can include lenders, agronomists, farm managers, and accountants. The indication can include an electronic location related to the receiver.
In another feature and advantage of embodiments, acres can be directly reported from the farmer user to the AIP and the FSA offices. Acres can be reported by importing planting intentions, precision farming, and manual entry.
In another feature and advantage of embodiments, a farmer user does not need to use a crop insurance agent to procure coverage, change coverage, or purchase hail coverage for private products.
In another feature and advantage of embodiments, a farmer user can execute an FSA re-con electronically, without having to physically go to FSA.
In another feature and advantage of embodiments, a farmer user has direct access to direct quoting based on his specific crop data without an insurance agent user.
In another feature and advantage of embodiments, policies and endorsements can be electronically combined based on an individual farming operation, including running a MPCI quote, hail quote and named peril quote all on the same screen, without a farmer user having to request running the quotes. If too much information is displayed, or if the farmer isn't interested in a product, he can easily deselect the product and the product is automatically removed from the screen.
In another feature and advantage of embodiments, past loss data can be incorporated to provide insurance rate of return and predict claim occurrence specific to the farm location using, for example, location engines.
In another feature and advantage of embodiments, artificial intelligence (AI) data can inform the user of the probability of a claim depending upon the type of insurance purchased. For example, if a farmer wants to purchase hail insurance, the embodiments can calculate and display the hail probability based on actuarial data for the specific fields the farmer user farms.
In another feature and advantage of embodiments, display interfaces can display best buys for a farmer based on actuarial data, as well as a coverage amount for the premium spent. Additionally, when the farmer's policy renews, embodiments can display all products the farmer has purchased on the same screen.
In another feature and advantage of embodiments, a farmer can indicate how much to spend, and a best fit can be calculated. For example, if a farmer wants $800 per acre coverage, embodiments can pull in the products that provide the best coverage totaling $800 of coverage. In another example, a farmer can indicate how much coverage he wants for each crop and a best fit can be calculated. For example, if a farmer wants to spend $18 per acre, embodiments can evaluate and display the best products to keep him under $18 in premium. Competitor's rates can further be displayed for various private products.
In another feature and advantage of embodiments, farmers can enter a plan as to what crops they intend to plant and in which fields the crops can be planted. This plan is referred to as planting intentions. Farmer users can input and upload planting intentions as well as indicate who should receive a copy of the intentions, such as an agronomist user or farm manager user. Any updates on planting intentions can also be sent to those users receiving a copy of the original intentions. Further, planting intentions can be linked to the acreage report, thereby eliminating repetitive work. As part of this linking process, farmers can adjust acres, if needed.
In another feature and advantage of embodiments, a “rotate acres” option, alternatively labeled a “flip acres” option, allows a farmer user to switch between at least two types of crops each year. For example, the majority of farmers in the Midwest plant a corn and soybean rotation, which means the fields that have corn this year can have soybeans on next year, and the rotate acres module can let the farmer switch last year's corn fields to soybean this year and vice versa next year. The rotate acres module can be used for acreage reporting, sales renewal (quoting), and planting intentions.
In another feature and advantage of embodiments, a prevent plant calculator can help the farmer determine if he is eligible for prevent plant, the amount of coverage per acre, the amount of acres eligible, the final plant date for the crop, and whether it is advantageous to plant a different crop.
In another feature and advantage of embodiments, a replant calculator can help the farmer determine if he is eligible for replant coverage, and the amount of replant payment. The replant calculator can automatically and electronically submit a claim to notify an adjuster user.
In another feature and advantage of embodiments, a production reporting module allows a farmer user to directly upload his precision data. When the farmer enters yields, the production reporting module can automatically determine if there is a possible claim. If it appears there can be a claim, the production reporting module can automatically submit a loss by asking the farmer a series of questions, thereby removing the need for the farmer to call an insurance agent. If the yields are not submitted by the deadline to report a claim, the production reporting module can notify the farmer via text, call, or email that the claim deadline is approaching.
In another feature and advantage of embodiments, during claims season, a farmer has the option to upload his scale tickets instead of having to give hard a copy to an adjuster. Additionally, the farmer can have access to claim records to see which adjuster has been assigned to his claim.
In another feature and advantage of embodiments, a farmer can have the option to enter price scenarios to see if he has a payable revenue loss, aiding with revenue price discovery.
In another feature and advantage of embodiments, each Spring (calculated by a timing engine, for example) the farmer can be presented specific questions to determine if there is added land, if new actual production history units need to be set up, if the farmer qualifies as a new farmer, if there is prevent plant, if there is replant, and if other crops need to be added to the policy.
The above summary is not intended to describe each illustrated embodiment or every implementation of the subject matter hereof. The figures and the detailed description that follow more particularly exemplify various embodiments.
Subject matter hereof may be more completely understood in consideration of the following detailed description of various embodiments in connection with the accompanying figures, in which:
While various embodiments are amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit the claimed inventions to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the subject matter as defined by the claims.
Referring to
Embodiments of the system 100, and the corresponding methods of configuring and operating the system 100, can be performed in cloud computing, client-server, or other networked environment, or any combination thereof. The components of the system can be located in a singular “cloud” or network, or spread among many clouds or networks. End-user knowledge of the physical location and configuration of components of the system is not required.
As will be described, the system and/or its components or subsystems can include computing devices, microprocessors, modules and other computer or computing devices, which can be any programmable device that accepts digital data as input, is configured to process the input according to instructions or algorithms, and provides results as outputs. In an embodiment, computing and other such devices discussed herein can be, comprise, contain or be coupled to a central processing unit (CPU) configured to carry out the instructions of a computer program. Computing and other such devices discussed herein are therefore configured to perform basic arithmetical, logical, and input/output operations.
Computing and other devices discussed herein can include memory. Memory can comprise volatile or non-volatile memory as required by the coupled computing device or processor to not only provide space to execute the instructions or algorithms, but to provide the space to store the instructions themselves. In embodiments, volatile memory can include random access memory (RAM), dynamic random access memory (DRAM), or static random access memory (SRAM), for example. In embodiments, non-volatile memory can include read-only memory, flash memory, ferroelectric RAM, hard disk, floppy disk, magnetic tape, or optical disc storage, for example. The foregoing lists in no way limit the type of memory that can be used, as these embodiments are given only by way of example and are not intended to limit the scope of the invention.
In embodiments, the system or components thereof can comprise or include various modules or engines, each of which is constructed, programmed, configured, or otherwise adapted, to autonomously carry out a function or set of functions. The term “engine” as used herein is defined as a real-world device, component, or arrangement of components implemented using hardware, such as by an application specific integrated circuit (ASIC) or field-programmable gate array (FPGA), for example, or as a combination of hardware and software, such as by a microprocessor system and a set of program instructions that adapt the engine to implement the particular functionality, which (while being executed) transform the microprocessor system into a special-purpose device. An engine can also be implemented as a combination of the two, with certain functions facilitated by hardware alone, and other functions facilitated by a combination of hardware and software. In certain implementations, at least a portion, and in some cases, all, of an engine can be executed on the processor(s) of one or more computing platforms that are made up of hardware (e.g., one or more processors, data storage devices such as memory or drive storage, input/output facilities such as network interface devices, video devices, keyboard, mouse or touchscreen devices, etc.) that execute an operating system, system programs, and application programs, while also implementing the engine using multitasking, multithreading, distributed (e.g., cluster, peer-peer, cloud, etc.) processing where appropriate, or other such techniques. Accordingly, each engine can be realized in a variety of physically realizable configurations, and should generally not be limited to any particular implementation exemplified herein, unless such limitations are expressly called out. In addition, an engine can itself be composed of more than one sub-engines, each of which can be regarded as an engine in its own right. Moreover, in the embodiments described herein, each of the various engines corresponds to a defined autonomous functionality; however, it should be understood that in other contemplated embodiments, each functionality can be distributed to more than one engine. Likewise, in other contemplated embodiments, multiple defined functionalities may be implemented by a single engine that performs those multiple functions, possibly alongside other functions, or distributed differently among a set of engines than specifically illustrated in the examples herein.
As will be described, a dynamically-guided presentation subsystem can be configured to manage workflow and presentation processes for user interface 102. The dynamically-guided presentation subsystem is operably coupled to user interface 102 and one or more databases 106 via dynamic agriculture server 104. Further, an analysis subsystem is operably coupled to the dynamically-guided presentation subsystem and configured to receive and analyze data received via the dynamically guided presentation subsystem. The analysis subsystem can further be operably coupled to the user interface 102 and one or more databases 106 via dynamic agriculture server 104.
As depicted in
Dynamic agriculture server 104 can comprise a computer other similarly capable computing or digital device. One skilled in the art will readily appreciate that dynamic agriculture server 104 can be implemented in a singular “cloud” or network, or spread among many clouds or networks. Likewise, dynamic agriculture server 104 can be implemented as a web server accessed using a browser with a remote device, such as a smart phone, tablet, or laptop. For ease of explanation, dynamic agriculture server 104 is described as a single computing device.
Dynamic agriculture server 104 generally comprises a processor 110 and memory 112 operably coupled to processor 110. Processor 110 is configured to carry out the instructions of the various engines for dictation management stored on memory 112. In embodiments, memory 112 can further comprise cache for recent or short term storage of queries and functions of the various engines. Processor 110 can be operably coupled to local database 106a and industry database 106b.
Local database 106a is configured to store local presentation data, including task, timing, presentation interfaces, and icon data. Local database 106b can be a general purpose database management storage system (DBMS) or relational DBMS as implemented by, for example, Oracle, IBM DB2, Microsoft SQL Server, PostgreSQL, MySQL, SQLite, Linux, or Unix solutions, in embodiments. Local database 106a can be integrated into dynamically-guided system 100, or dynamic agriculture server 104, as needed. In embodiments, local database 106a can also store industry-specific data as needed.
Industry database 106b is configured to store industry-specific data such as sales, acreage, billing, and claims data. Likewise, general medical database 114 can be a general purpose database management storage system (DBMS) or relational DBMS as implemented by, for example, Oracle, IBM DB2, Microsoft SQL Server, PostgreSQL, MySQL, SQLite, Linux, or Unix solutions, in embodiments. In general, industry database 106b is remote from dynamic agriculture server 104, but can also be integrated into dynamic agriculture server 104 as needed.
Referring to
In particular, referring to
In an embodiment, dynamically-guided presentation subsystem 200 generally comprises a task engine 202, a timing engine 204, a location engine 206, a data integration engine 208, a display engine 210, and optionally, a sensor/input engine 212. In embodiments, any of task engine 202, timing engine 204, location engine 206, data integration engine 208, and display engine 210 can be operably coupled with each other such that data can be passed.
Task engine 202 is configured to manage the user-specific tasks for presentation. For example, task engine 202 can be preconfigured with or access data corresponding to policy tasks, yield tasks, reporting tasks, coverage tasks, claim tasks, billing tasks, and so on. In an embodiment, task engine 202 is configured to input best practices such as, for example, Sustainable Agricultural Research and Education (SARE) or the USDA and output tasks corresponding to those best practices. In an embodiment, task engine 202 can be integrated with a farm management information system to develop tasks related to the particular farm. In an embodiment, task engine 202 can be integrated with accounting systems, production records, inventory controls, finance evaluations, or an enterprise resource planning system to develop tasks related to the particular farm. In an embodiment, task engine 202 can be integrated with a farmer's almanac to develop tasks related to the particular farm. Task engine 202 can selectively strip these data sources for relevant data related to a predefined set of tasks using natural language recognition and artificial intelligence to supplement the predefined set of tasks. In another embodiment, task engine 202 can selectively strip data sources to define a new set of tasks or individual tasks.
In an embodiment, task engine 202 can be communicatively coupled to other farms' data repositories. For example, task engine 202 can utilize data from other farms to develop tasks related to the at-issue farm. Similar situations (e.g. weather, location, and crop) can then be utilized to more accurately develop task data.
Timing engine 204 is configured to determine timing data related to each task. Timing engine 204 can determine time as narrow or broad as needed for the various tasks. For example, timing engine 204 can utilize a computer clock timestamp for narrow tasks, or in another example, an electronic seasonal calendar indicator for broader season-based tasks. In an embodiment, timing engine 204 can utilize electronic-available timing data such as the relative phases of the moon or daylight phases. In an embodiment, timing engine 204 can dynamically update timing data as necessary, including when an additional piece of timing data is incorporated. In an embodiment, timing engine 204 can derive timing information from a user device, such as the user's mobile or desktop device.
Location engine 206 is configured to determine location data related to each task. In an embodiment, location engine 206 can utilize computer location-based hardware such as a MAC or network address, or GPS-based location of a farm, farm equipment, or farmer location. For example, farm equipment can include a GPS transmitter that can be read by location engine 206. Similarly, a farmer user's personal device such as a mobile phone can include a GPS transmitter or GPS-based “home” setting that can be read by location engine 206. In embodiments, location data can be manually entered into location engine 206, such as the user indicating a relative location on an electronic map.
Data integration engine 208 is configured to integrate task data, timing data, and location data from the various engines and databases to populate the displays of display engine 210. In embodiments, data integration engine 208 is configured to consider various decision criteria related to the task, timing, and location of the data in order to select only appropriate data. Accordingly, tasks are populated according to user-specific timing and location data. In an embodiment, data integration engine 208 can incorporate decision criteria based on individual user data, such as crop not yet sold. In embodiments, once populated, the data is packaged for display engine 210.
In an embodiment, data integration engine 208 can make predictive suggestions based on historical data for the particular farm/field (and/or neighboring farms). Predictive suggestions can be made based on commonality of tasks or efficiency considerations (e.g. a neighboring farm is given more weight than a farm that is far from the instant farm). In another example, a farm operating at higher efficiency is given more weight than a farm operating at lower efficiency. Further, data integration engine 208 can indicate where the instant farm is slow or fast compared to nearby farms and package the task data accordingly. In an embodiment, data integration engine 208 can suggest key times for tasks (planning, etc.) based on the schedule of nearby farms from timing engine 204.
In an embodiment, data integration engine 208 can automatically suggest acreage during a reporting process based on the location data suggested. In an embodiment, data from location engine 206 can be utilized such that planting areas and/or rotations are suggested by analyzing the layout of the farm (e.g. easier to plan certain crops in long, straight rectangles compared to squares due to amount of turns for planting and harvesting).
In an embodiment, in the event of a problem area (or pending claim) on part of the farm (such as a flood), data integration engine 208 can automatically recommend a new layout with available space and report damage to the insurance agent user or insurance company database.
In an embodiment, data integration engine 208 can track or allow the farmer to enter pesticide location and/or frequency to order to predict the location of potential spread (in case of danger to other crops or “organics” considerations.
In an embodiment, data integration engine 208 can find and compare similar farm profiles based on data from location engine 206. In an embodiment, data integration engine 208 can automatically anonymize all data moving in and out of the system to provide privacy for the instant farm and comparison farms.
Display engine 210 is configured to display selected task data, as populated by timing engine 204, location engine 206, and data integration engine 208. In embodiments, display engine 210 can be integrated with a user interface such as user interface 102. The goal of display engine 210 is to present task data as applied to the specific user without overwhelming the user with massive amounts of data. For example, intuitive data fields, graphical icons, and radio buttons are utilized to intuitively present data to a user and receive data from the user. Algorithms determining the type and style of presentation are described herein, which one skilled in the art will understand can be implemented across task engine 202, timing engine 204, location engine 206, data integration engine 208, and sensor/input engine 212 as appropriate.
In an embodiment, display engine 210 is configured to populate the selected task data to the graphical user interface by selectively presenting all products the user has purchased on a single screen. Usability is thereby improved over existing systems.
In an embodiment, each of the plurality of tasks includes a set of icons associated with the task. Accordingly, display engine 210 is further configured to delete from memory the sets of icons for all tasks that have been completed. For example, icon data is not stored in the cloud and does not take up any memory. In an embodiment, a first step in executing a task is deleting the previous task's icon data and temporary data. In another embodiment, a final step in a task is deleting that task's icon data and other temporary data. Thus, memory usage is more efficient compared to existing systems.
In an embodiment, display engine 210 is further configured to populate a primary screen and a task-based screen, wherein upon log-out and re-log-in, the display engine is further configured to immediately populate the task-based screen. Usability is thereby improved over existing systems.
In an embodiment, display engine 210 is further configured to automatically present a subsequent task in the plurality of tasks once a previous task in the plurality of tasks is completed, as shown in subsequent figures and algorithms. More particularly, once an action has been completed, the main screen changes based on what has been completed. For example, crop insurance comprises four quarters (sales, acreage reporting, production reporting and claims). Once a quarter is done or if all actions within the quarter are completed, the system moves on to the next quarter (task). For example, if a farmer has reported harvested yields (production report), embodiments will proceed to the next cycle (e.g. sales screen). In an embodiment, if a deadline is approaching and the farmer has not completed certain criteria, the farmer will receive a text, phone call or email (he chooses) to remind him of the deadline. Usability is thereby improved over existing systems.
In an embodiment, dynamically-gided presentation subsystem 200 can optionally further comprise a sensor/input engine 212. In an embodiment, sensor/input engine 212 can utilize one or more sensors to drive task engine 202 presentation. For example, sensor/input engine 212 can be operably coupled to a rain sensor, sun sensor, atmospheric pressure sensor, or any other suitable sensor. Data from such sensors can be incorporated into task engine 202 so that tasks can be micro-tailored to particular users. For example, users in locations receiving an excess amount of rain can be presented different tasks that users in locations receiving an excess amount of sun. In embodiments, sensors can be located at specific user locations, such as a particular farm, or at particular regions such that regional data can be extrapolated for a particular location within that region. In another embodiment, sensor/input engine 212 can interface with databases containing weather data, such as from the National Weather Service.
Accordingly, external weather synchronization (both negative and positive weather indications) can be realized with sensor/input engine 212 to optimize the presented tasks. For example, a planting task may be moved up or back in the task schedule based on frost timing, rain, sun, etc.
In an embodiment, display engine 210 is configured to display and receive selected task data according to the algorithms described and depicted herein. For example, referring to
Referring to
I/O engine 222 is configured to receive user-inputted data from display engine 210, and upload analyzed data to various network locations. For example, I/O engine 222 can upload data in real time to a plurality of industry databases, such as an RMA database, an FSA database, or an AIP database. I/O engine 222 can be further configured to upload data to another electronic location, such as to particular users on the network (e.g. an IP address, FTP location; HTTP location, email address). In an embodiment, I/O engine 222 is programmed with the various data structures and protocols for particular target databases and particular users. Accordingly, I/O engine 222 can package data transmissions in packages unique to the target database or target user.
Analysis engine 224 is configured to analyze the user-inputted data. In an embodiment, the analysis can include normalizing, segmenting, parsing, or otherwise manipulating the data for later use or transmission. In an embodiment, analysis engine 224 can forward raw received data to I/O engine 222 such that the received data is not analyzed.
Referring specifically to
Referring specifically to
In embodiments, even if yields have not been reported, a user can still select Add or Revise Hail Coverage 314, an important workflow differentiator from existing systems.
Referring specifically to
In another embodiment, referring to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
In various embodiments, based on data from, for example, task engine 202, icons and their associated particular functionality is not displayed when the portion of the task related to that icon or display is not applicable to the timing, location, or has already been completed. In embodiments, “hidden data” can be deleted from memory to create more efficient storage.
Referring to
Referring to
In embodiments, as illustrated, portions of certain tasks can be pre-defined such that they can include P13 data. In embodiments, other tasks are customized to the individual farmer user (and are not addressed in P13). System flow is designed to present specific questions each season, and input from the user based on those questions then determines how the system responds. The way a user answers will determine if there are other questions to present or if the system can move onto the next task. When the questions are sufficiently answered, the user is routed to the next step, which is predefined. Accordingly, embodiments are customized to each user. Put another way, set questions are presented regardless of where the user farms, and other questions are presented based on the farmer user location and how the farmer user answers the previously-presented questions.
Referring to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Referring specifically to
Accordingly, time-based displays are achieved. In an embodiment, during the time period of March 16-April 29, if yields aren't reported, the home screen displays lines to report yields. Yields can be reported by importing precision field data, uploading scale tickets, or manual entry. Further, the following options are also visible on the primary screen: view current coverage, update planting intentions, replant calculator, prevent plant calculator, and add or revise hail coverage. In an embodiment, once yields are reported, the following disappear: yield lines, import precision field data icon, and upload scale tickets icon. In an embodiment, if yields are reported, the home screen displays: current crop coverage and add or revise hail coverage. Icons are also displayed to update planting intentions, replant calculator, prevent plant calculator, and update/revise previously reported yields
In an embodiment, during the time period of April 30-June 15, crop lines are displayed, making it easy to report acres. The following options also appear: quick plant, add or revise hail, import precision field data, FSA recon, import planting intentions, replant claim prevent plant calculator, add land, and field maps. In an embodiment, once acres have been reported, crop lines are replaced with a summary of planted acres by crop. The following icons (options) are then available: revise acres (available up to July 15), add or revise hail coverage, field maps, schedule of insurance, and APH.
In an embodiment, during the time period of June 15-July 15, crop lines are displayed, making it easy to report acres. The following options also appear: quick plant, add or revise hail, import precision field data, import FSA acres, report acres to FSA, import planting intentions, replant claim, prevent plant calculator, and field maps. The following icons (options) are also available: revise acres (available up to July 15), add or revise hail coverage, field maps, schedule of insurance, and APH.
In an embodiment, during the time period of July 15-August 15, a revenue calculator is displayed with the following options: pay bill, report claim, share data, and report yields.
In an embodiment, during the time period of August 15-September 30, fall renewal and a revenue calculator are displayed with the following options: report claim, share data, pay bill, and add fall crop.
In an embodiment, during the time period of October 1-October 31, a revenue calculator is displayed with the following options: report claim, share data, pay bill (if bill is paid in full, the pay bill icon is not displayed), and report yields (if yields are reported for all crops, the report yields icon is not displayed).
In an embodiment, during the time period of November 1-December 14, if yields have not been reported, the home screen displays a report yields icon. A user can report yields by importing precision field data, uploading scale tickets, or manual entry. In an embodiment, the following options are also visible: report claim, pay bill (once bill has been paid in full, this icon disappears). In an embodiment, once yields have been reported, the yield lines disappear and are replaced with options to renew coverage (sales season).
In an embodiment, during the time period of December 15-March 15, the home screen displays current coverage and sales renewal options with quotes. The following icons are also displayed: compare products for all companies, update planting intentions, update field info, pay bill (if not already paid in full), report yields (if not already reported), revise yields (if yields have been reported but need to be revised), add crop or county, 1099 info, revenue price discovery.
Various embodiments of systems, devices, and methods have been described herein. These embodiments are given only by way of example and are not intended to limit the scope of the claimed inventions. It should be appreciated, moreover, that the various features of the embodiments that have been described may be combined in various ways to produce numerous additional embodiments. Moreover, while various materials, dimensions, shapes, configurations and locations, etc. have been described for use with disclosed embodiments, others besides those disclosed may be utilized without exceeding the scope of the claimed inventions.
Persons of ordinary skill in the relevant arts will recognize that the subject matter hereof may comprise fewer features than illustrated in any individual embodiment described above. The embodiments described herein are not meant to be an exhaustive presentation of the ways in which the various features of the subject matter hereof may be combined. Accordingly, the embodiments are not mutually exclusive combinations of features; rather, the various embodiments can comprise a combination of different individual features selected from different individual embodiments, as understood by persons of ordinary skill in the art. Moreover, elements described with respect to one embodiment can be implemented in other embodiments even when not described in such embodiments unless otherwise noted.
Although a dependent claim may refer in the claims to a specific combination with one or more other claims, other embodiments can also include a combination of the dependent claim with the subject matter of each other dependent claim or a combination of one or more features with other dependent or independent claims. Such combinations are proposed herein unless it is stated that a specific combination is not intended.
Any incorporation by reference of documents above is limited such that no subject matter is incorporated that is contrary to the explicit disclosure herein. Any incorporation by reference of documents above is further limited such that no claims included in the documents are incorporated by reference herein. Any incorporation by reference of documents above is yet further limited such that any definitions provided in the documents are not incorporated by reference herein unless expressly included herein.
For purposes of interpreting the claims, it is expressly intended that the provisions of 35 U.S.C. § 112(f) are not to be invoked unless the specific terms “means for” or “step for” are recited in a claim.
This Application claims the benefit of U.S. Application No. 62/767,258, filed Nov. 14, 2018, entitled “Systems and Methods for Selective and Real-Time User Interface Display,” which is fully incorporated by reference herein.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5897619 | Hargrove et al. | Apr 1999 | A |
| 6990459 | Schneider | Jan 2006 | B2 |
| 9202252 | Smith | Dec 2015 | B1 |
| 9569803 | France | Feb 2017 | B1 |
| 20050027572 | Goshert | Feb 2005 | A1 |
| 20130185104 | Klavins | Jul 2013 | A1 |
| 20140012732 | Lindores | Jan 2014 | A1 |
| 20140035752 | Johnson | Feb 2014 | A1 |
| 20140350997 | Holm | Nov 2014 | A1 |
| 20160078570 | Ethington et al. | Mar 2016 | A1 |
| 20160247082 | Stehling et al. | Aug 2016 | A1 |
| 20160253595 | Mathur et al. | Sep 2016 | A1 |
| 20170091478 | Tiller et al. | Mar 2017 | A1 |
| 20170161627 | Xu | Jun 2017 | A1 |
| 20170213141 | Xu | Jul 2017 | A1 |
| 20170257426 | Wilbur et al. | Sep 2017 | A1 |
| 20170287082 | Karube | Oct 2017 | A1 |
| 20180322426 | Schmaltz | Nov 2018 | A1 |
| 20190090432 | Duquette | Mar 2019 | A1 |
| 20190347745 | Bones | Nov 2019 | A1 |
| 20190347836 | Sangireddy | Nov 2019 | A1 |
| 20200128721 | Lewis | Apr 2020 | A1 |
| 20200175475 | Olson | Jun 2020 | A1 |
| Entry |
|---|
| NAU Country Company. A QBE Insurance Company. EASY Quote User Guide. Installing, Configuring and Using EASYquote3. Jan. 22, 2018. https://www.naucountry.com/docs/default-source/agent/easyquote/easyquote-user-guide.pdf?sfvrsn. |
| NAU Country Company. A QBE Insurance Company. Mobile Policy Management. © 2019, As accessed on Nov. 13, 2019. https://www.naucountry.com/farmers/farmer-tools/mobile-policy-management. |
| NAU Country Company. A QBE Insurance Company. Production and Acreage Reporting. © 2019, As accessed on Nov. 13, 2019. https://www.naucountry.com/farmers/farmer-tools/precision-farming-and-acrsi. |
| NAU Country Company. A QBE Insurance Company. Weather Metrics. © 2019, As accessed on Nov. 13, 2019. https://www.naucountry.com/farmers/farmer-tools/weather-metrics. |
| YouTube. EASYquote: Creating a basic quote. Published Jan. 18, 2018. Transcript of the video is provided. https://www.youtube.com/watch?v=Qdn9iv3XMss. |
| United States Department of Agriculture Farm Service Agency. The Acreage Crop Reporting Streamlining Initiative (ACRSI). As accessed on Nov. 13, 2019. https://www.fsa.usda.gov/programs-and-services/initiatives/acrsi/index. |
| United States Department of Agriculture. 2018 Approved Appendix III/M—13 Handbook. Risk Management Agency; (2018). As accessed on Nov. 13, 2019. https://www.rma.usda.gov/en/Policy-and-Procedure/Appendix-III-M13-Handbook-Index/2018-Approved. |
| International Search Report and Written Opinion, International Application No. PCT/US2019/061203, dated Feb. 10, 2020, 18 pages. |
| European Search Report, European Application No. 19884071.2, dated Jul. 11, 2022, 9 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20200175475 A1 | Jun 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62767258 | Nov 2018 | US |
