CA2369854A1 - Conceptual interfacing technology - Google Patents

Description

The conceptual interfacing technology patent application (CONFIDENTIAL) 1. Background of the invention 1.1 Field of the invention The present invention describes a new methodology of designing and programming user interfaces. According to this new methodology, any user interface can be designed by using only three conceptual component types.
i.2 Background art The traditional way of designing user interfaces is by using specific components related to the development platform. The development platform can be a specific Operating System platform (e.g. Windows, Linux, Mac...} or a specific device (PDA, cell phone). For each of these platforms, a hierarchy of proprietary components is used, creating an incompatibility between each other. These components are usually related to visual capacities and specific capabilities of the target platform (components such as windows and buttons are common on GUIs whereas small menus are used on wireless devices), extending the incompatibility between GUIs and wireless interfaces. Moreover, they have inherent limitations: remote access is not available without external software and there is no multi-user collaboration functionality implemented.
Java was the best attempt to overcome the GUI incompatibility by offering its adaptable set of proprietary components. However, Java still offers at least three sets of UI components: AWT / SWING for GUIs, J2ME for wireless devices and JTAPI
for vocal access. It also doesn't really run remotely since applets must be downloaded first before running locally on the client.
So up to now, none of the existing user interface components is really portable on different platforms creating a necessity of redesigning and recoding to support other existing platforms. All these incompatibilities between different user interfaces are based on the following statement from the J2ME white paper:
"Consumer devices has substantial differences in memory size, networking, and user interface capabilities, making it very difficult to support all devices with just one solution."
1.3 Summary of the invention The objective of the present invention is to provide one solution which can support all devices whatever their differences are in memory size, networking andlor user interface capabilities. According to this method, users interfaces are no longer designed using specific components for specific target platforms, there are designed using three generic conceptual user interface components.
Using the generic conceptual components (subject of this invention), user interfaces are designed according to the needs of the user not to the capabilities of a specific The conceptual interfacing technology patent application (CONFIDENTIAL) platform. The look and feel is rendered at run-time and depends on the targeted platform or device.
This methodology doesn't only solve the problem of incompatibilities between the user interface of different platforms but also provides a new way of designing a user interface without having to think where it will be deployed. The generic aspect and natural portability of the conceptual user interface generates a substantial relief for the software developers who will not be anymore obliged to understand the capabilities of the different platforms or devices. Instead, they will focus more on designing and defining the functionalities of the application than on accommodating it to run on specific platforms.
According to its conceptual nature, this invention does not only resolve all the user interface incompatibilities for the existing platforms and devices, it will accommodate any substantial future platform or device. To finish, this invention does definitely create a new way of designing or even more defining user interfaces, a way that will make it possible for all devices to interact between each other.

2. Brief description of drawings FIG. 1 shows the conceptual interfacing process that occurs between the application logic and the end-user;
FIG. 2 presents the conceptual user interface;
FIG. 3 presents the inheritance diagram of the UI conceptual components;
FIG. 4 shows the general data structure and the modification methods of the UI
conceptual component;
FIG. 5A, FIG. 5B and FIG. SC respectively describe the data structure and modification methods of the container, control and text conceptual components;
FIG. 6 shows a tree of Conceptual Components (CCs), used for many examples;
FIG. 7 shows the different d-sizes (Base, Labels Matrix, States Matrix, Selection, Container, Values Matrix and Read-Only Flags Matrix);
FIG. 8 shows, for a Control conceptual component with a 2-dimensioned base d-size, the different renderings calculated from its label scope flags and its number of selection dimensions;
FIG. 9A and FIG. 9B illustrate in a real example the AND / OR relationship between the component children;
FIG. 10 illustrates MDI windows which occur when insertlremove flag of a 1-dimensioned CC is true.

3. Description of the invention 3.1 Flow Chart With reference initially to FIG. l, schematically shown therein is the flow of information between the Application Logic 5 and an End-User 20. Within the Application Logic 5, the Conceptual UI 10 is created by using Conceptual The conceptual interfacing technology patent application (CONFIDENTIAL) Components (explained later). The Conceptual UI 10 is rendered by the Rendering Adapter 15, a piece of software residing on any platformldevice, and is interpreted by the End-User 20. Conversely, the End-User 20 may modify the Application Logic 5 by applying actions on it. The Conceptual Interfacing 25 methodology, subject of this invention encloses the Conceptual UI 10 and the Rendering Adapter 15.
To understand this Conceptual Interfacing 25 process, three different parts are to be discussed in details:
1. The Conceptual UI 10 that is a stack of references to UI Conceptual Components.
2. The Conceptual Components needed to build a complete Conceptual UI
according to this invention.
The Rendering Adapter 15 that renders in real-time, from the Conceptual UI 10, a visible and interactive user-interface according to the specifications and capabilities of the End-User 20 target platform/device.
3.2 Concepfuai UI
A Conceptual UI is a user-interface model expressed in mathematical terms such as matrices and sets, instead of device-specific terms such as windows, buttons and menus.
Referring to FIG. 2, the implementation of a Conceptual UI 40 is a simple stack of references to conceptual components, detailed in the next section. References in the stack may be null as well (the reason is explained later). Both stack and conceptual components are entirely managed by the application logic.
Consider the Conceptual Component for now as the base unit defining user-interface information presented to the user. When a Conceptual Component is created in the application, it is not immediately rendered to the user. The rendering of this Conceptual Component to the user happens only at the time the Conceptual UI 40 adds a reference to it. A Conceptual Component referenced by the Conceptual UI
40 is said to be linked. A Conceptual Component not referenced by the Conceptual UI
40 is considered unlinked. Referring to FIG. 2, the Conceptual Component 50 and the Conceptual Component 55 are linked, whereas the Conceptual Component 60 is unlinked.
At application initialization, the Conceptual UI 40 stack is always empty.
Like any stack, the Conceptual UI has two methods: Push(CC) 65 and Pop() 70.
The Push(CC) 65 will add a reference, at the top of the stack, that points to either a valid Conceptual Component or null. When a new Conceptual Component is pushed in the Conceptual UI 40 stack, it becomes linked and the previously pushed Conceptual Component (if any) becomes read-only. User interaction always takes place only on the Conceptual Component located at the top of the stack, even if all linked Conceptual Components are rendered. When the null value is pushed in the Conceptual UI 40 stack, no user interaction is allowed for any linked Conceptual Components, until either Pop() 70 is called or a new Conceptual Component is pushed.

The conceptual interfacing technology patent application (CONFIDENTIAL) The Pop() 70 method removes the last pushed reference from the top of the stack.
User interaction is redirected to the new top Conceptual Component, if not null.
For the sake of clarity, the Conceptual UI 40 will be referred to as the CUI
in the remaining of this document.
3.3 Concepiuaf Components Any platform user-interface in order to be effective only needs the three following basic element types:
1. Containers that are sets of elements. Some elements within a container may be containers as well, allowing a hierarchical organization of the elements required to build a user-interface.
2. Controls where selections from the end-user can be made, allowing him to command the application logic.
3. Texts where end-user can enter character strings that are interpreted either by the application logic or by other end-users.
In conventional user interface APIs, a complex hierarchy of component types is declared to express those three UI basic types. In Graphical user-interfaces, windows, forms and menus are examples of containers; buttons, check boxes, list boxes, menu items are examples of controls; text fields, edit boxes, and note boxes are examples of texts. Our purpose in this invention is to mirror those three UI basic types into three and only three Conceptual Components. These Conceptual Components encapsulate all the required container, text and control functionality making it possible for the software developer to design a complete and effective conceptual user-interface.
Consequently, a conceptual user-interface is fully portable across all platforms and devices. Furthermore, using this new UI modeling approach, the software developer will not have to wonder which specific UI components must be used for a specific target platform or device. He will just have to define which specific functionality is needed, translate it into a conceptual user-interface with Conceptual Components and the choice of the required specific device components will be automatically made in the rendering process.
So, a Conceptual Component is the base unit of a conceptual user-interface that englobes either the container, control or text functionality. For the sake of clarity, a Conceptual Component will be referred to as the CC in the remaining of this document. CCs include Container CCs, Control CCs and Text CCs. These are the three CC types.
Each CC has a matrix of values. The value type depends on the CC type. The value type of a Container CC is a set of other CCs (and some of them can also be Container CCs, which makes up a CC tree) and a selected child CC. The value type of a Text CC
is an editable text. The value type of a Control CC is a selected state. When the application logic clearly knows how the value (either Container, Text or Control) should look like to the end-user, it does so by associating an image with the value that will be used in the rendering if possible (mostly for GUIs). So a value is composed of an image and either a CC set, a text or a selected state. There can be many values within a CC. These values are elements from a matrix, which characteristics are specified by the application logic.

The conceptual interfacing technology patent application (CONFIDENTIAL) Referring to FIG. 3, shown here is the inheritance diagram representing the three CCs needed to build conceptual UIs. The Container CC 80, the Control CC 85 and the Text CC 90 are all inherited from the CC 75. The CC 75 contains the common functionality of Container, Control and Text CCs. And since any CC value can be represented by an image, all image processing resides in the CC 75 base class. So, the three CC
types are sufficient to define any user interface.
Before explaining the inner workings of the CC 75 and all its derived classes, four concepts need to be understood.
The concept of a d-number ("d-" stands for "dimensioned-") is a multi-dimensioned number, composed of a number of dimensions, greater than or equal to 0, and a set of integer values associated to each dimension. For example, { 3, 2, 5 } is a 3d-number with values 3 for the first dimension, 2 for the second and 5 for the third dimension.
'The Od-number is expressed as { }. The number of dimensions and the values of a d-number may be modified. Operators such as =, +, -, <, >, <_, >_, =, !_, may apply between two d-numbers. When these operators are used, it is assumed that both d-numbers have the same number of dimensions and that the operator is applied for the corresponding values of the two operands for all dimensions. For example, {3,

4} <
{6, S} is true because 3 < 6 and 4 < 5, but { l, 3} < {2, 2} is false, since 1 < 2 but 3 >
2 (the operator < is false for the second dimension). When one operand is 0, the 0 in fact means a d-number that has a number of dimensions equal to that of the other operand and that all values are 0. So { 6, 5 } >= 0 is true but { 6, -3, 2 } >
0 is false.
There are many modification methods that used type dnum for parameters which is the type of a d-number. Value dnumnull always refers to the Od-number { }.
The concept of d-size is a d-number used to represent a multi-dimensioned area. The number of units in the area is the product of all dimension values. For example, d-size {7, 6} describes a 2-dimensioned area of 42 units. The Od-size { } always has 1 unit.
The units within the d-size are undefined.
The concept of a d-coordinate is a d-number used to locate a unit within a d-size. The coordinate must always have the same number of dimensions than its corresponding d-size. Usually, d-coordinate >= 0 and d-coordinate < d-size (or d-coordinate <= d-size). The Od-coordinate unit always refers to the only unit of Od-size { }.
The concept of a matrix is a collection of values of the same type, located into the units of a multi-dimensioned area. The matrix always has a d-size and content, which is the set of elements. Elements of the matrix can be of any data or object type (number, structure, array, even another matrix).
Finally, for the rest of this document, the Values Matrix always refers to either the Containers Matrix, the Controls Matrix or the Texts Matrix, depending on the CC
type.
With reference to FIG. 4, the CC 100, following the object-oriented concept, contains Data 105 and Modification Methods 110. The Data 105 of the CC encapsulates three matrices that will form the complete user information: the Labels Matrix 115, the Read-Only Flags Matrix 120 and the Images Matrix 125. These three matrices are superposed in order to give complete information to the user. The Modification Methods 110 are methods used to modify or update the Data 105 of the CC 100.
In the Modification Methods 110 column, Initialization time always means that the The conceptual interfacing technology patent application (CONFIDENTIAL) associated Data 105 member is set once at the creation of the CC. All information set at Initialization time cannot in any way be modified for the CC lifetime.
Still referring to FIG. 4, the Base d-size 150, entered at Initialization time will be used as the foundation for the calculation of the Labels Matrix 115 d-size, Read-Only Flags Matrix 120 d-size and Images Matrix 125 d-size and also other relevant d-sizes.
Referring to FIG. 7, it is shown clearly that the Base d-size 150 is used to calculate five different d-sizes that may be used by the CC.
Returning to FIG. 4, the Constant Flags 175 is a list of flags used to put constraints on the Base d-size 150. The size of the list of flags must be equal to the number of dimensions of Base d-size 150 to have a Constant Flag 175 per Base d-size 150 dimension. When one Constant Flag 175 is true, it means the corresponding Base d-size 150 value has to be specified directly at CC Initialization time. When it is false, the Base d-size 150 value' is 'automatically set to zero at Initialization time, but then can to grow or shrink with insert(dnum start, dnum range) 155 (start >= 0, start <=
Base d-size 150 and range >= 0) and remove(dnum start, dnum range) 160 (start +
range <= Base d-size 150, start >= 0 and range >=0). On constant dimensions, insert(dnum start, dnum range) 155 and remove(dnum start, dnum range) 160 will move values in (for remove) or out of (for insert) the constant size of the dimension (values out of the constant dimensions are deleted, new inserted values are empty).
The Constant Flags 175 are also used for the rendering. A practical illustration of the use of the Constant Flags 175 use in the rendering is the scroll bars existing in Win32, activated by Constant Flags 175 set to true; otherwise they are deactivated.
The InsertlRemove Flags 180 are, just like the Constant Flags 175, a list of flags, which size is also equal to the number of dimensions of Base d-size 150 (to have an Insert/Remove Flag 180 per Base d-size 150 dimension). An InsertlRemove Flag with value true means that the end-user is allowed to insert/remove units from the corresponding Base d-size 150 value by sending insertlremove events to the CC.
A
false value means the end-user cannot insert/remove units from the corresponding Base d-size 150 value. Therefore, the user is forbidden to send insert/remove events.
A practical illustration of the use of the Insert/Remove Flags 180 is a multiple document interface (MDn in Win32. Referring to FIG. 10, any of the documents (documentl 1050, document2 1055, document3 1060) is subject to insertion/removal (the Insert/Remove Flag is true).
Referring to FIG. 4, the Default Action Flag 185, if set to true, specifies that no event generated from user interaction in the CC will be passed on to the application logic, for further processing. Instead, the default behavior of user interaction in the CC will take place, without notifying the application that a change has occurred. For example, for most text-entry fields, the application never changes the normal behavior of modification events such as additions and removals of letters and therefore should not know about these events. 'The Default Action Flag 185, if set to true, can considerably speed up processing when there is a long delay between the user interaction on the client device and the reception of the event by the application. If the Default Action Flag 185 is set to false, user input is temporarily disabled when the user modifies the component. The user input will be re-enabled when the Push(CC) 65 (the CC may be null) and then Pop() 70 methods in FIG. 2 are called. In the meantime, the user is prohibited from entering other information while a previous command is still executing. For example in an address book, after the user has entered the first name, The conceptual interfacing technology patent application (CONFIDENTIAL) surname and phone of a contact he presses a submit button, he must be prevented from typing other information while the submission is being processed. Any attempt to modify the application at this time will be discarded, ensuring a safe use of the application.
Referring to FIG. 4, the Semantic Type 190 is a string that is used to identify a convention if applicable. Many applications have user interface fields that refer to known conventions, such as date, time, phone number, postal code, password, etc.
Many user interfaces have specific controls (semantic controls) that handle these so commonly user fields. Their look & feel might be different across platforms, but ultimately they refer to the same human convention. If the CC refers to a human convention, the Semantic Type 190 string will be one entry from a pool of predefined convention strings like "date", "time", "zip code", and "password". If the user interface does not have a semantic control for a given convention, the Semantic Type 190 string is not used. An empty string in the Semantic Type 190 indicates that the CC
does not refer to a human convention.
The User-Defined Flags 195 address the Labels Matrix 115, the Read-Only Flags Matrix 120 and Values Matrix (including the Images Matrix 125). Although those three matrices are detailed later, consider them as matrices of user information elements for now. By default, these information elements will be stored in internal memory by the rendering adapter, on behalf of the programmer. However, if a User-Defined Flag 195 is true, its corresponding information elements must instead be defined by the programmer in his source code (only the viewed part of the information will reside in the rendering adapter memory, for displaying purpose). The programmer will have to redefine the retrieval methods to get accurate data from its proprietary storage mechanism. The User-Defined Flags 195 are usually required when the information consumes too much memory to be blindly stored by the rendering adapter internal mechanism. For example, in an Excel sheet, the cells are not all stored in Windows rendering adapter memory using a huge string array. In this case, the Excel programmer holds a structure where only the non-empty cells are stored. The programmer of a conceptual Excel application must set the sheet component User-Defined Flag 195 for the Values Matrix to true and establish links between the sheet component and his own structure by redefining the retrieval methods. The User-Defined Flags 195 are also useful when all the corresponding information elements can be retrieved using a mathematical formula. Instead of storing all information elements of the formula in memory, by setting to true the User-Defined Flags 195 the programmer can dynamically call the formula within the retrieval method when needed and avoid wasting memory space.
3.3.1 Labels Matrix Referring to FIG. 4, the Labels Matrix 115 is used to describe the Values Matrix to the user. A label is a small description that is composed of a text string and a bitmap.
The Scope Flags 210 determine which dimensions of the Values Matrix will have labels. They are used in conjunction with the Base d-size 150 to determine the Labels Matrix 115 d-size, as shown in FIG. 7. Referring now to FIG. 4, the Scope Flags 210 are a set of flags corresponding to each Base d-size 150 dimension. Each one of those flags is set at Initialization time and interpreted as follows:

The conceptual interfacing technology patent application (CONFIDENTIAL) o if true, the corresponding Base d-size 150 dimension will be copied in Labels Matrix 115 d-size;
o if false, the corresponding Base d-size 150 dimension will not be copied in Labels Matrix 115 d-size.
Referring to FIG. 8, consider a CC that has two-dimensioned Base d-size { 2, 3 } 900.
If the Label Scope Flags 910 are { true, true} 965, the Labels Matrix d-size is { 2, 3 }
and has 6 different Labels (one label per first and second dimension coordinate). If the Label Scope Flags 910 are set to { true, false } 960, the Labels Matrix d-size is { 2 }
(only the first dimension has labels) and there are 2 labels. If the Label Scope Flags 910 are set to {false, true} 955, the Labels Matrix d-size is also {3} (only the second dimension has labels) and there are 3 labels. Finally, if the Scope Flags 910 are set to {false, false} 950, the Labels Matrix d-size is { } and there is a single label, which can be set to "".
Returning back to FIG. 4, the Scope Flags 210 are very useful since setting some flags to false means that for the corresponding dimensions, the same label in Labels Matrix 115 will apply to many elements of the Values Matrix. In the rendering, it will be used as a single header for a list of values.
The String Max Length 215 contains the maximal length the text string of any label in the Labels Matrix 115 can have. If the String Max Length 215 if 0, no text string can be entered within labels.
The Bitmap Size 220 specifies the size, in pixels, of all bitmaps in Labels Matrix 115.
If the Bitmap Size 220 width and/or height are equal to zero, then the Labels Matrix 115 cannot contain any bitmap.
The Labels Matrix 115 content will either be stored in the Buffered Storage System 225 residing in the application Logic, the Default Storage System 230 residing in the CC or a User-Defined Storage System 245 residing in the application logic, depending on the label User-Defined Flag 195, the Constant Flags 175 and the Scope Flags 210.
If the label User-Defined Flag 195 is set to false and all Constant Flags 175 are true (constant) for the dimensions where Scope Flags 210 are true, the Buffered Storage System 225 is used. In this case, the application must supply at initialization time a buffer of length (String Max Length 215 + 1 ) x Product of Labels Matrix 115 size that contains the text strings if String Max Length 215 is greater than 0 and, if Bitmap Size 220 is not null, a buffer of length Size Of Bitmap Structure x Product of Labels Matrix 115 size that will contain bitmaps.
If the label User-Defined Flag 195 is set to false and at least one Constant Flags 175 is false (not constant) for the dimensions where Scope Flags 210 are true, the Default Storage System 230 is used. Empty label elements can be created with insert(dnum start, dnum range) 155 for the dimensions where Scope Flags 210 are true.
For both Buffered Storage System 225 and Default Storage System 230, the method setlabel(char *label, dnum index = dnumnull) 235 is used to modify the text string of the label element pointed to by index d-coordinate and method setbitmap(Bitmap *bitmap, dnum index = dnumnull) 240 must be used to modify the bitmap of the label element pointed to by index. In both methods, the index parameter is a d-coordinate within Labels Matrix 115 d-size (index >= 0 and index < Labels Matrix 115 d-size).

The conceptual interfacing technology patent application (CONFIDENTIAL) If the label User-Defined Flag 195 is set to true, the User-Defined Storage System 245 is used. The updatelabels(dnum pos, dnum range) 250 can be used to refresh the label rendering whenever a corresponding change in the proprietary label storage mechanism of the application logic has occurred. The pos and range parameters must have the same number of dimensions than Base d-size 150, pos >= 0, range >= 0 and pos + range <= Base d-size 150.
3.3.2 Read-Only Flags Matrix Referring to FIG. 4, the Read-Only Flags Matrix 120 content determines whether or not the Values Matrix elements enable user input. If true user input is disabled, otherwise it is enabled. As shown on FIG. 7, the Read-Only Flags Matrix d-size 785 is equivalent to the Values Matrix d-size 780. The calculation of the Values Matrix d-size 780 is explained later in this document.
Returning to FIG. 4, the Constant Flag 270 is set at initialization time. If its value is true, all Values Matrix elements in the CC are considered read-only for the CC
lifetime. Consequently, the Read-Only Flags Matrix 120 will never be created nor accessed by the application logic. Methods updateroflags(dnum pos, dnum range) and setroflag(boolean flag, dnum index = dnumnull) 280 cannot be called.
However, if the Constant Flag 270 is set to false, the Read-Only Flags Matrix 120 values can be set to true or false to forbid or allow user editing on the corresponding Values Matrix elements within the CC. Methods updateroflags(dnum pos, dnum range) 290 and setroflag(boolean flag, dnum index = dnumnull) 280 can be called to modify Read-Only Flags Matrix 120 content.
The Read-Only Flags Matrix 120 content will either be the Default Storage System 275 residing in the rendering adapter or a User-Defined Storage System 285 residing in the application logic, depending on the read-only User-Defined Flag 195.
If the read-only User-Defined Flag 195 is set to false, the Default Storage System 275 is used. The method setroflag(boolean flag, dnum index = dnumnull) 280 modifies the read-only flag element pointed to by index. The index parameter is a d-coordinate within Read-Only Flags Matrix 120 d-size (index >= 0 and index < Read-Only Flags Matrix 120 d-size).
If the read-only User-Defined Flag 195 is set to true, the User-Defined Storage System 275 is used. Method updateroflags(dnum pos, dnum range) 290 will refresh the read-only flag rendering whenever a corresponding change in the proprietary read-only storage mechanism of the application logic has occurred. The pos and range parameters must have a number of dimensions equal to the Read-Only Flags Matrix 120 d-size, pos >= 0, range >= 0, pos + range <= Read-Only Flags Matrix 120 d-size.
3.3.3 Images Matrix The Images Matrix 125 is used by the application logic to express CC values (eit).~er containers, control selections or texts) with a graphical representation.
In any user interface, an image is a two-dimensioned array of pixels. The 2D
size 320 specifies, in pixels, the width and height of all images in the Images Matrix 125. It is set at Initialization time. Both width and height must be greater than or equal to 0. If 2D size 320 is not 0 for width and height, and the values User-Defined Flag 195 is set The conceptual interfacing technology patent application (CONFIDENTIAL) to false, the images are stored in a Default Storage System 325 and can be modified via a set of Text & Graphical Commands 330. The index parameter at the end of all Text & Graphical Commands 330 is a d-coordinate within Images Matrix 125 d-size (index >= 0 and index < Images Matrix 125 d-size). If 2D size 320 is not 0 for width and height, and the values User-Defined Flag 195 is set to true, the images are stored in a User-Defined Storage System 335. Method updatevalues(dnum pos, dnum range) 340 (pos >= 0, range >= 0, pos + range <= Images Matrix 125 d-size) will refresh the image rendering whenever a corresponding change in the proprietary value storage mechanism of the application logic has occurred. If 2D size 320 width or height is 0, Images Matrix 125 becomes inactive and is not used by the application logic.
The application logic may use the Images Matrix 125 to precisely control the rendering and user input of each Values Matrix conceptual element (container, control, text). The Images Matrix 125 d-size is always equal to the Values Matrix d-size. The Values Matrix d-size depends on the CC type and its calculation is detailed in the Container CC, Control CC and Text CC sections.
The rendering process of the Values Matrix is decided as follows.
o If the rendering adapter resides in a sophisticated platform where the user can view/manipulate images and the Images Matrix 125 is used (that is, the 2D
size 320 applicable to all images is not null), the Images Matrix 125 takes precedence over the conceptual elements (controls, texts, containers) matrix and images are displayed. Images from the descendent CCs (if the CC is a container) are also displayed within the CC images, at the specified position.
o If the rendering adapter resides in a limited platform where the user can barely view/manipulate images or the Images Matrix 125 is not used (that is, the 2D
size 320 applicable to all images is null), the conceptual elements matrix is directly used by the rendering adapter, which will use native device components to render the values.
3.3.3.1 Container CC
Referring to FIG. 5A, a Container CC 360 is used as a set of other CCs, referred to as child CCs. A Container CC 360 is used to build complex user interfaces, by building a tree of CCs. When rendered, it may end up, for example, in a menu or a window containing controls built from child CCs.
The Children Set 365 is a list of references to child CCs, they must be set immediately at initialization time. The Children Set 365 can be empty if desired. The Children Set 365 is subject to restrictions if the Semantic Type is not null and refers to a valid convention. In this case, the Children Set 365 (and all the descendants) must follow that convention to be effective. Furthermore, the read-only values and the values user-defined flag of the Container CC 360 also apply for all the child CCs values.
For example, if a Container CC 360 is not editable (read-only flag is true) its entire child CCs are not editable as well.
Each child CC also contains an internal Parent variable that will always reference its current Container CC 360. When a CC is not referenced by a Container CC 360, the Parent variable is set to null. Only CCs where Parent is null can be pushed in and The conceptual interfacing technology patent application (CONFIDENT'IAL) popped out of the CUI. The root Container CC 360 of each tree is the Container CC
360 that is directly referenced by the CUI.
Since the Children Set 365 of the Container CC 360 is set at Initialization time, the order of creation of the CCs that will be part of a CC tree is fundamental.
CCs must be created following their bottom-up order in the tree. For example, referring to FIG. 6, a convenient creation of the CC tree is by first creating CC { 7, 3 } 705, then CC { } 715, then Container CC { 4, 3, 2 } 720, then Container CC { 5 } 710 that immediately references CC { } 715 and Container CC {4, 3, 2} 720 at Initialization time, and finally Root Container CC { 2, 4 } 700, which references CC { 7, 3 } 705 and Container CC {S} 710 at Initialization time. The destruction order of the CCs in the CC
tree always happen in the reverse order of their creation.
Referring to FIG. 5A, all CCs referenced by a linked Container CC 360 are linked as well and will be rendered to the user. It means that a root Container CC 360 that is pushed in the CUI is not alone to become linked. All its descendants are also linked and consequently rendered to the user. The entire tree is considered linked.
The Child Relation flag 370, set at Initialization time, regulates the kind of relation between child CCs. This relationship is either AND-typed or OR-typed. In an AND-typed relationship, all the children are required to form the complete information. In an OR-typed relationship, the children are independent from each other and each child is considered one piece of information. The Child Relation flag 370 is heavily used in the rendering process and can influence which native control is chosen to render a component. Referring to FIG. 9A, an example of AND-typed relationship is a tax credit form 1000, where all fields (Name 1005, Address 1010 and Age 1015) are required to calculate the income tax. Referring to FIG. 9B, an example of OR-typed Win32 rendering for a Container CC is a Tab Control 1025 where each tab item (Name 1030, Address 1035 and Age 1040) refers to one piece of information (one child CC) and the end-user can switch between tab items.
Returning to FIG. 5A, the Select CC Flag 375, set at Initialization time, is only relevant for an OR-typed relationship (Child Relation flag 370 set to OR). In this case, the Select CC Flag 375 enables or disables the end-user to interact with any child CC, even if only one is rendered at a time. When the Select CC Flag 375 is true (only one child CC is visible at one time), it means that the end-user is allowed to select which child CC he desires to interact with in the Container CC 360 by sending select CC
events to the CC. The rendering in this case can be performed, for example, with Win32 tab controls, where the user can select from any tab item to use its content.
When it is false, the end-user cannot select which child CC is visible.
Therefore, he is forbidden to send select CC events. Win32 tab controls cannot be used in this case for the rendering.
The Values Matrix element in a Container CC 360 is the Children Set 365 (and the Selected CCs Matrix if applicable). Therefore, the Children Set 365, which is unique, must be duplicated in each element of the Values Matrix. The Values Matrix d-size is calculated from two factors: d-size accumulation and Container d-size.
D-size accumulation, expressed with operator I, happens when each element of a matrix is another matrix, as it happens in CC trees. For example, a two-dimensioned matrix of d-size {4, 2J may contain elements that are three-dimensioned matrices of d-size {3, 5, 2}. The d-sizes of the two matrices can be accumulated to form one 1'he conceptual interfacing technology patent application (CONFIDENTIAL) matrix of d-size { 4, 2, 3, 5, 2 } (e.g. { 4, 2 } I { 3, 5, 2 } _ { 4, 2, 3,

5, 2 } ). D-size accumulation is associative (e.g. { 4, 2 } ( { 3, 5, 2 } is equivalent to { 4, 2, 3 } I { 5, 2 } ), but not commutative (e.g. { 4, 2 } I { 3, 5, 2 } is not equal to { 3, S, 2 } I
{ 4, 2 } ).
Referring to FIG. 7, the Container d-size 770 of a CC is itself an accumulation of all the Base d-sizes 750 of its parent Container CCs, from the root Container CC
to the Container CC that directly references the CC. The Container d-size 770, to exist, must apply to a linked CC, else it is always { }. With reference to FIG. 6 that shows a linked CC tree with the base d-size of each CC (the Container CC 720 has no children). The Root Container CC 700 will always have Container d-size { } (1 unit). The CC

and Container CC 710 Container d-size is {2, 4} (8 units), since they are the children of Root Container CC 700. The CC 715 and CC 720 Container d-size is {2, 4, 5}
(40 units). This Container d-size is the accumulation of CC 700 and Container CC

base d-sizes.
Refernng to FIG. 7, for any Container CC, the Values Matrix d-size 780 is the d-size Accumulation 775 of its Container d-size ?70 and its own Base d-size 750. For example, returning to FIG. 6, the Values Matrix d-size of Container CC 720 would be { 2, 4, 5 } I { 4, 3, 2 } _ { 2, 4, 5, 4, 3, 2 } (960 units).
Returning to FIG. 5A, for an OR-typed child relationship (Child Relation flag 370 set to OR), two storage systems for the selected CCs Matrix values are available:
the Default Storage System 380 and the User-Defined Storage System 390. The Selected CCs Matrix contains the indexes of the child CCs that have been selected by the end-user in the case of an OR-typed relationship. For an AND-typed relationship the Selection CCs Matrix and the described storage system is not relevant (and then, not created). If the values (containers in this case) User-Defined Flag is set to false, the Default Storage System 380 will store the Selected CCs Matrix of the Container CC
360. The Selected CCs Matrix values can be changed anytime with method selectcc(int childindex, dnum index = dnumnull) 385 (childindex >= 0, childindex <
Number of Child CCs, index >= 0 and index < Values Matrix d-size).
If the values User-Defined Flag is set to true, the Selected CCs Matrix is stored in a User-Defined Storage System 390. Method updatevalues(dnum pos, dnum range) 395 (pos >= 0, range >= 0, pos + range <= Values Matrix d-size) will refresh the rendering whenever a corresponding change in the proprietary Selected CC storage mechanism of the application logic has occurred.
3.3.3.2 Control CC
Referring to FIG. 5B, a Control CC 400 is used to make selections from a matrix of states (the states content are taken from the CC labels, as explained later).
These selections are useful for the user to control the application logic behavior.
For a Control CC 400, there are two useful d-sizes that are relevant: the States Matrix d-size and the Selection d-size.
The Number of Selection Dimensions 405 is used to calculate the States Matrix d-size and the Selection d-size. The Number of Selection Dimensions 405 must be greater than or equal to 0 and less than or equal to the Base d-size 150 number of dimensions.
Referring to FIG. 7, the Base d-size 750 is divided into two d-sizes: the Selection d-size 765 and the States Matrix d-size 760. The Selection d-size 765 is composed of alt the first dimensions from Base d-size 750 within the CC Number of Selection The conceptual interfacing technology patent application (CONFIDENTIAL) Dimensions. The States Matrix d-size 760 is composed of all other Base d-size dimensions. For a zero-dimensioned Base d-size 750, both the Selection Size 765 and the States Size 760 are { }.
The States Matrix d-size 760 is the d-size of selectable states. The Selection d-size 765 is the d-size of selections per unit in the Container d-size 770. When the Control CC is linked, the Values Matrix d-size 780 in computed via the d-size Accumulation 775 of the Container d-size ?70 and the Selection d-size 765. In a Control CC, the Values Matrix is composed of selections, which are d-coordinates of the selected state within State Matrix d-size 760 (selection >= 0 and selection < State Matrix d-size 760).
Referring to FIG. 8 is shown the effect of the Number of Selection Dimensions 905 in different situations. Starting with a CC of Base d-size { 2, 3 } 900, if the Number of Selection Diiriensions 905 is 2, all Base d-size 900 dimensions go into the Selection d-size 915, leaving nothing to the States Matrix d-size 920. If the Number of Selection Dimensions 905 is I, the Selection d-size 915 claims the first Base d-size 900 dimension {2}, whereas the States Matrix d-size 920 claims the second dimension {3}. Finally if the Number of Selection Dimensions 905 is 0, the Selection d-size 915 claims is zero-dimensioned { }, and States Matrix d-size 920 claims all the dimensions of the Base d-size 900 { 2, 3 } .
FIG. 8 also shows the rendering of the Control CC. Note that for each of the three values of the Number of Selection Dimensions 905 (0 , l and 2), four values of the Label Scope Flags 910 are possible ( { false, false } 950, { false, true }
955, { true, false }
960 and{true, true} 965), giving a total of 12 different rendering possibilities which been evaluated on the assumption that Container d-size is { }. In this case, there will be Selection d-size 915 selections each one offering States Matrix d-size 920 states.
The states are composed, when possible, from labels taken from the Labels Matrix.
For States Matrix dimensions where Label Scope Flag 910 is false, the States are unnamed.
Four Win32 rendering possibilities (Rendering I 970, Rendering 2 975, Rendering 3 980 and Rendering 985) from the twelve shown in FIG. 8 are explained as followed.
Considering the Number of Selection Dimensions 905 equal to 0 and the Label Scope Flags 910 equal to {false, false} 950 (1 label), the generated Rendering 1 970 represents { } selection ( 1 selection) over { 2, 3 } states (6 states). It is expressed in Win32 as a check box that sets the first dimension value and a track bar that sets the second dimension value, included in a group box labeled A. Both the check box and the track bar were chosen for Rendering 1 970 because they do not contain labels (the Label Scope Flags 910 are false for both dimensions). The combination of the check box value and the track bar value expresses the current state (in this case, {
0, 0} ).
Considering the Number of Selection Dimensions 905 equal to 1 and the Label Scope Flags 910 equal to {false, true} 955 (3 labels), the generated Rendering 2 975 represents { 2 } selection (2 selections) over { 3 } states (3 states). It is expressed in Win32 as two combo boxes, each representing one selection with the labels of the second dimension as the states for the combo boxes. The two combo boxes values express the selections (in this case, {0} for the first one and { 1 } for the second one).
Considering the Number of Selection Dimensions 905 equal to 1 and the Label Scope Flags 910 equal to {true, false} 960 (2 labels), the generated Rendering 3 980 The conceptual interfacing technology patent application (CONFIDENTIAL) represents { 2 } selection (2 selections) over { 3 } states (3 states). It is expressed in Win32 as two track bars, each representing one selection. With no labeled states to select from the second dimension (the Label Scope Flag 910 is equal to false for the dimension), the Rendering 3 980 will use track bars (with anonymous states) instead of combo boxes (with labeled states) and show labels from the first dimension as titles. The two track bars values express the current selections (in this case, {0} for the first one and { 1 } for the second one).
Considering the Number of Selection Dimensions 905 equal to 2 and the Label Scope Flags 910 equal to {true, true} 965 (6 labels), the generated Rendering 4 985 represents { 2, 3 } selection (6 selections) over { } state ( 1 state). It is expressed in Win32 as 6 buttons for Rendering 4 985 because the States Matrix d-size is { }
(1 state). The selections can change from nothing ({ }) to nothing ({ }), which is why buttons (which are selections without the, concept of a state) are chosen for Rendering 4 985. Each of the buttons contains labels , since the Label Scope Flags 910 are true for both dimensions. 'The six buttons values express the current selections (obviously, { } for all 6 selections).
Returning to FIG. 5B, if the values (selections in this case) User-Defined Flag is set to false, the Default Storage System 410 will store the Values Matrix of the control CC.
The selection values can be changed anytime with method setselection(dnum sel, dnum index = dnumnull) 415 (sel >= 0, sel < States Matrix d-size, index >= 0 and index < Values Matrix d-size). The end-user may also send setselection events to the application logic, with the same parameters than setstate(dnum state, dnum index =
dnumnull) 415.
If the values User-Defined Flag is set to true, the Values Matrix is stored in a User-Defined Storage System 420. Method c~pdatevalues(dnum pos, dnum range) 425 (pos >= 0, range >= 0, pos + range <= Values Matrix d-size) will refresh the state rendering whenever a corresponding change in the proprietary state storage mechanism of the application logic has occurred.
3.3.3.3 Text CC
With reference to FIG. SC, a Text CC 450 is used to enter text strings. The Text CC
450 consists of a collection of characters such as 'U', 'S' or '$'. 'There are also control characters, such as LF (line feed) to indicate a line is over and FF (form feed) to indicate a page is over. Referring to FIG. 7, the Values Matrix d-size 780 for a Text CC is the d-size Accumulation 775 of its Container d-size 770 and its Base d-size 750.
The Number of Dimensions 455, entered at Initialization time, specifies the number of dimensions of the text, which is greater or equal to 0. The Text CC 450 is multi-dimensional, as a collection of characters, can span over multiple dimensions.
A Od text is always a single regular character (not a control character). No extra characters can be added or removed. A 1d text is one list of characters (a line), whereas a 2d text is a list of list of characters (a page), and so on. On any dimension, insertion and deletion are possible. Control characters are used to switch to the next unit in a given dimension. LF switches to the next unit in dimension 1 (a switch to the next line) and FF switches to the next unit in dimension 2 (a switch to the next page).
The Maximal Length 460 is a number indicating the maximal character count a text can have. The number of characters in the Text CC 450 will never exceed the The conceptual interfacing technology patent application (CONFIDENTIAL) Maximal Length 460. However, if the Maximal Length 460 is set to -1, the text can have any length and the number of characters in the Text CC 450 can grow indefinitely.
If the values User-Defined Flag is set to false, the Default Storage System contains all texts of the Values Matrix. The settext(dnum pos, long lengthtoremove, char *string, long stringlength, dnum index = dnumnull) 470 method modifies, for the text pointed to by index, its content, at the d-coordinate specified by pos, by removing lengthtoremove characters and adding stringlength characters taken from string. For this method, index >= 0, index < Values Matrix d-size, pos must point to a text character and from pos, lengthtoremove must not exceed the number of characters.
There is also a settext event that can be invoked from the end-user. It has the same parameters as settext(dnum pos, long lengthtoremove, char *string, long stringlength, dnum index = dnumnull) 470. ' _ , If the values User-Defined Flag is set to true, the Values Matrix is stored in a User-Defmed Storage System 475. Method updatevalues(dnum pos, dnum range) 480 (pos >= 0, range >= 0, pos + range <= Values Matrix d-size) will refresh the text rendering whenever a corresponding change in the proprietary text storage mechanism of the application logic has occurred.

Claims