WO2008106783A1

WO2008106783A1 - A generic, customizable navigation, layout and reporting system for mobile forms data capture

Info

Publication number: WO2008106783A1
Application number: PCT/CA2008/000422
Authority: WO
Inventors: Darren Nelson
Original assignee: Spoton Systems Inc.
Priority date: 2007-03-07
Filing date: 2008-03-07
Publication date: 2008-09-12

Abstract

A system for the automated synchronization of data collection forms and their fields to a relational database via an XML schema and metadata layer is provided. Data, which is input remotely into forms is collected, analyzed and used in reports. The system comprises a wizard-based form designer tool, a form deployment and routing mechanism, applications operating the forms, mobile data capture devices for the input and collection of data, a database repository to store the collected data in a data capture server, a data transfer client application periodically in communication with the data capture server, a reports and metadata generator component, and one or more target devices or field users.

Description

A Generic, Customizable Navigation, Layout and Reporting System for Mobile Forms Data Capture

Field of the Invention The present invention relates generally to data capture and management and, more particularly, to a system and method for creating, deploying, and managing data capture mechanisms that are customizable for any purpose. The system allows for the useful data reporting and analysis in a timely and cost effective manner.

Background of the Invention

Data capture has been occurring for centuries. When the volume of data exceeds or is expected to exceed the capacity of a typical person's short-term memory, it is practical to capture the data in a permanent or quasi-permanent manner, such as by writing. Historically, wherever possible, it was efficient for the data or the person possessing the data to travel to a central input location where the data could be gathered, stored and processed for later use or analysis.

In many circumstances, the data or person possessing the data "travels" to the location where the data is collected. For example, people visit their financial advisor to provide various data such as their name, address, assets, liabilities and financial goals.

Patients provide health information prior to being admitted to a hospital. Purchasers complete and mail information to register warranties on consumer products.

Often however, it is more appropriate for the person gathering the data to travel to the location where the data can be gathered. Property inspectors need to be on site to note the structural characteristics of a dwelling. A person repairing the electrical, plumbing or heating systems in a house typically need to be present to understand the nature and scope of the required repairs. Exit poll survey takers gather demographic and voter data soon after a vote is cast.

In this respect, mobile data capture is part of our everyday lives. People locate or receive information while on the go, and capture some or all of the information such as by writing on a form. The form can be placed in a temporary storage area, such as a clipboard. Mobile data capture can be as trivial as jotting down a grocery list for later referral, or as critical as carefully taking a victim's information as well as other observations at the scene of a crime.

Often the data needs to be accurately captured, such as health records or financial data, because other people, processes or activities will rely on the accuracy of the data. After the accumulation of at least two sets of records, comparisons can be made. As more and more data is gathered, it is analyzed to discover trends and other valuable information. For more complex data capture requirements, individuals and organizations have devised standardized forms, specific to a given situation, so that the same type of data can be gathered consistently, independent of the person gathering or inputting the data.

When forms are filled by hand, the data is often later transcribed into a more permanent and accessible records database. Sometimes more than one person is responsible for initially gathering the data, interpreting it, and later entering it into a system. The more people or the more processes that are responsible for data gathering, the greater chance that errors may occur during the collection phase due to inaccurately read information, misread handwriting, mistyped keys, or other human- related reasons.

More recently, forms-based data capture technology has been developed that operates in a web browser or as a client application on a mobile device. W3C and other groups have proposed a variety of standards, such as HTML, XHTML, XForms, or XUL that can be generically used for designing interfaces which can be employed for data capture linked to extensible markup language or XML. Amongst others, Adobe

(LifeCycle Forms™) and Microsoft (InfoPath™, Outlook Forms™) have product offerings for building and deploying generic forms-based applications. Still others, such as Research in Motion (Mobile Data System™) and TrueContext (mXForms™) have product offerings for building and deploying generic mobile applications.

With LifeCycle Forms, Adobe provides a software solution for the management of online forms. The system allows administrators to create data entry forms from

Microsoft Word™ documents and other word processors. The forms are stored centrally and access controls are enforced. Collected data is the responsibility of the implementer.

Research In Motion currently provides an Integrated Development Environment

(IDE) for the creation of mobile data applications. This offering requires developers with knowledge of the RIM platform, as well as extensive programming skills.

TrueContext's mXForms has product offerings for building and deploying generic mobile applications. Application builders are required to design from scratch, each and every new application. This approach requires developers with knowledge of various programming languages, and does not store the data outside of modified XML files. For instance, one of the operational requirements of mXForms is that each set of XML files must be parsed by a custom application and manually mapped to its final data repository. In this respect, there is no generic application that parses any possible

XML files output by the mobile client.

All of these approaches are generic application builders that require each new specific application to be custom designed. Technical skill is required in order to build and deploy such applications. In addition, these approaches do not possess integrated reporting and analysis support for the data that the applications collect.

Significant time, effort, and cost are required to provide a usable and useful solution that integrates data capture with reporting. There are numerous niche vendors who have canned applications for specific verticals, such as packaged delivery for massed asset delivery, but they have limited flexibility with limited customization capabilities often tied to specific technology choices.

The data captured in the field is typically introduced in a database, from which it can be later recovered for further processing, report generation, etc. Due to several economic and practical implications, it is desirable that the collected data be compatible with market-standard, commercially available database formats. In order to ensure this compatibility, application engineers have typically been used to monitor and review customization for any particular purpose which is performed on the data collecting application. Given the various needs of different users regarding data fields, data form aspect, etc. customization is frequently required. However each time a change is made to core systems, extensive testing must be performed to ensure seamless integration, which adds to the time delay in providing the final system and ultimate cost.

In fact prior art platforms require at least a certain amount of customization in order to interact with commercial databases. The average user either makes do with whatever standard features are included in the system or pays an additional sum for customizing it to the user's business specific needs. Therefore, there is a need for a data capture and reporting system that allows customization with minimal or no additional cost for the user. Furthermore, it should entail minimal risk, if any, regarding compatibility with mainstream, commercial databases.

Many organizations have struggled to deliver timely information to their clients, executives, and knowledge workers. Often, simple questions cannot be answered for days, weeks, even months, such as quantifying the work performed in a given day, understanding the time it took to perform each task or confirming whether a shipment arrived at its intended destination.

In order to answer these and many other questions, an organization had to invest in data capture systems, whether paper-based or electronic, and require its staff to accept and follow these systems. Once the data was captured, the information was presented to decision makers and knowledge workers. Converting the raw captured data into useful information could be difficult and expensive. Often, the organization may not appreciate how certain processed information could benefit the organization. Reporting in order to present and analyze collected data, such as report trends, is not new. In addition to a wide set of available relational databases and reporting tools, more recent technology has focused on On-Line Analytical Processing based on "cubes" and relational data sets that are optimized for reporting. Microsoft, IBM

Cognos, Business Objects and Hyperion are just a few companies in this industry. They also have support for collecting and reporting data that is delivered in the form of XML.

Generally, enterprise-class and/or commercial-grade reporting tools include the following features: high availability, multi-lingual support, high scalability, remotely managed system, capable of ad-hoc reporting, capable of operational reporting, and capable of OLAP analysis.

However, the current approach to reporting is limited, in that the data capture mechanism is usually reserved for migration purposes specific to those systems. In the present state of the art, there is no enterprise-class, commercial grade reporting tool that has any specific support for integration with forms-based data capture, and particularly mobile forms-based data capture.

Organizations sometimes struggle to train their staff when new technologies are introduced, resulting in organizational inefficiencies. The employee that, for a long period, has developed a comfort and familiarity at completing a given standard form may reject or fear a new way of collecting the data, if elements in the capture mechanism are not familiar. Therefore there is a need to provide the ability to customize a form actually used by the field user with considerations as to the forms currently employed so as to foster a smooth transition from the traditional technology devices, such as paper sheet forms, to the digital technology employing mobile or other data-collecting devices. This type of consideration may require several attempts at customization by administrators with field user feedback, which is not practical to do with prior art applications given the cost and time for customization.

In order to overcome the problems identified in the prior art, there is a need for a data capture and reporting system that allows customization with little or no additional cost for the user, which is compatible with mainstream, commercial databases. In addition, there is a need for an enterprise-class, commercial grade reporting tool supporting integration with forms-based data capture, and more particularly mobile forms-based data capture.

Summary of the Invention

The invention described herein addresses the conflict between user customization and compatibility with mainstream commercial database formats by increasing the user's autonomy without compromising compatibility. The user is enabled to customize the data forms with a degree of latitude which is spacious enough to cater to the user's specific needs and yet preserve the ability to interact with commercial databases.

Another aspect of the present invention is the elimination of additional costs and time delays, traditionally associated with customization by obviating the requirement of advanced programming skills every time a form template is customized. Thus empowered, the user can create a form or set of forms in an intuitive manner, in a single environment. Such abstract form definitions generate and deliver rich forms across any electronic data capture device including mobile phones, Blackberry™ devices, Windows Mobile™ devices, laptops, web browsers, etc. Forms data is automatically captured, validated, delivered and warehoused in a dynamically known database structure, optimized for business intelligence analysis and reporting.

It is an object of this invention to provide a system for creating and customizing data capture forms, applications and their integrated reporting and analysis, including multi-locale support.

It is a further object of this invention to provide a system which comprises a wizard- based interface.

It is a further object of this invention to provide a generic, navigational, layout, and reporting structure optimized for data capture that can be rendered for both data capture forms and reports on a variety of mobile data capture platforms.

It is a further object of this invention to provide a system which comprises integrated generation of metadata, report and security structures that can be integrated with any third-party reporting and analysis platform.

It is a further object of this invention to provide a form deployment and routing mechanism that can be integrated with any third-party email, calendar or scheduling application. It is a further object of this invention to provide an electronic system that allows for the replication of a standardized form's functionality.

It is a further object of this invention to provide integration with third-party notification and routing systems.

It is a further object of this invention to provide means to create a single form layout definition whereby forms are rendered on any device.

It is a further object of this invention to provide means to allow one or more users to populate parts of a form, and one or more other users to view and/or modify previously entered data.

Brief Description of the Drawings Figure 1 is a depiction of a generic abstract structure according to the present invention.

Figure 2 is a depiction of an embodiment of the present invention showing a generic, customizable navigation, layout and reporting framework.

Figure 3 is a depiction of another embodiment of the present invention showing a generic, customizable navigation, layout and reporting framework.

Figure 4 is a depiction of an appraisal application embodiment according to the present invention. Figure 5 is a depiction of a form design step according to the present invention.

Figure 6 is a depiction of a form publishing step according to the present invention.

Figure 7 is a depiction of a form scheduling step according to the present invention.

Figure 8 is a depiction of a step in which the form is pushed to the user according to the present invention.

Figure 9 is a depiction of form editing step according to the present invention.

Figure 10 is a depiction of data capture in the field according to the present invention.

Figure 11 is a depiction of data form(s) viewing according to the present invention.

Figure 12 is a depiction of the form designer application as it appears in a mobile device's screen, according to the present invention.

Figure 13 is a web browser depiction of the scheduling of the users that will fill in the data, upon the publishing of the forms, according to the present invention.

Figure 14 is a depiction of the metadata updating for reporting purposes according to the present invention. Figure 15 is a depiction of the generic data structure for the form that contains contact information, according to the present invention.

Figure 16 is a depiction of the list of forms made available to the scheduled user in the scheduled user's mobile device, according to the present invention.

Figure 17 is a depiction of a simple contact information form, illustrating sample data entry options, according to the present invention.

Figure 18 is a depiction of a simple contact information form, illustrating further data entry options, according to the present invention.

Detailed Description

The mobile devices used with the system of this invention can be based on any technology so long as there is the capability to input data and the capability to transmit the data. Once input into the mobile device, the data can be stored in a temporary or permanent manner. Once a key threshold of input data is met, such as some or all the information concerning a given record, the device must have the capability of transmitting the captured data, preferably, though not necessarily, in a wireless manner, to a data capture server. The data batches can be sent in raw form

(i.e.: unpacked) or in another form (i.e.: packed) in order to optimize the bandwidth used for the transmission. If packed data is sent to the data capture server, it is unpacked upon or soon after arrival. Alternatively, such as in situations where bandwidth size is less of a concern, the data can be continuously transmitted to the data capture server. Therefore data can be input on a variety of mobile devices, using any type of data capture platform, such as web browsers, J2ME devices, Blackberry™, Windows-based PDAs, smartphones, laptop, etc.

A generic abstract navigational, layout and reporting structure is shown in Fig. 1. The structure populates and generates user interfaces, data files such as XML data files, a database repository and reports, as needed. The structure comprises an application schema, such as an XML document. The schema can comprise various data assets, such as user name, graphics or images, personalized labels, bar codes, video, audio, linked lists, repeaters, complex hierarchies and simple form lists. A data asset, such as the user name, is linked to a specific field, within a specific form, within a specific application schema.

The database comprises a fact table, which may be a star schema, of specified dimensions. The database is automatically created by the system prior to the field user inputting data in the mobile device. When forms are created and published to the field user community, the database tables are automatically generated by the system. These tables will warehouse the data eventually input by field users. A unique key is generated. Furthermore, all textual and date fields are indexed for performance optimization.

The function for third-party reporting and analysis allows for the integration with an outside reporting provider, such as the IBM Cognos 8 BI™. The system of the present invention as described, does not include the reporting engine although it is contemplated that the invention and reporting engine may form one cohesive application which combines the features of the invention and the reporting function. There are both static and dynamic metadata elements that provide the reporting interface to the database repository. Metadata is created on-the-fly to accommodate the specific labeling and custom fields of each application. The metadata also serves as the starting point for creating the automated and custom reports.

In accordance with Fig. 2, a wizard-based designer or other user-friendly prompt guides an administrator user to create a new or modify an existing generic abstract structure or form template. In essence, the abstract structure provides the instructions to generate the application schema for each particular field task. Since each application will have different content, the interface must be both flexible and managed via a known workflow. The administrative user is empowered to modify a given application schema, such as by adding new data fields to a given field application, within the constraints of the wizard-based designer. The wizard-based designer prevents the user from compromising the system's regular workflow by creating non-standard data fields which would not be instantly recognized by the system upon performing data warehousing, reporting and other system functions. The wizard-based designer establishes a limited set of admissible, standard data fields, and prevents the user from introducing any non-standard data fields in the forms generated by the wizard.

Therefore the present invention's establishment of a generic abstract structure coupled with a wizard-based form designer harmonizes the requirements of data input flexibility and system format compliance. For example, the application schema for a drug trial system will be different from the application schema for a bill of materials system. These two applications differ in content, but the overall system will adhere to the abstract structure of each.

The present invention automatically generates and associates a stream of metadata to allow the report generator to recognize and communicate with the data. That is a typical use of metadata to be found in several commercially available products. For example, IBM Cognos has a metadata layer which allows its reporting applications to communicate with the user's data. In addition to IBM Cognos metadata, the system according to the present invention can integrate with other commercial reporting and lifecycle systems such as Microsoft Reporting Services™, SAP Business Objects™ and Adobe LiveCycle™.

One aspect of the invention is the automatic conversion and exposure of form collection documents, such as XML documents, to third party metadata for reporting. In order to identify the metadata format required for each specific third-party platform, the system according to the present invention relies on a "plug-in" mechanism. This "plug-in mechanism" ensures compatibility by formatting the invention's output metadata layer according to whatever reporting tool is selected. There are simple Application Programming Interfaces (APIs) exposed that can be satisfied by any vendor's metadata requirements. Examples of typical APIs are

"prepareForms" and "publishMetadata." The use of these APIs allows for the abstraction of the intricate details of each vendor's metadata mechanism requirements. Since the present invention's system generates the database tables, and knows the labels associated with each form field, the system can leverage the metadata "plug-in" for each BI vendor's metadata layer. The form fields are mapped to database tables and database table fields. However, this mapping alone is not sufficient for proper metadata integration. In the present invention, the actual field labels, in any language, are also exposed to the metadata layer so as to allow the reporting system user to know which data items are being used.

Various other components of the invention's system are described.

The data capture scheduler allows a user, such as an administrative user to pre- populate information in a form, and assign it to a target or field user who is responsible for completing some or all of the form by inputting data. In one embodiment, the scheduler uses a role-based security system to determine access capabilities. In another embodiment, the system according to the present invention can make use of the existing security systems from the third-party BI system that is being used.

For example, consider an organization that has an Active Directory server with 10,000 user profiles. To help manage the security issues of an additional set of users, to the system leverages the existing security infrastructure. The present invention is capable of using the security system of the very BI system being used, thus ensuring tight integration with the BI system and also reducing the cost of managing the additional repository of users. In one embodiment, there is provided a relational database management system (RDBMS) which comprises a database repository that stores the collected data in a data capture server. It comprises pre-configured tables, views, stored procedures, and functions that are required to operate the system and provide data to the reporting engine.

The data capture server provides the interface to produce and consume documents to and from mobile devices and web browsers. A purpose of this component is to provide login functions, initial asset delivery, such as XML documents that render the devices' interface, and a set of mechanisms to send, receive and confirm task delivery and process completed documents. The pack/unpack components are processes that lie dormant for a configurable timeout period. Once awakened, these processes seek newly dropped tasks, which may be in the form of compressed XML documents, images, video clips, sound clips, etc, and proceed to extract them into a temporary structure.

The reports and metadata generator component renders assets, such as XML documents, that were packaged and delivered by the data capture and data capture server components. It then pushes the information into a pre-defined database schema, which is the database repository component.

The same reports and metadata generator component prepares metadata for reporting. Upon receiving XML assets from the wizard-based designer, the generator analyzes the data field types, and uses predefined rules to create fact tables and metadata based on this XML. An example of the metadata created can be seen on Fig. 14. The generic abstract structure component comprises the schemas, such as XML schemas, and the RDBMS schemas that provide the framework for building generic data capture applications. This allows the system to follow a pre-defined flow and stock data into a pre-defined schema. The consistency of these structures provides the flexibility to build data capture applications tailored to the user's needs.

In the present invention, the wizard-based form designer tool, which is a simple web- based tool, can incorporate the functions of an XML editor. The complexities of the editing are hidden behind user friendly drag and drop controls. The data collection forms are created with simple gestures and minimal user intervention. This tool requires very little knowledge of data collection systems. Forms can be simple or complex. Complex forms allow for the creation and management of large lists, while simple forms allow for data capture with common input elements.

The data asset toolbox component allows the user to choose which pre-configured layout component to use on a form. The toolbox provides a drag-and-drop functionality to the wizard-based designer, serving as a visual, simplified representation of the complex XML editing actually carried out. This reduces the requirement of programming skills the user must have in order to use the present invention.

The forms can be customized within the limits of the wizard-based form designer and asset toolbox component. The invention leverages the administrative user's request for form elements. There is a user-specified number of available element controls that can be added to a form, or set of forms. By providing the administrative user with these controls, various parameters including the following can be determined: data type, constraints, available options (eg: pick lists or mutex lists), and parent form.

When the parameters are set, the system of the present invention can generate the required entries in known database tables, as well as generate new database tables which can be designed for high-speed reads, which are ideal for reporting. Since the data types are known, as well as the name of each field, the system can also create a metadata layer on top of the physical database tables, enabling automated integration with Business Intelligence systems such as those provided by IBM Cognos, SAP,

Microsoft and other systems commercially available.

In order to handle data capture devices that do not possess "push" capabilities, such as the current Pocket PC™ and a web browser, the present invention features a data transfer client application. It lies dormant for a configurable period of time, and then awakens to check with the data capture server for any new tasks. Completed tasks are delivered to the server. This component is also responsible for interfacing with the target device's contact manager and calendar systems. A depiction of one embodiment of the present invention comprising a data transfer client is illustrated in Fig. 3.

The data capture client application is the main user interface for collecting data. The application has been built to run on multiple platforms, including web browsers, mobile phones, PDA, Blackberry™, etc. The screen flow is pre-defined, but the elements are created on-the-fly at runtime based on the XML created by the wizard- based designer. The forms are filled out, XML is modified, digital media can be added, and when completed, the data is packaged, compressed and delivered to the repository with one or more simple commands, typically initiated by the field user, such as "Send". Given the reports and metadata generator component, reports are automatically created and available for immediate retrieval, such as by download to the device, pick up from the portal, or delivered via email or other means to one or more recipients.

In one embodiment, the packaged data capture component is initialized when a field user is working on or has completed a task. XML containing selections and entries, as well as other digital assets are consolidated and packaged for transport.

The third party email clients, calendars and schedulers are implemented via the data transfer client. This is a set of interfaces that allows the task-specific information to be integrated into the device's existing services.

Figures 5 to 1 1 illustrate in seven steps an embodiment of a generic example of use of the present invention. As illustrated in this embodiment, the steps are successive in nature. To the extent that any particular step does not rely on a previous to occur, other embodiments of the present invention may comprise two or more simultaneously occurring steps or steps within a different order.

In Step 1 (illustrated in Fig. 5) an administrator user performs the design of a form by entering instructions in the invention's wizard-based form designer. In Step 2 (illustrated in Fig. 6) the form layout created by the user, with its data field parameters already limited to those offered by the wizard-based form designer, is published to the Reports and Metadata Generator, duly framed by the Generic Abstract Structure. Based on the combined input of the form and abstract structure, the corresponding metadata is generated and forwarded to a third party report and analysis tool, while the database objects contained in that specific form layout are warehoused in the Database Repository.

In Step 3 (illustrated in Fig. 7) the Data Capture Scheduler marks the new form layout as available for the field users scheduled to receive them, returning them to the database repository afterwards.

In Step 4 (illustrated in Fig. 8) the Data Capture Server pushes the form layout to the field user's mobile device, such as by wireless communication means.

In Step 5 (illustrated in Fig. 9) the Data Capture Client application, which runs in the field user's mobile device, renders the form for the field user to input data to it. Subsequently, the same application is used to render in the mobile device any reports the field user may request.

In Step 6 (illustrated in Fig. 10) the data is input by the field user. Once some or all of the form is complete and the data transfer is triggered, the data transfer client application in the mobile device relays the packaged data to the Data Capture Server application, which unpacks the data, if required, and stores it in the Database Repository. In Step 7 (illustrated in Fig. 11) a user such as the administrator user, the field user or other user requests the data for visualization, and the third-party reporting and analysis tool consolidates the data obtained from the Database Repository in the requested visualization report.

There are limitless applications for the implementation of the present invention, across all industries, where mobile data capture is required or desirable. All of this is possible because the data that is collected from the mobile device is stored and processed as described above, complete with metadata, which allows for immediate report generation.

The following are just a few examples of implementation capitalizing on the present invention's features.

a) Property Inspection, Appraisal and Valuations

The collection of data during the inspection, appraisal or valuation processes is used to determine trends in this industry, including quality of properties, average time to complete inspections, anomalies, etc. Since the collected data is stored in a known format and includes information regarding the user performing the task, as well as where and when the task is being performed, analysis across all tasks/inspections is possible in an on-demand manner. The capability to generate immediate reports yields improved quality of service for these industries. One such scenario is depicted in Fig. 4. In this embodiment, a bank requires a home appraisal application to replace its existing paper-based system. A four-step process is illustrated. In the first step, the bank's system administrator uses the invention's wizard-based designer and the data asset toolbox to design the layout for the forms. This task only needs to be performed once, unless changes are required to the forms.

In the second step, once the form layout is complete, the system administrator publishes the forms to the required users, allowing forms to be accessible on their mobile devices. This triggers the creation of metadata and reports, utilizing the generic abstract structure to limit the contents of the actual data fields to what is admissible regarding further processing, and stores information in the database repository. In the third step, the user logs into the data capture client with pre-assigned credentials. This invokes the data transfer client, communicates with the data capture server and retrieves the form layout XML to draw the forms on the field user's (eg: appraisor's) mobile device. In addition, any scheduled tasks are added to the field user mobile devices' email and calendar systems. In the fourth step, the field user performs the field data collection and marks the tasks of filling in the forms as complete. All data assets are sent to the packaged data capture subsystem and prepared for transport. Once ready, the data transfer client delivers the assets to the data capture server, such as by wireless communication means. Data assets are then disassembled and stored in the pre-configured database repository, where reports are generated. The reports are then available for automatic email or other delivery back to the bank's system administrator and any other individuals who are required in the transaction. The reports can also be made available to the user in the field, to be printed or emailed. b) Health and Wellness

Individuals and/or personal trainers capture information with mobile devices during a physical training or fitness session. This information becomes part of the overall collected data. Since information about the individual and/or trainer is known, valuable information can be extracted, such as duration of session, time of activity, type of activity, body part exercised and body metrics.

In addition, this data can be sliced across any known dimension such as gender, age, address, weight, height, or other demographic information. Once trends are identified, organizations can adapt to offer appropriate services. For example, if the collected data from several fitness clubs in a given area indicates that a significant number of individuals in a certain demographic are exercising the lower leg muscle groups, specific training sessions can be offered by the organization at an appropriate time (i.e.: a time which is convenient to those individuals, given their previous work out times) to exercise those muscles.

c) Pre-owned Motor Vehicles

The collection of data is required for the purpose of quality control, customer satisfaction, warranties, etc. The data collected is immediately and automatically delivered from the inspected vehicle into the data collection system where it will be stored in the known database structure (fact tables) and reports will be immediately delivered to the required parties, for example: clients, quality control managers, division managers, district managers, etc. Upon completion of a critical mass of inspections, the data can be analyzed and compared across various dimensions, such as vehicle make and model, year, color, body style, etc. In addition, any collected measure can be used to aggregate the data, such as mileage, age, engine size, number of cylinders, fuel consumption ratios, etc.

d) Surveys and Voting

The creation of a survey form template is possible within minutes. Once the survey is prepared, it is automatically delivered to the data collection device where the field user (eg: survey taker) can begin filling out the form(s). Once the survey information is collected, the data is automatically delivered to the data capture server for processing. The survey data is immediately pushed into the known database schema and survey results are prepared in a report and delivered, or made available for download on the web. This method allows for the seamless creation, reporting, and analysis of surveys by non-technical users. In addition to the survey data being collected and reported on, the format in which it is stored allows for the natural mining of data by OLAP tools such as IBM Cognos PowerPlay™.

With the necessary safeguards in place, such as ensuring validation and anonymity, voting can be achieved with the present invention. Implementing the invention for voting may reduce or eliminate the possibility of low voter turnout under the current known voting systems, especially during inclement weather, as the voter can exercise his or her right by accessing a mobile device. The current state of the art, including text voting using a toll free number, affords only a limited and time sensitive access to the nominee's information. The present invention overcomes this problem when a voting form is accessed through a mobile device such as a smartphone. Immediate and accurate results can be achieved.

e) Transportation and Logistics

Many transportation and logistics companies have changing requirements due to regulatory and/or business demands. As such, the procurement of task-specific devices becomes cost prohibitive for small and medium enterprises, as well as larger organizations with many fleet units. The use of the system of the present invention allows for the provisioning of forms in the field within minutes. Forms are created by administrators without the need for high technical skills. The newly created forms are delivered to the device for use by field users (eg: fleet members). Data collected is immediately and automatically delivered to the data capture server for processing. The collected data is stored into a known database schema and reports are automatically generated and delivered to the required parties.

β Financial Planners/Insurance Retailers

Currently many financial organizations are overwhelmed by the volume of paper used for each transaction. By leveraging several key features such as signature capture and data entry time-coding, the strict rules of financial institutions can be observed, while optimizing the time to complete a given transaction. By provisioning forms in minutes, the retailer can collect all necessary data about the client, the transaction, etc as well as capture the client's digital signature. Once the data is collected, it is automatically and immediately delivered to the data capture server for processing. The collected data is stored into a known database schema and reports, including pixel-perfect financial/insurance forms, which are produced and delivered to the required parties, such as clients, clearing houses, managers, retailers, etc.

g) Simple Forms

A child can devise a simple form, populate it with data and send it to a parent as an educational tool. For example, an 8-year old can choose to make a simple list of tasks that have to occur to clean up her messy room. The checklist could include, for example 1) make bed, 2) put away toys, 3) fold clothes, etc. Once each task is accomplished, the child can mark it as checked off on her mobile device, such as a telephone. When the room is clean, the child can take a digital picture of the room as proof of her efforts and send the form to the repository. A standard email report can be sent immediately to a caregiver.

Older students can use simple mobile forms to keep track of homework assignment requirements. The student can create a form comprising fields for the homework assignment, particular class, due date, and choose from a list of tasks required to complete the assignment successfully. The data transfer client on the device can synchronize the data with the calendar function for scheduling reasons.

The foregoing has constituted a description of specific embodiments showing how the invention may be applied and put into use. These embodiments are only exemplary. The invention in its broadest, and more specific aspects, is further described and defined in the claims which now follow. These claims, and the language used therein, are to be understood in terms of the variants of the invention which have been described. They are not to be restricted to such variants, but are to be read as covering the full scope of the invention as is implicit within the invention and the disclosure that has been provided herein.

Claims

I claim:

1. A navigation, layout and reporting system for data input into one of more forms, comprising in combination: a) a wizard-based form designer tool; b) a form deployment and routing mechanism; c) applications operating said forms; d) one or more mobile data capture devices that collect input data for said forms; e) a database repository storing the collected data in a data capture server; f) a data transfer client application periodically in communication with said data capture server; g) a reports and metadata generator component; and h) one or more target devices or field users.

2. The system according to claim 1, wherein a wizard-based interface is used to create and customize said forms, the applications that operate said forms and their integrated data report and analysis, including multi-locale support.

3. The system according to claim 1, wherein the form deployment and routing mechanism renders a layout and reporting structure for both data capture forms and reports.

4. The system according to claim 1, wherein said reports and metadata generator component provides for the integrated and automatic generation of a stream of metadata.

5. The system according to claim 4, wherein said metadata is integrated with a reporting and analysis platform and includes the exposition of field labels to the metadata layer.

6. The system according to claim 2, wherein said wizard-based designer establishes a set of admissible, standard data fields, and prevents said user from introducing any non-standard data fields in the forms generated.

7. The system according to claim 1, wherein said one or more mobile data capture devices capture said data are capable of data input and data transmission.

8. The system according to claim 7, wherein said data is stored in a temporary or permanent manner in said one or more mobile data capture devices.

9. The system according to claim 1, wherein said data can be sent in batches from said one or more mobile data capture devices to said data capture server either in raw or packaged form.

10. The system according to claim 1, wherein said data can be sent from said one or more mobile data capture devices to said data capture server by continuous transmission.

11. The system according to claim 1, further comprising a data capture scheduler which determines system access capabilities.

12. The system according to claim 1 , wherein said database repository is a relational database management system (RDBMS).

13. The system according to claim 1, wherein said data capture server provides login functions, initial asset delivery and a set of mechanisms to send, receive and confirm task delivery and process completed documents.

14. The system according to claim 1, wherein said reports and metadata generator component renders assets comprising said data and pushes said data to said database repository.

15. The system according to claim 1, wherein said wizard-based form designer tool incorporates the functions of an XML editor.

16. The system according to claim 1, wherein said wizard-based form designer tool incorporates a data asset toolbox which allows said user to design said one or more forms based on a set of pre-configured form layout components.

17. The system according to claim 16, wherein said data asset toolbox features drag- and-drop functionality as a visual representation of complex XML editing.

18. The system according to claim 1, wherein said data transfer client application periodically prompts said data capture server for any new tasks, delivers completed tasks to the data capture server and updates the contents of said target device's contact manager and calendar systems.

19. The system according to claim 1, wherein said one or more mobile data capture devices include one or more mobile phones, J2ME devices, Blackberry^™, Windows- based PDAs, smartphones, laptops and web browsers.

20. The system according to claim 1, wherein said mobile capture devices are the same as said target devices.