WO2005031620A2

WO2005031620A2 - Electronic inquiry method

Info

Publication number: WO2005031620A2
Application number: PCT/FR2004/050461
Authority: WO
Inventors: Sébastien PANCHER; Nicolas Durand
Original assignee: Calame Software
Priority date: 2003-09-25
Filing date: 2004-09-24
Publication date: 2005-04-07
Also published as: WO2005031620A3; EP1676233A2; FR2860318A1

Abstract

The invention relates to an electronic inquiry method involving a first stage for generating an electronic form, a second stage for transmitting said form to a plurality of recipients' equipment, an information request stage made to each recipient's equipment about said form, a stage for transmitting data of said information form in the form of an electronic message according to an SMTP protocol obtained from said recipient's equipment to a mail server, and a stage for automatically aggregating collected data on the mail server by means of collection equipment. A continuous inquiry system for carrying out the inventive method is also disclosed.

Description

ELECTRONIC INVESTIGATION PROCESS

The present invention relates to the field of online survey solutions. The present invention relates more particularly to a technical process comprising different technical steps consisting in generating an electronic form, distributing and informing said form, transmitting data from said informed form and then automatically consolidating the data collected.

The invention lies in the field of data transfers and is specifically intended to facilitate the establishment of computerized data cycles. A data cycle being defined by the request for information from a requesting user to recipient users, the supply of the information requested by said recipients, the return of the information provided to the requesting user, the consolidation and the provision of consolidated information to the requesting user.

The data cycle is considered to have been successfully completed when the following conditions are met: All of the recipient users have provided the required information The consolidated data are consistent with the information system of the requesting user and can be entered there as is

In addition, since the data cycles are intended to collect information with a business meaning, it is important that the following conditions are met: The entire cycle must be capable of being implemented by a business user, whose IT skills do not exceed knowledge of a basic office environment. In particular, none of the operations necessary for the implementation of the cycle should require the writing of any line of code. The requested information must be able to be supplied by the users requested without this requiring training on their part. - In order to minimize the number of cycles necessary to obtain formally satisfactory information, the information provided by the users requested must be verified in real time. The implementation of the cycle must be non-intrusive. In particular, the cycle must not mobilize a server or any other device dedicated exclusively to the execution of one or more tasks necessary for its implementation. The implementation of the cycle as well as its update must be able to be carried out in extremely short time (<1 day / man for a user whose computer skills do not exceed the knowledge of a basic office environment) in order that the information collected reflects as closely as possible the situation whose analysis is the subject of the cycle.

In other words, the present invention relates to a method allowing the implementation of data cycles in accordance with the prerequisites given above. The problem set out above is today mainly dealt with by one or other of the 3 means set out below:

• Web form The Web is a good way to provide requested users with input forms. The HTML language natively assigns a certain number of instructions for this use and the major advantage of this solution is a deployment as a real thin client: no application is installed on the workstation of the users requested. However, using HTML forms as a data cycle support reveals several drawbacks.

First of all, if the HTML language, content language, provides for the display of input components (drop-down lists, edit zones, radio buttons, etc.), it does not allow the data entered by the user. A programming language is then required (Javascript is frequently used) for this task, but the programming of information transmission directives is not within the reach of an office user.

In addition, the reception of data transmitted by the users requested requires the maintenance of a database on a dedicated server, managing the consolidation of the information received. Again, these tasks are not within the reach of an office user and more, requiring dedicated software and hardware components, it is not non-intrusive.

It should also be noted that HTML technology does not easily make it possible to carry out validity and consistency checks in real time on the data entered by the users requested. Such controls can possibly be introduced by programming in an appropriate language but in this case, a verification of exhaustive consistency across all input sessions requires a great deal of information exchange with the data server, resulting in disabling bandwidth consumption

• Distributed architecture By “Distributed architecture”, we mean any database supplied in particular by input interfaces distributed to the users requested. (It also appears, according to this acceptance, that Web forms are a special case of distributed architecture.)

The advantage of this configuration lies in the fact that the database whose accesses are distributed can be an integral part of the company's information system (IS) and that the data thus collected can be immediately made available to classical information processing processes (decision-making tools in particular)

The disadvantage of this type of solution stems from its interest: any modification of a distributed architecture can impact the entire IS and must therefore be considered globally so as not to jeopardize the integrity of the IS.

In addition, the distribution of access requires the installation of an input software component at each of the users requested, this installation requiring a dedicated skill and specific training so that the requested user can perform their input task.

The use of distributed architectures for the purpose of data cycles is therefore inappropriate because the permanent reactivity required is very costly in terms of resources mobilized.

• Shared files Shared files are also a frequently used means of creating data cycles. The requesting user creates a document with fields to fill in and then distributes this document to the users requested. It is their responsibility to complete the document they have received and then return it to the requesting user, who then gathers the information thus collected.

The advantage of this solution is its ease of implementation, for which the requesting user has the possibility of acting independently.

In addition, the requesting user most often creates a document in a standard office format, thus guaranteeing that the users requested can use it without installing any additional component and a priori without prior training.

However, the downside of this ease of creation is an overall lack of reliability. Indeed: o The use of a document as an information medium does not guarantee the integrity of the data entered. o As the desired information is not organized in basic form, a priori there is no consistency with the IS data model: the data collected cannot be reintegrated there as is. o Once the documents have been completed and returned to the requesting user, the consolidation of all information collected is not automated and therefore proves to be long, tedious and a source of errors.

The programming of execution tasks (macros) makes it possible to partially fill certain gaps in the process, but in this case, the development and maintenance costs of these application tasks prevent reaching the expected reactivity. These 3 methods compared to the present invention have their qualification for the creation of data cycles shown diagrammatically in FIG. 1.

The prior art also knows, from PCT patent application WO 02/25486 (Interquest), a method for collecting and processing information. The invention presented in this PCT application relates to a method of collecting information from users of terminals connected to a data network, which consists in using the terminals via the network, and in submitting to the users of the terminals one or more questions from the list of questions. Thus, the degree of disturbance affecting users can be kept as low as possible by defining a maximum number of questions to be answered by a single user. For each question, at least one statistical characteristic is determined on the basis of the responses received, when one or more responses to a given question are obtained. The selection of questions may be based at least in part on said characteristic.

Few electronic survey methods or systems are known in the prior art. The purpose of this type of solution is, of course, to replace the forms of “paper” type, which allows significant time savings.

The present invention provides a software solution that meets the requirements of the context of using data cycles. It consists of four software modules, each serving one of the stages of a cycle: • Creation of the interrogation document; • Determination of the sub-populations of recipients, personalization of the interrogation document according to the recipients in transmission of this document to the recipients concerned; • creation of the desired data using said document; • consolidation and provision of the data collected.

To this end, the present invention relates, in its most general sense, to an electronic survey method comprising • a first step of generating an electronic form; • a step of distributing said electronic form on a plurality of recipient devices; • a step of informing said form, on each of said destination equipment; • a step of transmitting data from said form filled in from said recipient equipment to a mail server in the form of an electronic message according to the SMTP protocol; and • a step of automatic consolidation of said data collected on said messaging server by collection equipment. Preferably, the method further includes a step of producing a file in .csv format. Advantageously, the method further comprises a step of sending an acknowledgment of receipt to said recipient equipment. According to one mode of implementation, the method further comprises a step of statistical processing. Preferably, the method comprises an additional step of sending data from said statistical processing to said recipient equipment. According to a variant, the method comprises an additional campaign management step consisting in monitoring the progress of the survey and possibly in issue reminders to said recipients. Preferably, the method further includes a compression step. According to a first variant, said compression applies to said form. According to a second variant, said compression applies to the data collected. Advantageously, the method further includes a step of encrypting the collected data. Preferably, the step of generating an electronic form includes the use of filters allowing personalization according to characteristic data of the recipient. The present invention also relates to an online survey system for implementing the method comprising at least means for generating electronic forms and means for transmitting data.

The invention will be better understood using the description, given below for purely explanatory purposes, of an embodiment of the invention, with reference to the appended figures: • Figure 1 represents the state of the art; • Figure 2 illustrates an embodiment of the method according to the invention.

The electronic survey essentially consists of: • developing a questionnaire; • informing said questionnaire by a plurality of people; • automatic processing of responses.

The first phase of the process according to the invention consists in creating a questionnaire. The questionnaire being in an electronic format, it is easy to add to it, by means of an adapted interface, hypertext links, buttons and additional fields ... It is essential, during this phase to provide an email address electronic system that will collect the responses.

The questionnaire is then completed by the respondents. The filling of said questionnaire is carried out using downloaded client software. At the end of the filling, a click sends the formatted responses in the form of a digital file to the predetermined email address. This file can advantageously be compressed and / or encrypted before sending.

Finally, an additional module, installed on a server, examines the emails intended for said email address responsible for collecting the responses. The responses are processed, consolidated and results files are produced. Personalized emails can be sent to people who answered. Optionally, statistical or reporting tools can be used in combination before the data is consolidated. The method according to the invention will now be described in more detail.

I. Creation of the interrogation document The interrogation document is a file intended to be read by an appropriate executable on the station of the recipient to whom it is transmitted and on which it organizes the collection of the data that the sender wishes to obtain. This data can be of any type and must be able to be collected by any means that the recipient's workstation can understand. In a nonlimiting manner, it may in particular be data entered on the part of the user, data present on the user's workstation or in the environment accessible to him or data describing the workstation of the user or the environment accessible to him.

Preferably, the implementation of the module for creating the interrogation document (MCDI) will call on the one hand for an object structuring defining the attributes of the document and the structure of the data storage before referral for consolidation and on the other hand has object classes defining the interaction components with the recipient's station. Thus, from these sets of predefined classes can be derived an infinite number of interaction components as required. The object classes are mainly divided into 2 categories: o On the one hand, the objects defining the wrapping of the document, the graphic and multimedia aspects. These objects also define the structure of the document and its visualization logic. o On the other hand, objects whose role is to collect data. In order to facilitate the implementation of cycles, MCDI will make extensive use of the usual widgets defined by the operating system of the workstation on which it is installed, as well as advanced support for the most frequent file formats, optionally.

Among the objects whose role is to collect data, some of them are presented to the recipient user in the form of lists of items. To this group belong in particular the drop-down lists, check boxes, radio buttons, etc. In order to guarantee the cohesion of the data collected at the end of the cycle with the information system present in the company, these components can be fed by requests on this same information system. In order to avoid any programming for the designer user, the MCDI directly calls on the database drivers present on the computer on which it is installed, via high-level interfaces, ADO type. The MCDI also integrates a certain number of application control interfaces so as to allow the integration into the document of files intended to be used dynamically, in particular for interacting with the tools associated with the data intended to be collected. on the recipient's workstation. These interfaces, which can in particular be of the COM or OLE type, provide intuitive access for the recipient to the local applications managing said files, said applications appearing to the user as integrated into the document, with all or part of their properties. and available functions.

MCDI allows the user to manage the granularity of the data collected by the various components used in the document.

By default, each unitary data of each of the components is extracted by disregarding its collection context. Thus, during consolidation, a given response from a given user is always represented by a line in the final CSV file, regardless of the structure of the document. However, there are also plans for consolidation by sets, in which data from objects with identical granularity are grouped together. Finally, the MCDI allows the designer user to create a fully personalized consolidation model ex nihilo.

Once the design is complete, the query document is then created. This document is mainly intended to be transmitted by email, two imperatives must be reconciled: o The document must not be able to be altered by the mail servers. The messaging servers can, depending on the case, receive a specific configuration affecting the messages they convey. The most frequent violation concerns line breaks, which can be managed very differently from one server to another. To avoid this pitfall, the interrogation document is in the form of a binary file itself composed of 2 stream files containing the two object classes described above: document structure and dependencies on the one hand, data objects on the other. o The document must be as light as possible so as not to be pushed back by the mail servers, which are often limited in volume. For this purpose, the final document is compressed, which also has the effect of encrypting the resulting file.

II. Determination of the populations of recipients, personalization and transmission of the interrogation document

In order to send each recipient a document related to the information they have, it is necessary to personalize the query document according to one (or more) segmentation (s) that we will call "sub-populations" ". Said segmentations are frequently contained in the company's information system, as are the coordinates of the recipients of the document, frequently found in an LDAP-type directory.

The first task therefore consists in bringing these two pieces of information together. To do this, a certain number of requests are placed on the aforementioned systems. So that the demand on the servers hosting these systems is minimal, the information thus collected is gathered in a specific directory which can be refreshed field by field at the request of the user.

From the data in this directory, the interrogation cycles will be created. An interrogation cycle combines three elements: o An interrogation document created by the MCDI o A parameter file specifying on the one hand, the personalizations assigned to the interrogation document according to the sub-populations and on the other hand, information inherent to the course of the cycle such as its expected duration, the organization of recovery phases, the visualization of the degree of progress, etc. This file behaves like a script, allowing the re-execution of an entire cycle on refreshed parameters. o A set of sub-populations defined in the directory. The selection criteria are specified either absolutely (query on fixed parameters) or relative so as to envisage the automation of the selection process and these criteria are saved in the parameter file.

The execution of the parameter file is broken down as follows:

1) Possible updating of the directory 2) Request on the directory and extraction of sub-populations 3) For each individual of each sub-population, creation of a document of interrogation based on the document main interrogation and affected by the modifications specified for the current sub-population 4) Sending personalized interrogation documents to the individuals making up the sub-populations. In order to optimize the sending phase, this is done by group, a single email being effectively transmitted to all the individuals making up a given sub-population 5) Creation of intended environment variables, by reconciling the configuration from the cycle to information from the consolidation of the data returned, to piloting the cycle.

III. Creation of the data The creation of the data takes place on the workstation of the requested user. He receives the interrogation document and opens it with the dedicated module.

It should be noted that, frequently, users have limited access rights, in particular with regard to the creation of files. In order to overcome this pitfall, all operations to decompress the interrogation document and its dependencies are carried out in RAM using flu -memoire (memorystreams)

Once the document is open, the user can browse it and perform the requested data supply operations. Some of these operations are manual (entry, selection ...) others are automatic, either in that they arise from the entry operations, or in that they are carried out without the knowledge of the user ( system information requests, data embedded in the document, etc.) The user can, at any time, save the state of his entry. A file is then produced containing the structure of the responses: the data supplied are virtually attached to the class identifiers of the objects of the interrogation document which contained them. Thus it is possible on the one hand to split the entry and on the other hand to use the data thus recorded on other formally similar documents. If specified in the MCDI, the responses provided by the user can be stored on his workstation as a base. In this case, an additional interface is available, allowing you to browse this database, recall or delete all or part of the responses stored there and export this database to an ASCII data file.

The data creation module performs all the validation checks specified by the MCDI. The execution of the control procedures can take place at three times: o When entering (by analyzing the data entered, selections made ...) o When the entry in a given object can only be checked once that - done, the control takes place when the object loses focus o During the request for data transmission (overall consistency, completeness)

When the user makes a data transmission request, a global check is carried out and the data is organized in memory according to the model specified in the MCDI. Finally, a file is created containing the rearranged data in CSV format, then this file is compressed and emailed the address specified in the MCDI as an attached file.

For obvious security reasons, the email is sent transparently and the destination address is never exposed to the user.

To ensure that responses are sent by email, a configuration is made during installation, indicating the protocol to be used. Operating system environment variables provide default messaging settings that can be changed by the user. Three levels of interaction with messaging are possible: o The very high level protocols provided by the OS, MAPI type. In this case, it is verified that the messaging support software is activated, on the one hand so that the sending is transparent to the user and on the other hand hides the destination address. o Intermediate level protocols provided by messaging, VIM type o Direct addressing of an SMTP server

The user is also asked for an identifier. This, compared to one or more environment variables, will allow the responses to be discriminated during consolidation.

A procedure for sending data by file is also available if the connection to the mail service fails.

IV. Consolidation and provision of the data collected The consolidation and provision of the data collected is carried out using a dedicated module.

The purpose of this operation is to supply data files containing the responses provided by the users. These files are created in .CSV format in order to be completely standard and usable in any context

This module performs the following tasks: 1) Searching in the environment variables for information relating to the cycles in progress 2) For each of the cycles, retrieving the information then connecting to the specified mail server. The connection is always made via the POP protocol 3) For each of the mails present on the mail server, verification of the fact that this mail does indeed contain an authentic data file as an attachment 4) Possibly, deletion of unauthenticated mails 5) For each authenticated email, download of the attached data file, decompression, structural and logical verification, possibly request for arbitration by the user of the consolidation module, addition to the data of information relating to the progress of the cycle then addition of the data to the appropriate data file. If the file does not exist, it is created at this time. 6) Possibly, deletion of the processed mails. 7) Possibly, sending the sender of the data of an email containing the information relating to his data (successful integration, refusal for technical reasons (duplication ...), etc.). This email is personalized using variables provided by the data file on the one hand and the cycle parameters on the other. 8) Optionally, triggering of an external task depending on the cycle parameters. This external task can be of any type (EXE, BAT, COM ...) and is activated by the shell of the OS. 9) Optionally, maintaining an event file (log) in CSV format. It should be noted that the consolidation module can be fully used in command line mode (batch) as part of a production process integration.

The invention is described in the foregoing by way of example. It is understood that a person skilled in the art is able to carry out different variants of the invention without going beyond the scope of the patent.

Claims

1 - Electronic survey method characterized in that it comprises the following sequence of steps: • a prior step of downloading a specific application module for each piece of equipment from a plurality of recipient pieces of equipment; • a step to generate an electronic form; • a step of determining sub-populations of recipients and personalizing said form according to the recipients; • a step of distributing said electronic form on each device of the plurality of recipient devices; • a step of decompressing said electronic form into random access memory using memory flows; • a step of informing said form, on each of said destination equipment; • a step of processing digital data from the intelligence step by means of said specific application module installed on each recipient equipment, said processing notably comprising the local execution of control procedures; • a step of transmitting data from said form filled in from said recipient equipment to a mail server in the form of an electronic message according to the SMTP protocol; and • a step of automatic consolidation of said data collected on said messaging server by collection equipment. 2 - Method of electronic survey according to claim 1, characterized in that it further comprises a step of producing a file in .csv format. 3- electronic survey method according to claim 1 or 2, characterized in that it further comprises a step of sending an acknowledgment of receipt to said recipient equipment 4 - electronic survey method according to claim 1 , 2 or 3, characterized in that it further comprises a statistical processing step.

5 - Method of electronic survey according to claim 4, characterized in that it comprises an additional step of sending data from said statistical processing to said recipient equipment

6 - Method of electronic survey according to any one of the preceding claims, characterized in that it comprises an additional campaign management step consisting in monitoring the progress of the survey and possibly in issuing reminders to said recipients.

7 - Method of electronic investigation according to any one of the preceding claims, characterized in that it further comprises a compression step. 8 - Electronic survey method according to claim 7, characterized in that said compression applies to said form. 9 - Method of electronic survey according to claim 1, characterized in that said compression applies to the data collected. 10 - Method of electronic survey according to any one of the preceding claims, characterized in that it further comprises a step of encryption of the collected data. 11 - Method of electronic survey according to any one of the preceding claims, characterized in that the step of generating an electronic form includes the use of filters allowing personalization according to the recipient's characteristic data.

12 - Online survey system for implementing the method according to any one of the preceding claims comprising at least means for generating electronic forms and means for transmitting data.