The invention generally relates to document processing and distribution systems and methodology. More particularly, the invention relates to a system and method for enabling the electronic capture and transmission of a wide variety of forms in many formats in a manner which streamlines collaboration between organizations and/or between organizations and individual users.
Portable Document Format (PDF) is widely used for the secure and reliable distribution and exchange of electronic documents and forms around the world. PDF is a universal file format that preserves the fonts, images, graphics, and layout of any source document, regardless of the application and platform used to create it. Adobe® PDF files can be shared, viewed, and printed by anyone with Adobe Reader® software.
Governments and enterprises around the world have adopted PDF to streamline document management, increase productivity, and reduce reliance on paper. For example, PDF is a standard format for the electronic submission of drug approvals to the U.S. Food and Drug Administration (FDA), and for electronic case filing in U.S. federal courts. It is also used by the governments of the United Kingdom and Germany for electronic document exchange.
PDF documents are often electronically communicated between individuals, for example, via e-mail. These PDF file format documents typically tend to be passive documents which reflect a series of printed pages.
A recipient of a PDF file is able open such a file, read the file and print the file to obtain a hard copy. Such files generally may be regarded as static files, i.e., an electronic version of a printed document.
In accordance with an exemplary embodiment of one aspect of the present invention, such typically static documents are embedded with program code enabling, for example, a form to intelligently route itself to a desired destination, to prompt a user to respond to particular questions, to perform validation operations, and to present various pull down list choices from which a user may select.
In accordance with an exemplary embodiment, an active document may have associated therewith a form including an embedded questionnaire. A form should be broadly viewed as including an electronic file including information solicitation-related information. Such a form would include a mechanism for providing solicited information such as, for example, blank spaces for providing requested or required information. Rather than blank spaces, other approaches may be used to permit data entry of solicited information by a recipient such as by clicking a mouse on one of several alternative choices. Such an active document preferably has the capability of presenting a questionnaire to a user and when processed at a server results in the consolidation of responses to the questionnaire. In accordance with an exemplary embodiment, the active document-based questionnaire may be designed such that the responses to different questions are automatically sent to different recipients.
The active document controls the distribution of such questions and maintains the answers thereto. For example, in a marketing campaign, a marketing agency may receive certain general compiled statistics based upon responses to questions relating to how well a corporation's product is doing in the marketplace. A corporate sales manager responsible for the product may be likewise automatically sent certain statistics pertinent to the manager's responsibilities, together with names and addresses of individuals to be contacted in relation to purchasing and/or marketing the product. Additionally, feedback obtained from responses to questions regarding problems with the product may be sent to a product manager responsible for product quality control. Thus, in accordance with an exemplary implementation, the document itself has the embedded intelligence to perform such distribution functions.
A wide variety of applications are contemplated for the mobile software and active document methodology described herein. For example, such applications include product sales lead generation and product marketing to enable the collection and optimal distribution of information regarding potential customer names, feedback concerning opinions about the product.
The mobile software and active document methodology and apparatus of the present invention also may be applied to a wide variety of medical applications. For example, the mobile software and active document methodology described herein may be used for collecting medical history information related to new drug testing conducted by a pharmaceutical drug company.
In such a medical application, by way of example only, a doctor may fill an active document form detailing testing results. The information on such an intelligent document would be automatically routed to the appropriate places for data preservation and analysis. In this fashion, a doctor in a hospital may enter information from various patients via, for example, a tablet computer. The gathered information may then be intelligently routed to a server if an online connection may be immediately established. Alternatively, if an online connection cannot be established, the gathered information will be locally stored and will automatically be later forwarded to the server whenever the next connection is established.
The methodology described herein may be applied in wide range of product/system service applications. For example, a technician from a hardware vendor may be sent out to resolve a particular problem with the vendor's product. The technician having a laptop with a wireless communication capability may retrieve an active document form via which the technician may request a particular replacement part. The active document and mobilized software embedded in the form would be utilized to automatically establish a connection to the technician's home base or automatically save answers to questions which will be automatically forwarded to the home base once a wireless connection is established. Such operation would occur without the technician having to perform any required operation other than completing and submitting the intelligent form.
In this exemplary embodiment, from the user's point of view, communication appears to be seamless since the user need not personally establish a network connection. Thus, the technician, after submitting the document, does not have to be concerned with whether a connection is actually established or not since the active document will automatically ensure ultimate communication with the home base.
These, as well as other features of the present exemplary embodiments will be better appreciated by reading the following description of the preferred embodiments of the present invention taken in conjunction with the accompanying drawings of which
Prior to explaining the active document and mobile software aspects of the exemplary embodiments beginning with the description of
It should be understood that the subsystems shown in the template development system 1, the multi-channel server engine 2, and the client application system 3 are shown, for illustration purposes only, to explain certain aspects of the exemplary embodiments of the present invention. Certain modules may, for example, be combined with others, performed in another portion of the system or be left out of the system in a given implementation.
Turning back to the template development and operational monitoring system 1, this system supports the processing and management of received documents of any of a wide variety of types. The document management system 4, template designer 5, and viewer management system 6 coact in the document template development and setup process. Document management system 4 retrieves documents from a queue and identifies the type of document, e.g., Microsoft Word document, PDF document or image document, for further processing.
The template designer 5 creates documents that are managed by the document management system 4. The template designer 5 stores and retrieves documents and applies predefined rules for generating a template document. In designing a template document, various characteristics of an input document are mapped to predefined portions of the template document. As part of the template design process, a viewer management system 6 controls the display of the customer's input form and the template being generated during the template design process. Thus, through split screen techniques, a user can see both the original document and the resulting template created by mapping fields from the originating document onto the template.
The trading partner management system 7 links, for example, a customer (trading partner) who is forwarding, for example, a purchase order with the purchase order format that is characteristic of that customer. The overall system in
The customer may choose to transmit documents via, for example, a common email system. However, the overall system shown in
Turning next to the multi-channel server engine 2, this engine includes a document volume processing manager 35 which includes a listener (document extractor/monitoring system) 9, which monitors when documents have arrived for processing. The listener 9 detects the arrival of the documents and the document type. A thread management system 10 performs the necessary processing to ensure that the application is readily scalable. For example, if documents are received every two minutes, no enhanced processing capability for high volume is required. However, if documents are received at extremely high volume, the system hardware should be capable of processing at speeds required to properly handle such volume. The thread management system 10 ensures that processing capability will scale up as necessary. For example, if the system hardware includes multiple processors, then multiple threads may be processed in parallel.
An event management system 11 responds to various events such as, for example, the receipt of a document and triggers the required operation to be performed. The event management system 11 also responds to the detection of an error event.
The server engine 2 also includes a document driver management system 36. The document driver system 36 includes distinct driver software depending upon the nature of the document. The document driver management system 36 is used to dispatch the appropriate parser depending on the document type submitted by the customer, for example a FAX, Word, PDF, XFORM or some other format.
Such driver software includes fax/image document driver software 12 and machine readable document driver software 13. Thus, document processing will differ depending upon whether the document is determined to be a fax or image document or a machine readable document (which would include, for example, a word document or any other type of machine readable document).
In accordance with an exemplary embodiment, the system additionally includes a client application system 3 which may be embodied in a PC and includes a viewer subsystem 14 and productivity tools 15. The viewer subsystem 14 permits a user to view an original document and a document undergoing conversion to a standard document format. The client application 3 provides the system user with a set of productivity tools 15 depending upon the role of the user in the corporate environment and access capability built into the user's password. Productivity tools may permit a user to design templates, manage documents, correct documents, etc., based on the user's access authority. The client application module 3 interacts with both the template development system 1 and the multi-channel server engine 2.
Internal firewall 22 may be a conventional internal firewall within a corporate entity. The document information, after being transported via internal firewall 22 is processed and routed through a system including a conventional server 23, which for example, may be Microsoft Biztalk server, and a multi-channel engine server 24 which is described in detail below. The SQL server data store 25 is utilized by both servers as the system data repository.
The system shown in
This illustrative system, which is described in further detail in copending application Ser. No. 10/361,853, receives, via a wide range of multi-channel inputs, any document type, such as a PDF document 50, a Word document 52 an image document 54 or an XFORMS document 55. It should be understood that other document types are also contemplated and that the four document types shown are for purposes of illustration only.
Documents to be submitted 50, 52, 54 and 55 via some electronic means (as represented by Electronic Documents 56) are delivered to the Multi-Channel Document Conversion Engine 93 by various transport technologies such as eMail 58, eFax 60, Web services Portal 61, FTP 68. Physical media such as mail 70 and fax 72 can also be submitted by converting them to electronic form via, for example, a scanner 76 or a fax server 72. In an exemplary embodiment, the input documents 56 and physical documents 70 and 72 are routed to the Mail Server(s) 80. This allows a consistent method for submission of documents to the Multi-Channel Document Conversion Engine 93, and acts as a buffer in the case of extremely high volumes of input documents. The conventional e-mail message 58, the Web services Portal 61, and the FTP/File Receiver 68 could include document attachments of a variety of identified types.
If, for example, an image document 54 is transmitted as an electronic document 56 via a commercially available electronic facsimile service such as eFax.com, the eFAX document is e-mailed to an eFax portion 60 of the e-mail system. The e-mail transmission from e-Fax 60 is likewise a routed e-mail message, but is an “eFAX” e-mail having an image (TIF) attachment, as is offered by commercially available services. The e-mail with image attachment (60) is coupled to mail server 80. Such commercially available systems operate to receive a customer's fax via a telephone communication, package the fax as an e-mail and send the e-mail as directed.
Documents received via the Internet using the http(s) protocol are coupled via the Web services Portal 61 to one of the system http(s) receivers 62, 64, or 66. Each of the http(s) receivers 62, 64, or 66 receives the electronic document transmitted via the http(s) protocol and packages the document as an e-mail transmission, which is then sent to e-mail system manager 78. Multiple http receivers are utilized under circumstances where a high volume of documents are being received, so that the system can efficiently process in parallel and at high speeds when required. The http(s) receivers 62, 64, 66 run, for example, on one or more IIS servers 18 represented in
A document may be received via the file transfer protocol FTP. A file receiver 68 receives such a document file and couples the document to the e-mail manager 78. The FTP protocol is a conventional protocol which operates to send batch files to desired destinations via the Internet or via a dialup modem.
The illustrative embodiments also contemplate receipt of documents via regular mail, which will be received at a physical mail station 70. The documents received by mail may, for example, then be scanned via optical scanner 76 and coupled to the e-mail manager 78. Alternatively, documents may be converted into an electronic document via a facsimile device 74 and forwarded to a fax server 72 which couples the electronic version of the document to the e-mail manager 78. The fax server 72 may likewise receive facsimile documents directly from an external fax device. The received facsimile documents are then coupled to e-mail manager 78.
In accordance with certain illustrative exemplary embodiments, via the conversion of information received from http receivers 62, 64, or 66, FTP receiver 68 and scanned or faxed physical mail via 76, 74 and 72, the e-mail manager 78 ensures, along with the e-mail modules 58 and 60, that mail receiver 80 receives input from all sources in a common format, i.e., an e-mail with an attachment. Such an attachment may, for example, be a PDF, Word or image or any other document type. Through the use of mail servers 80, 88 which receive documents via attachments, the system operates to convert received documents into a desired standard document format on an “other than real time” basis. Thus, for applications where the standard documents must be processed as of a certain critical date, e.g., the due date for a government grant application or the due date for taxes to be submitted, the system will not be overrun by real time processing requirements resulting from the highly CPU intensive conversion process, which will be described below. In this fashion, the system may receive large numbers of e-mail communications per second, and later process the attached documents at a rate that the multi-channel engine can comfortably process. Mail server 80 may include a variety of mail servers, such a mail server 1 (82), which may be a Microsoft exchange server, or mail server 2 (84), which may be a Lotus Domino mail server. Additionally, server 80 may include other mail servers 3 (86). Additionally, mail server 80 may be replicated in the form of mail server system 88 to permit extremely high volume input processing. The mail servers 80 and 88 correspond to the
The system also includes a mail queue listener/extractor 90 which is coupled to mail servers 1, 2 and 3 (82, 84 and 86). Mail queue listener/extractor 90 retrieves the mail and determines for each retrieved e-mail, the number of attachments that are associated therewith. The mail queue listener 90 will then retrieve each attached document and store the attached document in the relational database 110 associated with server 110 which may, for example, be an MS SQL server.
Where there are multiple attachments and multiple attachment types, each attachment type such as a Word document or an image document, is processed to handle unique issues associated with each document type. For example, a Word document will likely result in a 100% successful conversion to a standard format, whereas a PDF document would be slightly less than 100%, and an image document would be converted at a still lower success rate. If an image document is being processed such that the conversion cannot be successfully completed without intervention, due to an unreadable field, but the PDF and Word document could be successfully processed, the system operates to direct the image document to error processing. For example, the image document may be transmitted to document correction facility 128, where, using the client tools correction utility 126, the image document may be viewed and corrected. Documents which are required to be corrected may be appropriately stored in, for example, data base 110.
If independent documents are received which can be presented to the desired recipient immediately after conversion, the system will follow through on that course. The mail queue listener/extractor 90 applies predefined setup rules for delivering converted documents, e.g., delivering each attachment as converted or holding until all attachments are successfully converted and appropriately storing such attachments in the database 110.
The documents are retrieved from the database 110 and are forwarded to one or more multi-channel engines 92, 93. One or more multi-channel engines 92, 93 is utilized to manage the overall core document conversion process. In an exemplary embodiment, the multi-channel document conversion engines 92 and 93 are implemented by a combination of a conventional Microsoft BizTalk server 23A and the multi-channel engine server 24 described in detail herein in the above-identified copending application, which has been incorporated herein by reference. The document router 102 shown in
The preferred multi-channel document conversion engines 92, 93 contemplates use of many different parsers. For example, the engines 92, 93 preferably include an image document parser, a Word document parser and a PDF parser and other types of document parsers.
The respective parsers in the multi-channel engines recognize that, for example, a purchase order has been received from a company A, which utilizes its own predetermined purchase order format, and transforms that company A purchase order format into a desired standard document form template purchase order in Extensible Markup Language (“XML”) format as represented in
An exemplary implementation of the Multi-Channel Document Conversion Engine (MDCE) 92, 93 will now be described in further detail. The MDCE receives document objects, associates them with preconfigured conversion templates or schemas, and generates machine readable data files as output. The MDCE is indifferent to the source document types, handling images generated by fax transmission, Adobe pdf, Microsoft Office (Word, Excel), XFORMS or any other rich document. The MDCE is, in an exemplary embodiment, built in a modular fashion such that any document type can be added as a standalone component.
In accordance with an exemplary embodiment, the MDCE runs in a transactional state, guaranteeing that when a document conversion process begins, it will either complete successfully, or be rolled back to its prior state. In the case of an error, the MDCE will send out notification alerts to previously defined administrators for their attention. In accordance with an exemplary embodiment, many different types of errors will be detected by the MDCE including those which are described in the above-identified incorporated copending application.
The MDCE is built to be scalable, supporting both a horizontal and vertical hardware growth paradigm. Horizontal scalability entails having a farm of servers with each server doing individual parts. Vertical scalability entails parallel processing hardware configurations.
The system also includes a user interface for the administrator of the process, which is represented in
The system also includes, in addition to infrastructure control 116, a template designer 123 for controlling the template design process and includes all the tools necessary in the ongoing document conversion process. In accordance with an exemplary embodiment, the template designer includes a template design module 124A, which controls a wide range of template design functions involved in the creation of templates, a template mapper 124B, which controls the process of transforming an original form fields to the proper zones on an appropriate standard document template, and a template manager 124C which manages the storage and retrieval of templates and sets up the required information for the “trading partners” referred to above. The operator of the template designer 123 will have more or less tools to manipulate depending upon the individual's associated access authority controlled by security/user role module 122 based, for example, on an analysis of the user's password.
A document correction facility 127 controls the viewing and correcting of documents in which errors have been detected. The rules for accepting or detecting a document will vary in accordance with the application. For example, in a business purchase order context, the system operates to avoid rejecting orders to purchase products whenever possible. The document correction utility 127 permits on-line correction during the document conversion process resulting, for example, from an inability to read data from an original form from a customer. When detection of a document conversion failure occurs, documents are forwarded to the document correction utility 127 and dependent upon the form of a document are delivered either to a Word correction utility, a PDF correction utility or fax/image correction utility embodied in correction utility 126. With respect to each document type, the original document is displayed in one window and the attempted conversion in a second window, thereby enabling a user to identify the error and make appropriate correction where possible. The correction utility uses available correction tools associated with each document type. For example, a Microsoft Word document editor may be utilized for Word document editing and a Microsoft BizTalk screen editor 244 may be utilized during the editor/viewer association process. The Microsoft BizTalk Mapping and Microsoft BizTalk Schema Editor may be utilized for handling errors during the document mapping process, where, for example, a source document is converted into the XML format as described above. With respect to PDF document correction, the Adobe Acrobat editor may be utilized. Similarly fax/image corrections may be made using a commercially available OCR engine such as the Scansoft OCR engine.
The system includes relational database 110 which, for example, stores all setup information including all the trading partner definitions, the original document transformation information, templates, the images that have been transmitted by form submitters and the resulting XML that was generated. The relational data base also stores meta data 112.
If a Microsoft Word document is obtained from the queue (162), an identification is made that the document type is a Microsoft Word type document (164). Thereafter, the Word template that had been created in the template designer 123 is loaded (166). Based on the template received, the required data elements are identified, and the identified data elements are extracted from, for example, the original purchase order form submitted by a company seeking to purchase goods or services (168). The extracted data is then placed in a Word XML format and is then mapped into the standard document template in XML (170). Thereafter, the destination XML is validated to make sure all the fields such as the date field, numeric fields, etc. are correct (172). Finally, the notification of success/failure is generated (174), which is then delivered to the submitter.
If a PDF/Adobe document is retrieved from the mail queue (176), the PDF/Adobe document is identified (178). An optical scanning engine may be used to scan the PDF document obtained via the e-mail attachment or some other data extraction technique may be used. An OCR template appropriate for the PDF document is then loaded (180) or the appropriate data extraction tool is loaded. Thereafter, the OCR engine or the data extraction tool runs to extract data from the original PDF document. A PDF-XML document is generated and mapped to a destination standard XML document (184). Thereafter, as indicated above, validation and notification processes are performed (172, 174).
With respect to facsimile documents, as indicated above, one mode for receiving a faxed document is via a commercially available eFAX service. Under such circumstances, a corporate customer service representative may provide end user trading partners with a phone number for sending facsimile transmitted purchase orders. Under such circumstances, a retrieved image from the queue (186) will be recognized as a facsimile purchase order (188). Thereafter, an OCR template is loaded for eFAX transmissions (190).
The OCR engine is then run. As the document is being scanned, known zones on the scanned facsimile are identified and data is extracted (196). An image-XML document is generated and mapped to a destination standard XML document (198). Thereafter, as indicated above, validation and notification processes are performed (172, 174). If the OCR engine is scanning, for example, a known date field, the software may be designed to generate an indication of the probability of a successful read of an identified zone. Depending upon the criticality of a particular field, a high probably of success, e.g., greater than 98% may be interpreted as a successful read. A probability below the selected value will result in an error being detected and the erroneous field highlighted.
In case of detected errors, the document correction facility 127 (
Reference is made to the above-identified incorporated copending patent application for exemplary screen displays depicting an image document in the form of a customer's original purchase order in the process of being mapped to a template standard document purchase order. The incorporated application depicts a variety of screen displays showing various exemplary applications at various stages during document processing using the above-described methodologies. For example, a screen display is shown therein which depicts the data extracted from a customer's purchase order form and inserted into a standard document purchase order template.
The eForm creation process in server 201 initially involves publishing the eForm for mobility (202). The publishing and creation of a forms package involves defining the form in the server, which may involve selecting, for example, a PDF file, selecting questionnaire information for placement in the file, and identifying those places in the PDF file where, for example, an intelligent questionnaire may be inserted. By way of example only, if the PDF file represents a textbook, a questionnaire may be inserted at the end of each textbook chapter to provide chapter tests for students. The questionnaire may ask questions, prompt students for answers and then automatically route the resulting test to an appropriate party. It should also be recognized that for this and many other applications, the answer properties can be controlled by adding some additional validation script. The typical examples are whether the answer is mandatory, what can be range of answers, etc.
The Eform publishing process 202 further involves adding a form ID to the PDF form so that it may be later accessed and identified.
The creation of an active document, i.e., eFORM, results in an exemplary embodiment adding JAVA script to the PDF document to translate the document from being a passive PDF to an intelligent document by adding program logic into the document. PDF files and JavaScript is one example of electronic form type and program logic which may be combined to form an intelligent document. Alternatively, for example, Microsoft Word documents may be combined withMicrosoft's Virtual Basic Script (VBScript). In a similar fashion, Microsoft Excel, or Microsoft InfoPath may be used with, for example, VBScript. Other contemplated technologies include MacroMedia Flash, PERL script, and XForms may be utilized.
Various users messages may also be added to the PDF file. For example, various error messages and status messages may be incorporated into the document. Usage rights may be established for the form user. For example, a user may be given the right to complete an eform, add comments, save the eForm locally, print the eForm, or digitally sign and submit an eForm.
In accordance with an illustrative embodiment, the embedding of Java script into the PDF form results in some level of form mobility. Thus, for example, the Java script may test to determine whether the system is online. If the system is online, the document may be immediately routed via, for example, the Internet to a desired location. If the system is not online, the form may be routed through e-mail or though some other store and forward mechanism, for example, the Java Message Queue. The document may be routed, for example, via the document router 102, shown in
The server 201, in creating the eForm (200), configures submission rules (204). The submission rules for an eForm incorporate validation rules which must be satisfied prior to allowing a document to be submitted. For example, an eForm would not be in the proper format to be submitted if it were incomplete in some significant respect, such as the omission of mandatory information. The submission rules 204 may also, for example, include routing information for use in determining the location of a destination server targeted to receive the created eForm, and various recipient e-mail addresses. In accordance with an exemplary embodiment, the answer to a particular question or set of questions, in a questionnaire may be routed to one e-mail address. The answer to a different question in, for example, a different portion of the questionnaire, may be routed elsewhere.
The configuration of submission rules 204 may further involve the configuration of web services to establish a connection via, for example, the Internet or, alternatively, to configure various store and forward mechanisms, such as e-mail or to identify another temporary local store for created eForms when an online connection is unavailable. The submission rules 204 may also, for example, include an indication of whether a partial submission is required, or whether a resubmission of all or a portion of the information is allowed. The submission rules may additionally permit the configuration of an initial submission which may later be accessed, revised, and then resubmitted, for example, once more complete information has become available.
The server 201 additionally configures process rules 206 which define how a form, once created, will be processed when it is received by the server. During such processing, the server performs various validation operations to check the basic data contained in the form. For example, if the form identified the name of a drug being tested, a check may be made to determine that the drug bears a name that server 201 has been previously programmed to be recognized. If such basic data validation checks indicate that the form must be rejected, the end user is sent an appropriate notification. A failure of a basic data validation check may trigger routing the form to a quality control site, where the detected error may be corrected. An end user may also receive notification, upon the server's receipt of the form, that the form had been received. Various post processing checks of the eForm may also be applied after processing by the server. An end user may subsequently be notified that the form had been processed successfully.
The server 201 also operates to integrate the created eForm 200 with a line of business application (208) by, for example, routing the created eForm to the appropriate line of business application shown in
As shown in
The create and publish processing operates to ensure version control of forms to keep track of changes that have been made in a modified form. The create and publish function also involves creating a task/forms package in which forms are stored in a repository. The forms packaging process involves inserting one or more forms into selected portions of a document to create the forms package.
With respect to the “find and apply” 227 portion of an eForms lifecycle, a user may, for example, connect to a web portal to search for and find a particular form package. The user may then download the forms package to, for example, the user's laptop computer, tablet computer, smart phone or PDA or home PC. The user, after downloading the forms package, may then subsequently fill in the form package, either upon receipt or at any subsequent time convenient to the user. It should be understood that the downloading operation may be performed via e-mail, where the forms package will be e-mailed to a requesting user, alternatively, the forms package may be downloadable directly from a customer's website. The forms package may even, for example, be received by a user by receipt of a CD through the mail.
In accordance with an exemplary embodiment of the present invention, under circumstances where a user does not have sufficient information to complete all of a form, after portions of the form are filled in by the user, a form portion is routed to a further site for collaboration in completing the form. In this fashion, a collaborator (e.g., a business partner having different product responsibilities than the original user) may provide information not available to the user who downloaded the forms package. Alternatively, in other applications, the routing and collaboration may involve the approval process for a purchase order to enable an electronic purchase to be completed.
The find and apply processing 227 may also involve validating data in light of rules which may, for example, be application dependent. In electronic commerce and other applications, the eForm may be digitally signed and other digital security measures may be incorporated to employ authorization and verification cryptographic operations.
The routing and collaborating processing may employ the enhanced digital signature methodology disclosed in U.S. Pat. No. 5,214,702, which provides for a wide range of collaborative digital signatures, including counter signatures and is hereby incorporated by reference in its entirety. Using the methodology described in U.S. Pat. No. 5,214,702, a submitted forms package may be routed through various layers of authorization. Using this technology, the person who signed the particular form package may be proven to have had the authorization necessary for a given application, such as an electronic commerce transaction, to be completed. Collaboration may also involve including a notification package receipt indicating success/failure and resubmission requests. Further, the collaboration may involve in the case of government grants, an indication of status changes in an application as, for example, the application goes through one of multiple steps involved in the application processing.
The forms package is thereafter delivered in the find and apply processing via either on-line or off-line methodologies. As an alternative, the package may be delivered via fax to fax server 72 (
With respect to filling in the form package, if the form is a PDF file, the process of filling in the form may utilize, for example, Adobe Acrobat Reader, together with “form client” and “reference data service” utilities provided at 235.
The reference data service permits the client to utilize the SubmitIT server 201 to retrieve reference data related to a particular forms package. For example, if the forms package involves ordering parts, the reference data service and the server 201 may be used to supply a list of valid part numbers.
The capture processing 229 occurs at the server 201 after a client has performed the find and apply processing 227. After the client has submitted a completed form, the form is received at the server side. The form will either have been submitted via an on-line submission of the forms package via web services or, for example, by an off-line submission via e-mail. Additionally, the form may be printed out and faxed to the server 201. The received fax would then be scanned and processed as explained above in conjunction with
The server 201, as indicated at block 237, has associated various utilities for use in capture processing. Form client software is used during submission processing to enable the client to submit the form. The portal services permits the capture of the form via web services. The reference data service is utilized during the capture processing 239 to provide access to business rules, validation rules, and to perform field level data validation beyond that performed in the find and apply step 227.
The design of the eForms-based system is intended to accommodate a wide range of communications media. For example, during capture processing 229, the system supports multiple transport protocols such as web services, HTTP(s), FTP, SMTP, WiFi (802.11), paper and fax, which may be utilized to capture a forms package. The system is intended to support a wide range of eForm vendors and technologies. During the capture processing, security may be enhanced by utilizing a digital notary so that it is possible to unambiguously establish the date and/or time of submission.
The server 201 performs a series of processing operations on the forms package (231). The form is received and processed by, for example, converting the form into XML (as explained above in conjunction with
The server 201, in an exemplary implementation, keeps track of form packages which have been received and maintains statistics indicative of, for example, how many form packages have been received, how many have been processed, etc., as has been described in conjunction with the above-identified incorporated application.
In accordance with an exemplary embodiment, the data may be converted into a neutral format, such as XML and then further converted into a line of business application format. The data then will be delivered to the line of business application.
During eForm processing 231, in order to properly validate a form, data may be fetched from a common data registry to receive financial information from, for example, a Dunn & Bradstreet data registry. The processing 231 supports the full submission of forms, a partial submission of forms, the resubmission and the partial resubmission of such forms. An integration monitor may be used to support multiple delivery protocols for delivering any forms package via web services, HTTP(s), FTP, SMTP, or supporting specific client requests.
If the line of business application is, for example, a government application, the server 201 utilizes agency systems software (239) to complete the processing.
The documents may, for example, be submitted to the server 201 via web services 252 or via e-mail 254. Alternatively, the document may be input via a physical media such as, for example, a floppy or a CD, which in turn is transmitted by physically transporting the media to server 201. A document also may be forwarded to a server via facsimile 258 or via postal mail 260. If the document is received via facsimile, then it is processed in server 201 via the capture processing (262) which was explained in detail in conjunction with the
Whether the information is received via facsimile and processed at 262 or via some other mechanism such as web services 252, the server 201 processes a form at 264 as, for example, explained above in conjunction with the
The data which is being routed may be stored within the server (272). Storage of the data at 272 may not occur in certain applications, where, for example, the data need not be referenced again. Additionally, various notifications are distributed to either the back end system 284 or the client who submitted the input form document.
A server 201 having the above-described functionality may be utilized in a wide variety of applications, including customer relationship management (CRM) applications. Thus, one application of the above-described active document methodology may be in managing customer support, responding to customer problems and managing data related thereto.
The received active form is processed by the SubmitIt engine 310 having the eForms processing package described above in conjunction with
The data is then customized to the given application for use by a custom lead generation system 314, which is described in detail below. Alternatively, the document for example, in XML form, may be routed to an ACT application 316, which is, for example, a contact management system for contacting customers and includes customer names, addresses, etc. or Quickbooks 316 which is an accounting system. The information may be routed to an Oracle database application 318. Alternatively, the information may be routed to any number of different trading partners as represented at 320 and 322.
Thus, the active form mobile software architecture described above permits wide flexibility in terms of connectivity. Data is permitted to enter the system via a wide range of input mechanisms including e-mail, facsimile, Web services, etc., and incorporates the ability to work with any document type, including PDF, Word, InfoPath, and others. Likewise, the system's output envisions via the same wide range of connection mechanisms.
Lead Generation Server Application
As shown in
Enterprises are spending significant sums in marketing their products and services by conducting events and publishing white papers and related marketing collateral on their products and services. The linkage between this activity and lead generation is loose at best.
The process of generating/capturing high-quality leads that can be taken through the complete sales cycle is still very complex, and in many cases a hit-or-miss effort. There is constant tension between the marketing organization, whose primary role is to generate sales leads, and the sales organization, whose primary role is to convert these generated leads into closed sales. Marketing departments typically measure the degree of success in their mission by the quantity of leads they generate, irrespective of the quality of these leads. Sales organizations on the other hand measure their success on booked/collected revenue, which is directly tied to high-quality, high-interest leads.
The gap between the leads that marketing is “tossing over the wall” and the leads that sales really needs can be bridged if marketing organizations execute marketing programs that allow them to generate, and more importantly, identify high-quality leads.
One existing method of capturing high-quality leads is through the process of getting feedback or inquiries from customers who read or review marketing documents. The fact that a reader has taken the trouble of “self selecting” themselves in responding, indicates a high degree of interest, which in turn is a strong indicator of a high-quality lead. Many companies currently conduct on-line surveys. The survey respondent has to login to a web site or post an e-mail to communicate his opinion or feedback. Online surveys have not been shown to be a very effective way to generate “publication driven” leads since most publications are distributed in PDF format that allows offline reading while the surveys are conducted online. Because of this gap, most readers lose interest in filling out the feedback surveys.
The marketing agencies or the marketing department within the enterprises runs various campaigns and surveys to collect information from the target users. These surveys may be online web based or through electronic forms such as PDF, Word, InfoPath forms or paper based. The inventors recognize that “lead” information needs to be captured and routed for action to people within the enterprise or the appropriate lead Partners for action. The information needs to be analyzed and preferably presented by charts or graphs. These lead data also need to be integrated with multiple third party applications such as CRM, Contact Management, Business Intelligence, Statistical Analysis and Lead Management applications.
The marketing documents are mostly available as PDF documents. These documents are passive documents.
The exemplary embodiments described below collect vital lead information from the reader of these documents by way of survey forms attached to these static marketing documents. This lead data captured and gathered from the user may also be used as a metric to measure the success of the various marketing campaigns and also help close the loop between marketing and sales by integrating the lead data with the CRM applications.
Each marketing agency and enterprise in accordance with the exemplary embodiment is able to capture the leads for multiple partners/clients or departments within an enterprise and also run multiple projects/programs for a partner/client or department. A flexible multi-line organization structure is provided for aggregating this lead information. The partners/clients or departments are able to view the lead data organized by projects or programs.
An exemplary embodiment of the lead generation system provides a comprehensive solution for the capture, analysis and processing of lead data submitted via online/offline, electronic and paper based forms that are embedded in marketing collateral, surveys or related documents.
The rich clients for the exemplary lead generation system will be content generation applications such as Front Page, Adobe Acrobate Reader, and Word where the marketing content is generated. The exemplary lead generation system client plug-ins will be embedded within these content generation applications to ease the process of designing and generating the appropriate survey forms, attaching these to the marketing collateral, and mobile-enabling these documents for distribution as Lead Generation Marketing Collateral.
This collateral or documentation can be distributed either manually, through a lead generation system portal for download or mass distribution using the distribution lists by email or fax through the lead generation server.
Platform Functional Overview
The server 201 interacts with eForms subsystem 350 and document image processing subsystem 356. The eForms subsystem 350 includes a question or label management system 352, a template management system 354 and an active document management system 356.
The question or label management system 352 is responsible for creating and maintaining a set of questions used to obtain feedback from the recipients. Questions are synonymous with the ‘label’ or ‘prompt’ accompanying a response area. This set of questions will be maintained in a questionnaire library for reuse. The questionnaire management subsystem 352 is operable to create a new questionnaire or to enable a user to select one or more questionnaires as will be explained further below. The system is operable to add, delete or modify one or more questions and publish a questionnaire. The published questionnaire is then stored in a questionnaire storage library so that one or more questionnaires may be selected for use.
The template management subsystem 354 relates to a survey questionnaire that has a predefined set of questions is a specific format and style. A list of standard templates will be available in the server 201. The template management system will permit the selection of questionnaires from a questionnaire library and a selection of themes from a theme library. The subsystem will permit users to create, modify or delete templates and to publish a generated template and store the template in a template library from which users may select a template for use.
Active document management subsystem 356 permits a user to manage a document that has an embedded survey form attached to it, in order to obtain feedback from readers of the document. The reader feedback can be captured online or offline and routed to the appropriate departments or business partner's. The document can capture feedback from any number of users who read the document. The active document management system will permit, for example, selecting a marketing document, selecting a template, and selecting a marketing program for generating an active document. The generated active document will be published and stored in an active document library. The generation of active documents permits the selection and updating of routing rules for the active document, and will include mobile software for distribution as required by a given application. The active documents will be distributed through an active document distribution management module through configured channels such as e-mail or fax to the target audience based on a distribution list. The distribution of an active document permits the selection of both an active document and a distribution channel. A distribution channel may, for example, include e-mail or facsimile. Users of the active document distribution management module will be able to select a distribution list and update the distribution list. For each generation system, in accordance with an exemplary embodiment, will also include an organization management module which initially installs a default or home organization. Users can be mapped to this home organization who can then set up partner organizations and partner users. The home organization users can create roles and privileges. The home organization users administer the other modules in the system. Suborganizations or departments can be created under the home organization. These suborganizations are not visible to one another. Each of these suborganizations may be strategic business units inside an organization.
In accordance with an exemplary embodiment, various additional modules are used in the lead generation system which are described below. For example, the lead generation system in accordance with such an embodiment utilizes a partner management module. A partner is an organization that subscribes and uses the lead generation server to publish documents related to its products, collect feedback and generate leads. For example, a marketing company might create a partner organization for each of the marketing companies clients. Each such client would only be able to interact with their portion of the system.
In an illustrative embodiment, the program management module is operable to perform the following functions.
PRM-02 1) Map Program to Partners
A partner user or home user is able to map the Program to multiple Partners. This may be the case for joint marketing program where more than one Partner is involved.
PRM-03 2) Map Program to Partner Users
A home user or partner user with appropriate privileges is able to map partner user or set of partner users to a Program. By default all the users of the Partners who are mapped to the program will be displayed. The partner user will be able to perform the following functions based on the privileges:
A home user with the appropriate privileges will be able to map home user or set of home users to a Program
PRM-05 4) Map Program to Sub Organization
A home user with appropriate privileges will be able to map Program or set of Programs to the sub organization
In an illustrative embodiment, the above-described questionnaire management module 352 is capable of performing the following functions:
QRM-01 1) Questionnaire Category
A home user will be able to select/add/modify/delete Questionnaire category for easy administration and retrieval of Questionnaires. Every Questionnaire will belong to one or more Questionnaire Category. During the process of creating a questionnaire a user will be required to specify the category the questionnaire belongs to, as shown in the exemplary screen display shown in
QRM-02 3) Define New Questions
A partner user or enterprise user with appropriate privileges will be able to define new questions for a given questionnaire using the Questionnaire Management module. For each question,
A partner user or enterprise user with appropriate privileges will be able to modify the existing questions in a given questionnaire using the Questionnaire Management module. For each question,
A partner user or enterprise user with appropriate privileges will be able to delete existing questions from an existing questionnaire as shown in the exemplary
QRM-05 5) Add Routing Rules to Question
A partner user or a home user with appropriate privileges will be able to add routing rules to each Question
QRM-06 6) Add Routing Rules to the Questionnaire
A partner user or home user with appropriate privileges will be able to add routing rules to the Questionnaire
QRM-07 7) Map Questionnaire to Partner
A partner user or home user will be able to map a Questionnaire to a Partner or set of Partners
QRM-08 8) Map Questionnaire to Program
A partner user or home user will be able to map a Questionnaire to a Partner or set of Partners
QRM-09 9) Map Questionnaire to Sub Organization
A home user will be able to map a Questionnaire to a sub organization or set of sub organizations
QRM-10 10) Spell Check
A spell checker routine will check the spellings of the common words based on a dictionary. The spell checker can be invoked during the process of adding or modifying questions (QRM-02 and QRM-03)
QRM-11 Pick One
This response option will define the possible options and the reader of this survey will be able pick and choose only one answer options as shown in the illustrative
QRM-12 Check All That Apply
This response option will define the possible options and the reader of this survey will be able to select one or more of the options as shown in the illustrative
QRM-13 Rank Along Scale
This is a comparative satisfaction scale used to measure the reader's satisfaction/dissatisfaction for a given problem. This is a user-friendly reader response in a scale of ‘1’ to ‘5’ for example. ‘1’ may mean very dissatisfied and ‘5’ may mean very satisfied. The reader will choose any one between ‘1’ and ‘5’. The reader has an option to select only one. See
QRM-14 Dropdown Box
This is an option for the reader to select only one of the pre-defined options from a dropdown list box. See
QRM-15 List Box
This is an option for the reader to select one or more based on the list which can be seen all or some based on the size of the list box. The list box can be scrolled vertically or horizontally to see all the choices available by the reader. See
QRM-16 Single Line Text Response
This is text box with only one line. There is no multiline capability. The length of the characters is fixed to the display length of the text box. See
QRM-17 Multiline Text Response
This is a text box with the capability to input more than one line. This is used in the scenario where the reader needs to give a free flow response. See
QRM-18 Numeric Allocation
This is a reader's suggested allocation of a predefined number may be 100 or 10 or any pre-set number. There is a list of options with a numeric box next to it. The reader will assign the appropriate number and the sum will always add up to the pre-set number. This is used to get an idea of the allocation of time or in case of a product feature list the weightage of each to the end user. See
QRM-19 Matrix
This option is used when response needs to be based on a row and column questions. There will be only one option to be selected on each row. See
This answer option ensures that the reader responds to this question without fail. The user will not be able to submit the survey without completing this question. See
QRM-21 Copy Questions from Existing Questionnaire
A new questionnaire can be developed by coping all or part of questions from one or more than one questionnaires
QRM-22 Display Horizontally
This option will design the answer options to be displayed horizontally
QRM-23 Display Vertically
This option will design the answer options to be displayed horizontally
QRM-24 Response Validation
This option will be useful when the user responses need to be validated such as date validation, numeric validation etc
QRM-25 Table
This option will be useful when the user needs to collect multiple rowset of responses. The number of rows may be pre-defined or unlimited. The columns are predefined and responses for each row are collected in unique cells. The response for each cell will be mapped uniquely to a row and column. These cell responses will be textboxes, select one, select all, combo box, etc.
QRM-26 Select Yes/NO
This option is used when the user needs to get yes or no response from the reader.
QRM-27 Display Questions in Questionnaire
The Questionnaire with the added or modified questions will be displayed to the user to verify for accuracy. The user will be able to navigate and select the individual questions for modification or deletion. See
QRM-28 Capture Questionnaire Name
This is the user given name for the Questionnaire. The user will change this name in future.
QRM-29 Generate and Save Questionnaire
The questionnaire will be saved locally on the users system. The Questionnaire will be saved on the default location for the questionnaire.
QRM-30 Store Questionnaire on Server
The completed questionnaire after saving locally will be stored on the Server. The LGS Questionnaire Management web service will be invoked by the LGS client plugin to save the Questionnaire on the Server
QRM-31 Select Questionnaire
The list of available Questionnaire will be displayed to the user for easy selection of the Questionnaire. The LGS client plugin will invoke the LGS Questionnaire Mgmt webservice to retrieve a list of the available Questionnaires. See
QRM-32 Select Question
Any question on the Questionnaire will be able to be selected for editing or deletion.
The question list will be displayed to the user. See
QRM-33 Modify Questionnaire Name
The Questionnaire Name may be changed by the user if need be.
QRM-34 Generate and Save Modified Questionnaire
The modified Questionnaire will be saved on the user's local system in the default directory. The user should however be prompted for the location to save the questionnaire.
QRM-35 Store Modified Questionnaire on Server
The modified Questionnaire will be stored on the Server. The LGS client plugin will invoke the LGS Questionnaire Mgmt web service to save the modification.
QRM-36 Delete Questionnaire
The selected Questionnaire will be deleted from LGS. The client plugin will invoke the LGS Questionnaire Mgmt web service to delete the Questionnaire.
For an example of an illustrative questionnaire management system, see the website www.websurveyor.com.
In an illustrative embodiment, the template management module 354 is operable to perform the following functions:
TPM-02 Template Category
All templates will belong to a previously defined Questionnaire category for now.
(see QRM-01)
TPM-03 Add New Templates
A partner user or enterprise user with appropriate privileges will be able to define new templates using the Template Management module
TPM-04 Modify Existing Templates
A partner user or enterprise user with appropriate privileges will be able to modify an existing Template using the Template Management module in the adobe plug-in
A partner user or enterprise user with appropriate privileges will be able to delete existing template using the Template Management module
TPM-06 Add Routing Rules to Templates
A partner user or a home user with appropriate privileges will be able to add routing rules to the template.
TPM-07 Map Templates to Partner
A partner user or home user will be able to map a Template to a Partner or set of Partners
TPM-08 Map Templates to Program
A partner user or home user will be able to map a Template to a Program or set of Programs
TPM-09 Design from Scratch
A template can be designed from scratch.
TPM-10 Copy from existing template (this might be similar to TPM-04)
A template can be copied from an existing template. All the questions and design elements of the template are editable A new set of questions can be defined. An existing set of questions can be deleted
TPM-11 Use Logo
The user will be able to insert a logo in a template per the pre-defined location in the selected template style
TPM-12 Header Text and Footer Text
The user will be able to insert header and footer text per the pre-defined locations in the selected template style
TPM-13 Title, Introduction, Closing Comments
The user will be able to insert a title, introduction and closing comments in the template. See
TPM-14 Use Pictures
The user will be able to insert a picture in a template and be able to position this in the desired location
TPM-15 Specify Key Format Items for Question Section
The user will be able to specify font type, font size and font color for the question section, header text and footer text. See
TPM-16 Select Template Style
Template style is a pre-defined template with place holders for logo, header text and footer text and footer logo. The logo and text will be inserted at the time of creation of the template.
TPM-17 Create a Pre-defined Format Set
The user can define his/her format sets. A format set is a set of font, color, size or uniform set of design elements which gives a similar look and feel for the templates with the same Format Set
TPM-18 Display Template
The template will be displayed as a preview to the user. See
TPM-19 Capture Template Name
This will be user given name to the Template. This name will be changed by the user in future.
TPM-20 Generate and Save Template
The template will be saved locally on the user's computer. The template will be saved in the default location on the user's computer. However the user will be prompted with the directory location to choose for saving the template.
TPM-21 Store Template on Server
The Template will be stored on the store. The client plugin will access the LGS Template Management web service to save the template on the Server
TPM-22 Pick and Choose Questions
The user will be able to pick and choose questions as the case may be to construct the template. This may be a subset or all of the questions from the selected Questionnaire. See
TPM-23 Select Template
The user will be able to select the Template from the list of available templates. The list of templates will be populated by the LGS Template Mgmt webservice in response to the LGS client plugin request. See
TPM-24 Specify Key Format Items for Template Style
The user will be able to specify font type, font size and font color for the Template Style, which will consist of the header text and footer text. See
TPM-25 Modify Template Name
The user will be able to modify the Template Name. The template name can be modified any time in the future.
TPM-26 Generate and Save Modified Template
The modified template will be saved locally on the user's computer. The Template will be saved in the default location. However the user will be prompted to choose the directory location on the comptuer for saving the template.
TPM-27 Store modified Template on Server
The LGS client plugin will invoke the LGS Template Mgmt webservice to store the template on the server.
As shown in
In an illustrative embodiment, the active document management module 356 is operable to perform the following functions:
ADM-03 Open Existing Document
A valid partner user in the system will be able to open an existing pdf document using the Adobe plug-in
ADM-12 Signon Templates
The Active Document author using the Active Document Management tool bar will access the predefined signon templates under the template category ‘Signon’. The selected signon template will be attached to the existing document. When the active document is opened by the reader, the Active Document will prompt the reader to provide the information in this “sign-on” form and capture the user information and display the content only after the user provides the requested information and submits the information to the Active Document Server. In case of subsequent access of the Active Document the cached information will be shown and an acceptance will be requested for sending the user information. Only on acceptance will the content be displayed to the user.
ADM-13 Reader Usage Statistics
The Active Document Management Module on the client will have this feature. The Active Document author will enable this feature. By default this feature will be off. If this feature is turned on the Active Document will capture the viewing time of the Active Document reader. The captured time will be cached and sent as part of the submission or during the closure of the Active Document.
ADM-14 Capture Comments Location Context
Capture comments anywhere on the document with location context to identity what part of the content the comments were placed on. The location context will include the relevant Page No, line no and any appropriate information
ADM-15 Context Sensitive Questionnaires
The Active Document author will be able to place on the existing static document questions or set of questions from the question library any where on the document. The Active Document author will be prompted the routing details for the question or set of questions. The Active Document author will be able to select the default routing rule or add on to the routing information. This feature will be similar to the capture comments feature in Adobe. Only a visual cue as to the existence of the questions will be available to the reader of the Active Document. When the mouse rests on this visual cue the relevant questions will be popped and the reader response will be captured.
ADM-16 Reader Response Detection
This feature will help not to lose the captured reader information by accidentally closing the Active Document. A fool proof mechanism to detect user responses in the Active Document needs to be developed. In the event of accidental closure the Active Document will popup a dialog to request the user for submission of the responses. If the user acknowledges acceptance then the captured information will be submitted to the Active Document Server. Accidental closure will be deemed when the reader of the Active Document responds to questions including comments but does not submit the responses using the action buttons of the Active Document.
ADM-17 Instant Collaboration
The Active Document will become a powerful collaborative tool between the reader and the enterprise users who are listening for the reader responses. The Active Document Management module will capture this feature. This feature will be disabled by default. If enabled the Active Document will become an instant collaborative tool enabling two-way communication between the interested reader and the enterprise user who wants to listen to the reader. The reader will see an icon in every page of the Active Document like the Instant Messenger. On clicking on this link will open a live two way communication dialog with the enterprise user. This feature is similar to live support on the web sites
ADM-10 Licensing
The client plugin will display all the Modules. Only licensed modules will be enabled and the others features will be grayed out. This will not only control the functionality in terms of packaging but also will provide significant marketing for more features.
ADM-18 Adobe Plugin Environment
In an exemplary implementation, the adobe plugin needs to available on the following versions of adobe
In an illustrative embodiment, an active document distribution management module is operable to perform the following functions.
ADD-01 Upload Distribution List
The partner user or home user with appropriate privilege will be able to upload a distribution list to the Active Document.
ADD-02 Configure Distribution Channel
The partner user or home user with appropriate privilege will be able to configure the distribution channel for distribution of Active Documents. In an illustrative embodiment, the possible distribution channels are:
The partner user or home user with appropriate privileges will be able to modify the distribution list. They can add, modify or delete some emails in the list.
ADD-04 Delete Distribution List
The partner user or home user with appropriate privileges will be able to delete the distribution list.
ADD-05 Configure Active Document Distribution
The partner user or the home user will be able to configure the Active Document for distribution using the distribution channel specified with date and time. This is a preset date and time for mass distribution of the Active documents to the target recipients.
ADD-06 Manual Distribution of Active Document
The user using the Active Document Distribution module may send the Active document using the distribution list and the distribution channel by activating this module. This will be used for repeat distribution or manual distribution
In an illustrative embodiment, the lead capture and distribution management module is operable to perform the following functions.
LDM-01 Distribute Lead Configuration
A valid user will be able to configure the distribution frequency by partner, program and Active Document
See use case below for details
LDM-02 Track Lead
A valid user will be able to view or download leads in Excel or XML
See use case below for details
LDM-03 Download Lead Data with the Template
A valid partner user will be able to download the lead data with the template
LDM-04 Acknowledgment Notification
The system will notify the submitter based on the configuration when the Lead data is successfully received by the LGS
In an illustrative embodiment, the lead analytics and reports module is operable to perform the following functions.
LAN-01 Excel Template
There will be pre-defined templates with graphics for analyzing data using Excel.
LAN-02 Partner Transaction Summary
A partner user will be able to search and display the report. This report will be printer friendly.
The Partner Transaction Summary report will display the data in the following columns:
Heading: ‘Partner xxxxx transaction summary for the period from xxxx to xxxx’
If more than one partners are listed the Heading will read ‘Summary transaction for the period xxxx to xxxxx’
Partner Names: List the Partner names
Column titles:
The Leads will be totaled and a total lead will be displayed at the end of the report
The report will display the run date and time at the footer
LAN-03 Program Transaction Summary
A partner user will be able to search and display the report. This report will be printer friendly and based on search criteria specified.
The Partner Transaction Summary report will display the following data
Heading:
Partner Name: <Partner Name>
<Partner Name>
Program Name: <Program Name>
Transaction summary for the period from XXX to XXX′
If more than one partners are listed the Heading will read ‘Summary transaction for the period xxxx to xxxxx’
Partner Names: List the Partner names
Column titles:
The Leads will be totaled and a total lead will be displayed at the end of the report
The report will display the run date and time at the footer
In an illustrative embodiment, the security module is operable to perform the following functions.
SEC-02 Support for https Protocol
The plugin will access the LGS through web services and all the transactions will be through https protocol
In an illustrative embodiment, the licensing module is operable to perform the following functions.
LIC-01 License Key
The client plugin will be activated only after the license key generated by the LGS and sent by email is entered during plugin installation. This key will be cached and encrypted on the local system of the user
LIC-02 Client Module Activation
The client plugin will display all the Modules. Only licensed modules will be enabled and the others features will be greyed out. This will not only control the functionality in terms of packaging but also will be a powerful upsell for more features.
Others
The lead generation system in accordance with further exemplary embodiments has the following capabilities:
Thereafter, as shown on the screen display in
After a questionnaire category is selected, a question style is selected from a menu (533).
Thereafter, the questionnaire creation process permits capturing the precise question and response text and meta data (which is information/data which is descriptive of the data) (535). Meta data may include, for example, question style information.
After the question response text is captured, a decision is made at block 537 as to whether an additional question is to be added. If an additional question is added, then the routine branches to 533 where a question style may be selected. If no further questions are to be added then the routine displays the questions in the questionnaire (539) as, for example, shown in
Thereafter, the routine will capture the questionnaire name (541) and generate and save the questionnaire locally (543). The questionnaire will then be stored on the server 201 shown in
As shown in the
Thereafter, as shown in the exemplary screen display in
The routine then sequences to block 562, where a decision is made as to whether a question is to be modified. If a question is to be modified, then a question is selected (564), such as one of the questions shown in
The routine then branches back to 562 to determine whether any further questions need to be modified. After all questions that need to be modified have been modified, the routine branches to block. 568, where the user has the option to modify the questionnaire name. Thereafter, the user may generate and save the modified questionnaire locally (570) and store the modified questionnaire on the server (572), after which the routine ends (574).
The user then has the option of selecting a template style (582). The style is specified, for example, by capturing the logo, the header and the footer text (584). Thereafter, the font name, font color and font size are selected, as, for example, shown in the exemplary screen display shown in
The template title, introduction and closing comments are then captured (588) using, for example, the screen display shown in
The user is then able to select a category of questionnaires for the template as previously described in conjunction with
Thereafter, the font name, font color, font size for the title, introduction, closing comments and questions may be selected as indicated in the screen display shown in
The created template is then displayed (598).
Thereafter, a template name is captured (600) and the template is generated and saved locally (602). The template is stored on the server (604) and the creation process is completed (606).
The user is then able to modify the font name, font color, font size, for the template style (the header and footer), using, for example, the screen display such as shown in
If the user had previously registered, the user logs in as indicated at block 640. Thereafter, the Adobe lead generation system plug in is downloaded (642), after which the Adobe lead generation system plug in is installed (644). The user is then prompted for entry of credentials which may include, for example, the user name and organization. All necessary credential information is stored in cache memory on the user's computer (646), after which the routine terminates (648). The captured information about the user will be later required by the previously described SubmitIt server 201 so that the system can determine whether the user is a partner, employee, manager, etc., for use during subsequent processing.
The user's credentials are then validated (650). These credentials determine to which system facilities the user will have access.
Depending upon the user's credentials, the user will be able to browse the template library (658) and select a particular template to which the user is authorized to access (660).
If desired by the user, the user may select a program such as a particular marketing program (662). As indicated at block 664, the user is able to page through a document and select page positions to insert templates. In this fashion, the user is able to pick locations in the document at which, for example, a particular questionnaire is to be inserted. As described previously, this methodology may be utilized, for example, in a textbook application to insert chapter tests at the end of each chapter.
Thereafter, the user is able to select and update routing rules (666) which will determine the routing rules that are specific to a selected program, thereby permitting routing of different templates or portions of a template to different parties through different routing mechanisms.
The active document is then generated (668), whereby code is actually embedded in a selected document, for example, a marketing related PDF file. The generation of the active document results in an electronic document with a wide range of logic incorporating questionnaires, routing rules, etc. Thereafter, the active document is published by being placed on the server (670) and/or by distributing the document via other means, after which the routine terminates (672).
Alternatively, after logging in, a user may select “program” which is a subset of all the leads (678). Thereafter, such subset of leads may be downloaded in, for example, an Excel spreadsheet form or XML form (684) after which the routine terminates (690).
Rather than selecting leads for downloads, a user may receive a listing of all the leads (680) and thereafter select a particular lead (686). After selecting a specific lead, the lead data with template may be displayed (692). Thereafter, the lead data which was displayed may be downloaded with template or the lead data may be downloaded in XML format after which the routine terminates (696).
A wide range of further embodiments are also contemplated. For example, a further embodiment is contemplated in the form of an interactive catalog. Such an illustrative embodiment may, for example, be an active document-based electronic replacement parts catalog for an equipment manufacturer. Such an active document-based catalog could be used by a field service technician to order replacement parts for, for example, a photo copier. The system would allow the selection by, for example, a technician, among all of a company's products. After a product is selected, the system may, for example, allow for the selection of a subassembly from a diagram of the product. After the subassembly is selected, the system may, for example, display an exploded parts diagram of the subassembly, allowing the required part to be selected interactively.
If the technician was on-line, the active document would use, for example, web services to query the availability and price of the part. The technician would then confirm or reject the selection. If the selection was confirmed, a parts order eForm would be generated for the selected item. Next, the technician would be given the opportunity to make additional selections. After all selections had been made, the technician would complete the eForm, including, for example, a customer number. Next the technician would submit the eForm. If the technician were on-line the form would be submitted immediately, through web services.
If the technician were off-line, the form would be submitted via, for example, e-mail. When the eForm is processed by the SubmitIt server, the customer number would be used to retrieve the customer's email address and shipping address. An order confirmation would be generated for the customer and sent via email. Finally, the order would be forwarded to the order processing system for final processing and installation scheduling.
While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the invention is not to be limited to the disclosed embodiment, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.
This application is a continuation-in-part of application Ser. No. 10/361,853, filed on Feb. 11, 2003, entitled “Facsimile/Machine Readable Document Processing and Form Generation Apparatus and Method” which application is hereby incorporated by reference in its entirety. This application claims the benefit of Provisional Application No. 60/563,799, filed Apr. 21, 2004, the entire content of which is hereby incorporated by reference in this application.
Number | Date | Country | |
---|---|---|---|
60563799 | Apr 2004 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 10361853 | Feb 2003 | US |
Child | 10837889 | May 2004 | US |