REGISTER  |  SIGN IN
United States Patent6094684
PallmannJuly 25, 2000
Title
Method and apparatus for data communication
Abstract
A data acquisition and delivery system for performing data delivery tasks is disclosed. This system uses a computer running software to acquire source data from a selected data source, to process (e.g. filter, format convert) the data, if desired, and to deliver the resulting delivered data to a data target. The system is designed to access remote and/or local data sources and to deliver data to remote and/or local data targets. The data target might be an application program that delivers the data to a file or the data target may simply be a file, for example. To obtain the delivered data, the software performs processing of the source data as appropriate for the particular type of data being retrieved, for the particular data target and as specified by a user, for example. The system can communicate directly with a target application program, telling the target application to place the delivered data in a particular location in a particular file. The system provides an external interface to an external context. If the external context is a human, the external interface may be a graphical user interface, for example. If the external context is another software application, the external interface may be an OLE interface, for example. Using the external interface, the external context is able to vary a variety of parameters to define data delivery tasks as desired. The system uses a unique notation that includes a plurality of predefined parameters to define the data delivery tasks and to communicate them to the software.
Inventors:Pallmann; David Frank (Fullerton, CA)
Assignee:Alpha Microsystems, Inc. (Santa Ana, CA)
Appl. No.:832027
Filed:April 2, 1997
Current U.S. Class:709/227 709/246 
Current International Class:G06F 9/46 (20060101)
Field of Search:709/227,228,236,202,246
U.S. Patent Documents
5572724November 1996Watanabe et al.
5721818February 1998Hanif et al.
5781743July 1998Matsuno et al.
5784570July 1998Funkhouser
5838906November 1998Doyle et al.
Other References
Fischer; "Netscapes' Strategy for Network-Based Computing"; Object Magazine, Jan. 1998; pp. 44-49. .
Heylighen, F.; "World-Wide Web: a distributed paradigm for global networking"; Proceeding. SHARE Europe Spring Conference, pp. 355-368; Apr. 18, 1994..~
Primary Examiner: Rinehart; Mark H.
Attorney, Agent or Firm:Wilson, Sonsini, Goodrich & Rosati
Parent Case Text


This application claims priority to each of U.S. Provisional Application No. 60/016,744, filed on May 2, 1996, entitled Method and Apparatus for Data Communication having inventor David F. Pallmann, U.S. Provisional Application No. 60/029,974, filed Nov. 5, 1996, entitled Method and Apparatus for Data Communication having inventor David F. Pallmann and U.S. Provisional Application No. 60/030,992, filed Nov. 14, 1996, entitled Method and Apparatus for Data Communcations. U.S. Provisional Application No. 60/016,744, filed on May 2, 1996, entitled Method and Apparatus for Data Communication having inventor David F. Pallmann and all appendices thereto are hereby incorporated herein by this reference. U.S. Provisional Application No. 60/029,974, filed Nov. 5, 1996, entitled Method and Apparatus for Data Communication having inventor David F. Pallmann appendices thereto are hereby incorporated herein by this reference. The microfiche appendices to the Application No. 60/029,974, filed Nov. 5, 1996, entitled Method and Apparatus for Data Communication having inventor David F. Pallmann are hereby expressly incorporated herein by this reference. U.S. Provisional Application No. 60/030,992, filed Nov. 14, 1996, entitled Method and Apparatus for Data Communcations is hereby expressly incorporated herein by this reference.
Claims

What is claimed is:
1. A data acquisition and delivery system that acquires source data having a first format from a selected data source, comprising:
a target computer;
a data target coupled in communication with the target computer;
a plurality of logical modules available for execution by the target computer in response to a plurality of predefined parameters which one of identify, and characterize an element of, particular logical modules in the plurality of logical modules to establish a data delivery task, to acquire the source data, to obtain delivered data from the source data and to provide to the data target the delivered data in a second format;
a notation data structure accessible by the target computer that includes the plurality of predefined parameters.

2. The data acquisition and delivery system of claim 1, further comprising:
an external interface provided using the target computer to enable input of at least one parameter in the notation to identify and characterize a set of logical modules within the plurality of logical modules to establish the data delivery task.

3. The data acquisition and delivery system of claim 2, wherein at least one parameter selects the selected data source from a plurality of data sources.

4. The data acquisition and delivery system of claim 2, at least one parameter specifies a process used to obtain the delivered data from the source data.

5. The data acquisition and delivery system of claim 2, wherein
the data target comprises a target application program and a target file accessible to the target application program; and
at least one parameter selects a location in the target file as the data target.

6. The system of claim 1, wherein one of the parameters comprises one of a network address and a network location.

7. The system of claim 1, wherein one of the parameters comprises one of a network address and a network location of an FTP server.

8. The system of claim 1, wherein one of the parameters comprises one of a network address and a network location of an HTTP server.

9. The system of claim 1, wherein one of the parameters comprises one of an Internet address and an Internet location.

10. The system of claim 1, wherein one of the parameters comprises one of a network address and a network location of an ODBC server.

11. The system of claim 1, wherein the selected data source is located on the target computer.

12. The system of claim 1, wherein the selected data source is at a location remote from the target computer.

13. The system of claim 2, wherein the at least one parameter comprises a plurality of sub-parameters and wherein the plurality of sub-parameters specify the data target in the target file.

14. The system of claim 2, wherein the at least one parameter is a data mapping parameter.

15. The system of claim 4, wherein at least one parameter identifies a logical module which includes a process by which the source data is transformed to obtain the delivered data.

16. The system of claim 4, wherein the first format comprises an HTML format and the second format comprises a normalized text format.

17. The system of claim 4, wherein the first format comprises a text format and the second format comprises a normalized text format.

18. The system of claim 4, wherein the first format comprises a record format and the second format comprises a normalized text format.

19. The system of claim 4, wherein the first format comprises a multimedia format.

20. The system of claim 2, including resources adapted to automatically execute the data delivery task at a time specified by the external context.

21. The system of claim 2, including resources adapted to automatically execute the data delivery task at a recurring time specified by the external context.

22. The system of claim 5, wherein the data delivery task can be executed independent of execution of the target application program.

23. The system of claim 22, wherein the external interface is adapted to enable the external context to execute the target application program.

24. The system of claim 5, wherein the data delivery task can be executed from within an interface provided by the target application program.

25. The system of claim 1, wherein the data delivery task comprises a set of logical modules and wherein at least one software module is adapted to recognize a plug-in that provides substitute functionality for the at least one software module.

26. The system of claim 25, wherein the set of software modules comprise at least one of a data retrieval module, a format conversion module, a data filtering module, a data mapping module and a data delivery module.

27. The system of claim 1, wherein one software module in the plurality of software modules comprises an FTP client integrated with the particular data delivery task.

28. The system of claim 1, wherein one software module in the plurality of software modules is adapted to recognize a data acquisition plug-in and wherein the data acquisition module is adapted to acquire the source data from the selected data source as specified by the value of at least one parameter using the data acquisition plug-in.

29. The system of claim 28, wherein the data acquisition plug-in is an external FTP client.

30. The system of claim 1, wherein one software module in the plurality of software modules is adapted to recognize a format conversion plug-in and wherein the format conversion module is adapted to format convert the one of the source data and data obtained from the source data as specified by at least one parameter in the notation using the format conversion plug-in.

31. The system of claim 1, wherein one software module in the plurality of software modules is adapted to recognize a data filter plug-in and wherein the data filter module is adapted to data filter the one of the source data and data obtained from the source data using the data filter plug-in.

32. The system of claim 1, wherein one software module in the plurality of software modules is adapted to recognize a data delivery plug-in and wherein the data delivery module is adapted to deliver the data target to the remote data target as specified by the value of the at least one parameter in the notation using the data delivery plug-in.

33. The system of claim 1, wherein the first format is the same as the second format.

34. A data acquisition and delivery system that acquires source data in a first format from a selected data source, comprising:
a target computer including a user interface;
a data target coupled in communication with the target computer;
a plurality of logical modules available for execution on the target computer in response to a plurality of predefined parameters which identify and characterize elements of logical modules in the plurality of logical modules to establish a data delivery task, wherein one of the plurality of modules comprises a process to acquire the source data from the selected data source using a network protocol driver, another of the plurality of logical modules comprises a process to obtain delivered data from the source data, and another of the plurality of logical modules comprises a process to provide the delivered data to the data target in a second format; and
a notation data structure, coupled with the user interface, that stores the plurality of predefined parameters in response to input from the user interface.

35. The data acquisition and delivery system of claim 34, wherein the user interface comprises a graphical user interface.

36. The data acquisition and delivery system of claim 34, wherein the process to obtain delivered data includes a process which filters the source data in response to one of the plurality of parameters.

37. The data acquisition and delivery system of claim 34, wherein the process to provide the delivered data to the data target in a second format includes a process to transform the delivered data from the first format to the second format.
Description
BACKGROUND OF THE INVENTION

1. Copyright Authorization

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the U.S. Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

2. Field of the Invention

The invention relates generally to data communication and conversion, and more particularly to methods and apparatus for enabling a user to retrieve data from a data source and to communicate it to a data target in a specified manner.

3. Description of the Related Art

Historically, the functions of communicating data and converting data have often been isolated from each other. An early means of data communications involving computers, for example, was manual data entry by a human being. In particular, a person using some input device, such as a keyboard, typically conveyed data to a program running on a computer, which stored the information.

Data communication has also been facilitated using a variety of media. For example, the output from one computer could be stored in a portable form, which could be input into another computer. Punched cards could be created by a computer, or a keypunch, and read by another computer, for example. Magnetic tape, magnetic disks, and drums were likewise useful for transporting data between machines. As disks became more and more popular, more portable and inexpensive disks came into use (floppy diskettes, for example).

Beyond data communiation using the movement of media from one computer to another, it became desirable to interconnect computers directly for such communication. Cables connecting computers ("hard-wired connections") permitted communication using digital or analog signals. The desirability of networking computers relates to the development of local area network technology, such as Ethernet.

For long distance data communication, the telephone network could be utilized through the use of modulators-demodulators (modems). As modem technology has increased, these devices typically became faster and less expensive. Software programs were typically required to facilitate these forms of data movement. Input and output involving portable media were usually accomplished by an operating system under the direction of programs, for example. Networking layers of operating systems or add-on products typically facilitate computer-to-computer communication over local connections. Modem connections are frequently handled by software programs for telecommunications.

Transportable media often require formatting conventions and file structures. Direct connections between computers, networking, and dial-up communications typically require protocols that may be agreed upon by connected computers in order to negotiate the orderly transfer of data.

Data communications today can encompass many different forms of communication. Even on one particular medium, there can be many possible communication protocols that might be used. For example, a dial-up modem connection could use any of the following protocols to transfer a file: XMODEM, YMODEM, ZMODEM, KERMIT, and many others.

An early means of data conversion involving computers was entering programs and data into computers, often through the user of front panels. Over time, attention moved to better human-machine interfaces, so that, today, we have the display and entry of text, graphics, and other media.

The need for data conversion of user information proper can come about whenever a user needs to switch from one format to another, for example. This is often mandated by switching from one application program to another, or from one computer platform to another. It can also be required when sharing data between two applications.

A brute force method of data conversion can be to use a human being. Output from one computer can be printed on some medium such as paper (a report), then re-keyed into another computer by a person. This conversion method may be used when a straightforward conversion method is not available to a user.

A higher level of sophistication may be to write a program dedicated to converting from one format to another. For example, a program could be written for use on a particular operating system that could read one data storage format and write another. As computers become more and more embedded in society, the need for data conversion may steadily grow.

The need for data communication has led to specialized software products for telecommunications. There often are, for example, many different communications methods and many different protocols that may have to be supported. Unfortunately, telecommunications products may be good at moving data from one location to another, but may neglect or even ignore data conversion. That is, data communications products may leave it to the user, a programming group, or another product to effect data conversion. A typical data communications product may move files but not change their format.

Similarly, the need for data conversion has led to specialized software products for conversion. There may be, for example, many different formats and a market for conversion between them. Unfortunately, data conversion products may be good at transforming data from one format to another, but may neglect or even ignore data communications. That is, data conversion products may leave it to the user, an MIS group, or another product to effect data communications. A conventional data conversion product may transform data but not acquire it from a remote location, nor deliver the converted results to a remote location.

As computers penetrate society at more and more levels, however, there may be an increasing need to have people who are not computer specialists perform more sophisticated computer operations. Users who need to perform data communications where the data to be received or transmitted is already in a useful form, may be able to easily operate today's telecommunications products. Users who need to convert data where the data to be converted is locally accessible may be able to easily operate today's data conversion products. Users who need to both acquire/deliver data from/to a remote computer and convert the data from one form to another may find a paucity of products to conveniently assist them with such tasks.

Using a conventional data communications product in conjunction with a conventional data conversion product, for example, may enable the user to accomplish the job, but the user (or an informed associate) may have to manually manage the interaction between the two products. This management may often require the user to have knowledge of (1) the internals of the

communications product and the conversion products; and (2) the file/directory structure of the local computer/network. Such information can be technical and beyond some users. Even if not beyond the user, it can be time-consuming to understand. When compared to the self-contained environment of just using a communications product or just using a data conversion product, the two-product combination approach can cost the user (1) time, (2) automation, (3) integration, and (4) require a greater knowledge of computers.

Accordingly, there has been a need for a data communication method or apparatus to facilitate data communication between data sources and data targets even when the data communication involves data conversion and to provide flexibility in doing so. The present invention meets these needs.

SUMMARY OF THE INVENTION

An aspect of the invention is to provide an integrated data communication method and apparatus that is extensible and/or has an open architecture. Another aspect of the invention is to provide a data communication method and apparatus that is flexible for and/or configurable by users of the method or apparatus. A third aspect of the invention is to provide a data communication method and apparatus that may be configured by a user to retrieve data from a selected data source and transfer it to a selected data target in a specified manner.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a system 100 that includes an embodiment 102 of the present invention for retrieving data from a data source and delievering data to a data target;

FIG. 2 illustrates possible data paths from a data source to a data target;

FIG. 3 illustrates a machine model 300 of software used to implement the embodiment 102;

FIG. 4 is an outline of the process of an external interface module of the model 300;

FIG. 5A is a list of link section link notation parameters;

FIG. 5B is a list of HTML section link notation parameters;

FIG. 5C is a list of DDBC section link notation parameters;

FIGS. 6A and 6B are an outline of the process of a data retrieval module of the model 300;

FIG. 7 is an outline of the process of a format conversion module of the model 300;

FIG. 8 is an outline of the process of a data filter module of the model 300;

FIG. 9 is an outline of the process of a data mapping module of the model 300;

FIG. 10 is an outline of the process of an application interface module of the model 300;

FIG. 11 is an outline of the process of a data delivery module of the model 300;

FIG. 12 illustrates the main screen of a graphical user interface used by the machine 102;

FIG. 13 illustrates a link editor screen of a graphical user interface used by the machine 102;

FIG. 14 illustrates a screen that may be displayed while a link is executing;

FIGS. 15A-C illustrate an embodiment of the invention being used as an OLE server;

FIG. 16 shows the screen 1600 used to create HTML files;

FIG. 17 shows the screen 1700 used to create HTML files;

FIG. 18 shows the screen 1800 used to create HTML files;

FIG. 19 is a sample link;

FIG. 20 is a example of a link history screen;

FIGS. 21A-D illustrate a sample of raw data that might be retrieved by an embodiment of the invention;

FIG. 22 illustrates an example of a screen that might be used to specify and display format conversion parameters;

FIG. 23 illustrates an example of a screen that might be used to specify and display FTP parameters;

FIG. 24 illustrates an example of an address book screen;

FIG. 25 is an example of a screen that might be used to specify and display data filter parameters;

FIG. 26 is an example of a screen that might be used to specify and display mapping settings;

FIG. 27 is an example of a Report learner screen that might be used by an embodiment of the present invention;

FIG. 28 is an example of a auto learn screen that might be used to specify and display variables related to an auto learn function;

FIG. 29 is an example of a screen that might be used to specify and display parameters related to gateway delivery;

FIG. 30 is an example of a screen that might be used to specify and display parameters related to remote FTP delivery;

FIG. 31A shows a report learner screen;

FIG. 31B shows a field properties dialog screen used with the report learner.

DETAILED DESCRIPTION OF AN EMBODIMENT

Embodiments of the invention provide a novel apparatus and method for communicating data from a data source to a data target. The following description is presented to enable a person skilled in the art to make and use the invention. Descriptions of specific embodiments are provided only as examples. Various modifications to the described embodiments may be apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the described or illustrated embodiments, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

FIG. 1 is a generalized diagram of a system 100 that contains an embodiment 102 of the present invention. This system 100 includes a data source 104 and a data target 106. We shall refer to the embodiment 102 as the AlphaCONNECT machine 102. The AlphaCONNECT machine 102 executes data delivery tasks. A data delivery task obtains data 120 from the data source 104. It may or may not transform (e.g. convert and/or filter) the data 120. It then delivers the transformed data 122 to a data target 106.

The AlphaCONNECT machine 102 shown in FIG. 1 includes software 114 running on a computer system 112. In the present embodiment, computer system 112 includes an IBM compatible personal computer running a Windows.TM. operating system such as, Windows NT.TM. version 4.0, for example. Embodiments might use Windows for Workgroups.TM. version 3.11 or Windows 95.TM. version 4.0, for example. Alternate embodiments of the invention might run on Windows 3.1 or 3.11, for example. Embodiments of the present invention are not limited to a particular operating system or a particular computer platform, however. The machine 102 is an engine that can perform a wide variety of data delivery tasks. It is usable in a wide variety of applications because it does not pre-suppose communication methods, source/destination platforms or operating systems, implementation platforms, source or target data formats, data layouts or data targets.

To provide the machine 102, the computer in system 112 should be able to comfortably run the data target 106(e.g. Excel, Word, WordPerfect or Netscape application). The software 114 of machine 102 adds about a megabyte of additional memory overhead, so systems that are performing poorly when running the data target 106, for example, will degrade further when running software 114. It is recommended that machine 102 be implemented on a computer that includes a 486 CPU or better, 16 MB RAM or better and an Ethernet connection or dial-up Internet connection (high speed connection recommended).

The data source 104 in system 100 can be as remote as on another continent, or can be on the computer on which the AlphaCONNECT machine 102 is implemented. If the data source 104 is a computer, the computer shall be called the source computer. The data source 104 contains data 108. Some or all of data 108 is retrieved by machine 102 as data 120. The process of obtaining the data 120 from a data source 104 is called data acquisition. The data 120 retrieved from the data source 104 shall be called source data 120.

Embodiments of the present invention can be platform-independent with regard to the data source. Embodiments of the present invention can be implemented to accept data from any data source 104 platform, provided the source platform and the implementation platform share a common method of communication. A source computer can run any operating system.

The data 108 of the data source 104 is in some format such as text or some form of multimedia data (e.g. audio, video or image data), for example. Machine 102 can retrieve and process data 120 from data 108 where the data 108 is in a text format, a report format (i.e. a text file with a repeating pattern of information) or a Hypertext Markup Language (HTML) format, for example. Machine 102 can also retrieve image files, audio files and video files. Machine 102 does not process image, audio and video files, but machine 102 is adapted to accept a plug-ins that might process such files. For example, the machine 102 might accept a plug-in that converts a gif file to a jpeg file. Alternate embodiments of the invention might process image, audio and video files in a desired manner. Machine 102 can also access data from database servers that are set up for database querying using the protocol ODBC (Open Data Base Connection). Embodiments of the invention are not limited to retrieving and/or processing data in these formats, however. Also, machine 102 can blindly acquire and deliver (without processing) other types of data.

The ability to retrieve data from a text file enhances the machine 102's flexibility. In particular, a text format typically provides a universal, platform-independent representation of data, and because most applications typically print, it is usually possible to get data into a text format regardless of the platform.

To filter textual data, the machine 102 can be instructed to ignore lines of the source data 120 that are blank, or that contain certain text values. Machine 102 can be instructed to filter out all lines of the data 120 except for those that contain specified text. The machine 102 does not filter multimedia data, but alternate embodiments could filter multimedia data in a desired manner or plug-ins could enable machine 102 to filter multimedia data.

The machine 102 can divide lines of textual source data 120 into data fields, instructing the data target 106 to pass these fields to specific places in a target file 110. The machine 102 can accept from a user, for example, rules for mapping the data 120 into fields. The machine 102 can apply such rules to multiple lines on a page of textual data 120 and to multiple pages of textual data 120. A user can also specify the starting and ending pages and lines that the machine 102 will process from textual data 120. This feature enables the user to instruct machine 102 to skip headers, footers, and non-data lines and pages. When source data 120 is multimedia data, the machine 102 can be instructed where in the target file 110 the multimedia data 120 will be placed.

If the data source 104 is located on a host computer remote from the machine 102, the communication path 116 might be some form of network connection. Alternatively, the data source 104 could be local to the computer system 112. If the data source is local to the computer 112, the communication path 116 might be an internal bus of computer system 112, a virtual path or some combination of an internal bus and virtual path, for example. Thus, the data source 104 might be a data file located on computer system 112 or a data file located on a computer connected to the same local or wide area network as the computer system 112, for example. Alternatively, the data source 104 might be a web page accessible by computer system 112 via the Internet. Embodiments of the present invention are not limited to any particular data sources nor to any particular communication paths.

Embodiments of the present invention also need not be limited to a particular type of data target. The data target 106 might be an application program, a file, an object or any other entity allowed by the enviroment in which the machine 102
exists. The data target 106 might be a target application program, such as Microsoft Excel.TM., running on computer system 112 and having a target file 110 on computer system 112, for example. In the present embodiment, target applications are Windows programs that accept data obtained by the machine 102. In the present embodiment, target applications fall into five basic categories: word processors, spreadsheets, databases, editors that come with Windows and web browsers. In the present embodiment, the word processor data targets 106 include Microsoft Word.TM., Corel WordPerfect.TM. and Lotus Word Pro.TM.. The spreadsheet data targets 106 include Microsoft Excel.TM., Corel Quattro Pro.TM. and Lotus 1-2-3.TM.. The database data targets 106
include Microsoft Access.TM., Borland Paradox.TM. and Lotus Approach.TM.. The Windows editor data targets 106 include Wordpad.TM., Notepad.TM., Windows Write.TM., Paintbrush.TM. and Media Player.TM., for example. The data target 106 might simply be the file 110. For example, the data target 106 might be an HTML file 110 created by machine 102. Such an HTML file might be read by a web browser such as Netscape Navigator.TM., Internet Explorer.TM. and Mosaic.TM.. The machine 102 can provide an HTML data target 106 that is a target file 110 in HTML 2.0 and 3.0 formats. Machine 102 can also provide a data target 106 that is a target file 110 in a text format, for example. Embodiments of the present invention need not include and are not limited to these particular data targets nor to targets having these particular formats. The data target 106 might be located on a remote computer. Machine 102 shields the details of the data target from the user.

The data 122 delivered to a data target shall be called the delivered data 122. When machine 102 delivers the delivered data 122 to a data target 106 that is an application program (i.e. a target application), machine 102 can instruct the target application program to handle the data 122 in a specified manner. Machine 102 may deliver the delivered data 122 to a target application in a manner that instructs the target application to create a new target file 110 to save the data 122, for example. The data may be delivered in a manner that instructs the target application to import the data 122 to the end of a preexisting target file 110, for example. Or the data may be delivered in a manner that instructs the target application to import the data 122 to a specified location in target file 110. The particular manner of delivery depends on the communication techniques supported by the data target 106. The present embodiment is designed to work with the target applications identified above. If a data target 106 is a remote computer, the delivered data 122 may be a file 110 that was created by a different data target 106 that is running on the computer 112 (e.g. a target application). For example, the machine 102 might deliver delivered data 122 to a first data target 106 that is a target application running on the computer 112. This data target 106 might create the file 110. The machine 102 might then be used to deliver the file 110 to a second data target, e.g. a remote data target
106. FIG. 2 illustrates a few possible data paths from data source 104 through machine 102 to data target 106. The delivered data 122 can be multimedia data.

Embodiments of the present invention can be implemented with any method of communication. The machine 102 shields the details of communication from the user. Communication methods shall be called protocols. Protocols such as FTP or ZModem may be used. In the machine 102, data acquisition and data delivery are isolated from the rest of the machine 102.

As shown in FIG. 1, communication path 116 enables communcation between the machine 102 and data source 104, and communication path 118 enables communcation between machine 102 and data target 106. Using the computer system 112 and software 114, machine 102 is adapted to acquire source data 120 from the data source 104, transform (e.g. format convert and/or filter) the source data 120 if desired or if necessary and deliver the

delivered data 122 to the data target 106. In particular, machine 102 integrates data communication and data conversion. Depending on the particular data 120 and data target 106, a transformation may or may not be required or desired. The machine 102 is not adapted to transform (e.g. format convert and/or filter) multimedia data without using plug-ins.

To acquire data 120, machine 102 creates a local file 120' on computer system 112. The source data 120 that has been retrieved from the data source 104 is stored in this file 120'. In the present embodiment, this local file 120' is given a "regulated name." The data 120 in this source file 120' can then be processed to produce the data 122. The data 122 is delivered to the data target 106 in a manner requested by a user, for example.

The AlphaCONNECT machine 102 can read data from local files or from just about any kind of computer located just about anywhere in the world. A local file is a file that is on a disk drive of the computer 112, or that is on the local area network of computer 112 that has been mapped to look like a disk drive to the operating system of computer 112(e.g. Windows). Local files in Windows, for example, are complete Window file specifications, and may take advantage of the long-filename features of Windows 95 and Windows NT 4.0. An example of a local file specification is f:.backslash.Documents.backslash.Legal.vertline.Brief065.txt.

Machine 102 can communicate with a remote data source 104 and a remote data target 106 over communication paths 116 and 118 using the FTP (file transfer protocol) protocol of TCP/IP, and it can communicate with the remote data source 104 over communication path 116 using the HTTP (hyper text transmission protocol) protocol of TCP/IP. In the machine 102, plug-ins might be used to support other protocols if desired. In alternate embodiments, other protocols might be supported without plug-ins. Accordingly, to be used with the present embodiment (assuming no plug-ins are used), a remote data source 104 might support FTP or HTTP of TCP/IP. A remote data target 106 might support FTP. To be used with the present embodiment, an FTP data source or data target might comply with the Internet standards document RFC-959. Embodiments of the present invention are not limited to these communication protocols, however. The system 112 uses a TCP/IP stack that is Winsock 1.1 compliant. Embodiments of the invention can use any TCP/IP for Windows, including Microsoft's TCP/IP-32. Using the FTP and HTTP protocols provides a number of benefits.

For example, TCP/IP and FTP have been implemented on virtually every kind of computer. As a result, the AlphaCONNECT machine 102 will typically be able to access anything from PCs to IBM Mainframes as a data source 104. Typically any combination of disparate computers in an organization will be able to be linked through the use of AlphaCONNECT machine 102.

Additionally, if a machine 102 is connected to the Internet, machine 102 will typically be able to access the large number of FTP servers on the Internet. An FTP server is a computer that has been set up to allow public or private access using the TCP/IP protocol named ftp. Such access will likely give the machine 102 access to millions of publicly available FTP servers on the Internet, providing a wide variety of source data. Using the HTTP protocol, machine 102 will also typically have access to the increasing number of World Wide Web pages on the Internet, as well as any private web servers that may exist on a local network, for example. The present embodiment cannot access secured web pages that use a protocol named https. The present embodiment cannot fill-in or submit web page forms for the user. Alternate embodiments might be designed to do so, however. Machine 102 enables the Internet to be used as a transport mechanism between computers. The AlphaCONNECT machine 102
enables users to obtain data from and deliver data to computers in locations across the Earth through the Internet.

Two FTP mechanisms are supported in order to give the user options for working around problems, addressing compatibility issues, and/or opting to use a more full-featured FTP client than the one provided with the AlphaCONNECT machine 102. In particular, users may select from machine 102's Internal FTP implementation or an External FTP plug-in. The Internal implementation is AlphaCONNECT 102's own implementation of FTP. This Internal FTP is more tightly coupled with the machine 102. For example, the machine 102 is able to display to the user the logon process of the internal FTP implementation. The machine 102 may not be able to do this with an external FTP implementation. Similarly, the external FTP implementation may not be configured to communicate to the machine 102 as many different types of error conditions. The machine 102 might more readily control file transfers when Internal FTP is used. The internal FTP implementation of embodiments of the invention may comply with the Internet standards document RFC-959.

When using the Internal FTP and the machine 102 prompts for a computer name, it is asking for an Internet system identification. Two forms of computer names may be supplied. In particular, an Internet address such as 192.245.218.138 (i.e. four numbers separated by dots where each numbers is in the range 0-255) may be supplied. Alternatively, an Internet name, such as ftp.alphamicro.com, may be provided. An internet name is a registered name that may be used as an alias for an Internet address. If the method of access is FTP, all that is required is the prefix ftp://and the computer name, as described above. For example, ftp://192.245.218.45 and ftp://jsmith@acme.com are acceptable. If the method of access is HTTP, the computer identication could be followed by path and file name information. For example, http://www.alphamicro.com, http://www. alphamicro. com/ac, and http://www.myschool.edu/student/main.html are acceptable. Embodiments of the present invention may determine the type of communication protocol being used by the prefix provided (e.g. ftp://or http://).

The internal FTP is a fully functional FTP client program, but also serves as a browser. The AlphaFTP program may be run directly from the Windows desktop or within the machine 102's user interface. alphaftp.exe is a stand-alone executable file that may be run independently from the rest of machine 102.

External FTP runs the user's specified FTP program instead of AlphaCONNECT 102's internal implementation. The External FTP mechanism may have less robust integration and error reporting. In the present embodiment, to use an external FTP program, the machine 102 can be used with FTP clients that support the -s:scriptfile syntax on the command line such as Microsoft FTP.TM.. For machine 102, the external FTP program should adhere to the Internet standards document RFC-959. An external FTP client to the machine 102 should also honor the open, user, password, cwd, get and bye commands.

The AlphaCONNECT machine 102 can also retrieve data using the HTTP protocol of TCP/IP (the World Wide Web). The AlphaCONNECT machine 102 uses a built-in HTTP reader to obtain HTML text file data from a network. As will be explained, parameters in AlphaCONNECT 102's link notation enable a user to decide, for example, how the HTML is to interpreted. In particular, the machine 102 can convert the HTML to text (intelligently remove all HTML tags), make an exact copy of the HTML file (include all HTML tags with the text) or process just the body of the HTML file (include all HTML tags and text from <BODY> to </BODY>).

The machine 102 is also able to query database servers connected to a network to which machine 102 has access. Database servers are computers on a network that have been set up for database querying using the protocol ODBC (Open Data Base Connection). ODBC servers accept queries--criteria indicating which information should be returned. Querying a database server allows records that match the query to be selected from a larger database. For example, a query might specify customers in a customer database who owe more than $1000.00 over the last 90 days. ODBC sources are addressed by specifying an ODBC driver name, a user id and password, a database and a query that applies to that database table. An example of a database query is

ODBC driver--Microsoft SQL Server

user id--jsmith

password--none

database--Sales

query SELECT*FROM Orders WHERE Ship ToState=`CA` OR BillToState=`CA`;

This example indicates that a query should be sent to the SQL Server database server for the database named "Sales." The query requests records from the database table named "Orders" that have a ship-to state and/or a bill-to state of "CA" (California).

FIG. 3 illustrates a machine model 300 used by the software 114 to implement the AlphaCONNECT machine 102. FIG. 3 shows the machine model 300 as related to the data source 104, the data target 106 having target file 110, an external context 301
and the local file 120'. As illustrated, the model 300 includes an external interface (XI) module 302, a logic control (LC) module 304, a data retrieval (DR) module 306, a format conversion (FC) module 308, a data filtering (DF) module 310, a data mapping (DM) module 312, a data delivery (DD) module 314 and an application interface (AI) module 316. In general, control of machine 102 is accomplished by the external context 301 through the external interface module 302. The external interface module 302 controls logic control module 304 which, in turn, controls the operation of the remaining modules 306, 308, 310, 312, 314 and 316, as needed.

The modular architecture of software 114 enhances the flexibility of machine 102. In particular, the operation of these modules is segregated by software 114 in a manner that makes replacement of the modules with compatible modules (e.g. plug-ins) relatively easy. This segregation is accomplished at least in part using "links" written in "link notation."

The link notation used by machine 102 is a platform-independent, communication method-independent, target independent, location independent means of expressing a data delivery task. Link notation shall refer to any notation that is used to specify the value of a parameter associated with a data delivery task. The described link notation used by the machine 102 is only an example of a link notation. Other embodiments can use other link notations

The machine 102 uses link notation to store parameters commonly associated with varying data delivery tasks. As used by the model 300, link notation can be used to accomplish a variety of tasks which may include but are not limited to data acquisition, format conversion, data filtering, data mapping, data transfer to a target application and data delivery. In the present embodiment, link notation contains a plurality of predetermined parameters where each parameter is assigned a value. Different data delivery tasks may use the same predefined parameters. Data delivery tasks may be different in that the values of the predefined parameters are different. For example, two different data delivery tasks may both specify the parameters: name of a data source, format of the source data and communication protocol. The value of these parameters may be different (e.g. the first task may specify source data in a text format and the second task may specify source data in an HTML format). But both tasks may use these same parameters having some value. A link notation formed by identifying parameters that a variety of data delivery tasks have in common enables flexibility of data retrieval and data delivery without sacrificing a relatively consistent and/or simple interface to the software the accomplishes the delivery tasks and a relatively consistent and/or simple external interface to the external context 301 (e.g. a easy to understand user interface).

For example, in the present embodiment, link notation enables the machine 102 to provide a consistent interface to the modules 306, 308, 310, 312, 314 and 316 and plug-in modules that are or might be used to accomplish the various processing tasks. Thus, the data retrieval module 306 may use the link notation parameters to acquire data. Alternatively, a plug-in data retrieval module that acquires data in a different manner than the module 306 and that is used to acquire data 120 instead of the module 306 might use the same link notation parameters to acquire the data 120. For example, the data retrieval module 306 may need to access data having a certain file name, in a particular directory on a particular host computer. The link notation in the present embodiment uses a first link notation parameter to provide to the data retrieval module 306 the file name, it uses a second link notation parameter to provide to the data retrieval module 306 the source directory and it uses a third link notation parameter to provide to the DR module 306 the source computer name. When the data retrieval module 306 is replaced by a plug-in, the plug-in will also look to the first link notation parameter to determine the file name that it is supposed to access. The plug-in will look to the second link notation parameter to identify the source directory and to the third link notation parameter to identify the source computer name. Accordingly, link notation enables plug-ins to have the flexibility to implement whatever type of communication protocols, conversion, data filtering, data mapping, data delivery or application interfaces are desired while maintaining a relatively consistent interface to the rest of the software and to the external context. The present embodiment does not provide for data mapping plug-ins, but alternate embodiments could do so. In the present embodiment, other necessary or desired link notation parameters could be defined and used by plug-ins and alternate embodiments.

Link notation also enables the machine 102 to provide a relatively consistent external interface to a user or an external program, for example, even as data delivery tasks change. In particular, because link notation includes parameters that a variety of data delivery tasks have in common, it enables a user interface, for example, to be designed that does not radically change whenever a different type of data delivery task is desired. In particular, the data delivery tasks can change while the parameters remain constant. Only the values of the parameters need to change. Thus, link notation enables a relatively easy to understand and relatively constant human interface where a human operator can simply specify the value of predetermined parameters to vary data delivery tasks. A user interface may have a predefined set of prompts and inputs that can be set by a user to accomplish varying data delivery tasks, for example. The predefined prompts and inputs may correspond to the predefined link parameters. The input provided by the external context (e.g. user) provides the values of the predefined parameters. Similarly, link notation enables a relatively consistent program interface to be designed when the machine 102 is to be controlled by another program rather than a human. The link notation can be easily extended by a developer to add additional features or services to the user. Even if a developer extends the link notation, however, the notation can still enable the developer to provide flexible additions using a similar relatively constant external interface.

A set of link notation parameters defining a data delivery task shall be called a link. A link can be stored as a file, communicated in memory, mapped to the properties of an object or instituted as variables, for example. FIG. 19 shows an example of a link. Once a link is stored, it can be re-run as desired. It can be run interactively, or scheduled to run unattended at a specific date and time. A link can be scheduled to run at regular intervals, such as once a day. In the present embodiment, the AlphaCONNECT machine 102 accepts only link notation for data delivery tasks. Other embodiments of the invention need not be so limited. With the machine 102, links are stored on a disk in a .backslash.Links subdirectory, having the file type .lk.

FIGS 5A, 5B and 5C illustrate the link notation parameters defined for machine 102. A link is composed of one or more sections. A section is identified by a line containing a section name, enclosed in square brackets. In the machine 102, fifteen section names have been defined: Link, Word, WordPerfect, WordPro, Excel, Quattro, 1-2-3, Access, Paradox, Approach, Notes, html, email, IE and Netscape. Other section names could be defined in other embodiments or by plug-ins. A link may contain additional sections for target application-specific parameters, network type parameters, or other areas in which extensibility is desired. In the machine 102, the defined section names are reserved and should not be used by a plug-in, for example. In the present embodiment, the section names not illustrated in FIGS. 5A, 5B and 5C do not have link parameters associated with them.

FIG. 5A illustrates parameters for the Link section. FIG. 5B illustrates parameters for the HTML section. FIG. 5C illustrates parameters for the ODBC section. With respect to each parameter illustrated in FIGS. 5A-C, the word on the left of each equal sign is the name of the link parameter. The word on the right of the equal sign represents the value that is assigned to the associated link parameter. The following provides a general model for a link and a specific example of a link in an adjacent column:

______________________________________ Model Example ______________________________________ [SectionName-1] [Link] Statement-1 HostAddress=http://www.alphamicro.com Statement-2 DestDir=e:.backslash.xfer . . . Statement-n SourceProtocol=0 [SectionName-2] [html] Statement-1 HTMLtemplate=e:.backslash.html.backslash.main.htm Statement-2 HTMLformat=1 . . . Statement-n HTMLbackground=#FFFFFF [SectionName-3] [ODBC] Statement-1 DataSource=Microsoft SQL Server Statement-2 User=jsmith . . . Statement-n Query=SELECT*FROM Customers WHERE STATE=`CA` ______________________________________

The following are brief descriptions of link parameters used by machine 102. Plug-ins and the modules of the model 300 are described after the description of the links.

In FIG. 5A, the Version parameter 502 indicates the version of link notation used by a particular link. In the present embodiment, the only valid version parameter values are 1.0, 1.1 and 2.0. Thus, a link might have a link parameter Version=2.0.

The Description parameter 504 indicates a descriptive name of the link. The value of the description parameter may also be passed to a target application as a title, header, or description. The argument value is a text phrase 1 to 140
characters in length which in the machine 102 can be specified by the external context through the external interface. Certain symbols may be embedded in the value of the description parameter. These symbols are resolved when a link is executed and replaced by their values-at-runtime. In the present embodiment, these symbols are:

{d} day of the month in natural format for the computer 112

{m} month of the year in natural format for the computer 112

{y} year in natural format for the computer 112

{d2} day of the month in 2-digit notation (e.g. 03 or 31)

{m2} month of the year in 2-digit notation (e.g. 05 or 12)

{y2} year in 2-digit notation (e.g. 97)

{y4} year in 4-digit notation (e.g. 1997)

An example of the use of the description parameter is Description=Census Bureau California Population Data.

The TargetApp parameter 561 is a text string that indicates the nature of the data target 106. The following codes have been defined, but other embodiments or plug-ins may use other values.

______________________________________ 1-2-3 for Lotus 1-2-3 .TM. access for Microsoft Access .TM. approach for Lotus Approach .TM. quattro for Corel Quattro Pro .TM. excel for Microsoft Excel .TM. iexplore for Microsoft Internet Explorer .TM. media-player for Windows Media Player .TM. netscape for Netscape Navigator .TM. notepad for Windows Notepad .TM. paintbrush for Windows Paintbrush .TM. paradox for Borland Paradox .TM. word for Microsoft Word .TM. wordperfect for Corel WordPerfect .TM. wordpro for Lotus Word Pro .TM. write for Windows Write .TM. ______________________________________

The Document parameter 506 indicates the name (without drive, directory, or other account information) that the target file 110 (see FIGS. 1 and 3) containing the data in its target format will be named. This file might be a new file or a pre-existing file. Machine 102 may provide data directly to the file 110 or indirectly through a target application. The value of the Document parameter 506 is a file name that is legal to the computer 112. On most computers, this value is a filename.type designation. On machine 102, the Document parameter 506 is required and must appear exactly once in a link. An example of the use of the document parameter 506 is Document=stocks.htm

The DataSource parameter 508 is used in the [Link] section to specify the name of the file on the data source 104 (without drive, directory, or other account information) from which the data is being retrieved. This parameter specifies the location of the data 108 on the data source 104. The value of the DataSource parameter 508 is a file name that is legal and exists on the data source 104. For example, it might be a legal and existing filename on a remote computer. On most computers, this file name uses a filename.type designation. In the present embodiment, this parameter is required and must appear exactly once in a link. An example of the use of the DataSource parameter 508 is DataSource=stocks.txt.

The DestDir parameter 510 identifies the path/directory/account on the computer 112 where the file 110 is to be created or updated. The value of the DestDir parameter 510 is a path/directory/account specification that is legal on the computer
112. The following symbols may be embedded in the parameter value for portability of links. The symbol $root$ is replaced by the root directory of the software 114 from the computer 112. The symbol $sub$ is replaced by the default subdirectory of the data target 106 on computer 112. This DestDir parameter 510 is optional and may appear up to one time in a link. If the DestDir parameter 510 is omitted, the root directory of the software 114 and the logical subdirectory for the data target 106 are used by the machine 102 to derive the value for the DestDir parameter. In other words, the default value for DestDir, if not specified, is $root$$sub$, which might evaluate to c:.backslash.connect.backslash.excel on a particular system, for example. An example of the use of the DestDir parameter 510 is DestDir=c:.backslash.documents

The HostAddress parameter 512 identifies the data source 104. In the present embodiment, the value of the HostAddress parameter 512 is a value such as a TCP/IP address which includes four integers, 0<=n<=255, separated by periods (such as
192.245.218.138) or TCP/IP resolvable name (such as ftp.alphamicro.com). The HostAddress parameter 512 may accept other types of values (e.g. an identification legal for the particular network technology being used) if a different type of network technology is being used, for example. In the present embodiment, the HostAddress parameter 512 is required and must appear exactly once in a link. If a data acquisition plug-in is specified, the HostAddress parameter will contain the name of the data acquisition plug-in. An example of the use of the HostAddress parameter 512 is HostAddress=192.245.218.138.

The Mapping parameter 514 describes the mapping of data from the normalized/filtered version of the source data 120 (discussed below) into the target file 110. This parameter is used by the data mapping module which retrieves the normalized/filtered data, for example, from the file 120'. The parameter value of the Mapping parameter 514 is a string of 1 or more field definitions, separated by semicolons. Each field definition consists of a number of field-definition parameters. The value of each field-definition parameter is enclosed in curly brace characters.

In the present embodiment, the Mapping parameter 514 is used for textual data. In embodiments of the invention, the mapping parameter may also be used for multimedia data. In each link that deals with textual data, the Mapping parameter 514 is assigned at least one field definition. Any number of field definitions is permitted, but a particular implementation of software 114 may impose an upper limit. The present embodiment supports at least 35 field definitions. An implementation should ignore field definitions beyond such an upper limit without complaint and without losing synchronization with the remainder of the link.

The data model of the machine 102 enables a wide variety of text data formats to be processed intelligently. The data model can be used with data as free-form as paragraph text, or data as rigidly structured as an accounting report. The normalized data form is represented by an array of field-definition parameters and a repetition array. The two combine to permit modeling of may different text data formats. Table oriented data relatively easily falls into the normalized data model. Columns of data from a report, for example, may directly correspond to machine 102's normalized data form. Paragraph formatted text is treated as a single wide non-space padded field per record (line). Data exported from database products, often in comma-, tab-, or custom-delimited form, is also accepted by the normalized data model.

The field mapping data model for a link consists of a number of fields: <field mapping arrayl>:=[<field>[<field>. . . ]]. Each field indicates a segment of the data in the file 120' to be captured. This segment may be as broad as all data in the file 120', or as narrow as a single character of one particular line on a page of the data 120'. Each field includes a number of field-definition parameters. In the machine 102, eight field-definition parameters are used. In particular, page, line, column, width, cell, fieldname, alignment and font field-definition parameters are used. I.e. <field>:= <page><line><column><width><cell><fieldname><alignment><font>.

The page field-definition parameter is either a specific page number or an asterisk, indicating all pages in the range. The page field-definition parameter identifies the page number of the data in the file 120' where the data to be acquired is found. The value of the page field-definition parameter may be an integer in the range 1 through p, where p is the maximum number of pages a particular implementation of machine 102 supports. To specify that a field mapping is to be repeated for every page of the data in the file 120', the page field-definition parameter is given a value of p rather than a positive integer. <page>:=integer.vertline.p.

The line field-definition parameter is either a specific line number or an asterisk, indicating all lines on the page. The line field-definition parameter identifies the line number of the page of the data in the file 120' where the data to be acquired is found. The value of this parameter may be an integer in the range 1 through .vertline., where .vertline. is the maximum number of lines an implementation supports. To specify that field mapping is to be repeated for every line of the page, the line field-definition parameter is given a value of l rather than a positive integer.

<line>:=integer .vertline.l.

The column field-definition parameter is either a specific column number (for fixed-width data) or an ordinal field number (for delimited data). The column field-definition parameter identifies the column of the line of the page of the data in the file 120' where the data to be acquired is found. For fixed width data, the value of the column field-definition parameter may be an integer in the range 1 through u, where u is the maximum line length an implementation supports. <column>:=integer .vertline.u.vertline.null.

The width field-definition parameter specifies the width of the field of the data to be acquired from data in the file 120'. For fixed-width data, this is the number of characters to capture from the source line. For delimited data, this field is not required. The value of this parameter may be an integer in the range 1 through u-c+1, where u is the maximum line length an implementation supports and c is the column field-definition parameter. <width>:=integer.vertline.null.

The cell field-definition parameter indicates the cell or field (if applicable) of the target file 110 where the data from the file 120' will be sent. The cell field-definition parameter is data target specific. The value of this parameter is always specified in the form field "name number." If the target field is a repeating field (used in multiple lines and/or pages), an asterisk (*) should be specified in place of a positive integer for the "number" portion of the cell field-definition parameter value. The name and number should follow the rules for legal field names in the target application. Thus, for example, Al or B* are valid parameter values for a cell field-definition parameter for Excel worksheets. Name*, Address*, and Phone* are acceptable values for cell field-definition parameters for Access databases. A cell of A3 when sending data to Excel indicates the cell named "A3". Cell references may use the asterisk symbol in order to auto-increment a row number, as in "A*". <cell>:=letter integer .vertline.letter * .vertline.{application-specific location}.

The fieldname field-definition parameter is used if the data source 104 is an ODBC database. This field associates a data item from the database with the data mapping field. <fieldname>:=databasefieldname .vertline.null.

The alignment parameter allows left-, right-, or centered-alignment to be specified for target applications that honor field/cell alignment. <alignment>:=L .vertline.R .vertline.C .vertline.null.

The font field-definition parameter allows a font, font size, bold, italic, and/or underscoring attribute to be specified for target applications that honor field/cell font control. <font>:=fontname [fontsize][B][I][U].vertline. null

An example of the use of the Mapping parameter 514 is Mapping={p}, {.vertline.}, 1,4,A{r};{p}, {1},8,7,B{r};{p},{1},16,7,C{r};

{p},{1},27,7,D{r};{p},{1},37,7,E{r};{p},{1},48,9,F{r};

{p},{1},58,8,G{r};{p},{1},68,6,H{r};

The HostDir parameter 516 identifies the directory/path/account where the data 108 resides on the data source 104. The value of this parameter may be blank or a legal account name of the data source 104, for example. The HostDir parameter 516
is optional, and may not appear more than once in a link. If omitted, the default value is blank (an empty string). An example of the use of the HostDir parameter 516 is HostDir=/pub/stocks.

The Pages parameter 518 identifies the number of pages of the data in the file 120' that the machine 102 will process. The value of this parameter may be a positive integer up to the upper limit allowed by the particular implementation or an asterisk (*), which indicates all pages of the data are to be processed. The Pages parameter 518 is required and must appear exactly once in each link. An example of the use of the Pages parameter 518 is Pages=*.

The Rows parameter 520 identifies the number of lines on each page of the data in the file 120' that the machine 102 will process. The value of this parameter 520 may be a positive integer up to the upper limit allowed by the particular embodiment of the invention or an asterisk (*), which indicates all lines of a page are to be processed. The Rows parameter 520 is required and must appear exactly once in each link. An example of the use of the Rows parameter 520 is Rows=*.

The StartPage parameter 524 indicates the starting page of the data in the file 120' that machine 102 will process. A value of 1 starts on the first page of the data in file 120', while a higher value causes the specified number of initial pages to be skipped over. This parameter will have a value that is a positive integer, in range 1 through the upper limit allowed by the particular embodiment of the invention. An example of the use of the StartPage parameter is StartPage=1.

The ReportFormat parameter 526 provides the machine 102 with information

about the structure of the data in the file 120' when it is the normalized text format. The currently defined and reserved structure codes are listed below. The values of this parameter is an integer greater than or equal to zero. Additional codes may be added in alternate embodiments or by plug-ins in the present embodiment.

______________________________________ 0 typical report (repeating lines and/or pages of data fields) 1 pure text (paragraph-formatted text) 2 complex (combination of discrete fields and/or repeating fields and/or paragraph text) 3 through
99 reserved 100 and higher available for users and third parties ______________________________________

An example of the use of this parameter is ReportFormat=0

The StartRow parameter 528 identifies the starting "row" (or the equivalent for the particular data target) on each page in the target file 110 where the delivered data 122 is to be inserted. This parameter 528 is used when the cell field-definition parameter of the Mapping parameter 514 contains an asterisk. In particular, it provides an "offset" as to where the delivered data is to be placed. The StartRow parameter 528 enables links to deliver the data 122 to the data target 106
where the data target 106 contains pre-existing formatting, macros, formulas, headings, or prior data, for example and it is desired that this pre-existing formatting, macros, formulas, headings, or prior data be left untouched.

Thus, suppose Excel is the data target 106 and an Excel spreadsheet is the target file 110. If StartRow is set to 5, then fields mapped with names A*, B*, and C* would transmit data to the following Excel cells as the link runs:

First record of data.fwdarw.cells A5, B5, C5

Second record of data.fwdarw.cells A6, B6, C6

Third record of data.fwdarw.cells A7, B7, C7

And so forth

The StartLine parameter 530 indicates the starting line of each page from the data in the file 120' that is to be processed by machine 102. The minimal value is 1, which starts processing a page of data at the first line. Higher values cause lines to be skipped at the top of pages. The StartLine parameter 530 can be desirable to bypass title or header data in the data.

The ImportMethod parameter 532 identifies the import methodology to be used when transferring data fields to a data target 106. The currently defined and reserved codes are listed below. Additional codes may be added by software implementation.

1 field-oriented: all mapped fields in a record are passed as defined to the data target as mapped.

2 line-oriented: all mapped fields in a record are concatenated into a single field and passed to the field name and number specified in the first cell field-definition parameter associated with that record.

3 through 99 reserved

The Sheet parameter 534 indicates a location in the target file 110 where the delivered data 122 is to be inserted. This parameter is optional. Its values are specific to the particular data target 106 to which the data is being delivered. In particular, the value of parameter 534 may be a sheet, a layer, a bookmark or a table, for example, as appropriate to the target application. A blank value or an omitted Sheet parameter implies that the default location for the target application be used. This default location typically will be specified by the data target 106.

The following data target 106 specific Sheet parameter 534 values are used in the machine 102. For new data targets 106, vendors may select their own values for Sheet parameters appropriate to the specific data target 106.

______________________________________ Default Value used by data target if the Meaning of Sheet parameter value is blank Data Target parameter value or omitted ______________________________________ Microsoft Excel Sheet name Sheet1 Quattro Pro Tab name A Lotus 1-2-3 Sheet name first sheet Microsoft Word Bookmark name /EndOfDoc WordPerfect Bookmark name (end of document) Lotus Word Pro Bookmark name (end of document) Microsoft Access Table name Table1 Borland Paradox unused unused Lotus Approach unused unused Netscape Navigator n/a n/a Internet Explorer n/a n/a Notepad n/a n/a Write n/a n/a Paintbrush n/a n/a Media Player n/a n/a ______________________________________

The IgnoreBlanks parameter 536 indicates whether blank lines in the data in the file 120' are to be filtered out (-1) by the data filter module 310 or are to be left in as data (0). The possible values for this parameter 536 are 0 (false) or -1
(true).

The IgnoreText parameter 538 indicates whether or not non-blank lines of the data in the file 120' that contain specified text are to be filtered out (-1) or processed as data (0). If set to -1, machine 102 uses IgnoreTextn clauses that are appended to the parameter 538 following the -1 to identify text lines in the data that are to be bypassed. The IgnoreTextn clauses contain a text string input by a user, for example, where the user wants lines containing the specified text string to be omitted from the data.

The RequireText parameter 563 indicates whether or not lines that do not contain the required text are to be filtered out (parameter value=-1) or processed (parameter value=0). If set to -1, the RequireTextn clauses appended to the parameter 563
following the -1 are used to identify text lines to be included. Only text lines containing the required value will be retained. An example of the use of this parameter is RequireText=0.

The Overwrite parameter 540 indicates whether an existing target file 110 should be overwritten (replaced) or updated (amended) when a particular link is executed. A value of 0 (false) of the Overwrite parameter in a link causes the link to update the target file 110 if it already exists. If the target file 110 does not exist, the link will create a new target file 110. A value of -1 (true) causes the machine 102 to create a new target file 110 even if a target file having the name specified by the link parameters already existed.

The PadSpaces parameter 542 indicates whether or not data fields in the mapped data should be space padded so that the data fields have a fixed width. Some combinations of data and specific target applications lend themselves to fixed width data spacing, while others do not. A value of 0 (false) trims all leading and trailing spaces from data fields and passes the data to the target application in varying widths. A value of -1 (true) space pads data to the right until the data field is the maximum width permitted by the width field-definition parameter of the Mapping parameter.

The LineBatching parameter 544 defines the number of lines of the data in file 120' that will be concatenated and treated as a single line by the DM module 312. A value of 1 processes each line of the data in file 120' in a direct 1:1
correlation. A higher value of the LineBatching parameter such as a value n will group lines of the data in file 120' together by concatenation in an n:1 ratio. Thus, every n lines will be treated as a single line. This parameter 544 is useful for handling data 108 where the values of data 108 on successive lines differ, but where the pattern of data in every n groups of lines, for example is repeating. For example, none of lines one to five may have the same data pattern as each other. But line six might have the same data pattern as line one, line seven the same data pattern as line two, line eight the same pattern as line three, line nine the same pattern as line four and line ten the same pattern as line five. If this pattern recurs every five lines, it might be desirable for processing to have the data mapping module treat lines one to five as a single line, lines six to ten as a single line, lines 11 to 15 as a single line, and so on. Each of these contcatenated single lines will then have the same data pattern and may be easier to map to a target file 110.

The Xfer parameter 546 indicates the frequency at which the data 108 changes on the data source 104. This parameter enables data to be retrieved more or less frequently depending on the frequency at which the data 108 of the data source 104
changes. The possible values of the parameter 546 are:

0--data changes frequently (obtain fresh copy of data 120 every time link runs)

1--data changes daily (obtain fresh copy of data 120 if the data in file 120' is older than today)

2--data never changes (obtain fresh copy of data 120 only if there is no file 120' already storing data for the link)

3-99 reserved Other values could be used by other embodiments or by plug-ins.

The UserName parameter 548 identifies the login user name, if applicable, for connecting to the data source 104. Some communications protocols, such as FTP, require a user name and password. If the communications protocol in use does not require a user login, the AlphaCONNECT machine 102 will ignore this value. If omitted, the value of theUserName parameter 548 defaults to anonymous, which is a common Internet default for public-access FTP sites. In the present embodiment, this parameter can have a value that is a text string of 0-100 characters in length.

The Password parameter 550 identifies the password to supply along with the UserName parameter 548, if applicable, for connecting to the data source 104. Some communications protocols, such as FTP, require a user name and password. If the communications protocol in use does not require a user login, the AlphaCONNECT machine will ignore this value. If omitted, the value of the Password parameter 550 defaults to an empty string (""). In the present embodiment, this parameter can have a value that is a text string of 0-100 characters in length.

The Obtain parameter 552 sets the data acquisition method and frequency, as follows.

______________________________________ Value Meaning ______________________________________ 0 Obtain the data from a local file when executing a link 1 Always obtain the data from the data source 104 when executing a link 2 Obtain the data from a remote computer "daily"-use local cached data in a local cache file if present and same-day 3 Obtain the data from a remote computer "once"-use local cached data if present 4-999 Reserved ______________________________________

The values 2 and 3 specify that a cached copy of the data 120 (before processing) is to be used. This cached data can be saved in a local cache file from which the machine 102 knows to aquire it.

The LocalFile parameter 554 specifies the name of the file local to the computer 112 that is to be used as the data source 102 when the Obtain parameter 552 is set to 0 (local file data source). The value must be a valid file specification for the computer 112. An example of the use of this parameter is LocalFile=c:.backslash.newdata.backslash.latest.dat.

The Created parameter 556 records the creation time of a link. In the present embodiment, the external interface 302 of the AlphaCONNECT machine 102 permits the creation of links. Accordingly, the creation date and time of a link is written to the Created parameter when the link is saved. In the present embodiment, the values of this parameter use a string representation of date/time, formatted as mm-dd-yyyy hh:mm: ss An example is Created=02-02-1996 22:58:50.

The Revised parameter 558 records the last revision time of a link. The external interface 302 of the AlphaCONNECT machine 102 permits the editing of links. Accordingly, the revision date and time of a link is written to the Revised parameter
558 when the link is saved. In the present embodiment, the values of this parameter use a string representation of date/time, formatted as mm-dd-yyyy hh:mm:ss. An example is Revised=02-28-1996 09:36:37.

The Target parameter 560 selects a destination naming method. A value of 0 uses the DestDir and Document parameters to determine the directory and file name of the file 110. A value of 1 automatically deduces the output directory and name based on defaults in the implementation of the AlphaCONNECT machine 102 (which may draw upon user-accessible defaults).

Values: 1) 0: specific directory and filename for target defined in link parameters DestDir and Document

2) 1: location and name of target should be derived/assigned automatically by the software from user accessible defaults

Example: Target=0.

The SourceProtocol parameter 562 indicates the method of data acquisition. A value of 0 causes an FTP transfer to be used to acquire the source data. A value of 1 causes an HTTP transfer to be used to acquire the source data. A value of 2
executes a third-party `plugin` program to acquire the data. Values 3 through 999 are reserved for future extensions to link notation. A plug-in may support additional protocols, which should be mapped to values 1000 and higher.

______________________________________ Values: Value Meaning ______________________________________ 0 FTP protocol data acquisition 1 HTTP protocol data acquisition 2 Execute plug-in program to acquire data 3-999 Reserved Example: SourceProtocol=1. ______________________________________

The SourceConversion parameter 564 identifies the format conversion method to be applied to the data 120 from the data source 104. This parameter is used by the Format conversion module. The AlphaCONNECT machine 102 can inherently handle direct text or HTML, with the ability to convert one form into the other.

______________________________________ Values: Value Meaning ______________________________________ 0 leave data 120 unchanged (text or HTML, to remain in same format in target) 1 convert data 120 which is in an HTML format to text (remove HTML tags and provide a text facsimile) 2 convert data 120 which is in an HTML format to "portable" HTML (i.e. include just the BODY portion of the HTML document) Example: SourceConversion=1. ______________________________________

The LastRun parameter 566 records the last time a link was executed.

The AlphaCONNECT machine 102 updates this parameter when running a link. This link is assigned a value of the date and time formatted as mm-dd-yyyy hh:mm:ss. An example is LastRun=04-30-1996 08:36:07.

The LastRuntime parameter 568 records the elapsed (chronological) time of

the last execution of this link. The AlphaCONNECT machine 102 updates this parameter after running a link. This link is assigned a value of the elapsed time since the link was last run, formatted as h:mm:ss. An example is LastRuntime=0:00:07.

The Results parameter 570 indicates the completion status of the link. The value is a text phrase, set to 'successful' or an error message. This parameter may be used to inform the external context 301 about the nature of an error. The error message may be specific to the machine 102 or may be an operating system error message, for example.

Values: 1) successful

2) error message

Example: Results=successful.

The FormatConversionPlugin parameter 572 specifies the name of an external program to be called as a format conversion replacement for the work normally done by the FC module 308. This parameter is optional; if specified, the user is overriding AlphaCONNECT's inherent format conversion features with an external plugin program.

Values: 1) Blank (indicates no plug-in)

2) File specification, valid for the implementation platform

Example: FormatConversionPlugin=c:.backslash.connect.backslash.plugins.backslash.cv tdoc.exe.

The DataFilter parameter 575 specifies the name of an external program to be called as a data filter replacement for work normally done by the DF module 310. This parameter is optional; if specified, the indicated program by the value of this parameter will be executed.

The DeliveryPlugin parameter 574 specifies the name of an external program to be called as a delivery extension for the delivery features provided by the Data Delivery module 314. This parameter is optional; if specified, the indicated program will be executed, in addition to any other delivery options that have been enabled in the link.

Values: 1) Blank (indicates no plug-in)

2) File specification, valid for the implementation platform

Example: DeliveryPlugin=ProgramFileName.

The DeliverFTP parameter 576 enables or disables FTP delivery of the link's target file 110 to another computer, via the FTP protocol. A value of -1 enables FTP delivery; a value of 0 disables it. This parameter is used by the data delivery module 314 to determine if it will deliver the file 110.

Values: 1) 0 disables FTP delivery

2) -1 enables FTP delivery

Example: DeliverFTP=-1.

The DeliverFTPsystem parameter 578 specifies the name of the remote computer to which the file 110 is to be FTP delivered. This parameter is not required unless DeliverFTP is set to -1 (enables).

Values: 1) Internet name of an FTP server

2) Internet address of an FTP server

3) Blank

Example: DeliverFTPsystem=smith.alphamicro.com.

The DeliverFTPuser parameter 580 specifies the user name for FTP delivery sign-on to the remote computer. This parameter is not required unless DeliverFTP is set to -1 (enabled).

Values: 1) User name for FTP sign-on to the remote computer

2) Blank

Example: DeliverFTPuser=jsmith.

The DeliverFTPpassword parameter 582 specifies the password for FTP delivery sign-on to the remote computer. This parameter is not required unless DeliverFTP is set to -1 (enabled).

Values: 1) Password for FTP sign-on to the remote computer

2) Blank

Example: DeliverFTPpassword=buzzard

The DeliverFTPdir 584 parameter indicates a directory name for FTP delivery to a remote computer. This parameter is optional.

Values: 1) Directory name, valid for remote computer

2) Blank

Example: DeliverFTPdir=/pub/stocks

The DeliverFTP file parameter 586 specifies the name by which the target file should be transmitted to a remote computer during FTP delivery.

This parameter is optional.

Values: 1) File specification, valid for remote computer

2) Blank

Example: DeliverFTPfile=testl.html

The DeliverEmail parameter 588 enables or disables electronic mail delivery. If set to -1 (enabled), the target file 110 is e-mailed to one or more recipients as specified by the DeliverEmailRecipient parameter.

Values: 1) 0 disables electronic mail delivery

2) -1 enables electronic mail delivery

Example: DeliverEmail=-1

The DeliverEmailRecipient parameter 590 specifies one or more recipients for electronic mail delivery of the target file 110. If multiple recipient names are specified, they should be separated by a semicolon.

Values: 1) List of one or more e-mail recipients

Example: DeliverEmailRecipient=John Forbes; Steve Mills

The SaveExit parameter 592 enables or disables automatic save and shutdown of the data target 106 when the data target is a target application. Embodiment are free to insist that this option be enabled in order to safely perform any data delivery tasks.

Values: 1) 0 disables save and exit (application is left open after link execution)

2) 1 enables save and exit (application saves results and exits at end of link execution)

Example: SaveExit=-1.

The Append parameter 594 indicates whether newly acquired data 120 should be treated in isolation, or appended to previously acquired data 120 in the cached file that contains the previous data 120. A value of -1 (enabled) will add new data to previous data in the file. A value of 0 always discards any data in a previous file.

Values: 1) 0 do not append to previous data

2) -1 append to previous data

Example: Append=0.

The DataType parameter 571 is assigned an integer value that represents the type of data 120 that is being retrieved from the data source 104. This parameter may represent data of a Report/Table, Text, Image, Audio or Video type.

The DataFormat parameter 573 is assigned an integer value that represents the format of the data 120 that is being retrieved from the data source 104. When the datatype parameter specifies a Report/Table type, this parameter may represent data having a fixed width, comma-delimited, tab-delimited or custom delimited format. When the datatype parameter specifies an image type, the DataFormat parameter 573 may represent BMP, GIF, JPEG, PCX, TIFF, WMF or icon data. When the datatype parameter specifies an audio type,the DataFormat parameter 573 may represent MIDI, Wave or RealAudio formats. When the datatype parameter specifies a video type,the DataFormat parameter 573 may represent AVI, MPEG or QuickTime formats.

The FieldDelimiter parameter 565 defines field delimiters for use with delimited data. The delimiters are listed as zero or more decimal character codes, each enclosed in square brackets. Values: Zero or more decimal character codes, enclosed in square brackets, as in [13]. Example: FieldDelimiter-[32].

The RecordDelimeter parameter 567 defines record delimiters for use with delimited data. The delimiters are listed as zero or more decimal character codes, each enclosed in square brackets. Values: Zero or more decimal character codes, enclosed in square brackets, as in [13]. Example: RecordDelimiter=[13][10].

The PageDelimiter parameter 569 defines page delimiters for use with delimited data. The delimiters are listed as zero or more decimal character codes, each enclosed in square brackets. Values: Zero or more decimal character codes, enclosed in square brackets, as in [13]. Example: PageDelimiter=[12].

The parameters in [HTML] section are used with links that create HTML (hyper text markup language) output, rather than sending fields of data to a target application such as a word processor or spreadsheet.

The HTMLmethod parameter 501 selects an HTML generation method for creating the target file.

______________________________________ Values: Value Meaning ______________________________________ 0 Simple: a simple HTML document is created without user- control over form or presentation. The form and presentation are predefined by the machine 102. 1 Wizard: an HTML document is created based on web wizard settings. The web wizard settings are specified in other HTML section links. 2 Template: an HTML document is created based on an HTML template document. Example: HTMLmethod=1 ______________________________________

The HTMLrules parameter 503 is a web wizard parameter. It enables or disables the appearance of horizontal rules in the generated HTML document.

Values: 1) -1 include horizontal rules in the target file 110.

2) 0 do not include horizontal rules in the target file 110.

Example: HTMLrules=-1

The HTMLbackGraphic parameter 505 is a web wizard parameter. It enables or disables a background graphic in the generated HTML document. If enabled, the HTMLbackGraphicSpec parameter identifies the name of the graphic file to use as background.

Values: 1) 0 no background graphic

2) -1 include a background graphic

Example: HTMLbackGraphic=-1

The HTMLbackGraphicSpec parameter 507 is a web wizard parameter. It specifies the name of the graphic file to be used as a background in the target HTML document. The present embodiment uses GIF and JPEG format graphic files.

Values: 1) File specification, valid for implementation platform

2) Blank

Example: HTMLbackGraphicSpec=goldtile.jpg.

The HTMLtitleGraphic parameter 509 is a web wizard parameter. It enables or disables the use of a title graphic in the target HTML file. If enabled, the HTMLtitleGraphicSpec parameter identifies the name of the title graphic file.

Values: 1) 0 no title graphic

2) -1 title graphic

Example: HTMLtitleGraphic=0

The HTMLtitleGraphicSpec parameter 511 is a web wizard parameter. It specifies the name of the graphic file to be used as a title graphic in the target HTML document. The present embodiment uses GIF and JPEG format graphic files.

Values: 1) File specification, valid for implementation platform

2) Blank

Example: HTMLtitleGraphicSpec=banner.gif

The HTMLforeColor parameter 513 is a web wizard parameter. It enables or disables a custom foreground text color for the generated HTML document. If enabled, the HTMLforeColorCode parameter provides the HTML color code.

Values: 1) 0 no foreground color settings for text

2) -1 foreground color is defined

Example: HTMLforeColor=-1.

The HTMLforeColorCode parameter 515 is a web wizard parameter. It supplies a standard 6-digit hex HTML color code to be used as a foreground color for text in the generated HTML document. This parameter only has an effect if HTMLforeColor parameter 513 is enabled.

Values: 1) #nnnnnn hexadecimal HTML color code

Example: HTMLforeColorCode=#0080FF.

The HTMLbackColor parameter 517 is a web wizard parameter. It enables or disables a custom background color for the generated HTML document. If enabled, the HTMLbackColorCode parameter provides the HTML color code.

Values: 1) 0 no background color setting

2) -1 background color is defined

Example: HTMLbackColor=-1.

The HTMLbackColorCode parameter 519 is a web wizard parameter. It supplies a standard 6-digit hex HTML color code to be used as a background color in the generated HTML document. This parameter only has an effect if HTMLbackColor is enabled.

Values: 1) #nnnnnn hexadecimal HTML color code

Example: HTMLbackColorCode=#FFFFFF.

The HTMLlinkColor parameter 521 is a web wizard parameter. It enables or disables a custom link color for the generated HTML document. If enabled, the HTMLlinkColorCode parameter provides the color code for the HTML link.

Values: 1) 0 no link color setting

2) -1 link color is defined

Example: HTMLlinkColor=-1.

The HTMLlinkColorCode parameter 523 is a web wizard parameter. It supplies a standard 6-digit hex HTML color code to be used as an unvisited link color in the generated HTML document. This parameter only has an effect if HTMLlinkColor is enabled.

Values: 1) #nnnnnn hexadecimal HTML color code

Example: HTMLlinkColorCode=#80FFFF.

The HTMLvisitColor parameter 525 is a web wizard parameter. It enables or disables a visited link color for the generated HTML document. If enabled, the HTMLvisitColorCode parameter provides the HTML color code.

Values: 1) 0 no visited link color setting

2) -1 visited link color is defined

Example: HTMLvisitColor=-1.

The HTMLvisitColorCode 527 is a web wizard parameter. It supplies a standard 6-digit hex HTML color code to be used as a visited link color in the generated HTML document. This parameter only has an effect if HTMLvisitColor is enabled.

Values: 1) #nnnnnn hexadecimal HTML color code

Example: HTMLvisitColorCode=#FFFFFF.

The HTMLheaderFont parameter 529 is a web wizard parameter. It enables or disables a custom header text font. If enabled, the HTMLheaderFontxxxxx options supply information about size and style.

Values: 1) 0 no custom header font

2) -1 custom header font

Example: HTMLheaderFont=-1.

The HTMLheaderFontSize parameter 531 is a web wizard parameter. It specifies a font size, in the range 1 through 7, for header text. This parameter is ignored when HTMLheaderFont is not enabled (-1).

Values: 1) integer, 1 <=n <=7

Example: HTMLheaderFontSize=5.

The HTMLheaderFontBold parameter 533 is a web wizard parameter. It enables or disables boldface type for header text.

Values: 1) 0 no bold

2)-1 bold

Example: HTMLheaderFontBold=-1.

The HTMLheaderFontltalic parameter 535 is a web wizard parameter. It enables or disables italicized type for header text.

Values: 1) 0 no italics

2) -1 italics

Example: HTMLheaderFontItalics=0.

The HTMLheaderFontUnder parameter 537 is a web wizard parameter. It enables or disables underscored type for header text.

Values: 1) 0 no underscore

2) -1 underscore

Example: HTMLheaderFontUnder=0.

The HTMLbodyFont parameter 539 is a web wizard parameter. It enables or disables a custom body text font. If enabled, the HTMLbodyFontxxxxx options suppy information about size and style.

Values: 1) 0 no custom body font

2) -1 custom body font

Example: HTMLbodyFont=-1.

The HTMLbodyFontSize parameter 541 is a web wizard parameter. It specifies a font size, in the range 1 through 7, for body text. This parameter is ignored when HTMLbodyFont is not enabled (-1).

Values: 1) integer, 1 <=n <=7

Example: HTMLbodyFontSize=2.

The HTMLbodyFontBold parameter 543 is a web wizard parameter. It enables or disables boldface type for body text.

Values: 1) 0 no bold

2)-1 bold

Example: HTMLbodyFontBold=-1.

The HTMLbodyFontItalic parameter 545 is a web wizard parameter. It enables or disables italicized type for body text.

Values: 1) 0 no italics

2)-1 italics

Example: HTMLbodyFontItalics=0.

The HTMLbodyFontUnder parameter 547 is a web wizard parameter. The HTMLbodyFontUnder parameter enables or disables underscored type for body text.

Values: 1) 0 no underscore

2) -1 underscore

Example: HTMLbodyFontUnder=0.

The HTMLformat parameter 549 is a web wizard parameter. The HTMLformat parameter selects a formatting style for data as it is inserted into a web page.

______________________________________ Values: Value Meaning ______________________________________ 0 Format data as text paragraphs 1 Format data as monospaced columns 2 Format data as an ordered list (numbered) 3 Format data as unordered list (bulleted) 4 Format data as a Netscape-style table 5-999 Reserved Example: HTMLformat=4. ______________________________________

The HTMLmono parameter 551 is a web wizard parameter. It enables or disables monospaced text. A value of 0 uses monospaced text font. A value of -1 uses standard text font. Example: HTMLmono=0.

The HTML 30 parameter 556 indicates whether or not HTML 3.0 extensions may be used in generating an HTML file (web page). If disabled, HTML 3.0 extensions may not be used and HTML 2.0 features are used.

Values: 1) 0 disable HTML 3.0 extensions

2) -1 enabled HTML 3.0 extensions

Example: HTML30=-1.

The Netscape parameter 559 indicates whether or not Netscape extensions may be used in generating an HTML file (web page). If disabled, Netscape extensions may not be used.

Values: 1) 0 disable Netscape extensions

2) -1 enabled Netscape extensions

Example: Netscape=-1.

The HTMLtemplate parameter 553 is a parameter that is used by the machine 102 when it uses a template to produce a file 110 having an HTML format. The HTMLtemplate parameter identifies the name of an HTML file that is to be used as a model for creation of the web page. The template file is copied, and extensions to HTML provided by the machine 102 are replaced by run-time values. HTML extensions that are honored by the machine 102 are discussed below.

Values: 1) Blank

2) File specification, valid for implementation platform

Example: HTMLtemplate=$root$.backslash.web.backslash.template.htm.

The GatewayDelivery parameter 555 enables or disables posting to the default gateway computer in a user's network. The AlphaCONNECT machine 102 has options for recording a user's local gateway settings (system name, FTP user name, password, and directory).

Values: 1) 0 no gateway delivery

2) -1 delivery target HTML file to gateway computer using FTP

Example: GatewayDelivery=-1.

Links that specify an ODBC data source will have an [ODBC] section. ODBC section parameters are illustrated in FIG. 5C. These ODBC parameters are used to gain access to a specific data source via the Open Data Base Connection protocol.

The DataSource parameter 502C specifies the ODBC driver name to use. This name is the name that the ODBC driver uses to register itself on a user's system, and is usually a long descriptive name such as "Microsoft SOL Server Databases". Values: text string (name of an installed ODBC driver on the users PC). Example: DataSource=Dbase III.

The User parameter 504C is used to log on to the ODBC source. If no sign-on is required, this parameter may be empty. Values: text string (user name or blank). Example: User=administrator.

The Password parameter 506C supplies the password that goes along with the user name in the User parameter 504C. This value may be empty. Values: text string (password or blank). Example: Password=abc123.

The Query parameter 508C specifies the criteria for data selection from the ODBC data source. In the present embodiment, this query is phrased in Structured Query Language (SQL). Values: text string (SQL statement).

Example: Query=SELECT Name, Phone, Fax FROM Contacts WHERE Type=`Friend`;.

Referring again to FIG. 3, as we have noted, the modular architecture of the software 114 in machine 102 enhances the flexibility of machine 102. Each module in the model 300 is designed to perform a defined type of task (e.g. data retrieval, format conversion, data filtering, data mapping, data delivery and application interface). This modular design facilitates extension of the machine 102 by faciliting replacement of an entire module, for example, with plug-ins. For example, a data retrieval plug-in could be designed to retrieve the data 120 from a remote site that does not use either FTP, HTTP or ODBC (i.e. a site with which module 306 is not configured to communicate). A format conversion plug-in could be designed, for example, to convert to a text format source data 120 that is not in one of the formats internally supported by the module 308 (e.g. text, record or HTML format). A data filtering plug-in could be designed to provide filtering options not provided by module 310. Plug-ins providing options not provided by modules 314 and 316 could also be designed. Although the present embodiment does not support a data mapping plug-in, in alternate embodiments such a plug-in could be designed to provide mapping options not provided by module 312.

A plug-in is simply a stand-alone program that uses agreed-upon conventions to work cooperatively with AlphaCONNECT. Plug-ins are .exe files that are placed in the .backslash.connect directory. Sample plug-in programs, including source code, are available for download from the AlphaCONNECT developer page, which is accessible from the main AlphaCONNECT web page: www.alphamicro.com/ac.

In the present embodiment, there may be four kinds of plug-ins AlphaCONNECT can interact with:

Data acquisition plug-ins

Format conversion plug-ins

Data filtering plug-ins

Data delivery plug-ins

In alternate embodiments, data mapping plug-ins might be implemented.

In the present embodiment, plug-ins interact with the software 114 in the following manner. In particular, the software 114 begins execution of a data delivery task. The LC module 304 tells the DR module 306 to acquire the data 120 as specified in the link. If a data acquisition plug-in has been specified in the link definition, the data acquisition plug-in is called. The source data 120 is acquired and placed in the file 120'. The target (application) is then launched. The LC module 304
then tells the FC module 308 to convert the data in the file 120' if appropriate (e.g. textual data where conversion has been specified). If a format conversion plug-in has been specified in the link definition, the format conversion plug-in is called. Format conversion plug-ins are called automatically based on file type. The converted data is saved in the file 120', overwriting the previous file 120'. The logic control module 302 then calls the data filtering module 310 if appropriate (e.g. textual data where filtering has been specified). If a data filtering plug-in is specified in the link definition, the data filtering plug-is called. The filtered data is saved in the file 120', overwriting the previous file 120'. The logic control module 302
then calls the data mapping module 312. The data in the file 120' is then mapped and sent to the data target 106. If specified, the optional save/shut-down of target is accomplished. If specified in the link definition, the logic control module 302
calls the data delivery module 314 to accomplish any specified post-processing. If a data delivery plug-in is specified in the link definition, the data delivery plug-in is called. After this process, link execution has completed.

A data acquisition plug-in is a program that obtains source data 120 from a data source 104 for a link being executed by the machine 102. Instead of the machine 102 accessing an FTP site, web page, or local file for the source data 120, for example, a data acquisition plug-in may access an alternative data source 104 using an alternative method, for example. Such a plug-in should respond to the link parameters related to data acquisition and provide the source data 120 in the file 120' when it is completed. There is no limit to what a plug-in can do to obtain data. For example, a plug-in could interact with the user, form criteria for an SQL engine, query a remote database, and ultimately pass the selected information on to the machine 102. The plug-in could acquire multimedia data. The plug-in could acquire any type of data that can be converted to text.

Data acquisition plug-ins are well suited to: integrating AlphaCONNECT with other applications, coupling AlphaCONNECT with alternative methods of communication, interacting with users before selecting data, triggering operations on remote computers to generate data.

A data acquisition plug-in is referenced by specifying the prefix plugin://in the HostAddress parameter 512, followed by the program name and any command line arguments to be executed. Example: plugin://get-data.exe. The plug-in is passed a source file and destination file specification on its command line, separated by a space. The source file specification is in the format the plug-in is designed to handle from the Datasource parameter 508. The destination file that the plug-in file will create should be a text file of a form the machine 102 can process or a multimedia file saved as the file 120'. Again, this file 120' is saved using a regulated name of the form linkname.datatype in the .backslash.connect.backslash.temp directory. The machine 102 will wait for the plug-in to finish executing, and will then open this file 120' as the link continues execution.

A format conversion plug-in is a program that converts a specific file format into a text form that the machine 102 can use. A format conversion plug-in could also convert multimedia data in a desired manner. This plug-in is called by the format conversion module 308 after the data in the file 120' is acquired. Before the plug-in is called, the FC module puts the data from the file 120' in a temporary file. When the plug-in is called, it is passed the name of the temporary file as the source file and the regulated name as the destination file. Thus, the plug-in obtains the data from the file 120' through the temporary file, processes the data and writes the resulting data as the file 120' over the old file 120'.

Whereas other plug-ins are specifically referenced in a link definition in order to be called, data conversion plug-ins can also run automatically whenever the machine 102 obtains a file type to which the plug-in can respond. Unlike most of the plug-ins used with the other modules, format conversion plug-ins can have specific names that identify the data types with which they are intended to be used. When machine 102 obtains a file from a remote computer, the file extension of the source data is inspected. The machine 102 treats the part of the file name following a period in the file name as a file type. For example, the file type of a file named letter.txt is treated as ".txt". If the machine 102 detects a program file named imp-filetype.exe, it assumes it is a format conversion plug-in for the file type specified in the program name after the hyphen and it is called if the retrieved file has a matching file type. For example, if you want to write a plug-in that handles .dif files, you would name it imp-dif.exe. It is also possible to specifically indicate a format conversion plug-in for a link by assigning a name of a plug-in to the FormatConversionPlugin parameter 572.

Format conversion plug-ins allow broadening of the type of data that the machine 102 can accept. Format conversion plug-ins let you handle many types of source data that are already `text` but are not in a form that the machine 102 can immediately accept without a plug-in. Worksheets, databases, documents, and many other data formats can be adapted as sources for the machine 102 with an appropriate format conversion plug-ins. Often, such programs can be very small Visual Basic programs. Naturally, some formats are more difficult to convert than others.

A data filtering plug-in is a program that selectively copies text from the file 120' and overwrites the file 120' with the selectively copied text. In embodiments of the invention, a data filtering plug-in could also process multimedia data in some manner. Data filtering plug-ins can be used when it is desired to extend the standard filtering options of machine 102. With a data filtering plug-in, you can control precisely which parts of a text data source, for example, will remain in the file 120'. If a data filtering plug-in is specified by the link being executed, the data filter module 310 calls the specified plug-in. The plug-in obtains the data from the file 120', processes according to any filter options specified by the link parameters or implemented in the plug-in and writes the filtered data as the file 120' over the old file 120'.

An example of where a data filtering plug-in might be used is in the case of a stream of data where some of the data does not fit the standard data field mapping. It might be difficult to configure the machine 102 to leave out such data if there is no common pattern that could be specified using the `Ignore Text` parameter or the RequireText parameter, for example. With a data filtering plug-in, your program can inspect the data from the file 120' and keep only the parts you want according to the capabilities of the plug-in.

A data filtering plug-in is referenced by assigning to the DataFilter parameter 575 a value of plugin://ProgramName. Example: plugin://filter2.exe. The plug-in is passed a source file and a destination file specification on its command line, separated by a space. The source file specification is the name of a temporary file into which the data from the file 120' has been copied, and the destination file is the regulated name of the file 120'. The destination file that the plug-in file will create can be a text file or multimedia file of a form that the machine 102 can map.

A data delivery plug-in is a program that post-processes a data result. Data delivery plug-ins are used to transform the file 110, for example, to another form and/or to deliver the file 110 to a final destination in a

manner not supported by the machine 102. In the present embodiment, the data delivery module is called after the target file 110 is created and/or saved and the target application is shut down.

A data delivery plug-in is referenced by assigning to the DeliveryPlugin parameter 574 a value of plugin://ProgramName. Example: plugin://mailit.exe. The plug-in is passed a file specification on its command line indicating the file 110 that the machine 102 created. The delivery plug-in can then transform/process/deliver the file as it sees fit.

Referring again to FIG. 3, the modules of the model 300 are now described. The external interface module 302 provides an interface between an external context 301 and the model 300 of machine 102. The external context 301 might be a human, for example. Alternatively, it might be a program controlling the machine 102. The external interface may vary as the computer system 112 varies and as the operating system run on the computer system 112 varies. The machine 102 does not define the external interface in the context of the operating system platform and user/program interface. The machine 102 may define the internal representation of data delivery information.

FIG. 4 outlines the process 400 accomplished by the external interface module 302 and machine 102. As noted in FIG. 4, the external interface module 302 is implementation specific and depends on the nature of the external context. Thus, when the external context is a human, the external interface module 302 might provide a graphical user interface, for example. When the external context is some kind of program, the external interface module 302 might provide a software interface, such as an OLE interface, that enables the machine 102 and the external program to communicate. An example of a graphical user interface and an OLE interface are described below. Element 402 represents the