US20150112930A1 - Method and apparatus for mobile data collection and management - Google Patents

Abstract

A method and apparatus for a middleware approach to initializing and updating required data entry fields, pushing such required data entry fields to mobile devices and applications, collecting entered data from such mobile devices, and the synchronizing and integrating of the data is presented. A “form builder” software component of the present invention allows for the creation of easy to read and use data entry forms by company management. A “web application” software component of the present invention allows for the forms to then be distributed via electronic and/or wireless means to mobile client devices, such as PDA's, Tablets, and Laptops, and to Desktop computers. The mobile client devices run applications to utilize the data entry forms and are that into which collected data can be entered. A “synchronization server” software component of the present invention then allows for two-way communication, storage and conflict resolution (versioning) of the collected data. An “integration server” software component of the present invention allows for external access to the collected and versioned data and modeling/mapping of such data. Thus seamless data entry, collection, updating, conflict resolution, versioning, storage, access and utilization is available.

Description

PRIOR PATENT APPLICATIONS
• The present application claims the benefit of U.S. patent application Ser. No. 12/834,879 filed Jul. 12, 2010, which claims the benefit of U.S. patent application Ser. No. 11/787,538 filed Apr. 17, 2007, which claims the benefit of U.S. Provisional Application No. 60/792,927 filed Apr. 18, 2006, the disclosures of each which are hereby incorporated by reference.
FIELD OF THE INVENTION
• The present invention relates to a method and apparatus of utilizing electronic forms, surveys and applications for mobile devices and of the collection and management of the data thereafter, and, more particularly, to a method and apparatus for incorporating complex business rules in template forms, data entry surveys and applications, distributing such forms, surveys and applications, along with user specific content/data, via electronic means such as the internet or wireless communications, and the collection, synchronization and integration of the entered data.
BACKGROUND OF THE INVENTION
• In a client/customer oriented world, servicing the client/customer through the efficient, timely and up-to-date collection and management of data is more important than ever. As organizations look for ever smaller edges over the competition, it is a must to increase their productivity in field data collection and analysis. One such edge can be had by the streamlining of the movement of client/customer data along with complex business rules, work flow and validations from the organizational enterprise to the field and vice versa. Being able to disseminate data or information efficiently are measurable ways to lower costs, increase revenues, optimize productivity and improve process management.
• Accordingly, once an organization has decided to implement a new solution for their data collection and management needs, certain necessary factors need to be considered. While specific tools provided to organizations differ among the configurable mobile platform products, there is a standard set of criteria any mobile platform provider should be able to deliver. Some of these elements include:
• • A strong architecture and robust feature set that can deploy applications to a mobile taskforce quickly, that is in days/weeks rather than months/years.
  • The ability to create an organization's mobile application once and then deploy it to various mobile devices such as SmartPhones, PDAs or Tablets. This way the organization is never tied to one technology.
  • Implementation of a technology that is proven in the real world and can be rapidly deployed.
  • Solutions should be easy to use by both executives and non-professional workers. Thus, a low learning curve is necessary.
  • The ability to migrate all existing business rules/logic and validation from a backend system to the mobile application, therefore decreasing any learning curve and increasing productivity.
• Many retail stores have specific backend systems in place upon which their technological hierarchy has been built. For instance, there are various types of mobile platforms to consider, synchronization of these various platforms, and data storage on various servers and databases. Clients also desire to have the backend systems integrated to the retail store side, and to have the ability to make custom reports that suit their business needs. Further, with an ever expanding stable of programs for various tasks, modules for data collection and management needs, flexibility and an ability for easy modification are a necessity.
• Retail stores are now using mobile handheld checkout devices to assist their retail customers in a seamless and quick checkout process. These mobile device checkout devices allow a retail store clerk to enter data for a particular product into the handheld device which device then presents data corresponding to pricing, quantity and other data points for the particular product. Having such data readily available to the store clerk and the retail store customer facilitates the point of sale transaction, wherein the store clerk need only scan the product SKU, check the product information, swipe the credit card and print-out a receipt, all through the handheld point of sale mobile transaction device.
• Having the aforementioned technology issues, and facing issues of integrating the data acquired at the mobile device to the stores backend retail purchasing and inventory systems, retail stores are looking for a middleware approach which can tie the various systems together and allow for both forward and backward data synchronization and storage, as well as the ability for ease of mobility and use of handheld devices serving the retail store's customers.
• Thus as can be seen, issues and problems have arisen with the use of the current system architectures that need resolution.
SUMMARY OF THE INVENTION
• Accordingly, the present invention is directed to providing a method and apparatus for a data collection and management system architecture that allows for data collection on a mobile device and synchronization of the data to back-end systems. Such is accomplished by the present invention by providing an end to end solution that puts the power of developing robust applications not only in the hands of the software developers, but in the hands of the business users as well.
• The present invention allows the full life cycle, that is, the creation, deployment, management and data analysis of an application and all related business processes to be simplified through various components. Paper forms are converted into a configurable mobile application through utilization of the present invention's “form builder” component. The component has built in wizards that allow an end user to achieve the creation of applications that need sophisticated filters, logic, jump patterns and complex business rules without the knowledge of programming. Thus organizations can simply “configure” their mobile applications as opposed to having to “develop” them. This significantly lowers cost and risk associated with a point or custom solution.
• Additionally, the present invention also allows mobile workers to collect data via the “mobile client” device component and to synchronize the collection of such data to the organization through the “synchronization server” component. In this manner then access to organizational data to and from the point of capture is allowed. It also allows the mobile worker to receive any kind of data (work history, schedule, reference material, alerts, etc) on the device from the enterprise, on demand or based on rules defined on the server.
• Additionally, the present invention allows for external feeds from hardware attachments or hardware device features built into the mobile device (e.g., GPS, photo capture, barcode scanner and RFID) that, through the “integration server” component, can be integrated into the system.
• The present invention, including its features and advantages, will become more apparent from the following detailed description with reference to the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 is an illustration of an overview diagram of the various middleware components of a mobile data collection and management system, according to an embodiment of the present invention.
• FIG. 2(a) is an illustration of an implementation hardware architecture of a data collection/management network platform of a mobile data collection and management system, according to an embodiment of the present invention.
• FIG. 2(b) is an illustration of an implementation of the communication architecture of a data collection/management network platform of a mobile data collection and management system, according to an embodiment of the present invention.
• FIG. 3 is an illustration of a diagram of the technical software architecture of the synchronization server, integration server, mobile client and operating systems and elements of a mobile data collection and management system, according to an embodiment of the present invention.
• FIG. 4 is an illustration of a methodology by which forms, surveys and/or applications may be constructed within the “form builder” component of a mobile data collection and management system, according to an embodiment of the present invention.
• FIG. 5 is an illustration of a methodology by which management of the created, distributed and collected forms, surveys and/or applications can be accomplished via electronic means with the “web application” component of a mobile data collection and management system, according to an embodiment of the present invention.
• FIG. 6 is an illustration of a methodology by which data transmission, data collection conflict resolution, form, survey and/or application versioning, and storage of the collected data occurs as performed by the “synchronization server” component of a mobile data collection and management system, according to an embodiment of the present invention.
• FIG. 7 is an illustration of a model of the platform architecture during a synchronization action as carried out by the “synchronization server” component of a mobile data collection and management system, according to an embodiment of the present invention.
• FIG. 8 is an illustration of a methodology by which external access to the collected and versioned data and modeling/mapping of such data occurs as performed by the “integration server” component of a mobile data collection and management system, according to an embodiment of the present invention.
• FIG. 9 is an illustration of a methodology by which the present invention delivers specific applications from the data collection and management system to the customer systems, according to an embodiment of the present invention.
• FIG. 10 is an illustration of a model of a centralized deployment of the implementation of the hardware architecture of a data collection/management network platform of a mobile data collection and management system, according to an embodiment of the present invention.
• FIG. 11 is an illustration of a model of a distributed deployment of the hardware architecture of a collection/management network platform of a mobile data collection and management system, according to an embodiment of the present invention.
• FIG. 12 is an illustration of an example of the middleware application architecture of a mobile data collection and management system, according to an embodiment of the present invention.
DETAILED DESCRIPTION
• FIGS. 1 through 12 illustrate a method and apparatus for a data collection and management system by which means template forms, data collection surveys and applications with complex business rules, along with user specific content/data, can be electronically created and distributed to mobile devices, and the data then collected and/or modified, stored, versioned, synchronized and managed.
• Referring now toFIG. 1, the present invention's end toend solution10 consists of five main components, that is: aForm Builder100, aWeb Application200, aSynchronization Server300, anIntegration Server400 and aMobile Client500. These five components are interconnected but, depending on the function to be performed, all don't necessarily need to be used together in performing the system's functions. Each component will be discussed in detail below, but as a brief overview each has a general function of:
• • Form Builder100: the form builder component allows for the creation of powerful forms/surveys/applications, retaining all business rules and validations, into which data can be entered;
  • Web Application200: the web application allows for management of users, forms and data;
  • Synchronization Server300: the synchronization server allows for a 2 way transport method as between the handheld devices in the field and the system itself;
  • Integration Server400: the integration server allows for a 2 way transport method as between the system and any external data sources; and
  • Mobile Client500: the mobile client allows for collection of data on various handheld devices.
• Referring now toFIGS. 2(a),2(b) and3, the physical hardware implementation and software requirements for thesystem10 are shown, respectively, according to embodiments of the present invention. Accordingly, regarding utilization of software, various parts of the platform of thepresent system10, such as theForm Builder100,Web Application200,Synchronization Server300, and theIntegration Server400 were developed using JAVA while themobile client500 was developed in C/C++.
• A preferred embodiment of theForm Builder component100 is run on a computer server having specifications of a CPU with a 1G+ speed, minimum RAM memory of 512 MB, hard disk drive space of 32 MB, and supports an operating system, such asWin 2000++ (excluding Win ME), or any operating system capable of running in a Java Runtime Environment (JRE) v1.4+. A preferred embodiment of theMobile Client component500 is supported on a Tablet XP or XP Professional (Windows 32 OS), Mobile Operating Systems (Win CE v4.1), Windows Mobile 5, and PocketPC 2002/2003. Additionally, the Mobile Client component can run communication components and supports peripheral and data collection devices via Bluetooth and WIFI. Preferably the development software tools used to create the dynamic applications and differing template forms, data collection surveys and applications can include: Borland JBuilder 2005, Sun Java SDK (v1.4), Visual Studio C++ (v7.1), and MS Embedded C++ (v3.0 or 4.0). Accordingly, the Mobile Device applications are configurable and allow for change/add business rules in real-time.
• Preferred embodiments of theWeb Application component200,Synchronization Server component300 andIntegration Server component400 are any J2EE Application Servers (e.g., WebSphere, Tomcat, JBOSS), run in a JRE v1.4+, and haveSQL Server 2000 SP3 security protocols. The servers are preferably capable of at least 500 simultaneous connections at 8 MB per connection, have a bus speed of 1.5 GHZ, and 512K RAM memory. It should be noted that each server is scalable as each has the ability to operate on both distributed and non-distributed processing models. Thus the system can supports additional servers (e.g.,servers201,202,301, and302) with numerous simultaneous users.
• With regard to thedatabases15 and16 (et. al), preferably the present invention uses it's own optimized databases which are based on a “Network Database Architecture”. This method offers fast search capabilities, multiple queries, and storage of complex parent/child relationships. Preferably utilizing a PPC (133 MHZ Processor) that can retrieve at least 263 records per second (300 byte) or 10,000 records in 38 seconds. In addition, some key attributes of this model of data storage are that it allows for modeling of many-to-many relationships of the data, supports a multi-parent concept, and is a network model that is based on mathematical set theory. It is to be understood, however, that alternative storage support may be utilized.
• In terms of implementation data transmission over the transport layer, data transport is handled using XML/SOAP and a BXML format that is compressed and encrypted to increase performance and minimize bandwidth usage. With regard to the security of the data, all transmissions from the System's servers to the client devices or vice versa is done over HTTP/HTTPS using BXML which compresses and encrypts the data to transfer it quickly, safely and securely. Thus in transit the data is both secured via https and in a binary format (i.e. unreadable to the naked eye). Preferably the underlying data is also encrypted/decrypted via blowfish 128 bit block cipher encryption and the LZ77 Deflation compression algorithm. Thus even if broken the underlying data is in a format that would render it useless, thereby providing end-to-end security.
• With regard to the communication architecture, the architecture can operate in two modes, that is a managed mode and a non-managed mode. In the managed mode, theform builder component100 andweb application component200 are utilized as described herein. In the non-managed mode, these components are not utilized.
• Instead, in the non-managed mode, there are two methods by which the non-managed mode works. The methods are the “proxy pass-through” method and the “proxy pass-through with data sync” method.
• With the “proxy pass-through” method, a retail customer usesAPI1000 which is embedded into the retail customer's existing code base onmobile device500. In such manner,API1000 is instructed to communicate withsync server300. Thesync server300 in return receives any communication requests and processes it throughintegration component400.Integration component400 takes the initial request sent bymobile device500 and redirects it to the appropriate back-end database of thecustomer system2000.
• In certain instances, the initial request that is communicated to thecustomer system2000 prompts a response from the customer system2000 (i.e., where the initial request requests a response). Then that response is communicated fromcustomer system2000 toIntegration component400, which response then gets processed bysynch server300, which response then gets communicated back toAPI1000, which response then gets displayed onto themobile device500.
• For example, where themobile device500 is utilized in a price checking capacity, a bar code SKU number on a piece of clothing is scanned by the mobile device. The SKU number is sent to thesync server400 by theAPI1000. At thesync server400 theintegration component400 takes that SKU number component and sends a request to the appropriate back-end customer system2000.Customer system2000 recognizes a price for that SKU number and then communicates that price back tointegration component300 insync server400. The response is communicated back toAPI1000, which displays a value of the piece of clothing onmobile device500.
• With the “proxy pass-through with data sync” method, the architecture need not have connectivity at all times between themobile device500 and thesync server400 in order to function. Instead data is synchronized from thecustomer system2000 onto themobile device500 utilizingmemory3000.Memory3000 is resident on themobile device500. This architecture allows for either one-way or bidirectional synchronization. One-way synchronization downloads data fromcustomer system2000 tomobile device500 with the expectation that the data source will always becustomer system2000. Bidirectional synchronization, on the other hand, downloads data fromcustomer system2000 onto themobile device500, but has changes made to that data and then synchronizes it back tocustomer system2000.
• For example, in inventory management a retail store receives an inventory request from headquarters. Such request is downloaded into the device (e.g., listing the inventory to be counted), and upon taking of inventory by scan, a list of purchases that should exist is modeled by the data and sent back to headquarters.
• Referring now specifically toFIG. 2(b),integration component400 has been coupled withsynchronization server300 to be a little more fluid in operation. Such is accomplished whensync server300 receives a request from themobile client500, themobile client500 instructssync server300 to use a specificintegration server component400. A part of the communication then instructs as to whichspecific integration component400 should be utilized for integration operation.
• Returning to the price check example,mobile client500 communicate withsync server300 by sending a value data point, such as a SKU bar code scan, and, in addition to that value data point, also specifies whichintegration component300 should process that SKU bar code scan. Theintegration component400 is prebuilt to accept commands or data requests from themobile component500, having a code to communicate to thecustomer system2000 to communicate the value data point with an expectation that a response will be forthcoming with information on that value data point, such as price and description of product. Such information then gets sent back tomobile device500.
• Referring now toFIG. 4, theForm Builder component100 is the tool that is used to create the template forms, data collection surveys and business rule applications that are run on theMobile Client component500 and subsequently managed through theWeb Application component200. The Form Builder is designed to be user-friendly and allows authorized users (e.g., IT or business users) the ability to design, develop, edit and deploy handheld forms, surveys and applications.
• In other words, the form builder's user interface and menu driven structure support the development and updating of forms/surveys/applications that utilize sophisticated scripting and business logic, by the business unit or internal IT resources. A key benefit of this design is the ability to self-maintain the system and deploy new forms and changes more rapidly without reliance on outside programmers. Another key benefit of this design is the ability to maintain processes defined by a business at the application level on the mobile client, thus eliminating the need for long training sessions and additional resources needed for references, and therefore improving the quality of the data pushed to the enterprise.
• TheForm Builder component100 comprises three operative interface pieces, that is, theTemplate Editor110, theSurvey Builder120, and theScript Creator130. The vast majority of forms are thus created using these interface pieces. It is to be understood that each of the three operative interface pieces may be utilized together or separately, and indeed, in so being utilized separately are therefore to be considered as independent one from the other.
• Insteps112 and114, the first operative interface piece, theTemplate Editor110, allows a system user to, respectively, design or choose a template form or edit an existing template form. The Template Editor is a full Graphic User Interface (GUI) development environment for editing/building forms. The system user selects the “Templates” tab to expand and present a list of template forms that are already populating theTemplate Editor110. The list may be categorized into groups. The template forms may be loaded in to the survey creation tree by double clicking.
• As is further shown inFIG. 4, the second operative interface piece, theSurvey Builder120, allows a system user, in step122, to create a new survey. The system user fills in a name for the respective survey they wish to create.
• Alternatively to, or in conjunction with, loading a template form, a system user may load a dataset. A dataset is a list of questions that the system user can use in order to create a new survey.
• When a system user desires to create a survey utilizing a dataset there are attributes that need to be provided. Dataset questions in the “Data Tree” represent questions with predetermined answer choices. A child dataset may be required depending on the structure and nature of the survey being created. The parent dataset is one level higher and directly associated with one or more children. A child dataset is on the dependent side of a hierarchical relationship where the parent would be on the controlling side. The child dataset is one level lower and must have one parent. Creating a child dataset requires the same process as creating a parent dataset.
• If the system user so desires, in step124 in conjunction with the above or again yet alternatively the system user may load a list of stored templates for use in the newly created survey. Utilizing each of these interface pieces, questions and data inputs for the field users are created (all from drop down GUI interfaces) for the forms. Accordingly, as has been show, questions can be made mandatory and answer choices can be pre-populated to minimize user error.
• TheSurvey Builder120 further allows a system user, instep126, to define and group object properties for each loaded survey and/or template form. Thus, specific properties and validations for the surveys/forms can be set. In addition, incorrect data entry error messages can be defined, font sizes and colors can be determined, graphics can be inserted, screen objects aligned, etc. For ease of use the screen designer is a drag and drop interface. Also in addition, the present invention supports various question types and “look and feel” controls (such as scroll bars and tab driven interfaces), as well as user friendly form and data element selection features (such as drop down lists, radio buttons, check boxes, text area for open ended questions), graphical drawings, signature captures, and numeric entry.
• TheSurvey Builder120 also further allows the system user, in step129, to save and, if so desired, further edit the form. Selecting to save the form would save the application in a bxml format within the database on the server (as further described below). A form preview screen then allows the system user to preview what the form(s) will look like on mobile devices before it is provisioned to the field. This has the practical effect of enabling better QA testing and design of the forms.
• As is further shown inFIG. 4, the third operative interface piece of theForm Builder component100, theScript Creator130, allows the system user to manually script advanced logic into the form if the need arises. TheScript Creator130 is a script wizard for implementing sophisticated logic (e.g., scoring logic, field verification, etc.) allowing for significant functionality and flexibility to be generated automatically. Thus, referring back toFIG. 4, in step132 the system user can operatively define logic (i.e., devise script) for the template forms or data collection surveys. The wizard operates by system user input and decision making along a series of steps via GUI based functionality. Such allows for a non technical user to create complex logic, manipulate control properties (i.e. font, color, size, etc.), set validations, filter lists, define jumps, define data save points, populate controls with value, etc., without ever having to write a single line of code. For the more technical user scripting can also be implemented directly. Accordingly,Script Creator130 allows for complete customization of forms and much more advanced logic.
• Together the three operative interface pieces of theForm Builder component100 allow the system user to develop and deploy much more than a simple template or data collection survey, and instead, system users can create comprehensive applications based on complex business processes.
• Referring now toFIG. 5, theWeb Application component200 is the computer software application that allows system users to access theSystem10. The Web Application runs on any J2EE compliant application server such as, for example, Apache Tomcat. This enables the present invention Web Application to be platform-independent.
• As is shown in the Figure, the present invention's Web Application component grants administrators three separate management abilities, that is, allowing administrators to manage the system users, manage the forms, surveys and applications in the systems database, and manage the collected data. As is detailed in the following paragraphs, this allows for form/survey/application creation and design management, distribution management, and management reporting through an intuitive and easy-to-use web interface.
• In allowing management of system users, instep210, a system administrator can create and/or edit system users and/or groups, and instep220, a system administrator can associate users and/or groups to specific forms, surveys or applications. In allowing management of the forms/surveys/applications in the systems database, instep230, the system administrator can view and selectively edit data fields in the forms, and instep240, can control who is able to access the forms. The system administrator can then choose the appropriate survey to view and edit. In this manner then, the system administrator can retain control over what data needs to be entered by the field users, control internal access, and implement, if so desired, a licensing program to control external access.
• In allowing management of the data, instep250, data can be exported, for instance into MS Excel, and instep260, reports and/or queries can be run against the data that has so far been collected in the field. There are three types of reports that a system administrator can run, that is, Tabular, Linear and Summary Reports. The Tabular Report allows the system administrator to select fields (questions) from the survey that is chosen and then display the data collected in a tabular (line list) format. The Linear Report shows data as a set of elementary (linear) records, which can be sorted by any field. The Summary Report details are displayed in a summarized format allowing the system administrator to group the data by certain fields. In this manner then, the system administrator can effectively manage the data collected.
• Thus, as can be seen, theWeb Application component200 allows system end-users to access their data, create queries, develop and design reports and export data without intervention by IT staff. Access to these functions can be limited based on user rights and is managed within the Web Application.
• Referring now toFIG. 6, theSynchronization Server component300 is the computer hardware/software that allows for control of the secure and efficient transmission and storage of data, forms and surveys as between the various other components of the mobile data collection andmanagement system10. TheSynchronization Server component300 also, as a primary feature, allows synchronization between the mobile devices of theMobile Client component500 and the architecture'sdatabase15, and re-transmission support such that if data was not synchronized the transmission is not lost and but is sent on next synchronization. The Synchronization Server component can be managed through a management console application which offers full management and configuration of the server.
• The first feature of theSynchronization Server component300 is, insteps310 and320 respectively, the control of storing and backing-up data on a central server database20 and on a organization's server database21. As an additional feature, instep330, theSynchronization Server component300 will synchronize the data, forms and surveys stored as between the various databases.
• Additionally, instep340, data versioning of forms and data collected from the mobile devices is accomplished and controlled by theSynchronization Server component300. Each time data is entered and each time a form is saved, new versions are saved. This is accomplished by storing such versions of the form and data therein entered under different version numbers. Thus during the life cycle of form modifications and data entry, the initial data model that was created is kept intact. If, for example, a particular question is removed from the form/survey, the question is removed from the form/survey, but not from the data model (i.e., the original or latest version). In this way then, a system user may still access data that is no longer being reported on in the field by the mobile devices.
• In response to the ability to version forms and collected data, theSynchronization Server component300 also, instep350, conducts conflict resolution. The need for conflict resolution can occur if and when data collected from the field is incongruous for or outside the scope of the intended form/survey, or such data collected as between mobile clients is inconsistent or out-of-date.
• As mentioned above, a primary feature as shown in step360 is the synchronization of data, forms and surveys, business rules and validation to and from the mobile devices of theMobile Client component500. Such synchronization is 2-way synchronization, that is, data is pulled from the device and data is pushed to the device. In other words, data not only goes from device to server but vice versa as well. In addition updates of the forms and/or surveys are pushed to the mobile device. Such updating can be system wide or selective in that data can be “pushed” to a mobile device on a user specific basis.
• Referring now toFIG. 7, an exemplary synchronization controlled by the mobile data collection and management system architecture'sSynchronization Server component300 is shown in conjunction with central and organizational servers. In this example, it is shown that there can bemultiple servers301,302,303 and304, each having anindependent database15,16,17 and18. Thus it is to be understood that the Synchronization Server has scalability in that there can be Primary and Secondary Sync Servers. In addition in this example, it is shown that additional components, such asmobile device500, central server20, organization's server21 and a 3rd party application/system can be synchronized. Thus it is to be understood that the system can support both distributed and non-distributed computing models.
• Synchronization occurs by and between each of themultiple servers301,302,303 and304 and then to each of the other components. Once data has successfully reached the mobile client it is kept in a secure manner by compressing and encrypting. For example, an encryption algorithm that can be used is a Blowfish 128-bit block cipher encryption, and a data compression that can be used is the zLib compression method (i.e., a variant of the LZ77, called deflation, which emits compressed data as a sequence of blocks). Such is done to ensure that data is transmitted securely without information loss between the present invention'sServer300 and the present invention'sMobile Client500. In addition, there is an option to “Smart-Sync”, that is synchronize only deltas from records. Such option allows for a reduction in the amount of data traffic.
• Referring now toFIG. 8, theIntegration Server component400 allows external systems to access and share the data that is stored in the mobile data collection andmanagement system architecture10 of the present invention. The “engine” of the “integration server” includes a proprietary Database Management System (DBMS—not shown) that stores all data collected from the mobile devices in the field. The DBMS uses Java Database Connectivity technology and a standard SQL database access interface, enabling it instep410 to be compatible with third party applications and existing infrastructure. Thus theIntegration Server component400 allows for data, business rules, validations and user interfaces to be “Pushed” and “Pulled” into the system by 3rd party systems. This is done through XML messages over HTTP. All data accesses require proper authentication and correct acknowledgment to exchange data. All messages are transactional to ensure data integrity.
• Instep420, the mobile data collection andmanagement system architecture10 of the present invention includes a data modeler. The data modeler allows a user to map fields between an external system/database and data fields within the present invention's mobile data collection and management system architecture. Thus, after the connection is established, the 3rd party system user will be able to view the different databases/tables/fields that are available. The Data Modeler also allows creation of a link between the present invention and an external system and supports two modes: 1. the present invention to external system and 2. external system to the present invention.
• Once the fields have been mapped between the external system and the present invention using the Data Modeler, the mobile data collection and management system architecture of the present invention then processes and understands the external system database tables and it's relationships. Next the present invention creates the same tables within the present invention and is then ready to use by the Form Builder. Finally, the user can create applications based on the tables of the external system. All functionality can be done without writing any line of code.
• Lastly, instep430, theIntegration Server component400 also includes an alternative database support for further back-end integration and support for XML feeds and other data outputs for advanced reporting and application integration.
• Referring back toFIGS. 1 and 2 and additionally now toFIG. 9, theMobile Client component500 comprises individualmobile devices501,502,503,510 and520 and the mobile software applications that resides on such devices. The mobile devices can be any device on which an application that has been authored by theForm Builder component100 can be run (i.e., devices such as a PDA, a Desktop, a Tablet, etc.). As mentioned, a Mobile Client software application that is capable of supporting the Form Builder component application is resident on each mobile device. Such placement allows for leveraging both data collection on a mobile basis at the device and management of data, forms and surveys through the system architecture's virtual machine technology. In this manner then cross-platform support and compatibility for all solutions deployed on the system is attainable.
• Referring now specifically toFIG. 9, a row of mobile and fixed devices500xwhich are in-store devices, consumer devices, executive devices and in-store appliances. Mobile and fixed devices500xcommunicate to thesynch server300 andintegration component400. The functionality ofsynch server300 andintegration component400 is such that they act as a single point of integration. The modules allow a customer to integrate or extract data fromcustomer system2000 by utilizing thesynch server300 andintegration component400 to leverage business rules so thatmobile device500 can take advantage of these systems to perform specific tasks either in the store or outside the store.
• Referring now specifically toFIG. 12, an example of the middleware application architecture of a mobile data collection andmanagement system10 and its utilization is shown. The present's invention's middleware, as it has been written in the computer software language of C++, allows implementation of a Virtual Machine (VM)architecture11. The applications ofVM 11 are deployed independently of each other and those needed to make a mobile solution work and thus can be stored on independent computer servers and/or databases (not shown). Thus, in this implementation example, the Form Builder component, ormobile server technology100, resides independently of themobile devices510 and520 of themobile client component500. Updates of the server technology or synchronization of the data collected by the field personnel is directed by thesynchronization server component300. Control over when synchronization occurs comes from input by the system management through theweb management console200. Access by 3.sup.rd Party Systems600 to and the capability to run analytics and reports of the data stored by thesystem10 is via theIntegration Engine Server400.
• With regard to security of thesystem10, both theSynchronization Server component300 and theIntegration Server component400 require proper authentication against a users access to a database and such authentication must correctly acknowledge each request.
• In addition system and database access can be established and controlled for individuals and groups through an interlocking system of roles and privileges. Role-based access to build, edit, change forms, deploy and manage users and access to other tools and functionality can be determined by the individual's role. Unnecessary options can be hidden from the system user, greatly simplifying the present invention's use and over the data collection process.
• Also in addition, administration and security control can be established and distributed such that individual and group Web authoring relies upon a unique tiered security system consisting of site administrators, departmental administrators and individual content creators. This functionality allows for effective distribution and management of security privileges.
• Thus as can be seen from the above description, the present invention facilitates development and solutions to a wide variety of concerns and obstacles to the introduction of mobile applications today. The present invention accomplishes the solutions through use of underlying technology, a variety of features, usability, acceptability by end users and of course ease of deployment and upkeep. By use of industry standards, the present invention shows how an organization can go from taking their backend and paper forms to robust and powerful mobile applications in weeks rather than months without being tied into specific technologies and having the flexibility of easy portability.
• With the use of an end-to-end solution like that disclosed by the present invention, an organization can eliminate any downfalls associated with using a smart client application approach due to its rapid deployment and ease of upgrade capabilities. An application can be developed by a non-technical user which would eliminate the need to hire anyone new with the appropriate skill set.
• In the foregoing description, the method and apparatus of the present invention have been described with reference to specific examples. It is to be understood and expected that variations in the principles of the method and apparatus herein disclosed may be made by one skilled in the art and it is intended that such modifications, changes, and substitutions are to be included within the scope of the present invention as set forth in the appended claims. The specification and the drawings are accordingly to be regarded in an illustrative rather than in a restrictive sense.

Claims (15)

What is claimed is:

1. A method of synchronizing a set of data resident in a mobile device as between the mobile device and a customer system, the method comprising the steps of:

receiving at a system server a first communication with a set of data from the mobile device;

versioning at the system server the set of data sent with the first communication;

directing from the system server the first communication with the versioned set of data to the customer server;

receiving at the system server a second communication with a set of data from the customer server based on the processing of the first communication with the versioned set of data pursuant to the set of applied business rules for forms, surveys and applications;

versioning at the system server the set of data sent with the second communication;

sending from the system server the second communication with the versioned set of data to the mobile device,

wherein the set of data resident in the mobile device is synchronized according to the second communication with the versioned set of data when there is continuous connectivity between the mobile device and the customer server, and

wherein the set of data resident in the mobile device is synchronized according to the first communication with the versioned set of data when there is discontinuous connectivity between the mobile device and the customer server when connectivity is restored.

2. The method according toclaim 1, comprising the further step of:

sending from the system server an instruction to “pull” the first communication with data from the mobile device thereby allowing the processing of the set of data in the customer server pursuant to a set of applied business rules.

3. The method according toclaim 1, comprising the further step of:

sending from the system server an instruction to “push” the second communication with data to the mobile device thereby allowing synchronizing the set of data as between a mobile device and a customer server.

4. The method according toclaim 1, comprising the further step of:

the system server conducts conflict resolution as between a plurality of sets of data resident on the mobile device and the customer server.

5. The method according toclaim 1, further comprising the step of:

performing a specific task on the mobile device as a result of the processing of the set of data pursuant to the set of applied business rules.

6. The method according toclaim 5, wherein the specific task includes at least one of a price checking capacity, a product description retrieval capacity and an inventory management capacity.

7. An apparatus for synchronizing a set of data as between at least one mobile device and at least one server with communications sent over a communications architecture, the apparatus comprising:

a mobile device, in which the set of data and an application programming interface (API) reside, and wherein the API sends from the mobile device a first communication with the set of data;

a synchronization server,

which receives the first communication with the set of data from the mobile device and versions the received set of data, and

which then versions a set of data sent with a second communication, and then sends the second communication with the versioned set of data to the API;

an integration server,

which receives the first communication with the versioned set of data from the synchronization server and redirects the first communication with the versioned set of data, and

which then sends the second communication with data to the synchronization server;

a customer server,

which receives the first communication with the versioned set of data from the integration server, processes the versioned set of data in the first communication pursuant to a set of applied business rules for forms, surveys and applications, and

which then creates the second communication with data on the basis of the processing of the first communication with the versioned set of data pursuant to the set of applied business rules for forms, surveys and applications, and then sends the second communication with data to the integration server; and

wherein when there is continuous connectivity between the mobile device and the customer server the set of data resident in the mobile device is synchronized according to the second communication with the versioned set of data, and

wherein when there is discontinuous connectivity between the mobile device and the customer server and only when connectivity is restored the set of data resident in the mobile device is synchronized according to the first communication with the versioned set of data.

8. The apparatus according toclaim 7, wherein the synchronization server sends an instruction to “pull” the first communication with data from the mobile device thereby allowing the processing of the set of data in the customer server pursuant to a set of applied business rules.

9. The apparatus according toclaim 7, wherein the synchronization server sends an instruction to “push” the second communication with data to the mobile device thereby allowing synchronizing the set of data as between a mobile device and a customer server.

10. The apparatus according toclaim 7, wherein the synchronization server conducts conflict resolution as between a plurality of sets of data resident on the mobile device and the customer server.

11. The apparatus according toclaim 7, wherein the processing of the set of data in the customer server pursuant to a set of applied business rules allows the mobile device to perform a specific task.

12. The apparatus according toclaim 11, wherein the specific task includes at least one of a price checking capacity, a product description retrieval capacity and an inventory management capacity.

13. The apparatus according toclaim 7, the apparatus further comprising:

a database, tied to the customer server, and on which the data of the first communication is stored.

14. The apparatus according toclaim 7, the apparatus further comprising:

a memory, resident on the mobile device, and on which the data of the second communication is stored.

15. The apparatus according toclaim 7, wherein the processed set of data is displayed on the mobile device.

Images