PT92066A - Software-level operating environment - Google Patents

Abstract

The present invention relates to a software-level operating environment between the level of the operating system and the level of the application programs, which controls the interaction of a user with one or more concurrent application programs in execution. By forming a common data structure, the operational environment allows functions within various application programs to be executed independently of the nature of the user's particular interaction. The common data structure starts from an application program aggregate, organizes the data so as to be concurrently accessible to the functions originating in the various application programs. In a reciprocal manner, the interactive nature of the user remains, substantially with the same characteristics independently of the particular nature of the application programs. The independence of the application programs of the particular input and output devices and format and batch data devices is also permitted. The high-level software modules of batch data systems (BDS) are flexibly interlinkable with specific low-level modules of devices and formats. Flexible interlinkability protects the user from the specialities of the data storage formats and easily accommodates new formats without modifying the high-level software. The environmental operative device supports means for defining and utilizing a sophisticated family of macros, flexible stamping and the capacity to modify data, either a video or text simulation mode, and a flexible and useful system of formulae for defining object fields.

Description

-3-

BACKGROUND OF THE INVENTION

1. FIELD OF THE INVENTION

This invention relates to software systems that operate at a higher level than the operating systems, but at a lower level than the application programs. More specifically, the invention relates to Operating Environments in which a variety of mutually differing data structure application programs may be developed or concurrently implemented and in which a variety of batch data devices may be employed or added. The invention further relates to a space management system advantageously using the particularities of an Operating Environment. 2. 0 Knowledge referred to.

Computer programs and multilevel software systems are known in the art.

For example, programs such as text programs are high-level programs. In addition to their high-level capabilities, they are able to perform some of the lower-level functions typically associated with software systems far beyond the application level, such as the use of automatically executed tags and formulas. However, application programs like these are very specific in relation to the application and adaptations of the application program to different input / output devices or different computers requiring an extensive revision of the application program code.

Development systems for individual application systems such as DATAFLEX (from the Data Access Corporation) allow for flexibility at a lower level than the application program level. DATAFLEX has a data structure that is flexible. That is, an " object " can have different numbers and type of " field " to decode it and the means by which different objects are connected can also be modified. However, DATAFLEX does not support the plurality of independently developed application programs. Moreover, there is no graphical representation.

Other software systems, such as AUTOCAD (from Autodesk Corporation), are specifically designed for Computer Aided Design application. While specifically suited for displaying a visual embossment of a physical object, the specificity of its application impedes the flexibility in dealing with complex data structures or output input devices.

Some known systems provide for the execution of various application programs in a non-concurrent manner. One way of running a non-concurrent program is referred to as " program switching ". Program switching involves alternating loading and alternate execution of multiple programs in sequence. Program alteration suffers from the lack of any data connection between two programs present so that data communication between the two programs is prevented. Therefore it takes development time to coordinate data transparencies as well as it will cost execution time during the operation. Also the utizador interception is generally different between programs. -5-

Another way to run multiple application programs is to run them separately but to pass information between the two programs through a process called Dynamic Data Exchange (from Microsoft., Inc. as part of your 11 Windows * package) . Dynamic data exchange suffers from the defect that the plurality of programs communicating data from one to another must be knowledgeable of the data structure that the receiving applications program must accept. The lack of flexibility that may be inherent in a common data structure causes the costs of developing additional application programs to grow beyond the costs that would be expected if a common data structure had been adopted. Even if a common data structure had been adopted before any of the application programs were written, this adoption of a given data structure would lead to potential numbing inflaxibility as new requirements arise at a future point in time. It is therefore desirable to have a " platform " where various application programs having mutually different data structures can be executed concurrently without the need to adapt low level software to different data structures.

Many software programs known in the art involve the transfer of embedding blocks between the U.C.P memory, and the disks. The incorporation format on the disks varied with the particular application programs. For example, text files, database files, or ASCII files could be found on one or more disks. The incorporation of these different files had to be accessed by batch data transfer software.

Unfortunately, if a new device were added to the system, or if a new data format on an existing physical device was added, then the software module including high-level as well as low-level specifications for transparency had to be modified "

This need to modify batch data transfer software makes systems known to be inefficient and resilient to expansion. Inflexibility and resistance to expansion is perhaps caused by the fact that high-level code writers work on the same software products for sellers as the low-level code writer. In addition, the applications that were designed by these software writers were thought to be limited in scope, so that the ability to easily add new external devices or formats is not designed there. Unfortunately, if a variety of application programs were required to access a growing variety of devices and formats, then the limitations inherent in known systems would prevent the addition of enhancements to existing features. It is therefore desirable to have a batch data transfer scheme in which the addition of a new device or new external data formats does not require substantial revision of substantial segments of the code. A " space management " denotes a field where (among other things) the positioning of objects in space is by strategy according to predetermined criteria. A specific example of space management is the optimal positioning of an optimal quantity of chosen consumer items on a supermarket shelf. The optimization of the use of space a supermarket depends not only on the di-

physical dimensions of the space inside the supermarket, floor plan and fixed physical elements, but also in factors that complicate such as different delivery times for various products and different orders for different products.

Computer space management systems are known. For example, SPACEMANII is a space management application program from LOGISTICS DATA SYSTEMS; INC; of Irving Texas. 0 SPACEMANII has been licensed to certain companies under conditions of strict confidentiality. It is representative of known application programs that are described in computer code (for example programming language C), and which are not immediately adapted to client or other modifications. Generally, any preparation for computer code customers requires the potentially expensive capabilities of a computer programmer.

These additional costs and inflexibility are undesirable from the user's point of view. It is preferable to have individual expertise in such areas as distribution, marketing, retail, floor planning and fixed parts and be able to work in the same space management system so that the experts can be integrated. When working on the same system without having to communicate directly with each other in their respective " languages " techniques, can contribute to their respective experts to optimize the space management system as a whole.

Known application programs generally deal with data files internal to the program. These can be readable ASCII data files separately for each scenario to be screened.

However, there is typically a lot of common information between data files. For example, the products may be the same.

There is a need for a single database that can store all product embedding, for example, from separate data files. A single database makes it easier to modify or update the import on products without having to modify each dataset separately, as was a limitation on known systems. There is a need to query, update, merge and store data from different places with different logic rules and be selective about which fields to work on.

Within space management systems, it is preferred to be able to facilitate the development, modification and / or integration of new features implemented in software modules originating from a variety of individuals in a variety of respective fields without requiring computer programming skills . It is also desirable to be able to market and otherwise modify the characteristics of space management systems without having to employ individuals with the capabilities of a computer progamator.

SUMMARY OF THE INVENTION

According to the present invention an Operating Environment serves as a software platform in which the programs of application of mutually different data structures can be developed or mutually executed and independent of the devices and input / output employed.

Another aspect of the present invention is its ability to flexibly display a variety of data structures (and in particular fill in data such structures) a variety of formats in selectable maps and graphs. Preferably, the particulate data and the data structures themselves, may be interactively modified by the end user, using a display mode either in " map " or " template " (graphic). The present invention enables application programs that can be separately developed, to be concomitantly executed, using a common data structure that is formed by an aggregation of the data structures of the individual application programs. The aggregation process comprises obtaining any commas between the fields of the different application programs. Subsequent conflict resolution forms common data structures in order to allow for the aggregation of application programs. Aggregation can be performed either at the time the application programs are being loaded or running, or in a combination of the two heights.

This aggregate of application programs performs more effectively than methods known in the medium, which do not have a common data structure whose data are conosely accessible by functions of the various individual application programs. The present invention aims at a wide range of conflict resolution techniques. Conflict resolution allows the aggregation of fields in a variety of particularities of the preferred nesting. For example the common data structure resulting from the aggregation of individual data structures allows the effective stamping of aggregated maps and graphs; menus; keyboard definition, modification and function; list of events in time; macros; capacities of input and output devices and the operation of batch data systems.

Conflicts between structures (or their respective fields) can be solved in a variety of ways, for each of these particularities. For example, a conflict between two data structures can be resolved by choosing one time from the other or modifying one slightly according to the characteristics of the other. Alternately, both portions of the conflicting data may survive conflict resolution, with each being modified according to the characteristics of each other. Further, a new manifestation of conflicting data structures may be formed, which is substantially different from the character of any of the conflicting structures.

Naturally, the present invention aims at the ability to alert the conflict, suspend the aggregation process and interact with a user in order to cause it to be executed in a choice of means to resolve the conflict.

A further aspect of the present invention has been in view of the call, by various application programs, of functions within the Operating Environment. The Operating Environment according to the present invention enables this function call without the separate allocation of memory to duplicate functions which is conventional in the middle.

Yet another aspect of the present invention is directed to a Batch Data System in which a variety of Batch Data Sources (" BDS ") in high level software modules can be defined and modified independently of the software modules of the lowest level of

types of Batch Data (" BDT ") specific to a device. 4

Any of the high-level BDS software modules defines which data is to be transferred and communicates this data filtering information to any BDT software module of a low-level, device-specific variety. The flexibility of interconnecting any BDS to any BDT enables a wide variety of data transfers to and from a wide variety of external memories. So as new devices are added to the system, creating a single BDT module avoids the need to modify the high-level module.

Yet another aspect of the present invention is directed to a software system in which the Batch Data System, which is capable of embracing a variety of data transfers, can itself perform loading, aggregation, the resolution process of conflicts a variety of mutually different data structures from the respective application programs to form an aggregate data structure in an aggregate application program.

Thus, several aspects of the present invention may be characterized as follows: The invention contemplates a method for concurrently executing one or more application programs, the application programs having a variety of data structures, the method comprising the steps of detecting the presence or absence of field conflicts between fields defined in data structures defined in application programs; resolving conflicts in the event that their presence is detected; aggregating the data structures defined in the various application programs into a common data structure, and executing an aggregate application program comprising the plurality of application programs, using the aggregate application program, the common data structure in order to that data formed within the comul data structure is concurrently accessible by functions of the single or more application programs. The invention also contemplates a system for concurrently executing one or more application programs, the application programs having a variety of different data structures, the system comprising a detector for detecting the presence or absence of field conflicts between fields defined in the structures of data defined in the application programs; A solver to resolve conflicts in case its presence is detected; an aggregator for aggregating the data structures defined in the various application programs a common data structure and processed to run an aggregate application program comprising the plurality of application programs, using, the aggregate application process, the common data structure by form that data formed within the common data structure is concurrently accessible by functions of the one or more application programs. The invention further contemplates a method of loading a file of structures for defining objects, fields and links, using a software module, BDS enabled, of a set flexibly interconnected with a BDT software module, activated, of a specific set the method comprising the steps of initializing a channel between the activated BDT software module and the chosen data storage type, the initialization is performed substantially within the software module BDT activated; transfer the structure file of the chosen data storage type and the memory of the U.C. for which the control is iteratively passed between the activated BDS software module and the BDT software module, and closing the data channel between the BDT software module and the data storage type. The invention further provides a system for loading a structure file of a data storage type defining objects, fields and links, the system comprising an activated module of a set of high-level BDS software modules flexibly interconnected with a module activated from a set of BDT software modules specific to a device for interaction with a chosen type of data storage; an initialization module located substantially within the software module BDT activated for initialization of a channel between the activated BDT software and the type of data storage chosen; transfer of modules for transparency of the chosen data storage type structure file and CPU memory in which the control is passed between the activated BDS software module and the activated BDT software module and a closing module to close the data channel between the BDT software module and the data storage type. The invention further contemplates a system for transferring information blocks to and from a variety of variable structure data storage types, the system comprising one or more high-level BDS software modules for specifying the transfer characteristics and one or more plus device specific BDT software modules, each of which is flexibly interconnected with any of the BDS software modules for interaction of respective types of data storage. The invention further contemplates a method of transferring a block of data using a BDS software module activated from a high level assembly, flexibly interconnected with a BDT software enabled module, a specific set of a device for interaction with a type of selected, the method comprising the steps of determining the transfer type; choosing which of other types of data stores is to be involved in the transfer; initializing a channel between the BDT software module and the chosen storage type, initialization being substantially performed within the activated software module; determined, based on the specifications coming from the software module, enabled, from BDS, which objects and fields are transferred; transferring the data between the chosen storage types and the U.C.P. memory, in which the control is iteratively passed between the activated BDS software module and the activated BDT software module; and closing the data channel between the BDT software module and the type of data storage.

Another aspect of the present invention is to provide an improved space management system.

According to a particularity of the present invention, the space management system comprises an application program and the Operating Environment. The application program includes support files and function files. The Operating Environment includes features described elsewhere in this inventive abstract.

According to the invention, the space management system provides flexibility in terms of adding new features, modifications of the existing features, and translation of known functions from other space management systems. This flexibility allows for substantial independence of development of a variety of software modules by individuals generally unfamiliar with computer programming. The space management system of the invention allows the concurrent execution of other application programs with the space management system. -15-

BRIEF DESCRIPTION OF THE DRAWINGS The following detailed description may be better understood when read in conjunction with the accompanying drawings, in which reference numerals refer as elements along and in which: FIG. 1 shows in a very schematic form a diagram of an aggregate application program formed by the Operating Environment according to the present invention in relation to other multilevel software systems with the input and output devices with which it communicates. FIG. 2 shows an exemplary data structure according to the preferred embodiment, including objects and the links between them. FIG. 3 shows in a very schematic form a diagram of the means by which the data structures of two or more programs, applications are aggregated an aggregate structure; FIG. 4A shows a typical map listing of those produced by application programs aggregated by the embodiment of the present invention. FIG. 4B shows an all-screen map typical of those produced by application programs aggregated by the preferred embodiment of the present invention. FIG. 4C shows a menu setting map as may be enabled by the present invention. FIG. 4D. shows an exemplary list map showing the available output devices in a list of output devices. FIG. 5. shows a flowchart diagram of the loading application process leading to the analysis loop in an interactive session. FIG. 5A is a detailed flowchart of the loading structure in the process shown in Fig. 5 as a block 512. FIG. 5B is a flow chart detailing the charging process on the input and output devices shown in FIG. 5 as a block 16. FIG. 5C is a flowchart detailing the charging process of the BDT device shown in FIG. 5 as a block 524. FIG 5E is a flowchart showing the preferred loading procedure of menu loading, lists, of keyboards; macros and lists of events shown in FIG. 5 as a block 528. FIG. 5F is a flow chart detailing the BDS loading process shown in FIG. 5 as a block 532. FIG. 5G shows the main analysis loop which is entered after the application program loading process is complete and starts an interactive session with the user. FIG. 6 shows a list of keystrokes typical of those found in an aggregated application program according to the preferred embodiment.

FIG. 7 shows the relationship of the BDS and the BDTs of the batch data system with respect to the memory of the U.C. and external data storage types. FIG. 8 shows an exemplary map listing detailing the data sources in a system for a typical application program. FIG. 9 is a high level flowchart showing the batch data system data transparencies according to the preferred embodiment. FIG. 10 is a map indicating the values of the three guards for each of five types of transparencies useful in explaining the data transfers in the batch transparency system. FIG. 11 shows the batch data transfer system in more detail than Fig. FIG. 11A is an illustrative flow chart, the routine " DATA WRITING " indicated as block 1156 in FIG. 11, according to the preferred embodiment. FIG. 11B is a flowchart illustrating the routine " DATA READING " shown as block 1154 in Fig. 11 according to the preferred embodiment. FIG. 11B is a flowchart illustrating the end-of-record cleaning routine shown as block 11252 in Fig. 11B (BDS READ) according to the preferred embodiment. FIG. 12 is a map schematically illustrating the table arrangement of a 3DS of a type advantageously employed in the Batch Data System according to the preferred embodiment; FIG. 13 illustrates in a very schematic way a preferred space management system, 1302, comprising a preferred space management application program and the operating environment of FIG. 1 together with an additional application program 1324 that can be performed concurrently with the preferred space management system.

FIG. 14A and 14B respectively illustrate a more complex to a relatively simple data structure for the preferred space management system according to the present invention.

Fig. 15A and 15B are flow charts illustrating the logical steps performed by the preferred space management system for the use of operations.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 1. Introduction The teachings of the present invention will be described with particulars referring to currently preferred embodiments. These teachings are advantageously applied to the particular problem of a space management system for consumer products on supermarket shelves. It should be understood that this embodiment is only one example of the many beneficial uses of the innovative teachings here. -19-

In general, the statements made in this specification do not necessarily delimit any of the various claimed inventions. Moreover, some statements may apply to some inventive features, but not to others.

As will be recognized by those skilled in the art, the innovative concepts described in the present application can be modified and varied over a wide range of applications.

Thus, the scope of the invention is not limited except by the appended claims. The preferred embodiment of the present invention involves a computer program written in a programming language " originally developed at Bell Labs. The operating environment according to the preferred embodiment operates from above the MS-DOS operating system. The Operating Environment according to the preferred embodiment finds special utility in aggregate to allow the execution of application programs such as those in the SPACEMAN family of space management available in the Logistics Data Systems Inc. of Irvine Texas. These preferred application programs can run on an IBM PS / 2 Model 80 computer with 70 megabytes of memory in a disk device. However, in accordance with the dictates of particular application programs or pre-existing computer systems, the teaching of the present invention may advantageously be applied regardless of the environment and hardware or software.

As used in the present specification, the term " structure " applies to any model of a hierarchical data system. Such a template includes " objects " connected to one another in a hierarchical manner, with one or more " fields " associated with the object, for example 0- to define or describe the object. In particular and unlimited example of a data structure is PIG 2. FIG. 2 is described and referred to throughout this specification as in an exemplary structure.

As used in the current specification, the term " structure file " implies any arrangement of data, which defines a structure. An example with no limit on use " frame file ". A non-limiting example of a framework file (used in a space management application) can be found in appendix A. It is an aspect of the present invention that a framework file can be treated very much as a data file corresponding to any other " particularity " of an application program.

A " record " refers to a current individual occurrence of an object. For example, when an application program has a " shelf " object there may be a large number of individual records that have the " Rack " identifier. Thus, in certain ways, objects, links defining object-to-object relationships, and fields defining or describing objects are usually abstract. However " records " refer to particular occurrences of an object. As described with particular reference to " frame file ", objects, lengths and fields may at certain times be treated as if they were simply another data file containing records. In fact, such unit treatment comprises one of the main advantages of the present invention.

As used in the present specification, the term " features " refers to any of the capabilities of the application programs, " features " looking for special utilities in space management systems include displays, menus, keyboards in lists, batch Data Systems modules, and formula-based fields. -21-

Generally, although not exclusively required, the term " features " refers to an attribute of an application program that is of less central concern than that of " structures " *

As used in the present specification, the term " application program " (or occasionally, " individual application program ") comprises one or more of the following elements; (1) a definition of a " structure " as described above; (2) code that is the object of functions capable of being executed in a computer apparatus; and (3) files containing one or more of the following " features "; displays, menus, keyboard lists, list of events, macros, list of output devices, list of input devices, batch data systems software and particle based fields.

As used in the present specification the term " aggregate application program " refers to the loaded and aggregated structures and characteristics of individual application programs. For example, three mutually different structures of three separately developed individual application programs can be loaded and aggregated to form an " aggregate structure " within the aggregate application program. Similarly three mutually different menu systems of three individual application programs are loaded and aggregated into an aggregate menu system within the aggregate application program. Of course, the interaction of the structures, functions and characteristics originating from several individual application programs ensure that the aggregate application program is not a table aggregating elements of the various individual application programs. -22-

\\

As used in the present specification, the term " running concurrently " applies to the interim execution of functions originating from one or more individual application programs. Once aggregated, the object code of the various individual application programs can be thought of as functions of the application program enlarged. As far as the user is concerned, however, the functions of the various application programs are all immediately available, such that the sequential execution of functions of the various application programs appear to the user as being concurrent execution due to the potentially complex interaction of different functions.

General View About the Characteristics of Embodiments

Preferred

Referring to FIG. 1, the Operating Environment according to the present invention produces aggregate application program features (preferably in U.C.P. memory) at block 102. The Operating Environment may be considered to be a " platform " of software in which the application programs 140, 142, 144, etc., can be developed or concisely performed, The Operating Environment in turn is based on a standard operating system 104 which (perhaps through software levels not explicitly shown in Figure 1) operate to the level of machine code 106. Figure 1 is very schematic in nature and intends to integrate the bed into the main concepts and features of the invention. It should be understood that the scope of the present invention should not be limited by the disclosure contained herein, but should be primarily defined only in accordance with the following claims. For example, it should be understood that there may be substantial conceptual variation so that when the operating system 104 terminates and the Operating Environment or its resulting aggregate application program begins. However, one skilled in the art upon reading the claims in the light of the following detailed description of preferred embodiments will enable one to understand and tax the scope of the present invention and recognized that modifications may be made to the particular embodiments described herein but remains within the spirit and scope of the invention.

The elements indicated as element 110 to 138 are indicated in blocks in diagram form. The connections that are important to explain the operation of the Operating Environment are indicated by arrows and graphical approximations in FIG. 1, but software elements within the Operative Scope can interact in ways that, if not explicitly written in this detailed description, would be understood by someone skilled in the medium with light in the existing description. " The base functions' which would thus be understood are indicated in area 108. The preferred embodiment of the present invention uses application programs directed to the interactive stamping and video modifications of representations of physical objects a video screen. Even more particularly, the invention tends to be used in a medium where the consumer products are disposed and selectively manipulated in a simulation of physical storage space on the shelves in a supermarket. A family of such interactive simulation programs, SRACEMAN (SPACE MANAGER) SPACE MANAGER) can be obtained from Logistics Data Systems, Inc., Irving Texas. Of course one must understand that. the scope and scope of the present invention extends well beyond the uses used therein.

Subsequent sections provide a description of the preferred embodiment of the various software features 110-138 shown in the memory portion of the U.C. indicated at 202 (FIG.1). In a later section, preferred embodiment implementation will be presented a description of a preferred process whereby the preferred embodiment fulfills loading, aggregation and conflict resolution resulting in a smoothly running aggregate application program such as that shown in FIG . 1.

A. THE FLEXIBILITY OF DATA STRUCTURES The Operating Environment according to the present invention provides the ability to work with application programs using a variety of data structures.

Any hierarchical data structure can be modeled using the preferred operating environment. One " Hierarchical data structure " is defined as a data structure in which objects are linked in one-to-one or one-to-many arrangements.

A set of objects and features links of a known application program for simulating, for example, the placement of consumer product on storage shelves may be as follows. Referring to FIG. 2 a " warehouse " 202 can be linked down via " owner link " to the object " gondola " 204 which can be connected via another disconnected object to the " shelf " 206, which can finally be attached to the product object " 208.

At the same time, the " warehouse " 202 can be coupled via-

an owner link 212 to the " product " object. 210, which may also be attached to the object " product position " 208.

In the preferred embodiment, each link 212 may link only one object. That is, many " products " 210 can be connected by connection 212 to a " warehouse " 202. The data structure of particular application programs is read by the Operating Environment. The input reading of data structures based on the particular application allows significant flexibility that there are no known systems. The conventional approach to the conventional formation of data structures is to mentally adopt a certain data structure and then write the program code to around her. This known method obviously suffers from the defect of which, to adapt a new data structure, the software to be modified, and recompiled.

In the preferred embodiment, the data structure which the Operating Environment can use to be found in files of frames 312, 314, 316 and so on (FIG.3). Structural files contain only revealing information to the actual structures themselves (warehouses, gondola, shelf, etc.) the nature of the attributes of each object (stored in fields) and the links that relate the objects.

An struct file is to be distinguished from a data file. A data file contains " records " specific information on particular stores, gondolas or shelves etc. The data in the records is advantageously arranged to be most accessible in formats defined by the structure file. According to the preferred embodiment, the data structures themselves (field objects, and links) such as in FIG. 2 may be suitably modified by users,

only the current data within the data file registers.

The data structures form the basis of other features of the invention, such as maps, models and menus. The aggregation of the data structures of individual application programs can be described as follows, with reference to FIG. 3.

In the preferred embodiment, we first assume that the application program 140 has a first data structure (comprising object definitions, fields and links) 312, and that the application program 142 has a second data structure (comprising object definitions, fields, and links 314. The aggregate data structure would have objects, fields, and links given in 310.

During execution of the program using the aggregate data structure (within the " aggregate application program " referred to in this specification), whenever the characteristics of the first application program are invoked, the structures originating at 312 are used. Similarly, when the features of the second application program are invoked, then the structures originating in 314 are employed. The invocation of 310 reflects the fields that are common to both application programs, demonstrating the ability for two independent application programs to access and modify data in those locations in the common data structure. The particular way in which the formation of the common data structure 110 is achieved in the preferred embodiment is described in detail in the Program Flow reaction, below.

An advantage of the 110/310 common (aggregate) data structure is that application programs that were independently designed and developed can

be merged and run as a single " aggregate application program " using the common data structure. At the abstract level of data structures (as opposed to features such as maps, models, and menus, the issues of conflict detection of fields of data structures of different application programs is advantageously solved in many circumstances including simply any non-duplicate fields of the data structures of the individual application programs in the aggregate data structure and inserting a single data field into data fields that are duplicated between the individual application programs.

More sophisticated tests for resolving field conflicts include, for example, resolution of a conflict in an entire field and a floating-point field by choosing a floating-point field in the aggregate object.

For the purposes of this finding, it should be understood that the word " conflict " must be interpreted broadly. The idea of a conflict encompasses not only the situation where two different application programs want conflict operations to be performed. The term " conflict " also encompasses situations where, for example, an application program assumed that a second application program would provide necessary information relating to data structures or their content, but according to the application program it assumed that the first would provide such information. The lack of definition of information required by any of the application programs or a specification of a structure or some data that is ambiguous due to lack of information from another application program should be understood as being accompanied by the word " conflict " as used in this specification, imply that application programs may not be actively competing for control of some process. The ability of aggregation of the preferred embodiment is related to other advantages. These other advantages include the fact that application programs

can be loaded without " " as is known in known systems.

In known systems, the process for program development involves compiling various source modules into code to form a set of respective modules into object code. Subsequently, the various object code modules must be connected to an executable program. In known systems, therefore, a modification in a single source code module required not only the compilation of that module, but also the connection with all other object code modules. Since in any large program the number of modules in object code may be thousands, the disadvantages of known systems are apparent.

In contrast, the Operating Environment according to the preferred embodiment allows other application programs to be run without " " with all the modules of the Operating Environment. Bridge code modules within an application program must still be connected together, but the Operating Environment automatically combines the resulting executable application program to present the user with a single program that incorporates the features of the Operating Environment and all applications.

So every application programmer needs to worry about connecting modules in object code in their own application program. The executable object in Operating Environment code 102, previously connected without any intervention on the part of an application programmer, is not modified. The connection between the executable application code and the Operating Environment executable code is not required. The avoidance of connections has the advantage that those who develop the application do not have to deal with the methods and modules of the Operating Environment, making their own connection stage faster and more independent.

tooth.

Likewise, the user can add or remove application programs simply by adding or removing executable files; you do not have to perform the technically and time consuming task of connecting, which is especially advantageous when the user is not specially trained. B. DISPLAY: Stamping of Data Structures The information contained in the structure file provides the basis on which the data structure generally and particular data relating to objects and their associated fields can be shown to the user. Two major modes of embossing are simply implemented by the preferred embodiment of the present invention, maps and models. (The embossing modes allow not only the view but also the modification of the current data and data structures, that is, data or data structures can be interactively exchanged by the use of menus or function keys. however, the flexibility to modify, as well as the stamping of data and data structures in a variety of formats, both textual and graphical, must be taken into account. preferred embodiment involves the embossing of deformation which may originate from more than one application program

being executed concurrently. In the vision categories, whether in the form of maps or models, the appearance of conflicts as an attempt for more than one application program to fill the same elements of the frame. The Operating Environment according to the present invention allows such conflicts to be resolved.

Conflicts are solved in a variety of ways. As expressed in more abstract terms in the Summary of the Invention, one of the application programs may have a simple priority over the other application program, such that the first application program effectively takes control of those elements of the frame. In a map format, this implies that the text of the first application program is stamped on the screen instead of text that would otherwise be stamped on the screen by the second application program. There are other ways to resolve conflicts of vision than the solution or one or the other described above. For example, in a map format, if two application programs wish to position a portion of text in the same location on the screen, a first application program may be given priority over that particular location, but the text of the second application program yes-plasmid would be re-attached to a different portion of the screen (instead of being completely written over). Likewise, if any text in a given application program had to be removed due to a conflict with text from another application program, the rewritten text may be oriented in some way to indicate its redislocation. Such orientation may take the form of suitable esterisers, arrows or indicators.

Preferably, model conflicts can be avoided together by not assigning identical names to any two viewers. Also, since viewers simply represent objects whose conflicts should have been resolved at the time of loading, in the preferred embodiment, then conflicts should not be left to be dealt with by the observation system. In the model format, conflict resolution can be stamped by, for example, positioning the physical object of an application program so that it appears " in front of " physically object of the other application program. The presence of the hidden or partially hidden physical object of the lower-priority application program may cause it to appear on the screen to indicate its presence. For example, a dotted line, on the outside, to shade and something else, can alert the user to the fact that there was a conflict as to the particular location involved.

Depending on the particular application program involved, they may observe special provisions either within the Operating Environment or through a " workout " of the system interactively, to implement high-level logic functions, depending on the particular application. For example, if a physical object known as being transparent conflicts with a physical object of a second application program known as opaque, then the transparent physical object can be made appear " in front of " the opaque physical object. This high data and application-dependent resolution technique allows both physical objects to be stamped, while minimizing how much one physical object deprives another of the user's vision.

This ability to resolve conflict that can be adapted by a user after all application programs and the Operating Environment have been written indicates the extent to which the Operating Environment can be designed as a software development system for itself . The ability of a user " programs " effectively the means of interaction and conflict resolution of different application programs has the advantage that no application programs code or environment-

Operatives need to be modified.

Since the user can modify the data structure as well as manipulate the location and manner in which the objects and their associated fields are shown, the user actually has complete control over the entire stamping process without having to resort to real changes in the software. This is no more than a basis on which the operating environment can be idealized as a software development system, and not merely as a means of assisting in the execution of software.

It will be appreciated that the means of modifying the data structure and the means for modifying other features of the present invention (such as OBSERVER punches) can all be performed using substantially the same family of foods. Thus, the user's friend property of the system is exalted, as the user " learn to feel " to a variety of modifying sequence while learning a single sequence.

1. MAPS

A map is a printed text describing one or more objects with associated fields in a variety of predetermined or user-selected formats. -33-

The. LIST OF MAPS Fig. 4A, entitled PRODUCTS IN STOCK IN RA455, shows a different six-object text (consumer products) with information associated with each object (data field such as the UPC label, amount by box, cost per box, unit cost, etc.).

Eonflites that appear in a map list are more likely to occur when the associated information in each object is different for different application programs. For example, one application program may have the UPG label and the unit cost, while another application program may have orders and movement information. Conflicting information takes the form of tagged columns in the map list. In the absence of other application programs, the columns associated with each individual application program would tend to occupy the leftmost column in the map list. However, the operating environment according to the preferred embodiment solves these conflicts by placing the columns that originate in the highest priority application program in the leftmost columns and placing the lowest priority program's columns in the columns to the right of them.

Fields that are duplicates, such as the product ID in the leftmost column, can be printed once instead of two. As a user gains experience with the system and learns how to arrange their readings on map more efficiently then higher level logic functions can be implemented that are more sophisticated than simply watering the highest application programs priority are assigned to the leftmost columns. -34-

The assignment of data fields from various application programs to specific columns can be chosen according to the dependency on the priority of the fields, based on the nature of the fields. In this way, the current data content of the different fields of the various application programs can determine the order and positioning of the columns in the map list as it is finally stamped.

According to the preferred embodiment, a number of mathematical functions such as those encountered in text processing programs as well as functions not yet designed or implemented which are within the scope of the present invention. For example, the sum of the numbers in a given column can be totaled, and the total can be printed on the bottom of the column. Such mathematical functions are described further below in the section entitled " Formula System " . The user can choose to specify different data on the map so that " in certain areas of the map.

B. Figure 4B, also titled PRODUCTS IN STOCK IN STORAGE RA455, shows an exemplary all-screen map. An all-screen map is a map in which a single re-generation is shown with its associated data. As in the map list described above, the content and format of the embedding can also be modified by the user according to the principles described, with particular reference to the menus, keyboards and events in time.

As more generally described above, in the section entitled DISPLAY. Embodiment of Structures and Data, the present invention provides a wide variety of means for resolving conflicts that arise when two application programs wish to position rex-to in the same area as an all-screen embossing map. Relatively simple data-conflict resolution techniques such as choosing text and ignoring the other or locating lower-priority text at a different location in the on-screen map stamping can be supplemented by more sophisticated conflict resolution techniques. More sophisticated conflict resolution techniques may include, for example, resolving the conflict between a blue object from one application program and a yellow object from another application program to be indicated on an all-screen map as green.

Further, it is within the capabilities of the user to redefine the stamping locations of the different fields, allowing him " to go over " of any or all of the locations otherwise imposed by the individual application programs. 2. Models

In the preferred embodiment, a model may be conceptualized as a structured graphic (frame) data stamping, plus all data structures attached thereto. Of frequency, the total hierarchy of data structures (or data themselves) at all levels of a presently chosen level can be shown.

In the course of an interactive section, the higher-level stamping can be changed by the user. Thus, for example, the user of a space management system would be able to "" from the entire stamping of a large to a shelf in the gondola, to a particular set of products a portion of the shelf.

As described above from. a more " generic form in the section entitled DISPLAY. Stamping of Structures and Data, a physical object can be graphically shown after simple or more legible conflict resolution techniques. For example, physical objects that two application programs would otherwise place on the same part of the screen can be solved by relocating one of the objects making it appear as if an object was in front of a second object by making the second object appear in " fastas-ma "; behind the second object, and so on. The same object, but with different attributes (such as color) can be solved, for example, by making a green object emblazoned when the two conflicting application programs wish the object to appear in blue and yellow

I respectively.

Conflicts between model viewers can be avoided, as they are in the preferred embodiment, by naming the viewers only. C. Creating MENU, Modifications and Functions

Menus are one of the three main ways in which functions and macros can be invoked according to preferred embodiment. (The other two

Preferred means are by Key setting and event lists). On the surface, the menus according to the present invention may appear individually to menus known in the art. However, the outstanding flexibility that characterizes the present invention is evidenced in that in the preferred embodiment the menu items may refer to preprogrammed functions, macros (either pro-programmed or user-defined), or refer to other menus, sub-menus. The present invention has in vieta that the menus may be of the horizontal or vertical or tree type, or any combination thereof. For example, a first menu may have five items listed horizontally along the top of the screen.

If the user chooses the fourth of the five items listed horizontally, an optically-oriented list of option submenus appears below the fourth iteration of the menu. The user can program their own menus in terms of either content or embossing format. For example, the user can add or remove items from the menu, or create entirely new menus. You can set your own macros to make them accessible from any given menu. FIG. 4C shows an exemplary menu setting system method in which several different menus together with their associated features are shown in sheet format. Defined or user-changeable features such as the (fixed or solar) position, the vertical or horizontal orientation, the presence or absence of a border, the presence or absence of a title, and background colors are examples of items that are modifiable by user in the preferred embodiment.

Conflicts may arise between different application programs when, for a given menu, each application program has a different (perhaps overlapping) set of options. Perhaps the simplest way to solve

viewing the conflict is to allow a higher priority application program to rotate the placement of the higher menu items. The lower priority application program would cause any entries not yet present in the first application program to be stamped below the menu entries of the first application program. Of course, the user does not even need to analyze the various menu items originating from different individual application programs; the list of aggregated menu options appears to you simply. Like when the user chooses one of the menu options to run, he does not have to worry about which of the application programs the control has to be passed in order to execute the menu selection »Why conflicts between application programs have been resolved prioritized to any selection, the user does not experience any delay due to the application programs that are concurrently executed.

That is, in fact that the separately developed application programs are being concurrently executed does not negatively affect user interaction due to the smooth resolution of conflicts facilitated by the Operating Environment in accordance with the present invention. As will be seen below, with the appreciation gained from understanding the macros whose execution is enabled by the preferred embodiment, the sequenced and rapid execution of functions of different application programs is facilitated without the time-consuming delays inherent in switching from programs and techniques of dynamic exchange of data known in the medium. -39-

D. Definition of KEYS. Modification and Functions.

A second means by which functions or macros can be invoked by the Operating Environment is by programming function keys. The function of several specific keyboard keys (or for example button presses on a mouse command bar) can be set and modified by the user. Such is the case with many other features of the Operating Environment according to the preferred embodiment, the manner in which the function keys may be defined is substantially similar to how another feature may be defined. The current definition or modification of the definition of a particular function key can be achieved, for example, by the use of the menu system, or perhaps a series of function keys predetermined or chosen by the user.

Functions that are performed in response to a predefined or user-selected function key include the following, A menu can be called, or a macro function can be performed. Although the keys labeled Fl, F2, F3, and so on, which many of the users will find useful in practical scenarios, it should be understood that any set of keys on the keyboard can be modified, even to the point of tiring an entire keyboard is set again.

Conflicts may arise between different application programs that want a single specific key to perform different functions. In the preferred embodiment, a " Key list " is searched top-to-bottom. This list contains programmed functions or functions that are to be performed in the event of a key being closed. The functions that each individual application program

associating with a particular table can * sometimes generate conflict.

When there is a conflict, the Operating Environment resolves the conflict, either in advance or interactively. Such is the case in many other conflict resolution techniques given to other features of the preferred embodiment, a higher priority application program may take over the function originating from a lower priority application program that would otherwise be associated with that key. Alternatively, a key that the lower-priority application program wished to have been associated with the function, could be " to a different key. In this case, the user can be alerted to the change in the function keys.

In a preferred embodiment, a screen embossing is provided so that the user can view each specially programmed key with its accompanying function. Of course, the finally resolved list of aggregate function keys does not have to reflect to the user that the various function keys do not originate from a simple application program. Of course, the flexibility of the Operating Environment according to the preferred embodiment allows the user to define or redefine (overlapping the application program) particular function keys. θ. E. List of Events

In the preferred embodiment, a list of events is advantageously included as a third means by which the functions or maps that are copied to the Operating Environment may be invoked. Briefly, a list of preferred events may be a list of functions or macros that are to be performed on a date at a height, at a given time after a predetermined event, or repeatedly at fixed intervals -

This list of events can be read to the Operating Environment by an application program. Optionally, the list of events can be interactively modified by the user much as the other features of the Operating Environment can be modified. (eg by using menus or keyboards or sequences shortly after). Advantageously, the functions or macros specified in the event list can be performed a given number of times, possibly at predetermined regular or irregular intervals. An exemplary application of this feature would be to carry changes to consumer products of a main computer at predetermined intervals, so that the system database is repeatedly updated.

Conflicts may arise when two different application programs call for executing respectively different defunctions at the same time. This conflict can be resolved by allowing the highest priority enforcement program to prevail. That is, the function that the highest priority application program wishes to be executed at that particular time will be executed and the functions desired to be executed by the lower priority application program may alternatively be delayed, matched or modified by a logic technique more sophisticated that is based on the current nature of the two functions. A 4-

example of a more sophisticated resolution technique depending on the function and to which a function can be "auto-off1" (indicating that it is not appropriate to be invoked), such as when a tabular transfer has been temporarily disabled. F. Macro Input

As described above, a macro is a sequence of commands input by the user that is stored for subsequent execution in sequence. Advantageously, macros enabled in the preferred embodiment form an extensive ordering. For example, labels and GO TO (unconditional deviations), SE proses (IK) dynamic variables, FOR loops and WHILE (while) submacros (concatenated macros), automatic message stamping and ready ones are available. In the aforementioned embodiment, the macros can be compiled as are the formulas (described below) even though they operate in object fields. Despite its flexibility and comprehensiveness, the language of the macros is designed for ease of use following substantially the same syntax as the object field formulas. Like other features of the Operating Environment, defining macros can be done in a way that is independent of the particular application program being run. The definition of macros, referencing and execution can be achieved as follows, a preferred embodiment. The nomenclature of the particular macros of the various application programs can be facilitated 43-

including in the name of each function an identifier of the application program followed by a period required by function index that specifies only the particular function being referenced in the application program. Thus, 1.7 would indicate the seventh function in application program number 1. and 4.3 would indicate the third function in application program number 4. A function number " of 0 can be advantageously used to indicate macros in the Operating Environment. Thus 0.5 indicates the fifth function provided in the Operating Environment itself.

Conflicts between macros of different application programs can be solved in a variety of ways. First, macros may simply have a guard designating that they are incomplete and so never compiled. Alternately, such a conflict can be resolved by branching out to other functions, perhaps based on the current content of conflicting roles. Ideally, conflicts can be avoided by advanced preparation and nomenclature planning, so that separate developments of different application programs do not produce macros that are in conflict. The nomenclature of the macros outlined above avoids such conflicts of being raised in the first place.

G. LIST OF OUTPUT DEVICES

A list of output devices, in accordance with the preferred embodiment of the present invention, comprises a list of output devices (such as,

such as printers, charts and video stamping) with specifications and associated capacities. 4D, entitled AVAILABLE OUTPUT DEVICES, shows eleven exemplary output devices with pertinent characteristics, including horizontal and vertical resolution, and height and width of the print. Other relevant features may include overwriting capabilities, by specification according to a series of random access devices, availability of different colors, specifications of how to access devices (for example, compliance routines), and so on. The independence of the operating environment executable code from the modification due to modifications to the output devices is provided by the inclusion of this list of output devices. When a new output device is added to the system, only the specifications in the output device list have to be modified; the Operating Environment software can be properly run without changes or subsequent compilation. Modifications to the list of output devices can be made independently of particular application programs whose execution is anticipated. H. List of Input Devices

According to the preferred embodiment, the flexibility in adding new input devices such as keyboards, " manches ", or data communication modules of other computers, can be achieved in substantially the same manner as for-output devices , described above with reference to the list of output devices. A list of devices

adapted for the purpose of allowing new input devices to be accommodated by the Operating Environment, is all that needs to be modified. The executable code of the operating environment remains unchanged and the addition of a new input device can be achieved independently of the application programs that will eventually be able to use those input devices. I. Batch Data Systems The batch data system, according to the preferred embodiment, allows the transfer of large amounts of data, generally not associated with the example of interactive data entry specially prepared by the lists of input and output devices about to leave. The batch data system comprises two main components, one being in a higher level of isolation of the type of isolation of the particular data type under consideration. The Batch Data Bridge (SDS) is the highest level software, dealing in particular with the definition of the data channel. The Batch Data Type, on the other hand, is the set of device-specific software modules that deal less selectively with the raw data, going to and from the batch data devices. -4-

Batch Data Sources The Batch Data Source is essentially the configuration with which the user can interact directly. BDS essentially defines the data channel in the broad sense, describing which objects and which fields are to be transferred. BDS never needs to be modified merely for the addition of a new type of batch data software. This modification immunity ensures that the user does not need to learn another whole set of instructions where data structures whenever new data software is added to those with which the Operating Environment must communicate.

Usually BDS encounters conflicts between different application programs when different application programs want different objects and fields to be transferred. Conflicts can also arise when different data referred by two different application programs are desirable to be placed in the same location. The preferred embodiment of the present invention solves such conflicts as " conflicts " of data duplication.

Since BDS generally has to transfer a chosen set of objects and / or fields, conflict resolution involves deciding which data should be placed in a given location or where to position a given structure in relation to pre-existing structures in the application programs are silent or are in disagreement. Also, since the application programs do not agree on the destination of the same data or relationship to the pre-existing data structures of the same new data structures, the Operating Environment resolves these conflicts.

The preferred embodiment of the present invention also contemplates a scope of options for dealing with conflicts that react and arise at the level of the relationship of the bonds of the different objects. (For understanding purposes, this is to be confronted with the conflicts in the positioning or location of input data, described above with respect to duplicate-read option systems). It is conceivable that during the transfer the structure (in the form of a data record) that does not have a complete hierarchical description can be transferred. For example, a shelf may be desirable to transfer without also transferring the gondola. This lack of definition of a particular link can be resolved by assignments from " parent substitutes " automatically, through it to a point at which a more complete hierarchical data structure is available. The hierarchical structure can be completed either later in the same data transfer, or a future data transfer can be completed. In the particular example of a shelf for which there is currently no gondola, a substitute gondola is automatically created.

Another way to resolve conflicts is through the use of a CONTEXT option. The context option encompasses assuming that records whose hierarchical data structure is undefined are located under the current object (assuming this has meaning). For example, if the user is currently examining a given gondola in a warehouse, a data record whose relationships in the hierarchy are ambiguous is located (either tentatively or permanently) in the current data structure (such as gondolas).

Also an order option allows the connection of the ambiguous or unspecified structure -48 -48

to be determined by the most recently transferred daddo structure which may resolve ambiguity or lack of specification. For example, if a shelf is transferred with a connection to a gondola which is not specially specified, then that attachment in the hierarchy is determined (permanently or by attempts) by that gondola that had been transferred more recently, reciprocally, is within the scope of this we envisage that the ambiguity of links can be solved by those structures which follow (as opposed to the preceding) the hierarchical structure present in order of transfer. The question of the format in which the data must enter an external destination in an outward directed transfer can also be solved by the preferred embodiment of the present invention. First, if there is no predetermined destination of the format, the target format can be advantageously created using the same structure as the source format. This effectively causes duplication of both format and data content. The DESTINATION feature allows you to use the default destination format. When this option is selected, the data in the pre-finished destination format is modified according to the conflict resolution techniques described above in the description of the duplicate treatment system. The data they only, and not the format, can be modified.

Alternately, the destination format can be specified a SCAN which contains a description of the destination format. The target format of the Scroll file is relevant to the store operations.

A central feature of BDS is to arbitrate which objects and which fields to transfer. What objects will be transferred is determined by the preferred embodiment by which the types of records will be transferred, since the known record structures in known data files are especially suitable for the object hierarchical data structure according to the corporate of the present invention. 2. Batch Data Types The Batch Data Type (BDT) is essentially a low-level data router, in which the particular operating data the user experiences. Inherent with BDT is a list of current functions that must be performed in order to successfully connect multiple batch data devices, such as local databases to the computer on which the Operating Environment is resident, processing program files standard text files, ASCII files, database files, or system files.

Together BDS and BDT tailor the Operating Environment to many types of batch data transfers without the need to modify the Operating Environment software (at least at the BDS level), forcing the user to learn a new format or a set of commands, or to change any particular application programs. The user can simply specify which objects and fields are of interest to a particular application and the Operating Environment data system delivers the specified information while repairing the particularities of the transfer. The user may be, or choose not to see, from both the data as he deems desirable, the BDS software showing on the screen indeed the undesirable information. -6-

In order to accommodate a new data type, the BDT (data advisor) must be added (or a previous BDT be modified). J. System of Formulas

Any field of any object in the structure file may be associated with a formula that defines the contents of those data fields. Defining data fields by formulas supplements the capabilities of the user or application programmer to define each field in particular as a constant value. Any of the functions that are present in conventional word processing programs can be included in the Operating Environment. A particular field can be defined as a combination of mathematical or statistical logic elements from other fields that are predetermined or constants chosen from the user. When fields not specified with a given formula, the fields can be chosen either from other fields in the same structure or they can be fields from other structures.

Inputs such as NA (unavailable) and ERR (error) may be specially entered by the user or generated by program operations.

According to the preferred embodiment, if a particular field is found to have an NA input resulting from a formula referencing other NA fields, the NA state of that field may be forcibly modified while maintaining the mutual consistency of the data.

X

This modification is achieved by what is called a " back poking " capability. When a particular value in -tra in the NA field, the function of " backtracking " works backwards " in order to supply any NA fields on which the forced field depended. Previous NA fields are replaced with whatever amount is required to cause the forced field to "" of assuming the first value.

This backward poking feature allows the user the ability, for example, to determine which initial conditions may be required to achieve certain results. For example, the pricing of a consumer product in a group of consumer products can be determined for a given profit margin, assuming that the price of the remaining products has already been established. The NA profit margin would simply be forced to the desired value and the Na consumer product would be automatically set by the automatic backward poking procedure. K. Reference to Functions from and Outside the Operating Environment

According to the preferred embodiment, the Operating Environment can effectively invoke functions that are present in application programs. A reference to the function of the application programs advantageously comprises a reference to the application program itself (by name or by index, for example) as well as being an indexing function in that particular application. The Operating Environment may invoke the functions of one or more application programs that are running concurrently, as permitted by the Operating Environment system. 52-

One advantage of this ability to invoke ramp functions of an application program is to be within the enhanced execution speed as far as the obvious capability of loading and connecting application programs in the middle of the processor section. This flexibility is demonstrated by the ability to write, compile, and link additional application programs without encoding the Operating Environment. The flexibility of the preferred Operating Environment framework is further demonstrated by the ability to call application program functions which in turn call for utilitarian functions that are inherent to the Operating Environment itself. The ability to reconnect to Operating Environment Punches is achieved by using a library (a list of functions that can be referenced to a " hook board "). The hook table comprises a number of addresses in the Operating Environment Code to transfer control when the application program wishes to perform the function.

As long as a separate build is not required because of the inherent interconnections the non-experienced user does not experience any delay during a terminal session which otherwise would be caused by a less efficient link procedure. Also unnecessary duplication of codes is avoided. Several particularly important features of the preferred embodiment according to the present invention are described below.

A first important feature is the loading and aggregation process, including the resolution of any conflicts, with particular application to the loading and aggregation of data structures of different application programs. λ: Ν

A second important caterer relates to the Batch Data system, comprising BDSs and BDTs (process Batch Data Sources and Batch Data Types) that flexibly interact.

Another important feature according to the preferred embodiment of the present invention is the use of a certain portion of the Batch Data System itself in the loading and aggregation process. III. Implementation of Preferred Embedding A. Loading and Aggregation of Application Programs

In FIG. 5 there is shown a flowchart of the loading and aggregation process 500 leading to the analysis loop in an interactive section.

After initialization, a list of all application programs containing functions and structures to be loaded and aggregated in an aggregate application program is compiled. This function is generally indicated as block 504 in FIG. 5. The creation of the list of application programs is within the capacity of someone skilled in the field.

Then, as indicated at block 508, the preferred embodiment carries an " image " of each application program. An icorn can be a representative embossing of the application program. Advantageously,

to also possess a stylistic expression, perhaps related to the function and purpose of particular application program.

All images can then be stamped in order to confirm to the user that all desired application programs are in fact being loaded. Block 512 indicates the process of loading the structure, and will be described below in greater detail, subject to PIG. 5A. In this block 512, the structures (one of which may resemble that shown in Figure 2) are read from the various application programs. In this block, any conflicts between structures are resolved. Furthermore, any application programs having structures whose objects and / or lengths are related to the objects and / or lengths within the structures of other application programs are combined to form an aggregate (common) structure. Block 516 represents the process by which the guiders of the output devices are loaded. This process is described in more detail below, with respect to PIG. 5B. Block 520 represents the process by which the unloaded BDT guiders. This process will be described in more detail below with respect to Fig. 5C. Block 524 represents the process by which the displays can be loaded and aggregated. This process is described in more detail below with respect to fig. 5D. Block 528 represents the process by which menus, keypad lists, macros, and -55-

Vv

lists of events can be loaded and aggregated.

This process will be described in more detail below, with respect to FIG. 5E. The loading and aggregation of these four characteristics was combined in the preferred embodiment, but such a combination is not necessary for the practice of the invention. The reason why in the preferred embodiment, loading and aggregation of these characteristic frames is combined in what can be conceived as a single process is that the xxx.MEN file according to the preferred embodiment contains information relating to these four characteristics. Its loading and aggregation is advantageously consolidated due to the intimate relationship of the list of keyboards, list of macro events (sequence of functions) and names that may be involved in invoking any of them.

In the preferred embodiment the conflict resolution of keyboards occurs after the loading process, at the time of running. See below the subsection on '' Keyboard Conflict Resolution at the time of Running " under the description of " Main Loop Analysis " in the " Preferred Embedding Deployment " section. This is an example of how conflict resolution can be resolved either at loading time, at run time or in a combination of both and still remain within the scope of the present invention. Block 532 represents the process by which batch data sources (BDS) can be loaded and aggregated. This process will be described in more detail below with respect to Fig. 5F.

The loading and aggregation characteristics of the present invention need not be limited to the application programs having these features described in FIG. 5, and in figures detailing those features already reviewed in this discussion of FIG. 5. The present invention contemplates the ability to load and aggregate features of a variety of application programs now known and developed later as long as the characteristics of the various application programs are desired to be loaded and aggregates (with possible conflict resolution) an aggregate application program. Thus, the invention should not be limited in scope by the particular features shown in FIG. 5 or listed in the related discussion, but should only be limited in accordance with the claims which follow this disclosure of the preferred embodiment.

After the application program and all its features are loaded and aggregated and have resolved as many conflicts as desired, then the added application program is complete. The user's interactive session can begin. In the preferred embodiment, a first map generated at block 536 by the aggregate application program is presented to the user. The control is then passed to an analysis loop along path 538. A preferred embodiment of the analysis loop is described precisely below with reference to FIG. 5G. 1. Loading structures A PIG. 5A illustrates in great detail the frame loading process shown as block 512 in FIG. 5.

Blocks 5104, 5106 and 5108 in FIG. 5A illustrate the loop in which the structures (such as FIG. 2) of various application programs are loaded and added,

two. A more detailed discussion of the loading and aggregation process is described in more detail below, with particular reference to FIGS. 9, 10, 11, 11B and 11B1. These figures represent, in progressively greater detail, the process by which the characteristics of the application programs in general and the particular data structures are loaded and aggregated. At this point it is sufficient to mention that the loading and aggregation process is carried out by software serving a more general purpose. The more general of the processes illustrated in FIGS. 9, 10, 11 and 11B and 11B1 namely batch data transfer) is applied to blocks 5104 of FIG. 5A for the particular purpose of loading structures. In fact, it is one of the inventive features of the present invention that the Batch Data Systems software can be used directly to load and aggregate structures. Block 5104 (FIG.5A) involves performing a path in Fig. 11, in which a transfer " INTERCHANGE " of this type is chosen. Briefly, in FIG. 11 the path followed in the loading and aggregation process 5014 (FIG 5A) can be followed in FIG. 11 by blocks 904, 906, 1110, 1116, 1134, 1136, 1138, 1142, 1154, 958, 1160, 1164, 1172 and 1174. After carrying out the process thus indicated in FIG. 11, the control returns to the loop end block schematically indicated as 5108 in FIG. 5A. The loop 5104, 5108 and 5106 (FIG.5A) is executed once for each application program. In this way, the aggregate application program is formed " accumulating " (broadly speaking) the objects and fields of the structures of each application program as they are processed in the loop. It is clear that the process of loading structures and aggregation (including conflict reduction) does not need to be performed by the software already present.

in the Batch Data System. However the economy of using the same code is advantageous. The invention contemplates not only the use of Batch Data System code for the loading and aggregation process but any loading and aggregation process consisting of the claims which follow this disclosure of the preferred embodiment.

Further, the loop structure shown as elements 5104, 5108 and 5106 (FIG.5A) does not limit the invention. Another process by which structures can be loaded and aggregated (such as processing the various application programs in a more parallel manner) also falls within the scope of the present invention.

Returning to the preferred embodiment description, after the last application program was processed by loop 5104/5108, the size of the aggregations and conflict resolutions was completed. What is left of the control is passed from block 5108 to block 5110 and beyond may be considered as a 'bookkeeper', or cleaning procedure that must be performed in order to allow the aggregate application program to operate smoothly on structures of data.

First, in block 5110, the highest level objec- tive is determined in the aggregate structure. In the example of FIG. 2, the highest level object would be the warehouse object 202.

After the highest-level object is determined in vloco 5110, a loop is executed once for each object in the aggregate application program. This object loop, shown with the entry point 5112 and the loop end decercation in the block 5138, has concatenated two loops within it.

According to the convention adopted in the present specification, each " object " can have one or more " fields " associated. The fields specify information about the object. Also one of the characteristics of the object is the connection of that object to other objects. Thus object specifications can include information such as the description of what features an object has, but also includes its relationship to other objects. Such relationship indicator specifications are called " links " with the standard adopted with respect to the SGA. 2.

Two concatenated loops 5114/5122 and 5121/5130 within the larger object loop 5114/5138 are arranged in series manner. This arrangement of series loops is based on a preferred arrangement in a " structure file " (See Appendix A) In a preferred arrangement of a structure file the lines of the file representing described fields are positioned before the lines of the file describing the links. This arrangement is not necessary to all embodiments of the invention, but is preferred by its organizational simplicity. The 5114/5122 loop is executed once for each descriptive field in the object. Shortly thereafter, the 5126/5130 loop is executed once for each binding on the object. Completing field and link processing on the object allows the object to be fully loaded with 5134.

Referring again to loop 5114/5122 the length of each field box is calculated at 5114. Briefly, a " box ", in the state that " box field " can take Each has an external name and a corresponding internal value. The length of the box field is thus simply the maximum length of the external names for all boxes.

So the memory space for each field has to be placed in each register. (A " record " is a particular instance of the object, and may contain particular data defining those particular instances). The space-

is placed so that when private data is received, sufficient memory has been set aside in the register to support it.

The fields are memory spaces allocated relative to the start of the record. The fields are advantageously located in a predetermined order in the register. When the length of all fields is calculated, then the total length of the record is calculated to make memory allocation. The length of each field is determined by the field type. For example, space allocated to a single character, or to one is determined by the length of character multiplied by the length of the string, then the length of the pointer (address) determines the space to be placed. If the field types are integer, large internal or floating-point numbers, the length of 16-bit, 32-bit floating-point numbers or the 64-bit IEE standard can for example be used to determine the allocation of space. In instances where the field type is a '' box " (one stored in multiple states), then the length to be allocated is determined by the tag. If the field type is a reference to a function, the space to be allocated is determined by twice the length of an integer. An integer is the application number; the other is the function number in this application function table.

These are examples of allocation of memory space that should take place in blocks 5116 (FIG 5A). Additions to and modifications of the described field types and corresponding memory allocation methods may be made by those skilled in the art while still remaining within the scope of the present invention.

Finally, any fields that are defined by means of the system formula (i.e., the particular content of the field data is to be determined as a function of the data content of another field) are compiled in 5118. After these functions have been executed for each field in the object, then the control passes the loop 5114/5118 along the path 5124 to enter the loop 5126/5130.

A loop is executed once for each link and involves the allo-cation of space for each of those links. Various means of allocating links are within the scope of the present invention. For example, different objects may be linked having the address of a first member object present in the owner link specification. The first member object may have space not only allocated to a pointer at the beginning of the owner object record, but may have a pointer to the beginning of a second member object record. The second member can have the address of a third object member (in addition to registering owner objects), and so on. (As shown in PXG 2, the " warehouse object " 202 is an owner object with respect to the " gondola " object member 204).

Whichever connection mode is chosen, space is allocated in block 5126. However many connections are present on the object determine the amount of space allocated for the specified connections.

Finally, after all fields and lengths in the record have been processed (and therefore space allocated) in loops 5114/5122 and 5126/5130, then the total object size is calculated or 5134.

This whole calculation of the total size of an object is used to reserve space for the objects during program operation.

When the total size of a given object is calculated, loop 5114/5138 is repeated until all 62-

objects in the application program have been processed. After the last object in the aggregate application program has been processed, the control passes path 514 (SIP.5) to the other loading and aggregation procedures. 2. Load Guiders Input and Output Devices FIG. 5B is an illustration of a flowchart illustrating the process by which the input and output device guiders are loaded and aggregated and subsequently processed.

Generally, each application program can provide one or more input or output devices with their support functions identified by a number. After loading, the functions themselves are based on that number. Then output devices for texts, graphs and reports are decided, based on the capabilities of the candidate devices.

Referring more specifically to FIG. 5B, the control passes the path 514 to enter the loop 5204/5206/5208. This loop is executed once for each application program. The function of the loop is to load and aggregate the input device and output device drivers. This is briefly achieved by reading one or more guiders from a guideline file (XXX.DEV) of each application program. Each output device is added to the list of output drivers and each input device driver is added to the list of input drivers. -63-

After the device guiders of all application programs have been loaded and aggregated, the control passes from the loop to 5208 to enter blocks 5210. The function of Block 5210 is to find the functions that are referenced in the device's guiders. At this point, these functions are to be found in the executable file of the application programs. Finding the functions allows the description of information in the list of devices to be connected to the current steering functions.

Finally, an output device is determined by default, as indicated in block 5214.

The means by which the default devices are determined are as follows the list of output device advisors is prescribed to find an advisor that can handle the needs with an interactive screen session, and if there are many, it will choose the one that has the best stamping (screen resolution and color depth).

The control passes along the path 518 to enter the block 520 (FIG 5) related to the loading of the BDTs * 3. Charging of BDT guiders FIG. 5C is a flowchart illustrating the process by which the BDT guiders are loaded, aggregated and subsequently processed.

Generally, each application program can provide one or more types of Batch Data, with its number-referenced response functions. After loading, the functions themselves are found based on the number.

Referring more specifically to PIG. 5C, control passes along path 518 to enter loop 5304/5306/5308. This loop is executed once for each application program. The function of the loop is to load and aggregate the BDT advisors. In summary, this is achieved by reading one or more BDT guides from the file (XXX.BDT) of each BDT application. Each advisor is added to the list of BDT advisors.

After all the device guiders of all application programs have been loaded and added, the control passes the loop at 5308 to enter Block 5210. The function of block 5310 is to find the functions that are referenced in the BDT guiders. At this point, these functions are to be found in the application executable file. Finding the functions allows the description of information in the BDT list to be linked to the current orienting functions.

Finally, the control passes the path 522 to enter the block 524 (FIG.5) related to loading the displays. 4. Charging of displays FIG. 5D is a flowchart illustrating the process by which the displays are loaded, aggregated and subsequently processed.

Generally, each application program can provide one or more viewers. As they are loaded, later applications can be updated or modify the viewers already provided, as well as add new viewers.

Referring more specifically to Fig. 5D, the control passes off path 522 to a loop 5404/5406/5408. This loop is executed once for each application program. The function of the loop is to load and aggregate the loops, viewers and fields of the viewers of the various application programs. In summary, this is achieved by reading one or more viewers and viewer fields from each viewer application file (XXX.VIE). Each new display is added to the list of internal displays with their fields. An application can modify or append to a display of another including the same display by name with different information than it will then write over (or partially write over) the original according to what information is given in its viewer file.

After all displays of all application programs have been loaded, the control passes from the loop to 5408 to enter block 5410. Block function 5410 is to find the displays that are sequenced in other displays. One time when a virus references another display, for example, is when a viewer describing how an object can be drawn wants to trigger the drawing of objects of lower level. Peace this by referring to the viewer that describes how this lower-level object is drawn. The viewers that refer to each other are then connected.

In subsequent block 5414, references to functions by number are also found (drawing functions). In summary, a " drawing function " is a function that given a record of that object can draw it (as one or more blocks) based on the fields in that record. In block 5416, the maximum number of " pages " for each display is determined in -66-

countering the reference page of the highest display number. A " page " is a collection of fields a screen full screen that fills the screen. The user can then swap eHtre pages to view and change fields (a record) that would fill a screen.

In block 5418, referenced fields and links by name are found in structures.

Finally, the control passes along path 5426 to other blocks 528 (FIG 5) relating to loading menus, key lists, macros, and event lists. 5. Loading Menus, Key List, Macros, and Event Lists FIG. 5E is a flowchart illustrating the process by which the menus, keyboard lists, macros and event lists are loaded aggregated and subsequently processed.

Generally, each application program can provide one or more menus, keyboards, macros, or events. Later application programs can update or change menus, key entries, macros, events that had already been provided, as well as add new ones. Menus, keystrokes, macros, and events that refer to each other are connected. Finally, all macros are compiled in an internal form for faster execution. -67-

Referring especially to PIG. 5E, control passes along path 526 to enter loop 5504/5506/5508. This loop is executed once per application program. The function of the loop is to load and aggregate the menus, keyboard lists, macros and lists of events various application programs. Briefly this is achieved by reading one or more menus, key assignments, macros and events from each application menu file (XXX, MEN).

Each new menu is added to the menu list. The same process is followed for key lists, macro lists, and event list. An application can modify or add to another menu including the same menu by name with different entries that will then write over or add to the original menu.

After the menus, key lists, macros and event lists of all application programs have been loaded and aggregated, the control passes from the loop to 5508 to enter the 5510. The function of block 5510 is to find the menus that are referenced by another menu entry. An example of when such a reference can occur is when a menu entry leads the user to a second level of menus.

The following blocks achieve the interconnection of the various menus, keys, macros and event lists as achieved in the above-mentioned embodiment. It is immediately apparent that the particular arrangement of interconnection, or the addition or deletion of certain of the interconnections, for particular applications, is within the skill of one skilled in the art without departing from the scope of the invention.

In block 5512, any macros that are referenced by the menu entries are found. At this point, macros can be found in the -68-

macros (described above).

In block 5514, any menus that are referenced by private keys are found.

In block 5516, any macros that are referenced by particular keys are encountered.

In block 5518, the macros are compiled to run faster.

In block 5520, macros that are referenced by particular events are found.

Finally, the control passes the path 530 to enter the block 532 (FIG.5), related to loading the BDS guiders.

6. Loading BDS Guiding Devices Fig. 5F is a flow chart illustrating the process by which BDS guiders are loaded, aggregated, and subsequently processed.

Generally, each application program can provide one or more BDSs. Once references to BDTs are loaded, references to objects, fields, and links in the structure and references to the BDTs are found. viewers.

Referring more particularly to Fig.5F the control passes the path 530 to enter a loop 5604/5606/5508. This loop is executed once per each application program. The function of the loop is to load and aggregate the various BDS application programs. In summary, this is achieved by reading one or more BDS from each BDS application file (XXX.BDS). Each BDS is next to the internal BDS list.

After all BDSs of all application programs have been loaded and aggregated, loop control at 5608 to enter the block 3610. The function of block 5610 is to find the BDTs that are referenced by the BDSs. At this point, the BDTs can be found in the list of BDT already read (Fig.5C),

In block 5612, any objects, fields and links referenced in the BDS criterion (in the BDS table, Fig * 12) will be found. At this point, objects, fields, and links can be found in the aggregate structure (Fig. 5A).

In block 5614, any displays that are referenced in the BDS will be found. At this point, viewers can be found in the viewer list (Fig. 5D).

Finally, control along the path 5634, to enter the block 5636 (Fig. 5) the main analysis area. -70-

Fig. 5G is a flow chart illustrating the main analysis loop according to the preferred embodiment. The main analysis loop of Fig. 5G is entered upon completion of the loading process of the application program 500, (Fig. 5).

If the program is in map mode, then the map details are arranged according to user specifications in block 5708. For example, the map is prepared to start from the first record in the list and the leftmost field . The " sorting list " block 5712 performs the sort order of the list of records according to the details given on the current display. The map is actually drawn in block 5714. The analysis loop itself starts at block 5716, in which the cursor is drawn (or redrawn). In the preferred loop of analysis, various tests are performed on blocks 5718, 5728, and 5738. The three tests are: (1) If a chain is running in height; (2) If an event is due, and (3) If a key (or mouse button and so) has been polluted.

If any of these conditions occur then the control passes through the respective branches 5720, 5730 and 5740. The processes found in these contingent branches are similar, in which the functions (or sets of functions)

such as 5724 (macros), 5732 (events), and 5746 (keyboards). Also, once their functions (or function sequences) have been executed, any return codes produced by the functions are processed, as shown in blocks 5726, 5736 and 5748. It is possible that some features of the added application program have conflicts resolved at the time of running, rather than during the initial loading and aggregation process (SIG 5). A choice of a feature that can advantageously have your conflicts resolved at the time of running are the keys. Such exemplary conflict resolution is indicated in block 5741 (SIG 5G). Because this is a very special case will be described below in greater detail, in the reaction on keyboards in running height, conflict resolution. The. Return Code Process

This subsection describes exemplary return code placements and describes the action to be performed on blocks 5726, 5736 or 5748 (FIG.5G) if the return code data is initialized.

In this specification, a return code word comprises a set of bits which are returned by a function of an application program after execution. The following is a description of return code bits that are present in the preferred environment.

Ineffective: if in use, this bit means that the function was not executed. One possible reason for the function not being executed was that, for example, the function could only be executed meaningfully if the aggregate application program was present in the " map " in mode, when in fact it was in " model " mode. Preferably put the ineffective bit into use " causes the loop to parse to continue despite the non-execution of the function.

Check Log: If this bit is put into use, the " log routine " is invoked. In summary a " verification log " the function performs the function of calling the function (specified in the structure for each object) supplied by the user to make any application-specific checks.

Reset Drawing / Scale / Cursor / Map: This bit, reset in use, causes each of these sets of current variables to be reset to their state before the command has been started. This replacement of variables ensures that manipulation in the functions of these variables does not adversely affect other uses of the values of these variables in other routines.

Rearrange the map: This bit, if put into use, causes the map information to be rearranged according to the details on the current display.

Next · · key: This bit causes the subsequent placement of the chosen ones of the following redesign codes until a key is loaded.

Redrawing the imaget (Meaning only in the " template " mode) causes the redrawing of the image of an internal representation of the three-dimensional object, of the previously drawn image.

Redraw Data: Causes an entire image to be redrawn from the original data.

Redrawing the registry: causes only a private registry to be redesigned.

Re-stamping: causes the screen to be re-stamped from a stained copy of the image. B. Conflict resolution on keyboards at the time of running

In the preferred embodiment the key conflict resolution is performed at the time of running in block 5744 (FIG.5G). In order to eliminate ambiguities, it may be preferable in many aggregate application programs to first translate the key in the list to uppercase. A loop is then entered where the entries in a key list are processed compared to the key symbol. Throughout this discussion, the word " key " is used as a shortened rotation for a signal of an input device of any conceivable type, here known, or after developed. For example, the inputs of a bar code reader, presses on a " mouse " button, movement of a " spot " and so on does within contemplation of the present invention. Keyboards are the focus of the present discussion, but the fact that input means is often used in the preferred embodiment does not limit the scope of the inventive principle exemplified herein. The list of keyboards according to the preferred embodiment may be designed as a map having four columns. An exemplary key list is shown in FIG. 6 and illustrates the association of keys with particular functions, menus, or macros. The leftmost column is a list of keys of the various individual application programs that can connect end-to-end. The second column is a lis-

is to be performed in response to the corresponding keys in the column. Advantageously, a number to the left of the decimal point in the reference function refers to the application program, and the number to the right of the decimal point refers to the particular function in that application program. The third column in the list of keys is the " menus " column. If a particular key is the one invoking a menu, then the menu name appears in the menu column still of the particular key entry.

Finally, the name of a macro to be executed in response to a particularly primitive keyboard can be found next to the key in the right-most position of the " macro " column.

There may be entries in none, one or more than one of the three columns labeled " function ", menu " and " macro ".

This merely exemplary key list represents in the abstract a preferred means of implementing and explaining a key conflict resolution method according to the preferred embodiment. For example, other key lists can be formed in which lists of different application programs are not linked end to end, but not ordered from one another by one for particular purposes.

Key conflicts arise when the same key appears in different applications but has different functions, menus, or macros associated with that key in the respective application programs. One such example, shown in FIG. 6, may occur if the " escape " (ESC) appears in both application programs number 1 and application program number 2. In this case, ESC would appear twice in the " keys " column. In addition to the first occurrence of the ESC character. can in its functions 1.7 of a first application program. Furthermore, the second occurrence of the ESC character may be a second function 2.8 of a second application program.

Turning now to how key conflicts are resolved at run time, the key conflict resolution routine examines the contents of the added key list. In a preferred embodiment, the key list is examined from top to bottom. However, other ordering and examining sequences of the key list entries are within the contention of the present invention.

For example, each of the key inputs can be given a " priority " which is a number from 1 to about 10,000 in the preferred embodiment. The aggregate key table is sorted by this priority so that the highest priority keyboard input goes to the top of the table before execution. This arrangement advantageously gives control writers control over how to resolve key conflicts.

In the consolidation shown in FIQ. 6, the entries in the three columns to the right of the keys are examined.

First, if there is an entry in the " menus " column, the following process is performed. If there is a pre-menu function (ie a function and a menu via entry in a Key List line), then the function is called. If the function execution causes the menu to be inhibited (prevent its operation), then the menu is not executed and the next line in the Key List is examined. If the function does not inhibit the menu, then the menu is activated so that the subsequent functions or sequence of functions are called. A return code from the menu system is then processed. -76-

This ends the description of what happens if there is a menu entry in the key list. If a macro is macro is present in the key list, macro execution is then started. The return code of the completed macro is then processed according to the principles described above in the section on " return code processing ",

If a function is present in the key list, then the processor checks to see if the function exists. If fading does not exist, then the next row in the Key List is processed. If the function does not exist, then the " function only for description ". 0 call the " function only for un-creation " the function is stamped to the user (the stamping is only in the menus ") so that the user can abort the execution. A description effectively comprises a help commentary to an active user, which is a self-documenting feature of the functions according to the preferred embodiment. If some automatic feature in the software chooses to abort the function prior to its execution, then the function can be rendered "ineffective" even at this early stage. The function is then checked for " invalidity ". The short excerpt, " invalidity " means that the function itself returns a code meaning that it is invalid in the present context (returned from a call to " description only " described above).

If fading is invalid, the current line in the key list is skipped and the next line in the Key List is examined. If fuzz exists and passed the above tests, then the function is called for execution. Upon execution, the return code is processed according to the description of the Return Code Processing above. Final-

the control loops come back as if to check the next entry in the key list.

In the preferred embodiment, this loop is executed until all entries in the list of keys have been examined. The foregoing description is provided to represent a substantial optimum blend of user friendliness, efficiency and friendliness and has been especially adapted in application programs for space management. However, variations and adaptations of the preferred embodiment to other applications are within the scope of the present invention, as defined by the appended claims.

If the list lines or keys are arranged differently, so that their processing takes place in a different order, for example, so the effective means of resolving the key conflict would be different. Given the above description, however, one skilled in the art is prepared to practice variations in preferred embodiment. The above description describes a process in which this function is performed which was first found in the Key list associated with the preferred key. In addition to choosing a different means of joints or intermediaries the entries in the Key List, such other means of solving key conflict resolutions includes giving each key code table a priority number and executing the key function first priority where there is a conflict. -78-

Β. Ο Batch Data System Fig. 7 depicts the relationship of the batch data system 701 with another portion of the U.C. 720 and exemplary external data stores 736, 738, 740 and 742. Fig. 7 also schematically depicts the relationship of BDS 702 (Source Data Systems) and BDT's 704 (Batch Data Types).

A batch data source (BDS) such as modules 706, 708 and 710 is a higher level software module than BDT's 712, 714, 716, and 718. BDSs specify controls on how the transfer is to be dealt BDS may include information such as by anticipated (or user-specified) use of file names, direction tables, update or write-up specifications, data filters (general, record and field level) , as well as modifiable references to particular BDT1s.

The batch data type modules (BDTs) 712, 714, 716 and 718, on the other hand, are each a device-specific software module which, in the preferred embodiment, handles much less selectively with untreated data going from and for external data storage types 736, 738, 740 and 742.

As a rule, it is the purpose of the Batch Data System to effectively, efficiently and flexibly carry out the batch data transfers. Generally, a batch data transfer occurs between the U.C.P. and an external data storage type. Such data stores often include files on a disk connected to a computer system on which the computer is resident,

Operating environment according to the preferred embodiment. For example, a text file 736, a database file 738, or an ASCII file 740 are often used as examples of data files found in space management in application programs. However, it is well within the scope of the preferred embodiment that the data of a manipulated computer (shown as element 742 in Fig, 7) can constitute a data storage for which the Batch Data System can communicate. Further, the data files in external main computers (not especially those in Fig. 7) are data stores with which the batch data system can communicate.

Finally, the batch data system according to the preferred embodiment may transfer data from a portion of the U.C. to another part of the memory of the U.C.P., although one of the portions of the central memory is in the space placed to the Operating Environment. The or portion of the CPU memory, from which the data is transferred, is considered (for the purpose of the transfer) to constitute the " data storage " which corresponds to the external " external " 736, 738, 740 and 742. 1. Interaction of BDSs with BDT1 s

7, BDS 706, 708, 710 are shown in juxtaposition with BDTs 712, 714, 716 and 718 in the Batch Data System 701.

Each of the individual BDSs in the BDT block 704. The particular correction shown in Fig. 7 is a

in which the BDS 708 is connected to the BDT 716. This connection enables a batch data transfer between an ASCII file 740 and the UCP 720 memory. The BDS 708 could have been so easily connected to other BDTs, such as 712 , 714 or 718 so that the data can be transferred between the UCP memory 720 and the text file 736, the database file 738 or a manageable computer 742, respectively.

Similarly, the BDT 716 could have been easily connected to other BDSs with 706 or 710. The present invention contemplates the possibility of transferring data from the portion of the memory of the CPU 720 allocated to the Operating System to or to another section 750 of the memory of the U.C.

This is achieved through an interconnection indicated in path 726 (Fig. 7). The representation of the BDS and BDT interaction is schematic in nature. The current flow of program control in the embodiment is described in more detail below with respect to Figs. 9, 10, 11, 11B and 11B1. For the present discourse, it is important to understand that each BDS, corresponds to a high level specification of the information that the user wishes to transfer to and out of the UCP 720 memory during the execution of the aggregate application program. Such high-level specifications can include which objects, sets of objects, fields, or sets of fields that you want them to be transferred. Of course, you do not need to be aware or appreciate that you are dealing with " objects " or " fields ". Preferably, everything you can consciously know about, during an interactive session

For example, he wants to transfer a set of retail prices (fields) to a predetermined set of consumer products (corresponding objects) that are on a given shelf (an object) a given gondola (an object) a given warehouse (an object). Thus, although this specification states that the user " try " BDS does it in a way that is understandable to him. The user does not " try " the operation of BDTs. Whatever BDS (such as 708) invoked and / or defined by the user effectively shields the user from dealing with any of the BDT specificities (such as 716). This is one of the advantages of the invention.

Another advantage allowed by the flexible interconnectivity of BDS and BDT is that when a new .744 external data storage is to be added to the system, all that needs to be added to the software is a new BDT 746. If it were not for the flexible interconnectivity of the various BDS with the various BDTs, then (assuming there are only three BDSs, 706, 78 and 710) the artist would first have written batch data transfer software into three modules: modules that perform the tasks accomplished by 706/746 and 710/746.

Using the present invention, new low level specific BDT software. can be added without making any modifications to BDS. This is of great use, especially since the characteristics of many BDSs are interactively defined by one used that has potentially little " literary computational habilitation ".

A typical BDT (for example, one dedicated to a 736 text file) would have had to match the format of the text file. For example, you would need to sort the labels for the columns, the nature and ordering of the entries according to the text, and the conventions adopted to reference other entries in the text if the system formula were used. The ability to perform a rational means of transferring data to and from such a text file is within the skill of one skilled in the art.

The details of how to write from the transfer software of the current file need not be detailed here, insofar as such a particular task, of and for itself, is not at the heart of the present invention. Previously, the flexible interconnection of BDS and BDTs represents a single issue in the field of known single identity software systems in which both the high level and low level functions have to be modified and recompiled whenever a data storage with a new format is to be added.

Referring to FIG. 8, a map showing a typical set of BDS data modules is shown.

In the leftmost column, the BDS name is displayed. In the column immediately to the right of the BDS name is the name of BDT that is currently connected to the corresponding data BDS module. The interconnection of BDT and BDS software modules previously shown in FIG. 7 may be interactively modified from the information into any of the leftmost columns in FIG. 8. These simple and effective means of reconceptualizing the relationships between the BDS and BDT modules proved to be effective in applications

When the preferred embodiment is used, many variations may be practiced by one skilled in the art without departing from the spirit of the present invention. Any means by which a BDS can be flexibly interconnected with a BDT software module is contemplated by the present invention. The third to fourth and fifth columns to the left of the map in FIG. 8 reflect the value of three important guards to the transfer process. The Management Guard, New / Add and Update, not only upgrade and its functions in directing the operation of the batch data transfer process are described in more detail below in the subsection entitled " 0 Transfer Process BDS Data ". The sixth column on the PIG map. 8 shows the user's specification on how duplicate records (that is, occurrence of the same object with duplicate keyfields) are handled by the system. The seventh and right-most columns of FIG. 8 reflects the specification of which objects are to be transferred. The meaning of the specifications in these two columns will also be described in more detail below. The seventh column of FIG. 8, entitled " objects ", shows what objects are to be transferred and whether the user should have some interactive control during the process. See discussion of FIG. 8 below, in the subsection " 0 BDS Data Transfer Process ". The eighth column of FIG. 8, entitled " orphans ", shows how to handle objects that can be given with incomplete information links. (See subsection titled " The Routine of Data Reading). The ninth column of FIG. 8, titled " target format ", shows whether to use a structure that is already in the destination, a copy of the internal structure, or another one separately specified, " template template " structure. (See description of block 1126 below, in the description of Figure 11.). The tenth column of FIG. 8, entitled " Stamping " shows if the used ones should be given a stamping on the screen describing the transfer and also if the errors during the transfer must be shown or ignored.

The eleventh column in Fig. 8, titled " drive file ", shows the file to use for download or a " meta-character " specifying a set of files that the user will choose. The map of FIG. 8 is presented as a non-limiting example of the use with which the data transfer, the process, can be directed by the user. The contents and arrangement of the exemplary map in FIG. 8 should not be construed as defining features which are necessary for all embodiments of the invention. Certain features may be listed and others not explicitly described herein may be present and still fall within the scope of the inventive concept of flexible interconnection of high level software modules with low level link routers. 2. The BDS Data Transfer process

Referring again to FIG. 7, the process by which the data is transferred between the U.C.P. 720 and an extensive data storage type such as the ASCII file 740 will be described herein. Most of this description will respect the way the functions are placed in typical BDS and a typical BDT. FIG. 7 is schematic in nature. Although BDS 708 and BDT 716 are properly designated as separate software modules, the control is passed between the two modules repeatedly through a typical data transfer in the preferred embodiment.

This repeated passage of control will now be described. 85-

/

Referring to PIG. 9, a basic flow chart of the BDS transfer process is presented.

In PIG. 9 (as well as in the figures that follow) blocks such as 908 and 958 are drawn with double lines on the right and left sides of the blocks. The double lines indicate that the function is substantially performed in the BDT. A block that does not have double lines on the right and left sides of the block indicates that the function is performed substantially on BDS. A block having dotted lines on the right and left sides is concurrently executed on BDS and BDT, the control being shared between the two modules.

A transfer is invoked by, for example, a user entering a command that requires additional information to be sent to or from an external data device or a " RAM disk " (or blocks of UCP Memory, a multitasking environment). On this transfer invocation, the contents of the control pass the path 902 to block 904.

At block 904, the transfer type is determined based on (in the preferred embodiment) three different quars in bits. Briefly referring to FIG. 10, five transfer types which are especially useful in the top columns of the preferred embodiment on a map. The value of the guards of three different guards defining each type of transfer given are listed on the map. -86-

GUARDS

The three guards have the following meanings: DIRECTION: A direction guard having an "inside" value means that the transfer is to be from an external storage device or (" disk " RAM ") to the CPU memory . Your address guard has the value " outside ", then the direction of the data transfer is outside the Memory of the U.C. for the type of data storage. NEW / ADD: This guard (if " new ") determines that the data in the destination file is erased prior to transfer. " UPDATE / NOT ONLY UPDATE ": This guard (if " UPDATE ') determines that only records with keys matching those of pre-existing data records update pre-existing data records, which data entry records that do not have matching keys from other pre-existing records are ignored. TYPES OF TRANSFER:

Five transfer types useful in the preferred embodiment of the present invention may be described as follows. LOAD: Causes all information currently in the CPU memory to be erased. New data will be -87-

transferred. INTERCALATION: The information presently in the memory of U.C.P. is left intact and new data is added to the existing information by batch data transfer. The interleaving type transfer is followed during loading and aggregation of the various characteristics of the application programs (SIP 5). UPDATE FROM: The currently existing information in UCP memory is left intact and some new data is transferred from data in batches. However, the data is only transferred to the records if those records already exist. If the data in the batch data transfer is followed for nonexistent records, this data not required is not written in the U.C. UPDATE TO: Causes a data transfer from the memory of the U.C.P. The information presently existing in the target data store is left intact. Any data in batch data transfer that does not write over that data pre-existing in the data store is allowed to be written to the data storage type. STORE: The data in the data store is erased and the data of the memory of the U.C.P. is transferred to the external data store.

Referring again briefly to FIG. 8, on the duplicate media most specifically specified in the sixth column, for each BDS listed in the first column. The preferred embodiment encompasses a duplicate handling system that solves conflicts in a variety of ways. First, the overwrite option erases an existing record to make room for all fields in an input record. The option to write over the fields allows only the fields that are transferred to be updated; 88-

the other fields that will presumably not be updated will be left unaffected by the transfer. The LEAVE option treats existing records as having a higher priority than the input records data. In this option, the cynical data of the information that is allowed to be written is the one that will occupy registries previously non existent. The COPY option can be followed so that in the event of a conflict between records or fields, the descriptive identifier of the input record or field is modified, and the preexisting new record or field is inserted under the previous descriptive identifier.

These are only examples of ways contemplated by the present invention by which duplication conflicts can be resolved. The column titled " Objects " in FIG. 8, indicates three options that are among those present in the preferred embodiment to show which objects to transfer. ALL: The " all " indicates that all objects are to be transferred. That is, no filter is to be run on batch data transfer. LISTINGS: The " Listings " indicates that only objects that are listed in a pre-determined field (accessible and modifiable through > menu system, for example) are not to be transferred. SELECT: The " select " indicates that the user can interactively select the objects that are to be transferred immediately prior to the transfer itself.

Turning to FIG. 9, after the transfer type has been chosen as described above with respect to guards values in FIG. 10, the external data file is chosen in block 906. This external choice of file is determined (explicitly or implicitly) by the choice of user information that it wishes to transfer.

If there is an ambiguity the user can choose promptly from one of the possibilities.

In block 908, the " INIT, BDT " is called. This routine resides in the BDT itself, initializes the BDT for the transfers. For example, a BDT database would need to be " opened " before any transfer can be made.

The blocks indicated as 910 and 936 represent the determination of the structure (as understood in Figure 2) of batch data transfer. This determination is described in more detail with respect to FIG. 11 below. Briefly, labeled sub-block 910 (FIG. 9) relates to more automatic transfer structure determination characteristics. Conversely sub-block 936 respects the determination of specifications for objects and fields to be transferred which may be more data dependent and therefore are more user-facing (than automatic).

In block 954/956 data transfer is performed including resolution of any conflicts.

Finally, in block 958, the routine " BDT CLOSE " is called. This routine carries out the channel closing routine which are complementary to those of routine 908 " BDT INITIALIZATION " described above. In summary, the CLOSED BDT routine performs the functions of, for example, telling a disk controller that the module has finished processing the file or telling a database that it has terminated a transfer, so that it does not situations occur " hung " and that all memory areas are freed for future use.

During the transfer process, if there is a serious problem with the data channel, then the BDT routine may return a fault code to the BDS. Such serious problems can include occurrences when a specific file is not found, there is a physical connection on data connection failure, or a disk is full, and so on. When BDS receives the BDT fault code, BDS can stop the process and mystify the user with a generic failure message or a specific message suffered by the particular BDT routine. After a failure such as this, the BDT closing routine is called to terminate the transfer process. Such events are not specifically indented in FIG. 9, due to its extraordinary nature. However, it should be understood that the BDT closing routine can be entered virtually at any point after the INITIALIZATION routine is performed. The BDS Table.

A more detailed understanding of the BDS Data transfer process may be facilitated if the exemplary BDS table in FIG. 12 is understood. Of course, variations and modifications of the exemplary BDS Table may be made by those skilled in the art, while still remaining within the scope of the present invention.

In summary, it is a function of a BDS table describing the characteristics of the type-independent air-

of a data transfer to or from an internal memory storage. FIG. 12 is a drawing on how the configuration of the inputs in a BDS are stored internally. Many of the inputs are positionally " one-time " which apply to the entire BDS. Other entries can be positioned for each object listed in the BDS. The sections describe links (1 to 11), showing, for example, that each BDS can have many BDS OBJECTS. The meaning of significant terms in the BDS table are described elsewhere in this specification.

More specifically, the level of the blocks labeled " BDS " specify inputs made once for each BDS only. The arrows pointing to the BDS entries indicate many BDS OBJECTS that can be supplied in each BDS. The level of the BDS table labeled " BDS object " specific entries made once for each BDS OBJECT. The arrows starting from BDS OBJECTS, going to the BDS CRITERIA, indicate

many BDS criteria that can be met with each BDS OBJECT. The level of the BDS Table labeled " BDS Criteria " requests one-time entries for each BDS Criteria. The BDS table level tagged " BDS field " specifies one-time entries for each BDS field.

With this understanding of the BDS Table, the BDS Data Transfer Process may be more readily understood, FIG. The overall view of the BDS data transfer process shown in FIG. 9 will now be described with greater specificity with reference to FIG. 11.

Referring to FIG. 11, blocks 904, 906 and 908 perform the functions as described above, with respect to Fig. Block 1110 indicates that the control continues along one of five paths, depending on which of the five transfer types are determined at block 904. While block 1110 indicates that a single branch is executed, such centralization of the branching is not required to implement the invention. For example, a single master path may have a series of individual tests branching out to functions as specific as those indicated at blocks 1124, 1125, 1132 and 1144. It is therefore not a feature of the invention to center the " branch on transfer type " in function, but rather is presented as that to simplify the exposure of the processes involved. Three different names of transfer type blocks 1110, 1138 and 1160 are present in FIG. 11. The five types of transfers having significance according to the preferred embodiment are advantageous those arranged vertically on the corresponding branches for the same type of transfer as for ease of understanding.

Referring back to the branch in the transfer type block 1110, one of the five paths 1114, 1116, 1118, 1120 or 1122 is followed, depending on the type of transfer.

If the three not only updated (direction, new / addition, update) guards determine that the transfer type is " load " then path 1114 is followed. In the preferred embodiment the user is trained to verify that he / she wants to have all the data presently in the memory of the U.C. destroyed so that new data of the external data storage type can be loaded in its place. (If the user does not want the existing data to be written over, then the control follows a path that will get the entire transfer). Assuming that the user checks his / her erasure to erase all data present in the U.C.P. memory, the control follows a path 1125 to " READ FORMAT " in routine presen-

in the BDT.

If the three guards determine that the transfer type is " Merge ", " or " Assay To ", then the control passes through lines 1116, 1118 or 1120, respectively, to the " READ FORMAT " 1134. This routine reading will be described in more detail below.

If the three guards determine that the transfer type is " STORE " then the control passes along path 1122 to a decision block 1126. Based on a 3-way guard called " predefined structure " the control passes along one of the 3 paths 1128, 1130 or 1131, depending on whether a Target, Source, or Scale structure is to be used as a " target " structure.

Destination means that the structure must be read from the existing target file prior to transfer; Source means the internal structure.

In short, a template file is a data file or external bridge of the same type as recognized by BDT as a structure that is used (if DEST = ES-CANTILHÃO) for our external structure. The Scroll file is formed by storing a data file previously, or creating it externally. If the predefined structure is determined by the SCAN FILE, then the control passes along line 1131 to the READ FORMAT routine in the BDT. The read-only routine is run for the ESCANTILÃO file.

If the predefined structure is determined by the source, then the internal data structure of - defined by the contents of the U.C.P. is used. The control passes along path 1130, avoiding the need to call the BDT read format routine. -94-

If the predefined structure is seen to be the target structure, then the control goes through path 1128 to the READ FORMAT IN BDT routine operating on the external file. In summary, the purpose of the read format routine executed either in blocks 1132 or 1134 is to terminate the structure that: is to be expected in the transfer between the BDT and the external data storage type. The details of this READ FORMAT routine is within the ability of one skilled in the art, given a knowledge of the particular type of external data storage (text file, database file, or ASCLI files), someone skilled at material will recognize that the functions that the READ FORMAT routine can do include learn what objects are available, what fields are available for each object, and the type of field. The READ FORMAT routine also provides links between objects.

Without looking at whether the READ FORMAT routine in the BDT was executed at 1132 or 1134, or if it was traversed along the path 1130, control eventually passes to the block 1136. The block 1136 involves the production by BDS (possibly with the help of interactive commands of more specifications for the objects, fields and field criteria that are to filter unwanted data to reach the destination The specifications formed in block 1136 can be thought of as extra high-level filters in the data that could otherwise be transferred only if the transfer structure determined in block 1135 can be maintained.

In summary, the BDS specifications for objects, fields, and field criteria may be resident in a BDS table. The BDS table is, in the preferred embodiment, interactively modifiable through the interaction of the user. -95-

Such a BDS table is indicated in exemplary form in Pig. 12. Typically, as specified in the BDS table, the criterion to be applied with filter rules comprises an object or field followed by a relation (such as =, &gt;, <), followed by its side by a value. An example may be &quot; product-name = dog food &quot;.

If they were to be the only specifications, then only those objects having a product name of &quot; dog food &quot; would be transferred. Of course, different criteria can be joined using Boolean logic, so that a variety of objects of different specifications can be transferred, for example, using a "&quot; between the different specifications criteria.

There are several options for choosing which objects to transfer, which fields to transfer, and field criteria (limiting which records are to be transferred).

The options for objects, records, and fields are described below. The all option allows all possible objects to be transferred (that is, everything understood as a bridge and target format). The option only allows only those predetermined objects that are specified in the BDS OBJECT list to be trafficked. The CHOICE option allows the user to select the specific objects to be transferred at the time of running. -96-

Records

For each object chosen, the preferred en-corporation allows the determination of which records will be transferred. At this end, a current data filter (such as &quot; equal to &quot; or &quot; less than &quot;) can be used.

In the ALL option, all records for a given object can be transferred. That is, filters are not actually employed. The ONLY option specifies from a predefined list (the BDS criteria list) the field conditions for inclusion in the transfer. The CHOOSE option allows the user to specify the field conditions at run time.

Fields The preferred embodiment also allows a similar filter function to be performed using the TODO, Só, and CHOOSE options that are analogous to those used for object and record filters. All fields, a predetermined list of fields or a specification of fields chosen at the time of running can be employed. The duplicate processing system as described above for registers is also applicable to other levels in a BDS. For example, fields below the logging level and objects above the logging level can also include-

be treated in the same way as described above.

Referring again to PIG. 11 no

Block 1138 is another branch in the transfer type decision. If the directional lock has the value IN, then the control passes along one of the lines 1140, 1142 or 1144, depending on whether the particular transfer type and Load Collate, or Update, respectively. In either case, the DATA READING routine is executed. The DATA READ routine will be described in more detail below, but with respect to FIGS. 11B and 1131.

If the directional guard has the QUT value, then the control passes along path 1148 or 1150, depending on whether the transfer type is to update to or store respectively.

If the transfer type is Stored (Indicating that the data in the extreme storage is to be erased before being transferred to the CPU), then the WRITE FORMAT routine is executed at 1152.

The WRITE FORMAT routine 1152 is resident in the particular BDT. The WRITE FORMAT routine can be encoded by someone skilled in the art, given a particular external storage knowledge that is to be the destination of the STORAGE transfer. Complementary functions are performed in the WRITE FORMAT routine 1132 as they were performed in the READ FORMAT routine 1132 or 1134. Specifically the transfer structure that occurs between the BDT and the external storage is determined here .. Because any previously existing data and the data structure were first erased in the external storage data structure, then the WRITE FORMAT routine effectively forces the data structure to the destination. -98-

The WRITE FORMAT routine according to the preferred embodiment needs to know from BDS what objects to store, which fields to store and the type of fields as well as the details of links between objects. This is all given to the exact WRITE FORMAT -in the same way as the READ FORMAT routine, it is thickened to return them.

No external data structure should be positioned if the transfer type is ACTUALI_ ZAR TO, so that the WRITE FORMAT routine is exceeded in this case, as the control is passed by path 1148.

Regardless of whether the Update to or Store transfer type is invoked, the control passes to the WRITE DATA routine 1156. In this block 1156, the data is in fact transferred from the U.C. to the target data store. The data writing routine is described in more detail below with reference to FIQ. 11A.

When the data transfer is complete (either in the CPU memory by the DATA READING routine 1154 or out of the CPU memory by the data writing routine 1156), control passes to the DATUM routine of BDT 958. The closing routine of the BDT functions as described above, with particular reference to FIG. 9.

Although the data transfer itself is technically complete after the BDT FOLD routine 958 has been terminated, some tasks are advantageously performed in the event of a transfer into the U.C. Block 1160 is a branch in the transfer type decision block in which the steering guard has the value IN (indicating that the type of transfer must be either Loading, Interleaving, or Updating From), then the control has to pass along path 1162, 1164 or 1166, respectively. When control passes along one of these three paths, any formula-based fields (those field compounds whose values are defined in terms of values present in other fields) are calculated in block 1172 prior to subsequent processing. After the formula-based fields were calculated at 1172, the control passes out of the Batch Data System by the Transfer routine of these. No formula-based field calculation is required if the direction guard is OFF. In the UPDATE TO and ARMAZE__ NAR transfers, the control passes directly along the path 1168 and 1170 respectively by leaving the data transfer, the used can continue its interactive section, having the data transfer complete. The. Routine &quot; DATA WRITING &quot;.

Referring to FIG. 11A, the DATA WRITING routine is shown in the data flow format. In keeping with the standard established in the previous flowchart in this specification, blocks as 11118, 11124 and 11126 are drawn with double vertical lines - on the left and right sides to indicate functions that are performed substantially within 3DT. Functions that are performed substantially within BDS are shown without double lines on the left and right sides. As can be seen from FIG. 11A, the control is passed back and forth between the BDS and the 3DT even internally for the loop of &quot; field &quot; concatenated within the register loop.

When the DATA WRITING routine is invoked, the control passes the path 11102 to the block 11104. In block 11104, the criteria for a given record is checked. If any of the criteria fails, this record is ignored (not written). Control passes along path 11108 to the next application of block 11104 to the subsequent data log. If all the criteria for the record are satisfied, then the control passes the path 11110 under a loop that operates in each field in the record. ' The field is translated to &quot; type &quot; (such as integer, floating point, and so on) that matches the field type of the intended fields. If no translation is required, translations do not occur in block 11112 and control passes to block 14.

In block 31114, the data in a field belonging to a record having passed all criteria is passed to the BDT WRITE routine for transfer.

A guard of &quot; first record &quot; (or any other means of communication whether it is the first pass through the field loop defined between elements 11112 and 11128) is passed to the BDT routine. A decision block 11118, if it is determined to be the first record in the transfer, then the INITIALIZATION routine for the new record is executed in the BDT in block 11124 for the new record. In summary, the INITIALIZATION routine performs the function of starting the BDT for a transfer. (For example, a database BDT would need to be &quot; opened &quot; before any transfer was performed).

After the INITIALIZATION routine is complete (or if it is not required because it is not the first record), then the control passes from block 11124 or directly along path 11122 to block 11126. Block 11126 represents the current transfer of values of the BDT fields for the external data store. 101-

The loop defined by blocks 11112, 11128 and 11130 is repeated for each field within the register.

Upon completion of the field loop for the last field in the register, control passes the path 11134 to decision block 11136. Decision block 11136 determines when the last record has been transferred. As long as there are more records to be transferred, control passes back along path 11138 to register criteria check block 11104. When the last record has been transferred, the control passes along path 11140 to exit the WRITE routine of DATA.

This description of the data writing routine is made an advantageous choice of field arrangements in the registers. This advantageous arrangement has proved to be effective in the preferred embodiment, in the variations ai &gt; for example, sequential processing of fields of different registers is within the scope of the present invention, although the efficiency in the development and execution of preferred embodiment dictates the concatenation of field loops within the loop of registration. B. The routine of &quot; DATA READING &quot;.

Referring to PIG. 11B, the DATA READING routine is illustrated in flowchart form. &lt; In summary, much in the same way as the DATA WRITING routine, the DATA READING routine present, comprises a loop concatenated in a register loop. The DATA READ routine is invoked at 11202 and control passes to the start of the register loop to enter the block 111204. The block 11104 passes the control to the BDT, where the object name for the present register is determined by the storage of external data. This object name is passed to BDS.

After the control is passed back to BDS in block 11206, the object is checked against a list in the BDS Table of required objects. In block 11208, the control branches according to whether the object is required. If object is not required. If the object is not required, the control passes along path 11210 and this record is ignored (unwritten). The maximum register will then be examined, after which the control passes along the path 11260 to re-enter the top of the register loop at 11204.

If an object is required to be compared with the BDS tables, then the control passes along path 11212 to the log processing block 11214. Basically, the log processing block may involve space allocations for the registration. Also a pre-insert routine (if any is required for this object) is performed. Such a pre-insertion routine may involve assigning any default values or analogous procedure that are in the library. Although not explicitly indicated in FIG. 11B, the transfer of this record can be passed at this point (and the control returned to block 11204) if, for example, conditions occur that the preprocessor routines determine that no further loading of that object is allowed (for example a DEMO session of a program allowing no more than a certain number of objects to be used).

Assuming that the data transfer was not completed in the register processing block 11214, the control passes to the beginning of a field loop delimited by the blocks 11216 and 11250. The field loop 11216/11250 starts with the BDT will fetch the value of the external storage field in 11216. In block 11220, the field value and field type (such as an integer, floating point, and so on) is determined.

In block 11222, the field is ramified against the criteria in the BDS Table. The criteria of the field can be, if the price (a field) of a particular consumer product, one (object) is greater than a particular dollar value, or if the object identification field is equal to &quot; dog food &quot;; and so on. If the field fails criterion checking, the control passes through decision block 11224 along path 11226 and the rest of the record is ignored. In this case, the control then passes along path 11260 to re-enter the top of the registration loop in block 11204.

If the field passes the criteria check, then the control passes decision block 11224 along command 11228, then block 11230 determines whether the field is required internally. In summary, a test whether a field is required internally comprises the checking of &quot; what field &quot; entry of OBJECT BDS and then find it in the list of BDS FIELDS.

If the field is not required internally, then control passes decision block 11232 along path 11234 so that the present field is ignored. The control can thus be returned to the top of the field loop in block 11216.

If the field is required internally, then control passes decision block 11232 along path 11236. Then a translation of a type (integer, floating point, and so on) is performed on the block. 11238, if required. -104-

Then in block 11240, the current value of the field is transferred from the BDT by the BDS to the memory of the U.C. After the current transfer is complete, it is determined whether a field is a descriptive field or whether the field is a link. If the field is a link, then the control passes decision block 11242 along path 11246 to block 11248. Block 11248 adds the connection is &quot; family tree &quot;. If the field is not a link, then control passes decision block 11242 along path 11244 to the end of field loop at 11250. Field loop defined by block 11216 and block 11250 is processed once for each value of the field in the record. After the final field has been processed, then the control passes from the field loop by decision block 11250 to enter the end-of-record cleanup routine. 11252. The cleaning routine EOR 11252 is described in more detail below with respect to Fig. 11B1,

After the cleaning FDR routine is complete, control passes to decision block 11254, decision block 11254 determines whether there are more records to be transferred to me. If there are more records to be transferred, then the control passes along path 11258 to the top of the register loop in block 11204. If there are no more records to be transferred, the control passes along path 11262 to routine DATA READING.

In short, a &quot; family tree &quot; is a trace of the complex hierarchy of a register to the top of the data structure so that it can be connected at the correct point. Referring now to FIG. 11B1, the end-of-record cleaning routine (FDR CLEANING) 11252 (FIG. 11B) is illustrated. Although the FDR CLEANING routine is illustrated in FIG. 11B as being after the decision block 11250 terminating the field loop, it is to be understood that the power routine may be placed within the field loop on a branch which has been tested-

if the last connection was being processed * The FDR CLEANING routine is illustrated by the loop for clarity and simplicity as far as it is executed after the final field in the register has been processed. Control passes to the FDR CLEAN routine along path 112102 (FIG 11B1). In decision block 112104, the record is checked to see if all the criteria have been satisfied. Although previous criteria checks may have been found in the past during the field loop interaction in FIG. 11B, and additional test criteria may remain for this FDR CLEANING routine. For example, a test that depends on a function of all the fields in the record can not be run until all the fields have been transferred. For example a function (or is) may have to be applied to a series of fields to determine if any (or all) of them have a certain value. Clearly, in this example, a multichannel verification criterion could have been iteratively executed in field loop 11216/11250 (FIG 11B). The present verification criterion 112104 (FIG 11B1) is only one of several variations in the preferred embodiment which is within the scope of the present invention.

If the verification criterion determines that certain criteria are not met, then the control passes along path 112106, and the rest of this register is ignored. The control passes along paths 112158 and 112162 to re-enter the &quot; log &quot; the end of which is marked by block 11254 (FIG 11B).

If the check criterion in block 112104 (FIG. 11B1) deters that all criteria are satisfactory, then the control passes along path 112108 to block 112116. Block 11210 causes the filling of space in the family tree to be filled according to four methods prescribed in the BDS Table. Four methods for filling spaces in the family tree have proven to be especially useful in applications found by the preferred embodiment. These methods include the following: CONTEXT: In this method, the current position of the user determines whether, for example, the object adapts to the family tree taking into account the current position of the user in the system. For example, if the user is viewing a particular gondola and the entry object is a shelf, the CONTEXT procedure assigns the shelf object to the gondola that the user is viewing. ORDER: In this procedure, the most recent record transferred to the required object determines how the family tree should be filled with respect to the current record. NONE: In this option, no action is taken. That is, there are actually filled spaces in the family tree. HUNT-EVERYONE (Always executed after one of the previous methods): If information is still missing from the family tree, then relatives are created artificially with the name &quot; AUTO &quot; in order to link the whole log.

Whichever method is chosen, the control passes along one of the lines 112110, 112212, 112114 or 112116 to the block 112118. In the block 112118, the spaces not filled by the above methods are filled by substituting. In this way, the register is connected to the internal data structure in a temporary way.

Then, in block 112120, the &quot; keys &quot; are checked to ensure that there is no -107-

is a duplicate record. (As is well understood in the art, a &quot; key &quot; is a set of character to other identifiers that identify only one item). If the object is a duplicate, the control passes through the decision block 112122 along the path 112126. If the present record is not a duplicate, then the control passes through the decision block 11122 along the path 112124. If the original record is a substitute, then control passes decision block 112128 along path 112130. The substitute is then written over at block 112124.

If the original record is not a substitute, then the control passes through the decision block 112128 along the path 11232 to the? The duplicate treatment block 112136 operates as follows.

The best of treating a record that is a duplicate of an original record is based on a choice of a variety of methods of treating specified duplicates of BDS. Four duplicate treatment specifications that have had particular utility in the applications covered by the preferred embodiment include the following: Above-written: A new record is copied over the old record so that even, unmodified, fields, are lost from the original record. WRITE-UP OF THE FIELDS: In this duplicate treatment fields transferred from new input registers are copied to the old fields. This is the only choice with any sense for &quot; UPDATE &quot;, as download. LEAVE: The original record is left intact; the new registration -103-

-V input is ignored. DO DUPLICATE: In this method of duplication processing the keys of the new records are modified so that it is not a duplicate of the original record.

Returning to the discussion of the common case where the input register is not a duplicate of the existing register in the destination, the control passed from the duplicate check block 112122 along the path 112124.

Then, the update guard is checked. If the update guard has the value &quot; ACT-LIZAR &quot;, this indicates that all pre-existing fields must be updated and the control passes along path 112152 so that this registry (not a duplicate of a registry is ignored. The control passes along path 112152, 112158 and 112162 to return to the end of the register loop (FIG 11B) so that the next input register can be processed.

If the UPDATE guard is set to the value &quot; not only update &quot;, then the control passes through decision block 112150 over 112154. In all cases when the input record is a duplicate of an existing record, as well as in cases where non-duplicative input registers were received with a guard &quot; not only update &quot;, the control passes along respective lines 112138, 112140, 112142, 112148 or 112154 to the block 112146.

In block 112146, the new record is linked to the data structure -internal according to the information in the now complete, family tree. After this new record has been connected to the internal data structure in block 112146. Then the control passes along path 112162 to exit the CLEANING routine FDR to reach the end of the register loop. (Figure 11B).

In this way, new input registers will be connected to the internal data structure in accumulation as the transfer progresses. IV: Space Management System, Embedded Software Operating Environment.

Referring to FIG. 13, there is shown a preferred embodiment of a space management system according to the present invention designated generally by the reference numeral 1302. The preferred space management system 1302 includes a space management application program 1304 and the Operating Environment 102, as shown and described above with reference to FIGS. 1-12. The preferred space management system 1302 may be written in C language, although encoding in other languages is certainly within the scope of the present invention. The combination of preferred space management application program 1304 and the Operating Environment 102 facilitates the concurrent execution of additional application programs with the preferred space management application program 1304. This results from the Operating Environment aggregation feature discussed in detail above,

In the prepaid space management system, only the message files are kept routed between the application programs. These are read separately because, as separate files, they allow application programs to be understood in a variety of languages.

As shown in FIG. 13, the preferred space management application program 1304 includes a function finer 1308 and a set of backing files 1306.

Support files 1306 include a frame file 1310, a menu file 1312, a key file 1314, a macro file 1316 an event file 1317, a display file 1318, a batch data source file 1320 and a message file 1322. A second application program 1324 including a set of backing files 1326 is shown with the space management system 1302. The Operating Environment 102 allows the preferred space management program 1304 the preferred space management system being concurrently executed with the application program 1324. A framework file included in the application program support files 1326 1324 is aggregated with the frame file 1310 to form a common data structure. The formation of an aggregate structure is possible by the above described Operating Environment.

It should be understood that a large number of other application programs such as the program 1324 can be concurrently performed with the space management system 1302. The maximum number of application programs varies greatly and is determined according to the size of the memory available from the computer used and the size of each of the application programs. The preferred space management system 1302 according to the present invention provides considerable flexibility by advantageously using the features resident in the Operating Environment &gt; 102. Thus, in the preferred space management system 1302, it is the Operating Environment 102, which compared to the preferred space management application program 1304, which includes many general purpose features, such as functions 124, macro 122 and formulas 138. The flexibility shown by the preferred space management system can be achieved by adapting functions of a known application program either in the application programs 1304 or the Operating Environment 102. Advantageously, the functions added to the operating environment 102 are not application specific, but are generally useful with various other application programs as well.

One advantage of generic utility-type storage functions in Operating Environment 102 is to avoid duplication in various other application programs and to effectively use Operating Environment 102. Space-specific functions are stored in functions 1308 in application program 1304 The preferred criterion used to determine the optimal placement of a particular function is if the function is a space management specific.

For example, if a known report schema allows for a specific field value of product parameters in reports, or generate subtotals, specific internal functions that provide these report schemas are required.

Equivalent features in the preferred space management system 1302 is in the display system 114 resident in the Operating Environment 102. This Display function has much more flexibility in the preferred space management system 1302 than in the known system report functions. There are significantly more options available with the preferred space management system -112-

with the View function.

For example, the preferred space management system 1302 is not limited to product reports, it may instead generate reports at the warehouse level, listing gondolas and sections), and may add user-defined fields constructed of formulas and other user-selected options.

However, the preferred space management system 1302 is advantageously arranged for use by users of existing application programs without being confused by their dramatically increased flexibility. In one embodiment, it is a de facto design criterion to limit the apparent external flexibility of the Operating Environment 102 so that the user would not be overloaded with the number of available options. This limitation of the appearance of flexibility is best achieved using the Operating Environment features to limit the available options. Operating Environment 102 is preferably arranged to such an extent that the field names are stored in structure files and the data is stored in separate data files.

In known Application programs, the user usually has the ability to modify the data files. In contrast, in the preferred space management system 1302, the user can modify the data structure by modifying and adding objects and fields in the structure file 1310. Operating Environment 102 maintains the structure files with the field names separate from the data. This is a distinct advantage over known systems, in which field names were stored with the fields. Thus, to facilitate the clientelization by the user of the preferred space management system. Operating Environment allows the user to modify the structure files. The preferred space management application program 1304 includes Function File 1308 which consists of a plurality of separate functions or function modules that can be connected together. Support Files 1306 are read by the Operating Environment 102 of the same way, sensibly than the data files.

Preferred Data Files 1306 comprise several groups of files arranged as follows. Structure file 1310 implements or defines a data structure as illustrated in FIGS. or 14B.

Menus 1312, keyboards 1314, macros 1316, are stored in the same file in the preferred embodiment; however, could be written in separate files. Macros 1316 is no other way of specifying executable code that can also be modified by the user. The 1317 events are used for specific functions the space management functions. Preview 1318 controls how screens will be, including something in graphics. The 1320 non-spatial data sources of the space management application program specify the logical rules of flowing data into and out of external databases. BDS 1320 determines which information you want to access. Messages 1322 are essentially short programs that provide data for various functions of the Operating Environment 102. These functions may be resident in Operating Environment 102 when they can not be specific to the preferred space management system 1302 or otherwise reside in the management program of preferred space 1304. Messages are accessed by their associated numbers to be able to work in different countries; allow you to specify certain words by number in separate areas; the names can be translated and the system will run the same way. -114-

The 1308 Functions block consists of functions specific to the preferred space management application program. For example, &quot; proportional filler &quot; is a command function to fill a shelf to keep all products on the shelf in proportions. The predetermined functions in Function block 1308 may comprise about 15% of the preferred space management program 1304, although differently indicated in Fig. 13.

Known space management application programs can generally be seen as a function freeze and intermixed support blocks such that there is no flexibility in patronizing the program for users. For example the menu structure may not be modified by non-programmers because it is embedded in executable code. Virtually all modifications required individuals with the skill level of computer programmers to codify the entire application program code to make modifications. In contrast, the preferred space management system 1302 provides for various levels of clientelization that can be achieved by users without requiring computer programmer skills, described below with respect to FIGS. 15A and 15B.

A significant feature is that the Operating Environment 102 allows the preferred space management application program 1304 and other application programs such as 1324 to be independently developed and then integrated by the Operating Environment 102 to run concurrently. Thus, for the user, new programs such as 1324 will appear as an integrated part of the preferred space management system 1302.

FIGS. 14A and 14B illustrate in schematic form (analogously to FIG. 2) exemplary data structure files which may be employed in the file structure 1310 of the preferred space management system 115-

1302 in accordance with the present invention.

Different versions of space management system can be defined that are more complex than any existing session in the market. This choice of space management system allows one to use all the features, flexibility and advantages of the Operating Environment. Some Application programs may have, for example, six objects (as shown in FIG. 2). One session of the preferred space management system has approximately 15 objects (see FIG. 14A) which may be too large for a user to read effectively. The structure of space management system can be much more complex than that shown in the PIG. 2. However, listing this additional complexity makes code shots of known application programs much more difficult and converts them into programs that use all the flexibility allowed with much of the operation of Operating Environment 102. A simplified structure, such as shown in FIG. 14B is desirable in cases where less complexity is allowed or software development budgets are limited. Such a structure includes a core of objects that effectively model the data structure of known application programs having hard coded structures so that the functions of the known systems can be immediately incorporated into the application program 1304 while using the allowable flexibility by design in conjunction with the Operating Environment.

A functional space management system 1302 uses the structure shown in the PIG. 14B. (A difference between FIG 2 and FIG 14B, however, is that the term &quot; gondola &quot; has been modified to &quot; section &quot; &quot; shelf &quot; as modified to &quot; fixed &quot; or &quot; fixed elements &quot; ). The latter is more representative of the capabilities of the preferred current space management system, which has added the ability to consider shelving partitions, gates, fences, and so on.

One reason to add objects to the structure is from different classifications to different things. For example, multiple sections of a warehouse are actually grouped by gondolas, which per se: shift comprises sets of shelves on each side of a wing; a department may have, for example, 6 wings; multiple departments can make a warehouse. The gondolas the shelves, the departments and so on, are just other ways to group in sections. There is no need to have them as separate objects: I can define fields under the &quot; object. The library (in FIG. 14B) is a separate object used to support separate lists of other objects used in other sites in the structure. Generally, the Library allows the storage and selection of a collection of interrelated objects at certain levels of the structure (shelves for example). The library uses the fact that the structure of the preferred space management system can be added to it. The benefit to the user is to be able to have a separate list in memory of stored sets of fixed parts that can be used again. Known systems may not have an external database for the shelves and do not have a library for storing shelf lists, so there was no flexibility to add or modify space requirements and representations.

In the preferred space management system, a BDS transfer may be made from an off-the-shelf library to the system to an internal shelf library; or the fixed parts on the desktop may be the updated one from the external library. Additional fixed clients can be copied to the shelf library. -117-

There is an entire market for the preferred space management system specialists. A specialist to fixed by adding specific shelves and dividers, a merchant uses a space management application program to add products to fixed ones. At present, in large commercial organizations the two departments are entirely separate and there is only limited communication between the two. In accordance with the preferred space management system, the fix expert can now use the preferred space management system to add products directly based on information given by the merchant. The fixed specialist can use the same software for both tasks; there will be greater inter-departmental interaction. This is a new possibility available to the users of the preferred space management system which is not available if known systems are employed. The operation of the preferred space management system will now be described.

At startup, Operating Environment 102 compiles a file list of available application programs that includes the space management application program. For each application program, Operating Environment 102 reads all Function Files including FUNCTIONS 1308 for the Operating Environment memory so that it is immediately available for execution in addition to functions that are resident in Operating Environment 102.

After the Functions and Support Files have been read into Operating Environment 102, a first display is read to stamp the first screen which is apparent to the user.

This first stamped screen is the main menu for i space management system 1302 mos -118-

table III.

Functions are selected by user inputs via preset keys or menu entries. Some keys do not have functions associated with them; instead, they have menus associated with them. When pressed this type of key is pressed the Operating Environment stamps the private menu (as it was stored in the Menus file in the application program of the preferred space management system). The menu entries can reference the function or other menus. For example, the main menu contains the word &quot; ANALYSIS &quot;, which in turn calls the ANALYSIS menu to show. Then the ANALYSIS menu contains the term &quot; PROPORTIONAL FILLING, 'with an associated function number. When some function number is activated, the system calls the particular location function in the improvement in Operating Environment 102 or outside the function block 1308 of the application program of the preferred space management system.

After taking control of the space management application program function, performs the necessary operations. Thus, for the &quot; proportional fill &quot; function &quot; within the preferred space management system, the preferred space management system looks at the user-designated shelf (for example by positioning the cursor) and performs a number of calculations to determine how the empty space on the shelf will fill. When the function is complete, the preferred space management system returns the control to the Operating Environment with a return code which is interpreted by the Operating Environment to cause the next function to execute.

In the case of &quot; proportional padding &quot; , this next function will be redrawn on the screen based on new calculations. In summary, the Operating Environment looks at user input and correlates this imput with the various functions in the preferred space management system. -119-

The functions are assigned in Operating Environment 102, properly, or in the space management application program 1304 FUNCTIONS file 1308. When the function is complete, the Operating Environment then performs the functions for stamping in indicating to the user a result of the execution of the complete function.

Some of the functions invoked by the user are some of those performed directly by the Operating Environment 102 and never utilize the 1308 functions of the application range 1304 space management system. For example a zoam ent / output function is resident in Operating Environment 102 other equally resident functions are listed below in Table I. In the same way as the internal functions 1308 to the space management application program 1304, when the execution of the resident function of the Operating Environment is complete, control is returned to the main part of the Operating environment with an appropriate code (called return code) to indicate to the user the result of the operation (for example for the zoom function, the code would direct the Operating Environment to redraw the screen).

In the application program, of the preferred space management system 1304, the 1306 support files are legible and editable ASCII files.

Support files 1306 can be edited by someone with knowledge in the field of applications. The editing functions of the support files in Operating Environment 102 allows a person to edit the files in the normal way in which the Operating Environment is edited.

By contrast in known systems, virtually all equivalents to the non-fixed space management system files 1306 in the context of all general executable code. -120-

The data structure is hard coded within executable code in the computer programming language. The structure can be embedded in source code files (for example, the C programming language). Thus, the structure can not be modified, other than being with a person with the level of a computer programmer. The only way to make changes to other features such as menus requires a programmer who knows the programming language and the specific program.

Generally, it is possible to adapt application program code to be used with Operating Environment 102. Known system users who are familiar with the preferred space management system may be able to utilize many of the same functions to which they are accustomed. A major advantage of using the preferred space management system is that the preferred space management system is more easily assimilated as new functions or versions are written. The modularity of the preferred space management system allows it to be assimilated without eliminating current functions that the client has self-trained to use. For example, the &quot; proportional fill &quot; can be retained, including its use via menu. If a new or better fill fill function becomes available, it can be assigned to the new application program, and you can have it appear with another menu file in the Analysis menu under a different name, thus giving the user the option of two types of proportional filling functions. So new functions and objects can be added very easily at any time without decreasing the usefulness (or changing the look and feel) of previous versions

As described above an advantage of the space management system 1302 over known systems is the positioning of the features in 121-

which can be easily edited by anyone in the field of applications. The separation of characteristics into discrete and easily modifiable units also makes it subtly more than to market the product to individual customers and, or for use in different countries. This ease of commercialization allows non-programmers to make necessary or desirable modifications. Because programmers are unaware of the retail market (or other related field or user of space management application programs), and because knowledgeable people generally do not know how to program computers, there is usually a lack of ability to communicate with both. The preferred space management system allows non-programmer connoisseurs to make the modifications they feel is necessary to present the appropriate output to the user or another customer.

Referring to Figs. 15A-15B, the user interactive clientization operation of the space management system 1302 will now be described with reference to the flowcharts Referring first to Fig. 15A, the sequencing operations of system 1302 start in response to a selection of clientelization received from the user indicated in block 1500. The user may enter this clientele selection by a submenu relationship as listed in Table III below the first menu which is first presented to the user at initialization (538 of Figure 5) and is available to the user while running at a defined input key.

A new user entry is received as indicated in block 1502. The next user entry is identified as one of a plurality of possible features to be clientelized, for example, such as a menu edition indicated in block 1504, an edition of key indicated in block 1506, a macro edition indicated in a block 1508, a display editor indicated a block 1510 in an addition of a DATA SOURCE in Lotus indicated a block 1512. Additional features not shown in FIG. 15A can be clientelized such as the input and output devices.

A corresponding list is then shown to the user the user's identifying selection together with any ready-made help messages in a block 1514.

A next ratio level entry is received and indicated in a block 1516 and corresponds to a selected modification such as to modify an existing feature or add a new feature.

Then the user enters the particular pro-gamma for modification to the existing feature or for a new feature that is received by the system 1302 indicated at the block 1518. User assistance messages may be stamped at each step as in block 1518 to receive parameters selected for the related feature, such as one from the sample menu, keys, macros, view, or Batch Data Source as indicated in blocks 1504, 1506, 1508, and 1510.

A predetermined key is then indicated a block 1520 to return to the entry at the user level a block 1516 in order to continue the clientelization operation or another key is pressed to return to the normal operations of the system to be indicated a block 1522 indicated. Operations in the system to be run are illustrated and described with reference to FIG. 5C above.

An example of a client process, when the addition of the menu is identified as selec- &gt; user input in block 1504, an additional entry may be added to an existing user menu by selecting a particular menu. Then a position in the selected private menu shown in block 1514 is selected.

Then a predetermined key is pressed by the user to add a new empty menu entry a selected menu position in the block 1516. When the menu entry corresponds to a function then the corresponding function number, such as 1219 is entered by the user in block 1518. Otherwise, when the new menu entry corresponds to either a macro or a submenu to be accessed, then the corresponding macro or submenu name, such as a label or a number, is entered by the user into the block 1518. Alternately, after the particular menu and the particular position in the menu have been selected, an existing private menu entry may be modified or canceled using other predetermined keys in block 1518.

A new menu can be added following a relationship corresponding to a new menu level in block 1516.

All desirable data parameters including multiple menu entries are then received in block 1518. Referring now to PIG. 15B, a flowchart is shown illustrating the operations of the management system 1302 to clientelize a structure file, such as the structure file 1310 of the space management application program 1304.

The sequential operations are indicated at block 1530 with a pre-terminated start command for the space management system 1302. A frame file input by the user is received as indicated at block 1532. The file of selected structures is loaded indicated at block 1534 and a list of -124-

objects to the selected structure file is shown indicated - a block 1536. The selection of clientelization selected by the user, such as adding a field to an existing object or otherwise modifying the file of selected structures, such as adding a new object to the selected structure is received indicated in block 1538. A selection of the user to modify an existing object is identified, indicated in a block 1540. A selection of the user to add an existing object is identified indicated a block 1542.

After selecting to modify an existing object to be identified in block 1540, then the selected additions and modifications in the fields for the selected objects in the frames file to be received and indicated in the block 1544. Similarly, after selecting to add an object to be identified in block 1542, then the description of the new object in the frame file is received and indicated in a block 1546. The description of the new object includes information provided by the user selection such as a name and multiple fields and links, have been arranged in a file structures as shown in the following APPENDIX A.

After the details are received in blocks 1544 and 1546 then the resulting new structure file is stored indicated a block 1548. Then the system 1302 can be reset indicated a block 1550 in order to load and aggregate the new structure file as shown and above described with respect to FIG. 5.

During each of the sequential steps for patronizing any feature or structure file, sample text and generic help messages can be shown to the user. Operation of the Batch Data System with respect to the preferred space management system 1302 will now be described. As described above, the preferred space management system, 1302, contains a plurality of data files. The space management system uses information or data from these data files and from outside databases (for example, database and text file). The Batch Data system facilitates data transfers to and from the preferred space management system 1302. The batch data sources 1320 include information that is independent of the logical device (type of data storage) involved. The BDS information respects the specifications for a data transfer. (For example, BDS determines which objects to deal with, either dealing with a list of products or a list of shelves or multiple objects, and so on). The BDS is configured to allow the user to choose the fields (for example, the object is a &quot; product &quot; and the field of interest would &quot; move &quot;) and allows dealing with duplicates. BDS 1320 provides criteria for 'parameters within fields and objects (for example, products with a movement greater than 100).

In summary, the BDS 1320 in the preferred space management system 1320 contains rules for the data transferences, but nothing specific to the type of current storage being read or to be written. (This device-specific communication is handled by the BDT or "Data Type" described above).

BDS rules can be pre - set or can be entered by the user. For each object transferred from a DBD, four unspecified elements including field name, relationship, value, and grouping. The field name is the name of a particular object grouping (for example, &quot; manufacturer &quot;). The relation is the logical relation (for example, = <, =>). The value and any fixed value (for example, &quot; XYZ Company &quot;). Finally, the collation links multiple criteria (for example, &quot; and &quot; or &quot; or &quot;). Thus, a required data item from a BDT could be: In the XYZ Company, products that cost> $ 10.00 and cost ^ 20.00.

To take into account the fact that different databases will likely use different terms for the same field or object, a &quot; Synonym List &quot; or &quot; Treasury Assemblies &quot; can be built on BDS.

Each Synonym List is specific to a BDS. BDS are part of the application program structure. If a new field is added to the preferred space management system framework file, it is necessary to add the same field to each Synonym List in each BDS.

In each BDS there are inter-active switches. If the appropriate interactive switch is on (for example, the field interface interactive switch), the user will see all possible fields to select. Advantageously, if desired, preselected fields can be shown in one color (for example red) and the remaining fields shown in a second color (black for example). The field list comprises all available fields at the intersection of fields available in BDS and the (BDT) Data Type in Batch. In other words, the list of available fields comprises all fields of the database in the (BDT) that can be read by the preferred space management system (i.e. those fields listed in the Preferred space management system Structures file)

Synonyms are used so that otherwise unrecognized field names on the outer bridge are recognized so that they can be linked to the field name known from the Synonym List.

If the interactive switch is turned off, there is no user interaction; field selections and transfers occur automatically based on previous establishments. The field preset is one of the numerous clientelization features in the combination of the preferred space management application program 1304 and Operating Environment 102. Gada BDS will perhaps have more than one interactive switch to select specific fields for each object to make interactive selection criteria (for example, mpg = ABC Company, mo-viment. <100, or a combination of criteria using * &amp; &quot;).

TABLE I

Summary of Preferred Space Management System Capabilities The preferred space management system can be considered as a single product, both as it appears to the user as a single executable computer program however as described above, the space management system The preferred program is in fact in two parts-The application program and the Operating Environment. The program basically operating (ie the Operating Environment) holds data (such as planogram data) a memory database structure, and -128-

allows the user to access the data either through tables and screen inputs or through an interaction in a 3 dimensional chart type. The preferred application program deals only with application-specific functions, such as allocations and proportional fill, and also specifies the data structure and other configuration information. 0 Operating Environment; The following description of Operating Environment supplements the above descriptions related to the Operating Environment considered as a separate entity from any particular application program. Here, the Operating Environment is described with particular reference to its use as platform for the preferred space management system. It should be understood that the Operating Environment is specially designed to be a &quot; platform &quot; (that is, an &quot; Operating Environment &quot;) not only for the space management system but for any other number of application programs. 1. Data structure. When started, the Operating Environment inspects a data file provided by the application program that describes its structure. The file describes private objects such as GONDOLAS, SHELVES and PRODUCTS giving their fields (for example, ID, PRICE, WIDTH) and also how they are related (for example, GON-DOLA has many shelves, SHELVES have many. Each object and all its fields can be made visible to the user in a tabular list called a map, for example, there is a map in the preferred space management system to describe the consumer products and the attributes that are A set of different formats (called a display) for graphical representation of objects and their fields are provided. These displays can be fixed, pre-edited, or stored in their fields. The display can specify on-screen totals and title information and can also prioritize the data by specific fields 3. Inputs per screen As well as describing formats for maps, the displays can also define inputs per screen. For example, where instead of a record (for example, a consumer product) takes only one line on the screen, one record is prepared to take the entire screen with its data fields.

Graphic system. Any map can also be shown graphically and the graphical representation can be viewed from any angle. Objects can be moved freely in graphics either with the arrow keys or, for example, with a mouse. 5. Menus and commands. The entry can be achieved, for example, through menus or direct key commands. For example, a key starts a particular operation, where the operation can be a complex evaluation or can be simply move the cursor, Qs menus and key command lists are provided by the application program and are also editable before and during the program. 6. Application programs. When started, the Operating Environment loads the data management structure, menus, commands, viewers, and so on. The Operating Environment will also load the functions of the memory space management application program so that they can be run as needed during program execution as quickly as if the 130-

of applications and the Operating Environment only one program. The Operating Environment may also deal with more than one application program concurrently, such that, for example, an application program to deal with automatic pricing may run concurrently with the space management application program. The two application programs would thus be accessing the same data in memory without modifications to the Operating Environment or existing application programs. 7. Report. The Operating Environment can report on any data using the flexibility of the VISUALIZATION system and can show, for example, total and subtotal breaks in any field in the application program. 7. Access to outside data. The Operating Environment can load / merge / update to and from any type of external data storage with full control over which objects and fields to transfer, particular criteria that fields must satisfy, how to handle duplicates, and so on. Links between programs called Batch Data Type modules that actually read and write are programmed specifically for each type of external data source. However, the increase in the Operating Environment handles most of the high-level transfer specifications, which makes creating these BDT modules specific to a reasonably simple device. The BDTs for more generally used data stores may be provided, for example, by the Operating Environment provider, or may be written by the user to adapt to common data storage types. These guides may include (a preferred useful embodiment) database files, text program listings, vendor-selected data files, manipulated computer files and the like. 9. Formulas. Each field can be assigned a formula so that its value is calculated by the greater formula than to be explicitly given. A formula can include references to fields either on objects or on other related objects.

All Lotus functions are available for use in formulas. Fields can take NA (not available) and ERR (error) for full compatibility with text systems. Formulas can be entered and edited before or during the corresponding program and apply to all situations of the object for which more than one "cell" is entered. Formulas are compiled internally for quick execution and many of the error checks (for example, wrong arguments, unknown functions) were made when compiled. 10. Macros. Macros can be entered as command lines, where each command runs in sequence after the macro is invoked. Macros are compiled as formulas and follow a similar syntax for ease of learning. All commonly available commands, such as the special commands and capabilities used to set &quot; macros &quot; &quot; special &quot; can be used in macros: labels and DROPS; IF phrases (condition test); dynamic variables; ties of FOR, WHILE, with BREAK and CONTINUE; submacros; stamping of messages; point values; and so on. 11. Input and Output Devices. Such as Screens, Printers planned Mice. The Operating Environment is independent of the particular type of screen it uses, but accesses it via a connection program known as Output Device Advisor. Similar guiders are used to connect to other types of output device such as planners, printers and photographic devices. New advisors can thus be easily written

to cover any type of screen, printer or graphics mode that is additional to the system. A Similar Input Device Orientation system handles any type of input devices, such as a keyboard, mouse, or successive digital inputs.

TABLE II

Use of the Operating Environment Catacteristics by the Preferred Space Management System The use of the features by the preferred space management system can be summarized in this section. It should be understood, however, that variations of the following summary within the capabilities of those skilled in the art within the scope. Thus, the allocation of functions between the preferred space management application program 1304 and the Operating Environment 102 may be modified from this allocation prescribed in this Specification and further within the scope of the present invention as defined by the appended claims and the claims of any patents applications. A. The functions of the Operating Environment that relate to the objects:

Stamping of:

Directional display View windows -133-

Deletion of subset, for example xsect screen area

Grills

Use of vector images (linked sets of coordinate points) -

Use of images, (color banks)

Interactive stamping

Cursor positioning Cursor reference Add / move / drop objects Objects Flip / drop objects

Movement of blocks / copies of similar articles

Collision check

Current cursor position on screen

Design based on structure

Part of Stamping Logic

Data input via screens

Display of special objects Per line Per screen

Updating related fields in a log

Totals and subtotals

Distance / date input and time values. Simple line and full page help system. 4. .s

N

Reports

Rewriting data, data entry screens or graphics stamping to other device leaders.

Ordering

About field combination under control of a viewer Files Input and Output

Version of the system reserving the format to allow high-to-low compatibility between versions

Store ASCII

Load ASCII

Selective ASCII Update Override ASCII

All database management uses low-level supplied connectors

Store to database

Upload from database

Selective database update

Selective database update

Unregister the database

Control System Current memory remap screen Current validation option screen. Β. Ο Preferred Space Management System uses the Operating Environment

ASCII Input and Output File o ASCII Operating Environment to store / load / update (de) / abort

Providing the WAREHOUSE object and all subsidiary objects

Separate loading / merge of loose libraries.

Lotus: the ASCII Operating Environment to store / load / update (de) / abort.

Providing relevant objects, selection criteria and format details in accordance with the WKS format. dBASE: 0 Operating environment of database to store / load / update / (of) / abort

Providing relevant objects, selection criteria, and dBASE connectors

Other databases: 0 even with relevant connectors

Stamping of the Planogram

Stamping in the Operating Environment of the Object WAREHOUSE · causes automatic stamping of the member objects The stamping of the object GONDOLA, by the Operating Environment, etc.

Add / move / delete Add / move / delete Add / move / delete Add / move / delete Add / move /

Interactive Gondola Interactive Shelf Interactive Position on relevant object in the Environment

Modifications of key input Warehouse / Gondola / Shelf / product Data entry screen manipulator in Operating Environment, Providing a DISPLAY

Map

Operational Environment input screen manipulator Providing a PRODUCT object.

Execution of reports

Manipulating Operating Environment reports Providing a viewer with hierarchical links to others

Generating and Modifying Reports

Screen input manipulator in the Operating Environment Providing a DISPLAY referring to a DISPLAY object.

Storage and replenishment in report format.

Storage ^ loading / updating (of) / canceling the VISOR object.

Product ordering

Operational Environment data entry screen -137- including details of criteria.

Sorting the Product Object in the Operating Environment given a display in extension.

Special Routines

Allocation fill.

TABLE III

The Files of Support 13Q6 of Preferred Space Management Systems

Structure 1310: A data structure for the application program of the preferred space management system is shown in FIG. 14B. A more complex, secondary data structure is shown in FIG. 14A. The structure of FIG. 14B is preferred by some users for its simplicity and will be the focus of the discussion. However, it should be understood that many variations in structure can be made by those skilled in the art. The exemplary structure of FIG. 14B may also be represented as follows where the spacings below a certain level imply downlinks:

Warehouse

Section

FIXED

Position (1 of 2)

Block

Product

Location (2 of 2)

Block

Libraries

Product

Section

Fixed

Fixed

Pin

Model Schedule

Order Schedule

Supply Schedule

Existence verification schedule

Menus 1312; In a preferred embodiment, a main menu is automatically displayed at startup. The main menu is available almost all the time during the program and has the following entries:

File Edit Exit Analysis Misc System Exit

All menus except Sais bring other menus. Options that are preferably directly linked to the Operating Environment functions are shown with an &quot; OE &quot; to designate. Other options refer to functions of the application program of the space management system

preferred.

Sub-menus may include:

File (Batch Data System)

Load Loading (OE)

Merge Update from Update to New OE

Edition:

Add:

Section with base / return Fixed.

Products

Position

Modification:

Section

Fixed

Products

Position

Movement:

Fixed

Position

To remove

Fixed

Products

Position

Duplicates:

Fixed

Products

Position

Listing:

Fixed

Product

Position

Block:

Add:

Positions

Listing Positions

Movement:

Fixed

Positions

To remove:

Fixed

Positions -141-

Copy:

Fix

Positions

Reviews:

Information window: more details about the product / current shelf

Proportional Filling: Adjust the space given to each product on a shelf proportionally to fill the shelf

Force the minimum: shorten the product space to a minimum.

Recommended: Show the level of existence of a product. Emphasis: Some products stand out depending on criteria entered by the user.

Download products: Empty all shelves

Remove unused products: Forget any products that are not currently on a shelf

Output:

Report of this (current display) OE

Report (select list viewer (s))

Switch OE devices - switch to another screen

Reset OE devices - return to the original screen

Change LIFE ON / OFF OE - change the ON / OFF stamping of stained images

Switch ON / OF OE forms - switch ON / OFF image stamping on vectors

Generate the file LIFE - Create a file to use in the live capture / warehouse system

System; DOS OE - temporarily return to the OE operating system Memory Maintenance

Misc:

Customer:

OE Menu System OE Viewers

OE Input Devices OE Output Devices OE Batch Data Sources Batch Data Types OE

Correction: &lt; Multiple routines for correction &gt;

Level:

Download the level of one degree OE Select the next display OE Raise the level of one degree OE

Viewfinder: Quickly enter OE -

Quickly exit OE

Quickly return to our OE system

OE Center

Top view OE

Left view OE

Right view

Front View

Back view

Other display options OE POSITIONING OF THE SELF-HELP KEYS 1314: Many of the other key functions available from the menus listed above. Others trigger the main menu or other subalter-nor menus directly. Others are &quot; abort &quot; or &quot; finish &quot; only available in certain screens.

Macros 1316: It has been found advantageous to use the following macros

Last Copies: This is a utility macro to assist in editing long data tables.

Abandon: This is a macro from the main menu that takes the program confirmation and then exit the program. AUTO EXECUTE: This is a macro executed automatically by the Operating Environment when it is initialized. It can be configured to automatically load data in the hanging library of a standard linked file.

Events 1317: An event is a function (or macro) that is time regulated to run without user intervention at a specific time and possibly repeated at even intervals after that time.

An event that is advantageously implemented is a function called every 1-2 seconds which will automatically stamp a small window in the corner of the screen reflecting the product to which the user is currently pointing with the cursor.

Viewers 1318: Viewers are screenshots, each one for a particular object in the structure. Viewers come in three varieties: 1. Map displays: This displays the data on the screen (or a ja in it) a tabular format, one record per line. 2. Full Screen Displays: This displays each entry on the entire screen (or window), placing the fields preceded by their names at various points on the screen according to the details on the display. 3. Model Viewer: This extracts three-dimensional information to draw each register according to details in the display and the stamping is graphically on the screen (or window), the model displays can be chained together to allow multiple objects of are printed graphically on a screen,

The displays are selected by the functions of the preferred space management system by requesting -

the internal functions, which then trigger and generate the stamping at the time.

Preferred displays may include: OBJECT NAME TYPE Warehouse • • • • • • • • Warehouse ... 001 Tot screen. Warehouse A.A. Warehouse Model Warehouse QPS * ADDITIONS Screen to1 Section A.C. SECTOR Model Section GONDOLA A.C. Model Section SEC. B.C. Model Section ADIC. SEC. Tot screen. Easy Section. SEC. Tot screen. Section LIST. SEC. Map Section LIST. GOND Map Section BIB-SECC. Map Fixed FIXES. A.E. Fixed Model ASM.A.E. Fixed Model SAMPLE Model Fixed ADIC. FIXED Screen, tot Fixed Sei. FIXED Map FIXED LIST: FIXED Map

DESCRIPTION

Flag the display, show version and copyright

White

Model Warehouse Standard Warehouse Level Options Standard Reaction Model Reaction Model with Dimensions Reaction Model Different Colors Section Editing

Split with base / return fields included

Section listing

Listing, one gondola

Section listing for use in the library

Standard model of fix Fixing model, single assembly Experimental Fixed edition

Fixed list, used for fixed selection.

Standard list of fixed 146-

Fixed BIBL. FIXED Map Fixed Map LIST ASM Map POS Position. A.F. Model Position ADIC. POSITION tot screen, ADDI. POS. Display-tot Position DTL. Position Module Position LIST. POSITION Map Product ADIC. PROD. Screen-tot, Product LST. PROD * MAP Product SEL. PROD. Map Block BLOCK A.G. Block Model LIST-BLOCK Map Pins BIB1. CAVILHAS Map Catalog of Models ADIC. MODEL Screen-tot. Model Catalog LIST-MODEL Map Model Catalog ADIC-MODELS Screen-tot. Order Catalog LIST-ORDERS Map Stock Catalog ADICrSTOCK Screen-tot. Stock Catalog LIST-STOCK Map Supply catalog LISTA-FORNEC. Screenshots

Fixed list for use in the library

Fixed list a single assembly element

Standard Model for Position Position Editing Alternate Position Editing Alternate Position Model Position Listing Product Editing Product Listing Product Selection in the List Standard Model for Block BLOCK List List of Pins

Model Catalog Editing

Model Catalog Editing

Order Catalog Editing

Order catalog list

Stock catalog edition

List Stock Catalog

Editing the supply catalog

Supply catalog LIST. FQRNEC. Map Suppliers Catalog

Special purpose displays for internal use of the special space management system: ADDITION OPTIONS BLOCK input options for use during block addition positioning. LISTFICHBDS shows the list of available files before the BDS download. XYZ editing of XYZ cursor position. EXEC, OPTIONS entry of run options used during proportional fill OPTIONS, FOCEM input options used by the minimum FORCE OPTIONS.ENFASE input options used by the emphasis feature. OPTIONS, CUT input options used during positioning Ser right up

Other system displays used to clientelize menus, viewers and the like may also be included.

Batch Data Sources 1320 BDSs (sometimes referred to as 'data banals') that are advantageously employed may include;

BDT NAME DESCRIPTION

ASCII EC planograms Standard planar files all objects

OE ASCII Stud Library

Ϊ4β-

OE ASCII

Lock library

Spaceman II SP.IIASCII Products dBASE (R) N dBASEIII (R) Lotus (R) Spreadsheet OE ASCII CAREGAMABLES

Sections / pinning under the library

SPACEMAN II files, all objects.

List of products from / to the dBASE file

Lotus (R) ALL all objects from / to the Lotus spreadsheet. Only bolts, there is no embossing during the transfer.

Messages 1322: This is a list of all messages used by the application program, kept separately and indexed by number of other application files to allow for easy translation between languages (ie, &quot; human &quot; languages such as German, French, English and so on).

The names, descriptions, and error messages are referenced in the preferred space management system functions and the other Support Files as numbers, which correspond to actual messages in the Message File.

TABLE IV

Functions of the Preferred Space Management System 1308 System Support Functions:

SYSINIT internally initializes the values of the preferred space management system. non-input connected to some fields for for editing the end user 1. end 2 esc 1 esc 2 bar 1 bar 2 stores the edited record and then allows a move stores the edited record and allows a move ignore the edited record ignore the record edited brings the main menu brings a small edit menu during data entry. skip-page page exchange on a full-screen display input 1 selects the current item. new-data new file - removes all current data internally.

end-s / move stores edited record, without moving end-clecç finalizes a multiple selection, flooplane mode switches to VENICE mode planogram switch to regular planogram mode mode-bib-section switch to section-mode library bib- fixed exchanges for the library of fixed mode-bibl.-cav. exchange to the exchange library of exchange-units exchange between units / block mode for position stamping. info-pos draws an information window for the current product. dim.cur. shows the current cursor position cur.bill shows the ad space for the current shelf you find the current product in the list, find de.ch find the current product in the auto-window model brings summary information of the current product

Warehouse-level routines: pre-warehouse initializes a warehouse post-warehouse checks a warehouse after a new warehouse is edited Edit warehouse (not now in use) modif-warehouse Edit modified warehouse

Catalog Routines: pre-model initializes a model catalog post-model verifies a catalog of model entered model list List of new model-model catalog Adds catalog of model double-model Model of model duplicates model Modify catalog of models rem-model model Removes the analog model catalog for order catalogs, stocks and deliveries.

Editing routines section: pre-secc, sec-sec-list new-sec dup-sec initializes a new section Edits the list of sections Edits the added section Edits the duplicate section -151-

modif-sec remove-sec move-sec xfr-sec puts section

Edit the modified section

Edit the removed section

Edit section move

Edits section (not yet output), transfer within library

Edit the post section (not yet output), transfer outside the library

Similar functions for editing fixed, product and position and also grouped objects, gondolas, department and wing.

Extra drawing functions: dim-abetta-prop d im-al tur af ix dim-width-fixed draws-grid dim-grid draw-draw-traffic draws the dimensions to the open shelf depth draws the height of the fixed draws the width of the fixed draws a grid in an open shelf draws the dimensions in a grid draws my arrow showing the traffic traffic to a section draws all the pins draws all the wafers in a frame of pins draws the pins draws a pin in a product draws it, pin-present draws a total position of the pin in the front of the product draws spaces draws a space between the products on a shelf-

Punctuation Analysis: locinfo cursor position unloads-all Analysis Product download removes-out-of-use Analyzes Removal of out-of-use products forces Analyzes the minimum dist-dist. (NYI) inforeq Recommended Analysis - shows the recommended inventory optiquery Evaluates inventory in summary (NYI) emphasis Analyzes the emphases LIVE (shaded) related functions: makes live file Generates a live file for the cross section

The file-specific functions of the preferred space management system: load the file in the file system. The file is updated. The file is updated. The file is updated. The file is updated. In order to invoke a BDS through the preferred space management system, created in SPACEMAN II s2bdt-inic s2bdt-ler -153- s2bdt-pmtler s2bdt-close

TABLE V

Features Advantageously employed in the Space Management System

The features listed in this section reflect those features that can be advantageously used in the application program of the preferred space management system in conjunction with the Operating Environment. This reaction gives those skilled in the art a list of features that are desirable in a space management system. Those who are accustomed to using another space management system may make use of the degree of transfer of a variety of features from existing application programs in addition to application programs that may be specially designed to operate in conjunction with the Operating Environment. Those skilled in the art have the ability, based on the present disclosure, to design and implement space management programs that are derived from existing programs with desirable characteristics or that are independently developed.

Managing the Fixed.

Automatic shelf positioning The positioning of a shelf a section once entered into its details can be auto-mailed based on the positioning of other previously placed shelves and the space of goods they need.

Shelf Positioning by Cut Number The positioning of a shelf in the reaction can alternatively be vertically based on a cutting number entered by the user, the number being: a) the number of cuts from the ground b) the number of cuts below the shelf, next higher

Subsections The reaction can be divided horizontally into subsections by entering lengths of subsections into the section register. These can be used for: a) stamping of subsection vertical lines b) graphic stamping of a single subsection c) automatic positioning of shelves (be above) ♦

Warehouse walls

Aided by construction to allow easy construction of walls in a floor plan of the warehouse. -155-

Products

Product lists A list of products implemented as viewers showing the same fields as they can appear in known space management systems.

Find the model

A function to find and move (in the section shown) the current product in the product list.

Descriptions definitions

Some product description fields (often referred to as DESC A to DESC J) may have their names changed on a central screen, after which any product listings in maps (or any other screens that display the names of those fields) will display the already redefined field names. This is achieved by a global shift to all relevant viewers.

Updating a single product from a database

Update all fields of a product per user input of a single identifier such as the UPC number.

Placing products on a shelf

Shelf / Peripheral Position Design -156-

Certain features of certain products / shelves that are not automatically addressed by the automatic design functions of the Operating Environment can be designed by specific drawing functions. These include the design of: a) Bolts on dowel plates b) Spacers on shelves c) Grids in front of shelves

Addition of blocks Placing a group of products on a shelf can be done in one step by: a) choosing them from the list of products b) selecting the criterion based on certain product fields

Proportional fill

When a shelf is not full, a proportional fill algorithm can add more covers to some or all existing products to fill the shelves while still keeping them in proportion as much as possible.

Minimal forcing

This feature will remove the covers of some or all of the products on a shelf, leaving only the minimum number of covers required by the inventory calculation system. -157-

Exchange / mirror

This function will reverse the order of the products on the shelves and if desired the horizontal placement of the shelves as well.

Download

This feature removes all products from all shelves in the section, leaving the product list intact. Emphasis

This function modifies the label-gem or color of the products on the screen in order to enhance them, based on the included entry criteria; a) Best / Worst products in action (sale) b) products in excess of or lacking in existence c) products corresponding to certain fields entered by the user

Product overview

This function summarizes all products with one or more &quot; medium &quot; products &quot; for use in a general warehouse level analysis.

Stamping of Units / block mode.

Using different displays the products on the shelves can be shown as a whole or separate units. 158-

Labeling Product labeling can be controlled and patrolled using the Operating Environment display and formula system.

Right justification

Products can be grouped to the right of a partially filled shelf rather than left as usual.

Automatic positioning / shelf window

When pointing to a product / silverlight the system can automatically display a window with details of that position / shelf a corner of the screen whenever the cursor is not moved for a cost period of time.

Fill / sião-fill / manual placement

There are options for placing along a shelf a) Do not fill-normal but touch all products left or right b) Fill-automatically make a proportional fill after each placement. c) Manual-position the products exactly where specified without adjustment

Find the next product

Find the next occurrence of the same product in section se. there is a. 159-

Evaluation screen

Stamping current financial statistics of the whole screen Recommended screen

Shows the recommended inventory for the current product.

Data management

Spaceman XI file binding Implemented as a BDT DXP Autocad output

Output to a standard CAD system, DXP file implemented as a BDT

Exit

Section dimensions

Peripheral drawing punches added to the displays to draw dimension information in: a) Shelves b) Entire section c) Bolts d) Shelf racks e) Direction of flow traffic

File VIVO -160-

Output of a product specifically for use in the Warehouse Printing / Shaded Logistics system

Guidance for other screens

a) EGA

b) EVGA c) Targa V. Conclusion

While the various details of the preferred embodiment of the present invention have been described above, it should be understood that the detailed description above has been presented by way of example and not limitation. Thus the width and scope of the present invention should not be limited by the features described above, but should be defined only in accordance with the following claims and their equivalents. -161-

APPENDIX A: STRUCTURES FILE EXEMPLARY CONNECTION, ID, 1, DESCRIPTION, 1, MULTI-DNO, 3, MULTI-MEMBER, 3, DE, -1, FORMATION, -1, TO, -1 BOX, LABEL, 1, VALUE, 3 DETERMINATION DETERMINATION -1 DEG -1 FORMATION -1 FIELD ID 1 TYPE 7 LENGTH 3 PREC 3 VIS 7 HELP 1 PRE-ENTRY 8 POST-ENTRY , 8, ON-FORMULA, 2, OF, -1, TRAINING, -1 OBJECT, ID, 1, DIMENSION, 3, DRAWINGS, 8, PRE-ADD, 8, POST-ENTRY, 8, TRAINING, -1 SYSTEM , ID, 1, DESCRIPTION, 1

SYSTEM, SPACMAN, Data structure Spaceman III

OBJECT; WAREHOUSE, 0, 0.237, 0.0, 0.0, SPACEMAN

FIELD, ID, STR, 12,0, YES, &quot;, &quot;, Ô.Q, 0.0, NO, STORAGE, SPACEMAN

FIELD, # .10 /, STR, 12.0, YES, &quot;, 0.0., 0.0, NO, ARMA_ ZEM, SPACEMAN

FIELD, X, DOUBLE, 12.3, YES, &quot;, 0.0, 0.0, NO, &quot; , WAREHOUSE, SPACEMAN

FIELD, Y, DOUBLE, 12.3, YES,, Eye, 0.0, NO, &quot;, WAREHOUSE, SPACEMAN

FIELD, HEIGHT, DOUBLE, 12, 3, YES, '»**, 0.0, 0.0, NO, AR

MAZÉM; SPACEMAN

FIELD, WIDTH, DOUBLE, 12, 3, YES, 0.0, 0.0 «NO, &quot; .AR

MAZÉM, SPACEMAN

FIELD, DEPTH, DOUBLE, 12, 3, YES, 0.0, 0.0, NO, WAREHOUSE, SPACEMAN FIELD, SALES, DOUBLE, 12, 3,

WAREHOUSE, SPACEMAN

FIELD; TYPE, INT, 2, 0, YES, 0.0, 0.0, NO, WAREHOUSE, SPACEMAN

FIELD, AREA, STR, 30, 0, YES, &quot;, 0.0, 0.0, NO, WAREHOUSE, SPACEMAN

FIELD MANAGER, STR, 30, 0, YES, &quot;, 0.0, 0.0, NO, STORAGE, SPACEMAN -Ό - FIELD, GROUP, INT, 2, 0, SIM, 0.0, 0.0, NO, STORAGE, SPACEMAN ' '1' FIELD, DEPARTMENTS, INT, 3, 0, YES, 0.0, 0.0, NO,

WAREHOUSE, SPACEMAN

CONNECTION, DENTRY, 0.1, WAREHOUSE, SPACEMAN, GONDOLA

SPACEMAN, OBJECT PRODUCT, GONDOLA, 0, 0.237, 2.7, 0.0, SPACEMAN FIELD, ID, STR, 12, 0, YES, 0.0, 0.0, NO, &quot;; &quot; GONDOLA, SPACEMAN

FIELD, NAME, STR, SPACEMAN 12 0, SIM, II II i 0.0, 0.0, NO, IIII 9 GONDOLA FIELD, X, DOUBLE, SPACEMAN 8, 3, &quot; SIM &quot;, II tl 9 0.0, 0.0, NO, II II 9 GONDOLA FIELD, Y, DOUBLE, SPACEMAN 8, 3, &quot; SIM &quot;, II «1 / o • o • o • o NO, II II 9 GONDOLA FIELD, Z, DOUBLE, 8, 3, &quot; , II II 9 o • oo • o NO, II II 9 GONDOLA

SPACEMAN

FIELD, DIRECTION, INT, 3, 0, YES, &quot; *, 0.0, 0.0, NO, GONDOLA, SPACEMAN

FIELD, HEIGHT; DOUBLE, 8, 3, YES, 0.0, 2.8, NO, '· ", GONDOLA, SPACEMAN

FIELD, LENGTH, DOUBLE, 8, 3, YES, 0.0, 0.0, NO,, GONDOLA, SPACEMAN

FIELD, DEPTH, DOUBLE, 8, 3, YES, '&quot; ·, 0.0. , 0.0, NO, '' &quot;, GONDOLA, SPACEMAN

FIELD, BASE HEIGHT, DOUBLE, 8, 3, YES '*, 0.0., 0.0, NO,' &quot; ·, GONDOLA; SPACEMAN FIELD, BASE LENGTH, DOUBLE, 8, 3, YES, 0.0, 0.0, NO,

«&Quot;, GONDOLA, SPACEMAN

FIELD, DEPTH BASE, DOUBLE, 8, 3, YES, »&quot;, 0.0, 0.0, NO, GONDOLA, SPACEMAN

FIELD, THICK, DOUBLE, 8, 3, YES, &quot; ", 0.0, 0.0, NO, GON

DOLA SPACEMAN

FIELD, OBSTRUCTION, BOX; 3, 0, YES, 0.0, 0.0, NO, GONDOLA, SPACEMAN

BOX, NO, 0, OBSTRUCTION, GONDOLA, SPACEMAN BOX, YES, 1, OBSTRUCTION; GONDOLA, SPACEMAN 163-

FIELD, Y, DOUBLE, 8, 3, YES, 0.0, 0.0, ΝΑΟ; (© ADD (/ Y /, / BASE HEIGHT /), GONDOLA, SPACEMAN ''

FIELD, BASE, X, DOUBLE, 8, 3, YES, 0.0. , GONDOLA, SPACEMAN CONNECTION, ON, 0, 1, GONDOLA, SPACEMAN (1), GONDOLA (2), GONDOLA, SPACEMAN , SPACEMAN 0.0, NO, PRODUCT, FIELD, SPACEMAN ID, STR, 12, 0, SIM, ··,,,,,,,,,,, • "NO", "NO", "PRODUCT", "FIELD", "SPACEMAN", "SPACEMAN", " YES, 0.0, o * NO, PRODUCT, FIELD, SPACEMAN HEIGHT, DOUBLE, 8, 3, YES,, • oo • NO, PRO-

DUCT, SPACEMAN

FIELD, THICKNESS, DOUBLE, 8, 3, YES, &quot; », 0.0, 0.0, NO,, PRODUCT, SPACEMAN

», 0.0, 0.0, YES, (QAddition (/ height /, / width /), PRODUCT, SPACEMAN, H + W, DOUBLE, 8, 3,

FIELD, DEPTH, DOUBLE, 8, 3, YES, «, 0.0, 0.0, NO, PRODUCT, SPACEMAN FIELD, BOX, APPLE, INT, 3, 0, PRODUCT, SPACEMAN SIM &quot; 0 0 2.6, NO, FIELD, CASH, COST, DOUBLE, 8, PRODUCT, SPACEMAN 2, YES, 0 .0, 2, 6, NO, &quot; FIELD, COST UNIT, DOUBLE, PRODUCT, SPACEMAN 8, 2 ,,,,,,,,,,,,,,,,,,,,,,, SPACEMAN II II f 0.0, 0.0, NO, '· ", PRODUCT FIELD, TEST3, IONT, 3.0, SIM, SPACEMAN II 11 / 0.0, 0.0, NO, •', FIELD PRODUCT, WORK COST, DOUBLE; , PRODUCT, SPACEMAN 8, 2, YES, &quot; »o • o, 0.0, NO, 164-

CAMPOJ DPC, DOUBLE, 8, 2, YES, 0.0, 0.0, NO, PRODUCT, SPACEMAN FIELD, MOVEMENT, DOUBLE, 8, 2, YES, ··· *, 0.0, 0.0, NO,

PRODUCT, SPACEMAN

2, YES, ····, 0.0, 0.0, NO, · &,; PRODUCT, SPACEMAN FIELD * ORDER, DOUBLE, 8, 2, YES, 0.0, 0.0, NO,

SPACEMAN FILE, ID, STR, 12, 0, SIM, 0.0, 0.0, NO, ··, SPACEMAN LINK, 0, 1, PRODUCT, SPACEMAN, POSITION, OBJECT, SHELF, 0, 0.237, 0.0, 0.0 &quot;, SHELF,

SPACEMAN

FIELD, SH TYPE, BOX, 10, 0, YES, », 0.0, 0.0, NO, &quot; , SHELF, SPACEMAN

BOX, SHELF OPEN, 0, SH, TYPE, SHELF, SPACEMAN BOX, BOX BOARD, 1, SH TYPE, SHELF, SPACEMAN BOX, CH FRIGORIFICO, 2 SH TYPE, SHELF, SPACEMAN BOX, SHELF, SPACEMAN FIELD, X, DOUBLE, 8.3, YES, 0.0, 0.0, NO, SHELF,

SRACEMAN FIELD, Y, DOUBLE, 8, 3, YES, 0.0, 0.0, SPACEMAN NO, II II 9 SHELF FIELD, Y, DOUBLE, 8, 3, YES, 0.0, SPACEMAN 0.0, NO, FIELD, LENGTH, DOUBLE, 8, 3, SIM, SHELF, SPACEMAN 0.0, 0.0, NO, &quot; FIELD, DEPTH, DOUBLE, 8.3, YES, &quot; &quot; , SHELF, SPACEMAN o • oo •, FIELD, THICKNESS, DOUBLE, 8, 3, YES, 0.0 TELEIRA, SPACEMAN, 0.0, NO, &quot; YES, 0.0, * o • o NO, &quot; PRA-

TELEIRA, SPACEMAN

FIELD, PENDER, INT, 3, 0, YES,, 0.0, 0.0, NO, ·· &quot;, SHELF, SPACEMAN -165-

FIELD, TOP, DOUBLE, 0, 3, YES, '· " , SPACEMAN, PLACED ON, ΟΝ, 0, 1, SHELF, SPACEMAN, OBJECT POSITION, POSITION, 0, 0.237, 0.0, 0, 0, SPACEMAN FIELD, ID, STR, 12, 0, SIM *, '&quot;, 0.0, 0.0, POSITION, SPACEMAN FIELD, FRONT, INT, 4, 0, SIM, , NO, POSITION, SPACEMAN

FIELD X, DOUBLE, 8, 3, YES, 0.0, 0.0, NO, POSITION, SPACEMAN FIELD, Y, DOUBLE, 8, 3, YES, &quot; 0.0, 0.0, NO,

SPACEMAN FIELD, Z, DOUBLE, 8, 3, YES, 0.0, 0.0, NO,, POSITION,

SPACEMAN

FIELD, HEIGHT, DOUBLE, 8, 3, YES, 0.0, 0.0, NO, &quot; POSI

SPACEMAN FIELD, WIDTH, DOUBLE, 8, 3, YES,, 0.0, 0.0, NO, »&, POSITION, spaceman

FIELD DEPTH Dual 8, 3, YES, 0.0, NO, POSITION, SPACEMAN FIELD, COR1, BOX, 8,0, YES, '0.0, 0.0, N O,

SPACEMAN

BOX, WHITE, 15, COLOR, POSITION, SPACEMAN BOX, YELLOW, 14, COLOR; POSITION, SPACEMAN BOX, PINK, 13, COLOR, POSITION, SPACEMAN BOX, LIVE ENCARNADO, 12, COLOR, POSITION, SPACEMAN BOX, BROWN, LIGHT, 11, COLOR, POSITION, SPACEMAN BOX, GREEN LIGHT, 10, COLOR; POSITION, SPACEMAN BOX, BLUE CLEAR, 9, COLOR, POSITION, SPACEMAN BOX, GRAY, 7, COLOR, POSITION, SPACEMAN BOX; BROWN 6 COLOR POSITION SPACEMAN BOX VIOLET 5 COLOR POSITION SPACEMAN BOX ENCARNADA 4 COLOR POSITION SPACEMAN BOX BROWN 3 COLOR POSITION SPACEMAN BOX GREEN 2 COLOR, POSITION, SPACEMAN BOX, BLUE, 1, COLOR, POSITION, SPACEMAN BOX, BLACK, 0, COLOR, POSITION, SPACEMAN -166-

EXPLANATION OF THE EXAMPLE STRUCTURING FILE Appendix A illustrates a typical structure file. To advantage, the framework file can be named with a &quot; .str &quot; suffix in the name of the application program. For the sake of clarity, everyday marks have been omitted from textual specifications, except where a textual field is completely empty (&quot; &quot;). Spaces were also inserted between listed objects in order to more clearly delineate the different sections of the structure file specifications.

Referring to Appendix A, a working format for a structure file is shown. Many variations can be made in the structure file of Appendix A, while still remaining within the scope of the present invention. However, any structure file operable with the present invention must contain an object specification, fields contained therein and links between the objects. Additional additions of rearrangements and improvements may be made, although some definition of the structure in which the application program may operate is present.

This is exemplary of structure files that are treated as normal data files that follow the transfer path &quot; Merge &quot; in the Batch Data System (FIG 11) during the loading / aggregation process (FIGS. 5 and 5A)

Referring to the first few lines before the blank line in the structures file, the general definition of the format of links, cases, fields, objects, and the system are provided. The remaining portion of the remaining frame file (after the first blank line) includes the current definition of the private fields, case links in the objects. -167-

Each of these objects, fields, links, and homes require the general format defined in the few lines at the top of the file. Of course, this arrangement need not be followed in all embodiments of the invention. However, the illustrated organization of a structure file has been shown to be effective.

To illustrate how the format of entries in the body of the structure file follow the definitions at the beginning of the structure file, you can see that in the line immediately after the first blank line, paiavra &quot; matches the word &quot; system &quot; just before the blank line. The word &quot; Spaceman &quot; (short for SPACE MANAger the application program of Logistics Data Systems, INC., Irving, Texas) corresponds to the &quot; ID &quot; in the definition. The number &quot; 1 &quot; means that the &quot; ID &quot; field is of type &quot; string &quot;.

Pinalmente, corresponding to the field &quot; description &quot; is the term &quot; data structure &quot; &quot; Spaceman III &quot; in title.

In the preferred embodiment, each object is first specified by declaring an object and naming it with an &quot; ID &quot; for example, &quot; warehouse &quot;. This particular example can be seen in the line after the second blank line in the structures file.

Following the object declaration are various field definitions. The &quot; warehouse &quot; is shown in Appendix A as having 14 fields. Each row is allocated to each field of the &quot; warehouse &quot; object.

Following the 14 field declarations are two connection definitions. -168-

There are no specifications of "cases &quot; under the &quot; warehouse &quot; object. However the object &quot; gondola &quot; has in fact boxes specification fields &quot; In the field whose &quot; ID &quot; is &quot; clog &quot;, the third field is seen as &quot; box &quot;. (Previous fields in the gondola object have a &quot; double &quot; or double (&quot; int &quot;) type, or integer (&quot; int &quot;).

But because the field &quot; obstruction &quot; has a &quot; box &quot; type, two specifications &quot; box &quot; get the &quot; obtru-tion &quot; field specification. The two boxes &quot; have &quot; tags &quot; which are or &quot; not &quot; or &quot; yes &quot;.

The following is a brief description of a format presented in the first few lines of the exemplary structure file shown in Appendix A.

CONNECTION ID. A unique and explanatory string showing the relationship between the two objects that binds. DESCRIPTION: A longer version of the ID, not necessarily unique, to be stamped to the user. MULTI-DONO; Specifies whether or not this link has multi-owners. MULTI-MEMBER: Specifies whether or not this link has multiple members. DE: Specifies the &quot; owner &quot; object. TRAINING: A link back to the name of the global structure of which it is a part. TO: Specifies the object in the &quot; member &quot; end of the call

BOX LABEL: The name corresponding to a particular value -169-

VALUE: Specifies an internally stored numeric value corresponding to &quot; label &quot;. DETERMINANT: Specifies the ID field that has the field type &quot; case &quot; DE: Link back to the object. TRAINING: A link back to the name of the general structure of which it is a part.

FIELD ID: 0 field name TYPE: Specifies the field type (ta; l as the character string, floating point, and so on). LENGTH: 1) Length of the Chain; 2) Numeric-how many characters to display, usually in the decimal representation. PREC: How many decimal places to display normally in the decimal representation VIS: Living to the user or totally hidden. HELP: Reference to a help message that explains the meaning of this field. PRE-INPUT: Call function before editing a field. POST-IN: Function called after editing a field. ONLY-FORMULA: Whether or not this field is stored in the record, or simply calculated from the formula each time it is needed. FORMULA: Formula or field (if present) based on other fields. DE: Reference to the object TRAINING: Reference to the global structure

OBJECT ID: Name of the object. objects to which it connects. DIMENSION; Large dwarf is a record of this object-computed internally based on fields / links. DRAWING: Default drawing function for this object. PRE-ADDITION: Function called before a new record of this type of object is added. POST-ENTRY: Function called after a new record of this type of object has been added or modified. FORMATION: Reference to the structure of which this object is part.

SYSTEM

Global name of the structure.

With the above description of an exemplary preferred structure file for an application program commonly used with the Operating Environment according to the preferred embodiment of the present invention, those skilled in the art may practice the invention, including loading, aggregation, conflict resolution of different application program structures. Also the means by which structure files are loaded and aggregated, with conflict resolution within Batch Data System according to preferred embodiment, is available here.

Claims (4)

1§. A method for concurrently executing one or more application programs, which have a variety of different data structures, characterized by comprising the steps of: detecting the presence or absence of field conflicts between fields defined in data structures defined in the programs of application; resolve such conflicts in case their presence is detected; aggregate the defined data structures of the various application programs into a common data structure; and executing an application program comprising the plurality of application programs, using said aggregate application programs using said common data structures so that the data formed within said common data structure is concurrently accessible by functions of one or more application programs. 2â. A method according to claim 1, characterized in that said execution step comprises displaying images of physical objects. 3â. A method according to claim 1, characterized in that the detection, resolution and aggregation steps collectively comprise: loading iteratively and cumulatively aggregating structures of one or more application programs. -172- 4â. A method according to claim 3, characterized in that each iteration of the iterative loading step and each cumulative aggregation step of the cumulative aggregation step comprises an iteration of a data transfer process comprising: 1) determining the type of data transfer to be of the &quot; interleaving &quot; type, comprising the type of data transfer &quot; interleaving &quot; the specification of: a) a &quot; direction &quot; indicating that the direction of the transfer is to be from an external data store to a destination file, b) a &quot; addition &quot; indicating that the data in the destination file is not deleted, and c) a signaling of &quot; not only updating &quot; indicating that the entry records update pre-existing records regardless of whether the keys of the entry records match the keys of the pre-existing records; 2) Initializes a channel for the source of a current application program; 3) performs a routine of &quot; reading format &quot; to determine an initial structure expected for the transfer; 4) determines additional specifications by which the records of the data entry registers are filtered; 5) performs a data reading routine 1.1 to transfer the records of the current application program along the channel according to the signals and according to the expected initial structure as modified by the additional specifications; 6) Closes the channel for the source of the current application program; and -173- 7) pre-calculated any fields based on a formula, which may be present in the target file. 5â. A method according to claim 4, characterized in that the step of determining additional specifications comprises: interaction with a user to receive or form the additional specifications. 6ã. The method according to claim 4, characterized in that: said initialization &quot; read format &quot;, and the closing steps comprise performing said initialization, &quot; read format &quot;, and closing steps substantially within a module of BDT software specific to a device that is connected to one of a number of high level BDS software modules for which the BDT module can be flexibly interconnected. Said step &quot; reading data &quot; understand the execution of the &quot; data read &quot; by iterative transfer of control between the BDT software module and the BDS software module to which it is connected; and said step of determining additional specifications comprises determining specifications while maintaining program control substantially within the BDS module for which the BDT module is connected. 7i. A method according to claim 4, characterized in that the step of performing a data read &quot; comprises executing a log loop, input to each log of an input file, the log loop comprising: 1) retrieving an object name for the; current registration; 2) verifying the object according to a table of required objects and determining the current iteration of the register loop if the current register is not required; 3) allocate space as needed for current entry registration; 4) to make the loop a field loop, each iteration of the field loop comprising the steps of; a) retrieve the value of a field for the current field; b) checking the value of a field according to a criterion in a table, and terminating the current iteration of the register loop if the current field does not meet the criterion; c) determining whether a field is required internally, and terminating that iteration of the field loop if not required internally; d) translate any field values into fields of different types, if necessary; e) transfer the field value along the channel; f) if the field is a &quot; binding &quot; field, by adding &quot; binding &quot; to a tree as that for searches the positioning of the register with respect to a structure that accumulates successive iterations of the record loop; and g) terminating the current iteration of the field loop, returning to the beginning of the field loop only if there are additional fields in the register after the current field; 5) perform a registry cleanup routine; and 6) terminating the current iteration of the log loop and returning to the beginning of the log loop only if there are additional logs after the current log. -175-. 8â. The method of claim 7, wherein the steps of retrieving an object name and retrieving a field value comprises performing said respective steps to recover substantially within a BDT software model of a specific device that is connected to one of a number of high-level BDS modules to which the BDT module may be flexibly interconnected. 9i. 7. A method according to claim 7, wherein the step of verifying the value of a field comprises: comparing the value of the field to a predetermined value to determine if the value of the field is equal to, than the predetermined value. 10 â. A method according to claim 7, wherein the step of verifying the value of a field as opposed to a criterion comprises: comparing the field value to a predetermined string and whether the field value is identical or not , to the pre-determined string. llã. Method according to claim 7, characterized in that the step of executing a registry cleanup routine comprises: 1) checking the final criterion after all fields have been processed and terminating the current interaction of the register loop if the field current is not in accordance with the final criterion; 2) fill in as many spaces in the tree as possible. based on the entry records; 3) fill in the remaining spaces with substitutes as if by correct attempts to register to the internal data structure; 4) check a registry key to determine if the registry present, is a duplicate registry or not; (a) if it is determined that this is a duplicate record, determine whether the original record is a substitute (i) if it is determined that the original record is not a substitute, perform a duplicate manipulation routine and correct the new record to the internal structure of the data structure. ii) in case the original record is determined to be a substitute, write over the substitute and connect the new record to the internal data structure; b) if it is determined that it is not a duplicate record, based on the state of the &quot; updating &quot; signaling, selectively i) correcting the new record to the internal data structure; or ii) ignore the entry record; and 5) leaving the end-of-record cleanup routine. 12§. The method of claim 11, wherein the space filling step comprises; s * v dock the entry object record, in the tree at the user's present location in the tree. 13 ã. A method according to claim 11, characterized in that the space filling step comprises: fitting the register entry object into the tree in the same location as the latest transfer object registration docked. Method according to claim 11, characterized in that the execution of a duplicate handling routine comprises: writing over the old record with the new record even though duplicate fields are written over. 15a. A method according to claim 11, characterized in that the execution of a duplicate manipulation routine comprises: writing over the old record fields which are new, so that non-duplicate fields are not written over. 16a. A method according to claim 11, characterized in that the execution of a duplicate handling routine comprises: ignoring the new record, so that the old record remains unchanged. -178- 17a. Method according to claim 11, characterized in that the execution of a duplicate manipulation routine comprises: changing the key of the new record so as not to be a duplicate of the old record. 18. A method of transferring a data block using an activated one of a set of high-level BDS modules flexibly interconnected with an activated one of a set of BDT software modules specific to a device for interaction with a processing process selected data zenamantine weapon, characterized by comprising the steps of: determining a transfer type; choosing which of the data storage types should be involved in the transfer, Initializing a channel between the activated BDT software module and the chosen data storage type, said initialization executed substantially in the activated BDT software module; determine, based on specifications of the activated BDS software module, which modules and fields to transfer; transfer the data between the chosen data storage type and the U.C. for which control is passed interactively between the activated BDS software module and the activated BDT software module; and closing the data channel between said BDT software module and said type of data storage. -179- 19a. A method according to claim 18, characterized in that the step of: pre-calculating fields based on formulas in the case of a transfer to the memory of the U.C. 20a. 6. A method according to claim 18, wherein said determining step comprises: interacting with a user to produce additional specifications about objects, fields and field criteria, in order to react subsequently to the characteristics of the data transfer . 21i. 5. A method according to claim 18, wherein said transfer step is a &quot; loading &quot; transfer means comprises the steps of: deleting all pre-existing data in the U.C.P. and transferring therein new data according to said specifications of the types of data storage and collected. 22â. A method according to claim 18, characterized in that the transfer steps are a &quot; interleaving &quot; comprising the steps of: retaining, at least temporarily, any pre-existing data in the U.C.P. from memory; and -180- transferring data according to said specifications of said types of data storage chosen for the CPU memory, said transfer step including transferring records regardless of the identification keys of the input registers to match those of the registers pre-existing in the CPU memory 23a. 8. A method according to claim 18, wherein said transfer updating step comprises the steps of: retaining, at least temporarily, any data pre - existing in the memory of the U.C.P .; and transfer data according to said specifications of the storage types chosen for the U.C.P. memory, but where the registers having identification keys do not correspond to the U.C.P. are ignored. 24ã. 7. A method according to claim 18, wherein said transfer step is an &quot; updating &quot; which comprises the steps of: retaining, at least temporarily, any data pre-existing in the types of data stores chosen; and transfer data in accordance with said specifications of the U.C.P. for the storage types of the chosen ones, but where records that have identifier keys that do not match the key identifiers of the records in the chosen storage types are ignored. -181- 25ã. 3. A method according to claim 18, wherein said transfer step is a transfer of &quot; which comprises the steps of: deleting any pre-existing data a target file in the chosen data storage type; and transfer data according to said specifications, from the U.C.P. for said type of data storage. 26ã. A method according to claim 18, characterized in that the steps of determining choice, initialization, determination, transfer and closure collectively comprise: loading iteratively and cumulatively aggregating data block structures. 27ã. A method according to claim 26, characterized in that each iteration of the iterative loading step and each cumulative aggregation step of the cumulative aggregation step comprises an iteration of a data transfer process comprising: 1) determining a type of data transfer to be of the &quot; merge &quot; type, the data transfer type &quot; merge &quot; comprising the specification of: a) a &quot; indicating the direction of the transfer as being from an external data storage type to a destination file; 182- b) an &quot; addition &quot; indicating that the existing data in the target file is not deleted, and c) a guard &quot; not only updated &quot; indicating that the entry records update the pre-existing records regardless of whether the keys in the entry records match. the keys to pre-existing records; 2) initializing a channel for the data block bridge; 3) execute a &quot; reading format &quot; routine, to determine an initial structure expected for the transfer. 4) determine additional specifications by which the records of the input data records are filtered; 5) performing a data reading routine to transfer the records of the data block along the channel according to the guards and according to the expected initial structure as modified by the additional specifications; 6) close the channel to the tip of the data block; and 7) pre-calculating any form-based fields that may be present in records in the target file. 28ã. A method according to claim 18, characterized in that said transfer step comprises a &quot; data writing &quot; in a routine comprising the following steps: 1) a loop in an internal register loop to determine whether the criteria for registers are found, return to the beginning of the register loop if the register does not meet the criteria and salts of the register loop if the registration is subject to the criteria; 2) a loop in a field loop, each iteration of which comprises: a) translating a value from a field of the current field to a type required by the type of required data storage; b) passing the field value to a device-specific BDT data transfer module; c) initializing the BDT data transfer module in case it is the first register to pass through the field loop; d) output the field to the external data storage type; and e) returning to the beginning of the field loop only if there are more fields in the record to be transferred; and 3) return to the internal log loop only if there are more logs to be transferred. 29ã. A method according to claim 28, characterized in that: the initialization and output steps comprise performing the initialization step and the output step substantially within an activated BDT software module. 30i. - Method of loading a structure file by defining objects, fields, and links, using an asset from a set of high-level BDS software modules level interface modules adapted to interact with a data storage type, characterized in that it comprises the steps of: Initializing a channel between the activated BDT software module and the type of selected data store, said initialization performed substantially within the activated BDT software module; transferring the structure file of the selected data storage type and the memory of the U.C.P., where the control is operatively passed between the activated BDT software module and the activated BDT software module; and closing the data channel between said BDT software module and the type of data storage. 31â. A system for concurrently executing one or more application programs, said application programs having a variety of different data structures, characterized in that it comprises; a detector to detect the presence or absence of field conflicts between fields defined in data structures defined in application programs; a corrector to resolve the said conflicts in case their presence is detected; an aggregator to aggregate the data structures defined in the various application programs a common data structures; and a processor for executing an aggregate application program comprising the plurality of application programs- said application programs using said common data structures so that the data formed within said common data structures are concurrently accessible by functions of one or more application programs. Fig. 8. A system according to claim 31, further comprising; a stamping system for stamping images of physical objects. 33ã. The system of claim 31, wherein detecting, correcting and aggregating collectively comprises: means for iteratively loading to cumulatively aggregate structures of one or more application programs. 34§. The system of claim 33, wherein the means for iteratively loading and cumulatively loading comprises a means for data transfer comprising: 1) means for determining a data transfer type as being of the &quot; interleaving &quot; type, the type of data transfer from &quot; merge &quot; comprising the specification of: a) a &quot; steering &quot; indicating that the direction of the data transfer is to be from an external data storage type to a destination file; -186- b) an &quot; addition &quot; indicating that the data in the target file is not to be deleted, and c) a guard of &quot; not only updating &quot; indicating that the input registers update the pre-existing registers regardless of whether or not the input register keys match the keys of the pre-existing data records; 2) means for initializing a channel to the source of a current application program; 3) a routine of &quot; reading format &quot; to determine an initial structure expected for the transfer; 4) means for determining additional specifications by which the registers of the input data registers are filtered; 5) a data reading routine &quot; to transfer program records to current applications along the channel according to the guards and according to the expected initial structure as modified by the initial specifications; 6) means for closing the channel to the bridge of the current application program; and 7) socks to pre-calculate any form-based fields that may be present in records in the target file. 35i. A system according to claim 34, characterized in that the means for determining additional specifications comprises: means for interacting with a user to receive or form the additional specifications. 361. A system according to claim 34, characterized in that the data reading routine &quot; comprising a register loop, executed for each input file register, the register loop comprising: 1) means for retrieving an object name for the current record; 2) means for checking the object against a table of required objects and for determining the current intersection of the register loop if the current register is not required; 3) means for allocating space as required for current input registers; 4) a field loop comprising; a) means for retrieving a field value for the current field; b) means to check the value of the field against criteria a table and to determine the current interaction of the register loop if the field does not meet the criteria; c) means for determining whether a field is required internally and for determining this field loop interaction if not required internally; d) means for translating any field values into fields of a different type, if necessary -188 e) means for transferring the value of the field along the channel; f) means, if the field is a &quot; link &quot; field, to add the link to a tree in order to detect the register positionally with respect to a structure that accumulates with successive interactions of the register loop; and g) means for terminating the current interaction of the field loop and returning to the start of the field loop only if there are additional fields in the register after the current field; 5) an end-of-registry cleanup routine; and 6) means for terminating the current interaction of the log loop and returning to the top of the log loop only if there are additional logs after the current log. 37â. A system according to claim 36, characterized in that the means for verifying the value of a field comprises: means for comparing the value of the field with a predetermined value to determine if the value of the field is equal to and greater than or less than the predetermined value. 38a. Systems according to claim 36, characterized in that the means for verifying the field value according to criteria comprise: means for comparing the field value to a predetermined character string, in order to determine whether the field value is identical or not identical to the predetermined value of the string. 39â. A system according to claim 36, characterized in that the means for executing a record-end cleaning routine comprises: 1) means for checking the final criterion after the fields have been processed and for terminating the current interaction of the loop register if the current field does not meet the final criterion. 2) means to fill as many spaces in the tree as possible, based on the input registers; 3) means to fill any remaining spaces with substitutes such as by attempts to correct the registry to the internal data structure, 4) means for verifying a registry key in order to determine whether the present registry is a duplicate or not; (a) means, where it is determined that it is a duplicate registration, to determine whether the original registration is a substitute; i) means, in the event that it is determined that the original record is not a substitute, to execute a duplicate processing routine and correct the new record to the internal data structure; ii) means, in case the original record is determined to be a substitute, to write over the substitute and correct the new record to the internal data structure; b) means, if it is determined that. it is not a duplicate record, based on the state of the &quot; updating &quot;, to selectively i) correct the new record to the internal data structure; or ii) ignore the entry record; and 5) means to exit the end-of-regimen cleaning routine. 40¾. System according to claim 39, characterized in that the space filling means comprises: means for engaging the input object in the tree at the user's present locations on the tree. 41a. A system according to claim 39, characterized in that the space filling means comprises: engaging means for entering the register entered into the tree at the same location as the latest transfer of the registration object to docked. 41¾. The system of claim 39, wherein the duplicate processing routine comprises: writing means over the old record with the new record, so that the same non-duplicate fields are written over. 44ã. The system of claim 39, wherein the duplicate processing routine comprises: means for overriding the new record, so that the old record is left intact. 45Â °. The system of claim 39, wherein the duplicate processing routine comprises: means for changing the key of the new record so as not to be a duplicate of the old record. 46a. A system for transferring blocks of information from and to a variety of variable structure data storage types, characterized in that it comprises: one or more high-level BDS software modules for specific transfer characteristics; and one or more BDT software modules specific to a device each, flexibly interconnectable with any of said BDS software modules, for interaction with respective data storage types. 47â. A system according to claim 46, characterized in that an active BDS software module and a BDT software module are connected as to transfer data between a portion of the U.C. and another portion of the memory of the U.C.P, -192- 48ã. A system according to claim 31, characterized in that the system including the BDS software modules and the BDT software modules further comprise: means for iteratively loading and cumulatively aggregating structures of one or more application programs. 49â. Systems according to claim 48, characterized in that the means of loading and accumulating cumulatively comprises means for transferring the data block, comprising: 1) means for determining a data transfer type as being of the &quot; interleaving &quot; type, comprising the data transfer type &quot; interleaving &quot;, the specification of: a) a &quot; address &quot; indicating that the transfer direction is to be from an external data store type to a destination file, b) an &quot; addition &quot; indicating that the data in the destination file is not to be deleted, and c) a "not only update" guard, indicating that the input registers update the pre-existing registers regardless of whether the input register keys correspond to the keys of the pre-existing registers. 2) means for initializing a channel apart from a current application program; 3) a routine of &quot; reading format &quot; to determine an initial structure expected for the transfer; . (I.e. 4) means for determining additional specifications by which the data entry registers are filtered; 5) a data reading routine &quot; to transfer the records of the data block along the channel according to the guards and according to the expected initial structure as modified by the additional specifications; 6) means for failing the channel to the data block source; and 7) means for pre-calculating any form-based fields that may be present in the target file. 50. The system of claim 31, wherein said BDS software modules each comprise! 1) an internal log loop comprising means for determining whether the logging criteria are found returning to the start of the log loop if the log does not meet the criteria and leaving the log loop if the log meets the criteria; 2) a field loop, the following means: a) means for translating a value from a current field to a required type in the chosen data storage type; b) means for passing the field value to a specific BDT transfer module; and c) means to return to the beginning of the field loop only if there are more fields in the register to be trans- injured; and means for returning to the beginning of the record loop to process a new record only if there are more records to process a new record only if there are more records to be transferred; and said BDT software modules each comprise: 1) initiating means of the BDT data transfer module in case this is the first register to pass through the field lane; and 2) means for outputting the field to the external storage type. A system for loading a structure file of a storage type defining objects, fields and links, characterized in that it comprises: an activated module of a set of high level BDS software modules interconnected with a module of a set of BDT software modules enabled, specific to a device for interaction with the type of data storage »chosen; an initialization module located substantially within the activated software module BDT, for initiating a channel between the activated BDT software module and the chosen data storage type; transferring modules for transferring the structure file of the chosen data storage type and the memory of the JU.C.P., for which the control is interactively passed between the activated BDS software module and the activated BDT software module; and a closure module for closing the data channel between said BDT soft- ware module and said type of data storage. Lisbon, October 20, 1989 J. PEREIRA DA CRUH AgfiPtt3 SScká Ú8 Frspnsilade taistrísl RUA VICTCí! CORD® N, 10-A, 1- * 1200 USBQ