Program modules and parameter files in a network

Description of equivalent WO 9802823 A2

DESCRIPTION PROGRAM MODULES AND PARAMETER FILES IN A NETWORK

Technical Field The present invention relates to computer system and network system. Background Art

Microcomputers have evolved from simple 8-bit electronic toys to powerful business management tools. Almost all large and medium size companies now use at least one microcomputer for business purposes. As a result of mass production, the price of microcomputers dropped drastically over the last few years. Currently, microcomputers are within the reach of many homes and small companies.

In order to make computers more useful in a corporate environment, many companies connect their desktop microcomputers in local area networks. Currently, some companies also install wide-area communication networks so that information can be shared among microcomputers dispersed over many cities. The experiences of these companies confirm that sharing of information among computers increases the overall productivity of the whole system.

However, computers owned by different companies are generally not linked together. Further, the computers owned by homes and small companies tend to be stand-alone desktop machines. Consequently, there is no sharing of information among these computers. The availability of a wide-area network called the "Internet" changes the situation and potentially allows all these computers to be electronically connected.

The Internet grew out of research in the 1960s to design a robust wide- area data communication network. For a long time, the Internet was used by researchers in universities and national laboratories to share information. As the existence of the Internet became more widely known, many users outside of the academic/research community (e.g., employees of large corporations) started to use Internet to carry electronic mails. In late 1980s, a wide-area information system know as the World Wide Web ("Web") was developed. The Web is a wide-area hypermedia information publishing and retrieval system aimed to give universal access to a large universe of documents. At that time, the Web was known to and used by the academic/research community only. There was no easily available tool which allows a technically untrained person to access the Web. An development in Internet is the release of a software called a Web "browser." It has a simple but powerful graphic interface. The browser allows a user to retrieve web documents and navigate the Web using simple commands and popular tools such as point-and-click. Because the user does not have to be technically trained and the browser is pleasant to use, it has the potential of opening up the Internet to the masses.

A document designed to be accessed and read over the Web is written in a language called the "Hypertext Markup Language" ("HTML"). The HTML document, when interpreted by a Web browser, is able to display text, images and other multimedia contents. However, the HTML document itself is merely an ASCII coded text document together with "tags" of predefined format that add some features to the basic text. As a result, the multimedia presentation (e.g., computer display) generated by the HTML document can only contain simple structure.

Another problem of HTML document is that it is difficult to design. As explained above, HTML document is an ASCII coded document while the final display is a multimedia presentation. It is not easy to relate the ASCII document to the presentation. Even though there are tools that help users to write HTML documents, these tools are not easy to use. Consequently, only well-trained persons are able to design HTML documents. Thus, most users can only be a recipient of information instead of being able to deliver their information to other Web browsers. Recently, there are movements to improve the basic Web architecture. When the Web was first developed, the aim was to share documents. It has been pointed out that programs can also be shared over the Internet. In this systems, a first computer can send program code to a second computer via the Internet. The second computer then executes the code so as to dynamically alter the display generated by a browser. As a result, the Web can be changed from a passive wide-area document sharing system to a dynamic information processing system. Examples of such developments are Java and ActiveX. Java is a variation of a popular programming language called "C++" while ActiveX derives from Microsoft's Object Linking and Embedding.

Even though sharing program code is a powerful idea, the current direction of implementation (e.g., Java and ActiveX) is contrary to the trend of opening the resource of the Internet to a large number of users. Both Java and ActiveX require writing computer programs by experienced programmers. These programs are more difficult to write than HTML documents. Thus, the current direction reduces the number of users who can participate interactively in the Internet experience.

Currently, many computers on the market are sold with a sound card, high resolution video card and color monitor. These computers are sometimes called "multimedia computers." Computer applications that make use of some or all of these components are called multimedia applications.

Multimedia applications are based on graphic images and icons. The interface with users is commonly called a graphic user interface (GUI). In contrast, old style interface is based on single line commands. Multimedia applications are more difficult to write. One of the reasons is that GUI needs to coordinate a large number of computer resources. For example, it typically needs to monitor both a keyboard and a mouse (while command line based interface only needs to monitor a keyboard). Users can click on an icon located anywhere on a computer screen (while command line based interface allows users to enter commands line by line only). The output of GUI could be graphic images, movie and/or audio sound (while command line based interface generates text only). It can be seen from the above that it is not easy to write multimedia applications. While it is difficult to write multimedia applications, the graphic environment encourages people who had little or no prior programming experience to develop applications. For example, people who have experiences in graphic design, movie making, song writing, etc. could be interested in using their skills and training in a multimedia computer environment. Currently, there is a small number of authoring software that allow users to develop multimedia presentations. An example is Director 5.0 marketed by Macromedia Inc. However, they are difficult to use and the variety of presentations are limited. Consequently, there is a need to develop an easy-to-use and flexible multimedia authoring software. When digital computers were first available, the amount of memory in a computer was very small. Consequently, the size of a computer program was also very small. The challenge of writing a good computer program was to squeeze as much functions as possible in the available memory, i.e., the code to implement each function should be as small as possible. As the amount of memory increases, there is no need to place a premium on reducing the size of computer programs. Instead, the challenge becomes developing methods to write large applications efficiently and free of bugs. It is found that making software "modular" goes a long way in meeting this challenge. This is because it is much easier to write many small programs (and integrate them in an appropriate manner) than to write one large program. This approach can be used by both the traditional procedural-oriented programming environment and the recent object- oriented programming environment.

In modular programming, a complex system is decomposed into several subsystems. Each subsystem is associated with a program module. The subsystem could itself be decomposed into lower level subsystems (which are associated with lower level program modules). Ideally, these program modules are independent modules that can communicate with other program modules. As a result, programming can be performed by a team of programmers, with each programmer taking care of a small number of program modules. Consequently, modular programming encourages team work. Further, it is comparatively easy to debug and maintain each program modules. This is because defective or unsatisfactory program modules could be isolated and modified while the rest of the system is either not affected or minimally affected. In order to combine program modules into a large application, the modules must be able to communicate with each other. An important factor for using modular programming successfully is that communication between program modules are handled efficiently. If the communication is cumbersome, the modules would use much computer resources for communication (instead of performing useful work) and the programmers would spend much time in writing codes to handle program communication.

An essential tool in manipulating graphic and text images is scrolling. The need for scrolling arises when the size of a window displaying a graphic/text image is smaller than the file site of the image. Thus, the window can display a portion of the image only. In order to display other portions of the image, a user can "scroll" the image. Typically, the window contains one or two "scroll bar") for allowing the user to indicate the direction of scrolling, e.g., up, down, left or right. The user places a cursor in the scroll bar area to indicate the direction of scrolling. The position of the cursor is controlled by a mouse (or other pointing devices) held by the user. The location of the cursor is delivered to the operating system and the application software (e.g., word processor program) controlling the graphic/text image. The images on most display devices need to be refreshed (i.e., re-drawn) periodically, e.g., sixty times per second. During scrolling, the refreshed images would show a series of shifted images depicting movements of the graphic/text image. The operating system and the application software use the position of the cursor to determine how the series of images should be drawn.

An important factor in scrolling is its granularity, i.e., the smallest number of picture elements (or "pixels") in each scrolling operation. It is found that prior art scrolling of text images is line-by-line and character-by-character, i.e., the minimum scrolling distance is a line or a character. Thus, the granularity is very rough (i.e., a large number of pixels in each scrolling). The result is that scrolling of text images is jerky and unpleasant to watch. Disclosure of Invention

Accordingly the first object of the present invention is to allow the users access the Internet interactively.

The second object of the present invention is to provide an easy-to-use and flexible multimedia authoring software. The third object of the present invention is to achieve an effective communication between program modules.

The fourth object of the present invention is to provide a scrolling which can scroll the text image smoothly.

The first object is achieved by applying a new programming architecture, called the "digital cell technology" or DCT, to a digital data network. In DCT, applications are formed from special program modules, called "cells," which do not follow conventional hierarchic programming structure. In this invention, the multimedia files used in the cells, which are program modules used in developing applications and having a specialized structure, could be obtained from other computers connected to the data network. As a result, the number of multimedia files that could be used in applications increases drastically.

Each cell in the digital cell technology is associated with one or more parameter files (called DNA files). These files contain parameters to define many characteristics of their associated cells. In an embodiment of cells, the DNA files also provide means for cells to communicate with each other. One aspect of the present invention involves distributing these DNA file to various computers connected to a data network. The second object is achieved by providing a novel way for a user with little programming experience to develop complicated multimedia applications using pre-existing program modules.

These program modules could be written by the user or one or more software developers. Each module has an associated display window. Some of these program modules could communicate with each other so as to perform, in combination, desired activities. The user can select appropriate program modules to form an application. The user organizes the windows associated with these program modules in a desired arrangement. Graphic relationships of these windows are formed by defining various parent-child relationships among the display windows. These relationships place predetermined constraints an the appearance of the windows. When the program modules are executed, they communicate with each other to perform desired activities while the associated windows maintain the predetermined graphic relationships. Consequently, the application gives a viewer the appearance that it contains tightly coupled program modules instead of modules that can be selected and arranged easily by a user with little programming experience.

The third object is achieved by providing a novel method of communication between programming classes in object oriented programming. This method uses a specialized communication controller class to manage communications. Classes are not designed to communicate directly with each other, and all communication between classes is designed to be routed by this controller class. As a result, there is no treed for each class to keep track of any hierarchical relationship of these classes in an application in order to be able to communicate with other classes.

The above described classes (including the controller class) can be grouped together to form a program module (also called program "cells"). The modules can then he grouped together to form an application. The above method can be used to allow the modules to communicate with each other. Specifically, a specialized communication controller module, is used to control and manage communication between modules. Modules me not designed to communicate directly with each other, and all communication must be routed by the controller module. This method can be extended further to manage (i) communication between different applications and (ii) communication between program modules in different computers in a data network.

The fourth object of the present invention is achieved by allowing a computer user to scroll a text image pixel-by-pixel instead of line-by-line or character-by-character. A pixel is the smallest unit of display. Thus, this scrolling method represents the finest granularity in scrolling text images. The present invention involves creating a child window associated with a window generated by an application used by a user (hereinafter the "application window"). The text image is drawn on the child window instead of the application window. The size of the child window is larger than the application window. However, only the portion of the child window overlapping the application window is displayed by a computer screen. If the user desires scrolling, the child window is moved, a pixel at a time, in a direction corresponding to the direction of scrolling. As a result, the user sees scrolling at a pixel granularity. When a full line or a full character is scrolled, the child window clears itself and returns to its original position. At the same time, the text image is scrolled one line or one character on the child window so as to match the pixel-based scrolling. The child window is moved again pixel- by- pixel. As a result, the user sees a smooth scrolling of a text image, preferably at the smallest granularity. These and other features and advantages can be understood from the following detailed description of the invention together with the accompanying drawings.

Brief Description of Drawings Fig. 1 is a schematic diagram of an application based on a DCT (Digital

Cell Technology) or boss less architecture which can be used to implement the present invention.

Fig. 2 is a drawing showing the structure of an application using a digital cell technology.

Fig. 3 is a block diagram showing the logical structure of a DNA file associated with a cell CA.

Fig. 4 is a block diagram of the logical structure of the cell CA.

Fig. 5 is a block diagram of a computer system running an applications based on the DCT. Fig. 6 is a drawing of a computer network which can be used in the present invention.

Fig. 7 is a drawing showing multiple windows associated with program cells of the present invention.

Fig. 8 is a drawing showing the structure of a DNA files of the present invention.

Fig. 9 is a block diagram showing a cache design of the present invention. Fig. 10 is a schematic diagram showing distributable DNA files of the present invention.

Fig. 11 is a diagram illustrating the actions involved in designing an application using a method of the present invention.

Fig. 12 is a diagram illustrating the actions involved in designing an application using another method of the present invention. Fig. 13 is a flow chart of the steps that can be used in implementing the application illustrated in Fig. 11.

Fig. 14 is a flow chart of the steps that can be used in implementing the application illustrated in Fig. 12. Fig. 15 is flow chart showing the steps involved by two independent windows to form a parent and a child relationship in accordance with the present invention.

Fig. 16A is a drawing showing the components of a window that may be used in the present invention. Fig. 16B is a drawing showing the relationship of a parent and a child window that may be used in the present invention.

Fig. 17 is a schematic diagram of a programming structure designed using prior art classes.

Fig. 18 is a schematic diagram of a programming structure of the present invention.

Fig. 19 shows the structure of communication controller class of the present invention.

Fig. 20 is a schematic diagram of an extension of the structure shown in Fig. 18. Fig. 21 is a schematic diagram of an multi-computer application designed using the programming structure of the present invention.

Figs. 22A and 22B show an example of scrolling in a prior art system. Fig. 23 shows the relationship between an application window and a child window of the present invention. Fig. 24 is a flow chart showing the scrolling operation of the present invention.

Best Mode for Carrying Out the Invention First, Digital Cell Technology(DST) is described. A detailed description of this technology is described in a published PCT patent application number PCT/JP96/00821 entitled "Bossless Architecture And Digital Cell Technology For Computer Programs". The PCT application is incorporated herein by reference. This technology will be described briefly here to the extent necessary to understand the present inventions.

One characteristic of the digital cell technology is that it is a "bossless" architecture because every program module (or cell) is on equal footing with other program modules. There is no module that controls the overall operation of the program (i.e., no boss).

Fig. 1 is a schematic view of an application 160 based on the "bossless" digital cell technology. Application 160 comprises a plurality of program modules, such as modules 162-165. Each program module (called a "cell") is the same as the other cells in an hierarchical sense. Cells are linked together in a way in which no history or linkage information needs to be retained. Each link is independent. For example, there is no need for links to be active simultaneously. Each link is direct, i.e., two cells can be linked directly without the need of using one or more intermediate links. For example, cells 162 and 164 can be linked directly using line 166 instead of using lines 167 and 168 and passing through an intermediate cell. An application can be formed by defining the cells involved and using the direct link.

Fig. 2 is a drawing showing the structure of an application 200 using the bossless architecture. Application 200 contains a plurality of cells, labeled as C1-C5, loaded and executing in RAM. Each cell has an associated file (labeled as D1 -D5), called DNA file, which contains information of the cell. The term

"DNA" is used here in analogy with the biological relationship between a living cell and its DNA. At a desired time, cell C1 can send statements (called "DSF statements") to cell C2 using a protocol called digital shifting function ("DSF") protocol. Cell C2 will execute these statements. The detail structures of cells, DNA files and the DSF protocol will be described below.

In this application 200, Cell C2 does not retain information on the origin of these statements, i.e., no history of the inter-process communication is kept. Thus, once cell C1 completes its writing of DSF statements to cell C2, there is no further linkage between cells C1 and C2. Cell C2 does not know the origin of these statements during their execution. It is possible for cell C1 to later establish communication with cell C2 again by sending another set of statements to C2. However, this communication is separate from the previous communication, and terminates once the new set of DSF statements is sent.

Each of the cells can send DSF statements to any of the cells it desires. Thus, cell C1 can also send statements to cell C3. Similarly, cell C2 can send statements to cell C4, which in turn can send statements to cell C1. Cell C3 can also send statements to cell C1.

In this example, cells C1 and C2 are not bosses to C4. For example, when C4 is executing DSF statements, there is no need to maintain any links between cells C1 and C2 and between cells C2 and C4. Cell C4 has no obligation to report results of execution to any cells in application 200. Links are maintained only during the time DSF statements are transferred. Further, the writing of statements by cell C1 to cell C2 could be independent of the writing of statements by cell C2 to cell C4. In addition, cell C4 merely execute statements, and does not care where the statements come from.

In this architecture, there is no need to save and restore register values on a stack when cell C2 executes statements written by cell C1. There is no need to register cells in a central database prior to sending commands. There is no need to send messages back and forth to report status of execution. As a result, the application can be executed quickly.

As explained below, a ceil can be implemented as an "EXE" file (in the MSDOS or MS Windows environment) and can be invoked by loading into RAM for execution using well known methods in accordance with the operating environment. The cell's associated DNA file can also be loaded into RAM. The invoked cell takes on the attributes stored in its DNA file. It is also possible to modify the DNA file when the cell is invoked or while running by writing to the file (which could be an ASCII file).

Fig. 3 is a block diagram showing the logic structure of a DNA file 250 associated with a cell, such as cell CA. File 250 has a section 252 containing parameters ("own parameters") related to the characteristics of cell CA itself. For example, section 252 may contain parameters related to the way cell CA manifest itself when invoked: the window size and background color of cell CA, the name of cell CA, the names of audio files associated with its invocation and termination, etc.

File 250 also contains a section 254 containing linking parameters ("link parameters") on cells related to cell CA. Examples of the parameters contained in this section are: the names, symbols and positions of the other cells. One of the parameter is "close," which is interpreted as closing cell CA when the cell associated with this parameter is invoked.

File 250 further contains a DSF information section 256. This section contains a regular section 257 and a top priority function section 264. The structure of the regular section 257 and top priority function section 264 are substantially the same, except that top priority function section 264 has a higher priority in DSF statement execution. These two sections contain individual headers for identifying the sections (e.g., each section headed by a different name or symbol). Regular section 257 contains a "condition" section 258 and a statements section 260. Statements section 260 comprises statements sent to cell CA by other cells. Statements in statements section 260 are executed sequentially. Each statement also contains parameters necessary for the execution of the statement. Condition section 258 comprises three components: (a) a first pointer to the last DSF statement currently existing in statements section 260, (ii) a second pointer to the current DSF statement being processed by cell CA, and (iii) the current status of the cell.

Top priority function section 264 contains a condition section 266 and a command lines section 268. The structure of condition section 266 is similar to the structure of condition section 258. Command lines section 268 contains executable command lines which are sent by other cells using DSF (or similar) protocol. The command lines have a higher execution priority than the statements in statements section 260. The command lines in command lines section 268 are executed sequentially.

It should be appreciated that the logic structure shown in Fig. 3 can be implemented using one or more physical files. Further, portions of the logical sections may intermingle physically. In one embodiment, DNA file is a text file. Thus, the content of the DNA file can be modified by using a regular text editor.

Statements sent by one cell to another follow the DSF protocol. A sending cell (e.g., cell CS) sets up a communication link with the DNA file 250 associated with cell CA. Specifically, it looks up the address of DNA file 250 and determines whether DNA file 250 is able to accept DSF statements by examining its status in condition section 258. Statements will be issued by cell CS only when cell CA is ready to accept them. In one embodiment, the issuance of statements involves writing ASCII characters to statements section 260 of DNA file 250. When cell CS is authorized to issue statements to cell CA, cell CS reads the first pointer (in condition section 258) to the last DSF statement to determine the appropriate address to write the DSF statements. It is important not to overwrite DSF statements already existed in cell CA. Cell CS writes DSF statements to statements section 260 of DNA file 250. Cell CS also updates the first pointer in condition section 258 so as to point to the last DSF statement newly written into statements section 260. The communication link between cells CA and CS is terminated. It can be seen that cell CA and DNA file 250 do not maintain record (i.e., history) indicated that these new statements originate from cell CS.

It should be appreciated that the above described DSF protocol is only an exemplary protocol. Other protocol could be used to write DSF statements to cells. For example, different pointer structures can be used, e.g., the first pointer can point to the position after the last DSF statement. Different types of status and different ways for checking status information can be used. Further, the statements could be stored in accordance with a logic structure instead of stored physically in a sequential manner. For example, the statements could be organized into groups with the address of each group pointed to by a pointer.

Command lines are sent by one cell to another using a protocol substantially the same as the DSF protocol. Because regular statements section 257 and top priority function section 264 have different headers, the sending cell can distinguish between these two sections and write to the appropriate section. Other means for identifying these two section can also be used.

Fig. 4 shows the structure of cell CA. It is grouped logically into a plurality of sections, each implemented using instructions executable by a computer. Cell CA contains an initialization section 312 and a DNA interface section 314. DNA interface section 314 allows cell CA to read from and write to its corresponding DNA file 250. Initialization section 312 takes care of housekeeping tasks when invoked, including reading parameters from "own parameters" section 252 of DNA file 250. Cell CA also contains a DSF interface section 316 (for processing DSF protocol). This section contains code (or program instructions) for sending and receiving statements/command lines using the DSF protocol.

Cell CA contains an execution section 318 containing code for automatically executing statements and command lines in DNA file 250 written by other cells. The code sequentially read and execute statements in statements section 260 of DNA file 250. After each statement is executed, cell CA branches to top priority function section 259 and executes all the command lines therein. Cell CA then executes the next statement in statement section 260.

Cell CA contains a temporary memory section 322 for storing temporary information. As an example, it is possible to change attributes (e.g., background color and the size of the display window) of cell CA during its execution. In one embodiment, the changed attributes are temporarily stored in temporary memory section 322 instead of immediately being written to DNA file 250. In this embodiment of cell CA, the attribute information stored in temporary memory section 322 is written into "own parameters" section 252 of DNA file 250 only when cell CA is terminated.

Cell CA also contains a cell invocation section 324 for invoking other cells. In one embodiment , this section obtains information about the cell desired to be invoked and pass this information to a specialized cell which actually invoke the desired cell. It is also possible to incorporate the functionality of this specialized cell in the cell invocation section 324 of cell CA and other cells.

It should be appreciated that the above mentioned sections in cell CA are prouped logically, and portions of these sections could intermingle physically. Fig. 5 shows a block diagram of a computer system 380 running the above described application development system. Computer system 380 comprises a personal computer 382, such as an IBM compatible computer. Personal computer contains components such as a CPU, RAM, ROM, hard disk and multimedia device (e.g., sound card, CD-ROM reader, video card, etc.). Personal computer is loaded with a MS-DOS 384 and a MS Windows 386. Cells 391-393 of the present invention run on top of MS Windows 386. Some of these cells can be graphically displayed on a display device and played on a sound card of personal computer 382. First Embodiment

The present invention can be used in a computer network system 400 of Fig. 6. System 400 comprises a data communication network 402 (such as a local area network, wide-area network, or the Internet) a plurality of servers, such as servers 404-406, and a plurality of client computers, such as computers 410- 412. Preferably, the servers contain a large database of multimedia content

(such as images, audio files, video files, text documents, etc.). The servers may also contain pointers to other computers which contain such databases. Some of the client computers run an operating environment designed under the "digital cell technology" ("DCT"). One aspect of the present invention is to extend DCT to a data network environment.

<Multimedia Files Downloaded from Remote Servers>

As stated above, In DCT, applications are formed by managing a plurality of small program modules called "cells." Each cell is associated with a parameter file (called "DNA" file in the terminology of DCT). The DNA file contains parameters to define some of the characteristics of its associated cell. The DNA file may also provide means for one cell to communicate instructions with other cells. For example, a first program module (cell) contains program code for sending a first set of commands to a parameter file associate with a second cell. Similariy, a second program module (cell) contains program code for sending a second set of commands to a parameter file associate with the first cell. The first cell also contains code for executing the second set of commands without returning result of execution to the second cell. Similarly, the second cell contains code for executing the first set of commands without returning result of execution to the first cell, In one implementation of DCT, some of the cells generate a display window upon execution. Fig. 7 is a drawing showing a display 450 of a computer monitor. It contains four display windows, 452, 464, 468 and 474, each associated with a cell. The details of these windows will be explained below.

Fig. 8 shows the structure of an exemplary DNA file 420 associated with a cell CA. Cell CA resides in a client computer, such as computer 410. The focus here is a statement 436 (i.e., "IMAGE=http://www.site/file.JPG") under a "own parameter" section 422. In the cells disclosed in the published PCT patent application number PCT/JP96/00821 , the image file of its display is located in the hard disk of the client computer. In the present invention, the image file could be located in another computer connected to network 402.

More specifically, each file accessible by computers connected to the Web must have an address in a recognized format, called the Uniform Resource Locator ("URL"), that enables computers all over the world to access it.

Statement 436 indicates that the image file has a URL of "www.site/file.JPG". In order to obtain the image file, cell CA causes client computer 410 to send a request (via network 402) for a file named "file. JPG" to the server containing the file (such as Server 404). In the Microsoft ("MS") Windows environment, cell CA would call a WinSock module to initiate a TCP/IP communication with server 404. In response, server 404 delivers the file "file. JPG" in its database to client computer 410, which in turn delivers the file to cell CA using regular MS Windows notification protocol. If server 404 is running under a MS Windows environment, server 404 also uses a WinSock module to receive information from and send information to client computer 410. As a result, cell CA can generate a display window in accordance with the parameters in its associated DNA file.

It should be noted that the downloaded file is not limited to image files. Other types of files, such as audio and video files, can also be specified in the own parameter section of a DNA file as remotely located files. Further, the communication protocol does not have to be the hypertext transport protocol ("HTTP"). Any kind of protocol allowing transfer of files over network 402 could be used. Further, server 404 could operate under various operating environments, including UNIX, Macintosh, and DCT.

Once the image file is obtained from the server, cell CA behaves like a regular cell disclosed in the published PCT patent application number PCT/JP96/00821. For example, a user can manipulate the cell by linking other cells to it. Some of these linked calls may also obtain its image file from various servers in the Internet. When these cells are launched, they obtain their image (or other) files using the same method described above.

An example of this linking can be seen in Fig. 7. For illustrative purposes, assume that window 452 is a display generated by cell CA of Fig. 8. It has a title bar 454 containing a title (i.e., "site 1") of the display. In this illustrative example, the titles of all the windows in Fig. 7 show the origin (i.e., in the form of server "site 1", "Site 2", etc.) of the display images. The actual title of a cell can, of course, contain any words or symbols. Thus, windows 452, 464, 468 and 474 contain images that are downloaded from sites 1 , 2, 3 and 2, respectively. Window 452 also contains a tool bar 456 having a plurality of tools (such as tool 458) for manipulating window 452 (and the underlying cell). Examples of tools are edit tool for accessing an edit mode (for editing the window) and tools for invoking other pre-defined cells. In this embodiment of the present invention all the windows in display 450 have title bars and tool bars In this illustrative example, the image of window 452 includes a shape 461. Users can link a button cell (represented as button 460) and a visual cell (represented as symbol 462) to window 452. The IMAGE parameters in these DNA files could specify a local or a remote image file. It should be noted that any number of cells (or no cell, if appropriate) can be linked to window 452.

When a user clicks on button 460, the underlying button cell is launched. Window 464 is generated, in this example, the image (having a shape 466) is generated based on one of the files (called "file 1 " in this example) stored in site 2. When a user click on symbol 462, the underlying visual cell is launched. Window 468 is generated. In this example, the image (having a shape 470) is generated based on a file in site 3. Users can attached another visual cell (represented by a symbol 472) to window 468.

When a user click on symbol 472, the underlying visual cell is launched. Wind6w 474 is generated. In this example, the image (having a shape 476) is generated based on another file (called "file 2" in this example) stored in site 2. Note that some of the cells in the illustrative example of Fig. 7 could have a locally stored image file. There is no need to have all the image files downloaded via network 402.

Windows 452, 456, 468 and 474 are each associated with a DNA file. The link parameter sections of these DNA files contain the file names (both local or remote) of the DNA files which are linked to the corresponding cells. For example, the link parameter section of the DNA file associated with window 452 contains the file names of the button and visual cells associated with windows 464 and 468, respectively. In this example, the file names are in URL format because these files are remotely located.

In the preferred embodiment of the present invention, a URL cache is included. This cache stores in a hard disk all the URLs processed by a client computer. Fig. 9 shows a block diagram containing an implementation of the URL cache. When an exemplary cell 502 wishes to access a remote file, it issues a command to a program module called the "internet resource loader" 504. Loader 504 first checks a cache list 506, which contains a list of URLs that have previously been downloaded from the network and stored in the local hard disk. Thus, each URL in the list is associated with a file address in a local hard disk. When the URL of the desired file is in cache list 506, loader 504 fetches the file from the local hard disk instead of downloading it from the network. If the URL, of the desired file is not in cache list 506, loader 504 calls WinSock 508 to download the desired file. Upon receiving the remote file from the network, WinSock 508 delivers it to loader 504, which in turn causes the operating system to store it in an appropriate local file. The address of the local file together with the URL are added to cache list 506. From this time on, the client computer has access to this file without the need to obtain it from the network.

The implementation of loader 504 can be easily performed by a person skilled in the art based on the above description of its activities.

It is know that some servers update the content of its files frequently. For example, if a server contains files related to prices and specification of products, these files need to be updated whenever the price or specification information is changed. In the above embodiment, the URL cache would prevent users from accessing these updated files because loader 504 would fetch the files from its cache instead of from the server. There are at least three methods to handle this situation. The first method is to allow a user to clear all entries in the cache. As a result, a remotely located file must be fetched from the network. The second method is to allow a user to clear entries related to selected applications. Thus, remotely located files related to these applications will be fetched from the network. The third method is to allow a user to remotely reload all files appearing on a screen. These methods can be implemented using a number of ways. For example, the cache list could be in ASCII form, and the entries therein could be erased (in total or selectively), marked, or replaced in accordance with the desire of the user. distributable DNA Files>

In the above illustrative examples, the DNA files are stored locally in the client computer even though the multimedia files referred to in the DNA files could be remotely located. In another embodiment of the present invention, the DNA files could be stored in a serve . Client computers can download appropriate DNA files from the server so as to create and execute an application.

An embodiment of the present invention in a MS Windows environment is described. Under MS Windows, it is possible to associate a file having a predefined extension with a certain application. As an example, files having the extensions "SFM" and "SFR" can be made to invoke a visual and a run cell, respectively, operating under DCT. In one embodiment of the present invention, all the DNA files are ASCII files. These DNA files define an application through their own and link parameters. By downloading these DNA files and invoking associated cells to a client computer, the client computer can execute an application stored in a server by transferring ASCII files (as opposed to pr gram codes).

Fig. 10 is a schematic diagram illustrating distributable DNA files of the present invention. The browser (not shown) of a client computer may display a Web home page 530 which contains icons 532 and 534 indicating downloadable DNA files. The HTML document (not shown) corresponding to home page 530 contains "tags" which allows a browser to generate icons 532 and 534. In the present invention, these tags contain the URL of the DNA files. When any one of these icons are clicked, the browser accesses its own cache 535 to determine if the corresponding DNA file (for convenience in this discussion, this DNA file is called the "home page DNA file") is in cache 535. If it is in the cache, the browser can invoke the cell associated with the DNA file (e.g., a visual cell) without the need for downloading the file. If it is not in the cache, the browser causes the DNA file to be downloaded from a server (e.g., server 540). The corresponding cell is then invoked by the operating system based on the extension of the downloaded DNA file. As an example, icon 532 is linked to a DNA file called "DNA-1.SFR."

Because this file is not in browser cache 535, it is downloaded from server 540. Once downloaded, the browser invokes a run cell 544. The characteristics of the window associated with cell 544 is defined by DNA-1.SFR.

Note that up to this point, no URL cache is involved. This is because a URL cache is invoked when a cell (instead of a web browser) attempts to download a file. In this embodiment, a URL cache 536 would be used if the DNA file of an associated cell makes reference to a second DNA file which is located remotely. At that time, the procedure discussed above in connection with Fig. 9 will be followed (i.e., the cell issues a command to the internet resource loader, which in turn causes WinSock to download a file, if there is a need to do so).

As an example, if cell 544 needs to access a remote DNA file (e.g., "DNA-2.SFR"), if it asks URL cache 536 to obtain the file. If DNA-2.SFR is not cached, it will be downloaded from a server (which could be in the same server 540 or another server 542). In a preferred embodiment of the present invention all the home page

DNA files contain a "SFR" extension. Consequently, a run cell is invoked when a user clicks on an icon associated with a downloadable DNA file. This cell performs only one function to download another DNA file (if not present locally) and associate a corresponding cell (e.g., cell 546) to the DNA file. This newly downloaded DNA file (e.g., DNA-2.SFR) is the real DNA file of interest which contains the application designed by a programmer. In this preferred embodiment, the home page DNA file can be considered a phantom DNA file. The reason for separating phantom DNA files from the real DNA files of interest is that this arrangement allows users of the DCT technology to review and edit all the DNA files under its control. As explained above, the home page DNA files are cached by browser cache 535. Each browser uses a proprietary cache design, and the files cached therein (e.g., DNA-1.SFR) are generally outside the control of users and DCT. DCT can only control files in URL cache 536. The above arrangement places all the real DNA files of interest (e.g., DNA-2.SFR) in URL cache 536, and thus can be controlled by DCT. As explained above, in one embodiment of the present invention, the cache list and DNA files are written in ASCII form, thereby allowing users to view and edit these files. Consequently, the users have full control over their applications. On the other hand, the files cached in the cache of the browser is generally not accessible by the user or DCT. <Uploading Distributive DNA Files>

In one embodiment of the present invention, all the DNA files are ASCII files. Thus, it would be easy for a client computer to develop an application using DCT technology and then send the associated DNA files (and if needed, other files referred to in these DNA files) to a server. Other client computers can then download these DNA files for executing the application.

It should be noted that the servers are used in the present invention as a convenient place to hold files. The present invention does not require the use of a server. For example, a first client computer could send DNA files to a second client computer, and the second computer could execute the application. There is no need to have an intermediate computer (e.g., a server) involved.

The present invention could he used by a group of programmers to develop applications. As explained above in connection with Fig. 7 an application may involve many cells, each associated with a DNA file. The development of these DNA files could be assigned to several programmers working in different client computers. These programmers upload their DNA files to a server. A programmer in the server could integrate these DNA files into a complex application. Alternatively, a programmer in a client computer can download these files and integrate these files. The programmer then upload the integrated application to the server. Client computers in the network can download the DNA files of this complex application and execute it.

Second Embodiment This embodiment provides additional tools for users to develop more powerful applications. Figs. 11 and 12 show two embodiments of the present invention. Fig. 11 is used to illustrate the actions of a user in designing a video application under Microsoft's MS Windows operating system. It should be noted that other applications could be designed in MS Windows (or other graphic operating environments) using the same procedure. The user activates a cell (i.e., program module) which generates a window 600 on a computer display 602 for allowing the user to define relationship between other windows. For convenience, this cell is called the "relationship" cell and the associated window is called the "relationship" window. In this example, window 600 contains a table for allowing the user to define relationships. Other means for defining relationships can also be used (e.g., see the method indicated in Fig. 12). Details of the relationship cell will be described below. The user then activates a video cell which generates a video window 606

(shown as a dashed block) on display 602. This window allows movies and animations to be shown therein. The name of a video file using this window is defined during activation. The video file can be easily changed so that the same window can be used to display different movies (or animations). This window is registered in relationship window 600 and assigned an identification (e.g., the number 1 ) under the "window" column of the table. In one embodiment of the present invention, registration can be performed by the following steps: (i) the video cell sends a message to the relationship cell indicating that it is active and (ii) the relationship cell stores this information in its memory space. Note that the use of a video cell is for illustrative purpose only. Other types of cells could be used.

The user then activates another cell (called control cell in this application) which generates a control bar window 604 (shown as a dashed block). During activation of the control cell, the user enters the name of the above described video cell which generates video window 606. As a result, control bar 604 can be used to control the operation of video window 606 (e.g., start, rewind, stop, etc.). Control bar 604 also registers with relationship window 600 and assigned an identification (e.g. , the number 2) under the "window" column of the table.

Finally, the user activates a visual cell which generates a window 608. This window is registered with relationship window 600 and assigned an identification (e.g., the number 3) under the "window" column of the table. As explained below, this window will be used to frame video window 606 and control bar 604. For convenience, this window is called the "framing window." In this example, there is no need for this window to communicate with windows 604 and 606.

The user can drag video window 606 and control bar 604 to separate locations inside framing window 608, e.g., by dragging their title bars (not shown) using a mouse (not shown). These new locations are shown as solid blocks 612 and 614, respectively. At this point in time, window 608 is independent of windows 604 and 606. The user then enters numbers under the "parent" column of relationship window 600 to define a parent-child relationship between windows 608, 622 and 614. In this example, framing window 608 (represented by a numeral 3) is defined to be the parent of windows 612 and 614 (represented by numerals 1 and 2, respectively). The parent-child relationship is a well-know relationship between windows and is implemented in many windows-based operating system (such as MS Windows). This step establishes a specific relationship between windows 612 and 614 on one hand and framing window 608 on another hand. The underlying mechanism for establishing such relationship will be described below.

Once the parent-child relationship has been established, windows 612 and 614 behave as if they are parts of window 608. For example, the user can move framing window 608 to a different location on display 602, and both windows 612 and 614 would also move with framing window 608. This is because one of the characteristics of the parent-child relationship (as implemented in most windows- base operating system) is to fix the position of the child windows (i.e., windows 612 and 614 in this example) relative to the parent window (e.g., framing window 608 in this example).

In one embodiment of the present invention, video window 612 is used to show movies and animations. Control bar contains buttons for controlling the operation of video window 612. For example, when a user clicks on a start button (not shown) on control bar 614, a movie (from the predetermined video file) starts to show in video window 612; when the user clicks on a stop button (not shown) on control bar 614, the movie stops; and when the user clicks on a rewind button (not shown) on control bar 614, the movie rewinds from the current time to the beginning. When the user uses a mouse to drag and move framing window 608, the entire content of the window (including video window 612 and control bar 614) moves together. Thus, from the perspective of the user, framing window 608, video window 612 and control bar 614 form parts of a complex application.

In the above example, the control cell controls the video cell by sending commands to the video cell. For example, when the user clicks on a start button, the control cell sends a command to the video cell to start playing of the video. One advantage of the present invention is that a software designer has almost complete control over the design of the application. For example, the designer can select one of several pre-designed control bars to use in the application. Other types of display windows (instead of a video window) could be selected. For example, the designer could select a scroll bar (which is one example of a control bar) to work with a graphic or text window. Thus, the system of the present invention is very robust and flexible. Another advantage of the present invention is that the system can be easily maintained and upgraded. For example, a software developer can initially ship an authoring software with a small numbers of control bars and display windows. The developer can add different types of control bars and display windows to the authoring software at convenient times. Further, each component of an application can be upgraded without changing the applications (as long as the interfaces between components are kept the game).

In the prior are method of programming, the above collection of windows (608, 612 and 614) is typically generated by a complex application incorporating movie playing and control routines. Typically, these routines are tightly coupled. A user has to accept the features of the application, and can only change some minor preferences allowed by the application. Upgrades to the application involve delivering another complete application software to users; and the users have to re-install the whole application. Thus, prior art applications are inflexible, difficult to maintain, and time consuming to upgrade. It should be pointed out that the user has freedom in selecting the parent window and the child window. For example, in the process of designing another application, the user could assign video window 606 as a parent and window 608 as a child. As a result, the present invention allows users a great deal of flexibility in application development. Fig. 14 is a flow chart 630 summarizing the above described operation.

In step 634, a user activates a relationship cell. This cell displays a relationship window. In step 636, the user activates a program cell (which could be a visual or other cells) which displays a display window. This cell contains program code which communicates with the relationship cell. In step 638, the newly activated cell registers with the relationship cell. This can be performed by sending a message (using the above described communication protocols) to the relationship cell. In step 640, the user determines whether other cells (and windows) need to be activated. If other cells need to be activated, now chart 630 branches back to step 636 to activate additional cells. If the user does not wish to create more cells, flow chart 630 branches to step 642, which starts the next phase (i.e., definition of relationships) of the design of an application.

In step 642, the user bags a first display window (other than the relationship window) created above to a desired location inside a Second display window (again, other than the relationship window). The user then defines the relationship between these windows. This involves going into the relationship window to assign the first display window as the child of the second display window. Once a window is designated as the child of a parent window, the relationship cell causes the operating system to change the window to a child style (step 644). The underlying mechanism to perform this operation will be discussed below in connection with Fig. 15. A window in the child style has a predefined visual relationship with a corresponding parent window (e.g., in the MS Windows environment, the child window is confined within the boundary of its parent and cannot move outside). In step 646, the user determines whether additional relationship between windows need to be defined. If the answer is positive, flow chart 630 branches back to step 642 to define additional relationships. If the answer is negative, flow chart 630 terminates.

It should be pointed out that an application may contain a hierarchy of parent-child relationships. For example, a first window could be defined as the child of a second window, which could be defined as the child of a third window. In this case, the first window is bounded by the second window, which is in turn bounded by the third window. When the third window moves, the first and the second windows move with the third window. Alternatively, a parent may contain several child window at the same hierarchical level.

It should also be pointed out that the use of relationship cell and window is one of the methods for defining relationship among the cells. An alternative method is now described. Some of the cells (e.g., the visual and button cells) could be switched into an edit mode so that user can change the characteristics of cells by entering information in an edit window. When the cell is in the edit mode, a dialogue box is displayed. A user can click on various icons and enter alphanumeric characters in selected boxes. When the edit mode is switched off and the cell returns to an executing mode, the cell now takes on a new behavior defined by the information entered in the dialogue box. In one embodiment of the present invention, the dialogue box contains an icon for allowing a user to define a parent-child relationship (referred herein as a "relationship ices" for convenience). Fig. 12 shows an embodiment of the present invention that does not require a relationship window. Instead, the above-described relationship icon is used. A user does not need to enter numbers in order to define relationships. In the present application, picture elements that are common in Figs. 11 and 12 have the same reference numeral.

In order to illustrate this embodiment of the present invention, Fig. 12 shows a video cell in an edit window 607. It contains a relationship icon 616 for a user to indicate that this window should be a child window. Thus, the user can click on relationship icon 616 to allow the system to know that this window should be the child window of a soon-to-be determined parent window. The user then selects the parent window. For example, the user can move a cursor 620 to framing window 608 (e.g., by depressing a button of a mouse 622 and then moving the mouse). After cursor 620 is at an appropriate location inside framing window 608, the user releases the button to indicate that this is the desired location and framing window 608 should be the parent window. The user can then cause the video cell (indicated by edit window 607) to exit the edit mode. A new window, window 612, is generated inside framing window 608 while the original window of the video cell is cleared. Window 612 is set by the operating system as a child window of framing window 608. The underlying mechanism in creating this parent-child relationship will be described in detail in connection with Fig. 15.

Similarly, Fig. 12 shows a control cell in an edit window 609. This control cell communicates with and controls the visual cell using the same method described above in connection with Fig. 11. Edit window 609 contains a relationship icon 617 allowing a user to indicate that this window should be a child window. The user can click on relationship icon 617. Cursor 620 is moved (by depressing a button of mouse 622) to an appropriate location inside framing window 608. The user then releases the button to indicate that the child window should appear at this location. After the edit window 609 is exited, a new window, i.e., window 614, is generated inside framing window 608. The original window associated with the control cell is cleared. Window 614 is set by the operating system as a child window of framing window 608.

Fig. 14 is a flow chart 660 summarizing the above described operation. In step 662, a user activates a first cell (which could be a visual, video, and other cells) and its associated window. This first cell will be chosen, for illustrative purpose in this example, as the parent window. In step 664, the user activates a second cell (which again could be a visual, video, and other cells) and its associated window. The user then switches the second cell to an edit mode. The relationship icon is clicked (step 666). The user then defines a new location of the child window by indicating this location inside the window of the first cell (step 668). In the above example, this location is indicated by moving a cursor thereto. The window style of the second cell is then changed to a child (step 672). The detailed mechanism for performing this step will be described below in connection with Fig. 15. The original window of the second cell is cleared and a child window at the desired location inside the window of the first cell is generated (step 674).

The steps described in flaw chart 660 can be used to add other child windows to the window of the first cell (which becomes the parent window). In this case, the other child window would be at the same level as the window of the second ceil. Alternatively, a child window can exist within another child window. If step 668 is modified such that the user indicates that the desired location is inside an existing child window, the newly created child window would be the child of the existing child window. Thus, this newly created child window cannot move out of the boundary of the existing child window, which in turn cannot move of the boundary of a parent window. As a result, a hierarchy of parent-child relationships can be created. As a further embodiment, a parent window could contain several child windows at the same level and each or all of the child windows could contain additional child windows (which could be called the grand- children of the parent window). The grand-children could further contain child windows. There is no limitation to the levels of parent-child relationship in the present invention.

Fig. 15 is a flow chart 700 showing the steps in creating a child window. In flow chart 700, two windows are involved. The first window is the one that will be turned into a child window and the second window is the one that will be turned into a parent window. Prior to forming a parent-child relationship, these two windows could be entirely independent or could interact with each other under DCT or other program architecture. Upon receiving a command from the user that the first window should be the child, the first window sends an instruction to the second window requesting it to be the parent (step 702). In the preferred embodiment, this instruction includes the window handle of the first window. In step 704, the second window checks itself to determine if it is eligible to be the parent of the first window. If the answer is yes, flow chart 700 branches to step 710, in which the second window prepares itself to be a parent. In MS Windows environment, this step invokes using a "SetWindowLong" function to prepare a "base window" of the second window. The second window then notifies the first window. In a preferred embodiment, the window handle of the second window is passed to the first window. The concept of the "base window" is explained in Fig. 16A.

Fig. 16A shows the components of a typical window 730. In the present invention, this window is called the "top level window" because it includes all the components of the window. As an example, window 730 contains a region 732 for holding title and tool bars and a region 733 for holding a status bar. Regions 732 and 733 are created by MS Windows operating system. A base window 736 is a region (outside of regions 732 and 733) in which user-generated information (in the form of video, graphic, text, etc.) can be presented. The total composition (including base window 736 and regions 732-733) forms the "top level" window.

When a child window (such as window 752 of Fig. 16B) is created inside a parent window (such as window 750 of Fig. 16B), a complete window (i.e., the top level window) needs to be created inside the parent window. On the other, only the base window of the parent is affected in creating a child window. That is the reason why step 710 affects only the base window of the second window.

Returning now to Fig. 15, the first window prepares itself to be a child window (step 712). In MS Windows environment, this step involves using a "SetWindowLong" function to prepare a top-level window of the first window. In step 714, the first window changes itself to be a child window. In MS Windows environment, this step involves using a "SetParent" function. This function performs the necessary redrawing and repainting of the child window. The situation in which the answer to step 704 (i.e., the second window checks itself to determine if it is eligible to be the parent of the first window) is negative is described. In this case, now chart 700 branches to step 720 in which the second window informs the first window of the negative result. Flow chart 700 then terminates.

Third Embodiment Fig. 17 is a schematic diagram of a prior art object oriented programming ("OOP") structure 800. It comprises a plurality of classes, shown in Fig. 17 as classes 802-810. In many software applications, these classes are arranged in a hierarchical structure. Communication between classes in structure 800 follows a hierarchical path. For example, class 807 (which is at the end of a branch in structure 800) can communicate directly with classes in its branch, but cannot communicate directly with classes in other branches (e.g., class 809 at the end of another branch). Thus, if class 807 wishes to communicate with class 809, the message has to pass through class 803, which is common to both classes 807 and 809. Similarly, if class 807 wishes to communicate with class 806, the message has to pass through class 802, which is common to both 807 and 806.

The above described communication method works fine for simple applications. If the complexity of an application increases, it is sometimes difficult to keep track of various branches and communication paths. Further, it is very difficult to upgrade the application. This is because a change in the hierarchical location of one class could affect the program code of all classes which need to communicate with this class. Fig. 18 is a schematic diagram of a programming structure 820 of the present invention. Structure 820 comprises a plurality of classes, shown in Fig. 18 as classes 822-826. Classes 822-825 are essentially regular OOP classes with a requirement that they are designed to communicate with only one class: class 826. Class 826 is a specialized class designed to manage communication between classes 822-825 inside structure 820. In a further embodiment of the present invention, class 826 also controls communication between classes 822- 825 and program modules outside of structure 820 (e.g., other applications). Thus, class 828 can be considered a communication controller class, and is referred herein as controller 826.

In structure 820, classes 822-825 are not designed to communicate with each other directly. They are designed to communicate with controller 826. For example, if class 822 wishes to send a message to class 823, it first sends the message to controller 826. The message contains (i) an instruction to a destination class (e.g., class 823), and optionally (ii) the name or address of the destination class. Note that it is possible to identify the destination class based on the instruction if the instruction is unique to the destination class. In this case, controller 826 contains a list of instructions and their associated classes. When controller 826 receives a message without any designation, it can determine the destination of the message by looking up the list. The instruction can be forwarded to the correct destination class. The above described protocol of communicating via a controller class is called herein as the "local digital shifting function" (local DSF) protocol. In many applications, the classes in structure 820 can be activated at different times. Thus, controller 826 needs to keep track of which class is active at any given time. As part of the activation process, a class registers itself in controller 826 by sending a message thereto. Thus, controller 826 can reserve resources for this class. When a class is deactivated, it should also send a message to controller 826 so that controller 826 can release the reserved resource for other classes. Consequently, controller 826 knows which classes are active and are able to send and receive messages.

In another embodiment of the present invention, communication between classes 822-825 and controller 826 does not require any acknowledgment message (or a return value). For example, when class 822 sends a message to controller 826, controller 828 is not obliged to return any value or message to class 822. Similarly, when controller 826 delivers the message originated from class 822 to class 823, class 823 is not obliged to return any value or message to controller 826. This aspect of the present invention allows communication to be carried out with the least amount of overhead and delay.

In a further embodiment of the present invention, the messages between classes 822 -825 and controller 826 are ASCII coded. That is, the name of the instruction and other optional information (e.g., identification of the destination class) are coded in ASCII format.

Fig. 19 shows the structure of controller 826. It contains a block of program code 840 for receiving, processing and sending local DSF protocol and a block of program code 841 for receiving, processing, and sending instructions external to structure 820. Blocks 840 and 841 can communicate with two storage regions: (i) a region 844 containing a list of instructions and their associated classes, and (ii) a region 845 containing information of classes that have been activated. Information in regions 844 is used to match instruction with destination classes, as explained above. As an example, when block 840 receives a message from class 822-825 that does not indicate a destination class (or from other programming structures external to structure 820), controller 826 examines the list in region 844 to determine the destination of the instruction. If no destination is found, the message can be ignored. Information in region 845 is provided to controller 826 by other classes in structure 820 when a class is activated. The activating class registers with and supplies registration information to controller 826. The information allows controller 826 to manage messages more efficiently.

In the present invention, controller 826 is a specialized program module. The only function it performs is to control the communication of messages. Thus, controller 826 could be written in an efficient manner (e.g., the program size is very small and speed of execution very fast).

The operation of structure 820 is now described. An example is used to illustrate the operation: displaying the result of arithmetic operation of two munbers. It is assumed that (i) class 822 is a dialogue box class for users to enter numbers, (ii) class 823 is a arithmetic class for performing arithmetical operations on numbers, and (iii) class 824 is a display class for displaying information, including the result of the computation by arithmetic class 823. In the present invention, there is no need to know the hierarchical structure of these classes. All communication is one-to-one between these three classes and controller 826.

As part of the activation process, classes 822-824 register with controller 826. The function of dialogue box class 822 is to accept inputs from users (entered via it mouse or a keyboard). When a valid input (e.g., a number) is entered, dialogue box class 822 takes the input and encodes it in the local DSF protocol for transmission to arithmetic class 823 via controller 826. Arithmetic class 823 calculates the sum when the two numbers and the "add" operation have been received. The result of the computation is sent by arithmetic class 823 to display class 824 via controller 826. When display class 824 receives the result, it displays the result in a window.

As can be seen from the above described operation, there is no need for any class to know the hierarchical structure of the application. All communication is directed to a single controller. For example, arithmetic class 823 could be a branch of a mathematics class which contains classes for performing arithmetic, integration, logic operations, etc. Under prior art communication method, dialogue box class 822 needs to know the hierarchic structure relating to arithmetic class 823. There is no need to do so in the present invention. The improved architecture reduces programming complexity. It allows program codes to be developed and maintained in a more efficient manner. Even though there is overhead involved in adding a communication controller class and requiring communication be routed by that class, the overhead (in terms of program size and speed) is minimal because controller 826 is designed to perform limited number of operations. <Extension of the Architecture>

The above described architecture can be extended easily. In this case, structure 820 is only one program module in a multi-module application. The application could have a conventional architecture, or it could he built from a new programming technology called digital cell technology (DCT). Under DCT, applications are built from program "cells." One of the main differences between DCT and conventional architecture is that there is no "boss" that controls the operation of these cells. All the cells are at the same hierarchical level. Instructions can be sent from one cell to another without going through a long chain. In contrast, conventional applications are built from a main program (the boss) and many levels of sub-programs. In order for the sub-program at a low level to communicate with sub-programs at a high level, the communication must go through these levels.

In one embodiment of the extension, each cell is designed to have the same structure as structure 820. Thus, each cell has a communication controller which manages communication (i) between the classes inside a cell and (ii) between of the cells and classes inside a cell. Classes inside a cell are not designed to communicate directly with other cells.

Fig. 20 shows an embodiment in which a plurality of cells 852-855 are grouped together to form an application 850 (or a portion of an application). Each cell is similar to structure 820 of Fig. 18. Thus, each cell has a communication controller class (not shown in Fig. 20) which manages communication to and from the cell. Application 850 also comprises a communication controller cell 856. The role of this cell is similar to the role of communication controller class 826 of Fig. 18. Each cell is designed to communicate only with a communication controller cell 856. The communication protocol and method of operation of application 850 is similar to that of structure 820. Application 850 can communicate with other applications and data networks (such as the Internet) via communication controller cell 856.

In the arrangement of Fig. 20, the classes in a cell can optionally be made available to other cells. In this case, a first cell (e.g., cell 852) can issue an instruction to a second cell (e.g., cell 853) via controller cell 856. The controller class of the first cell then directs the instruction to an appropriate class inside the first cell. Note that a cell can hide some or all of its classes from other cells. This arrangement allows some or all of the classes in a cell to be shared by other cells.

The architecture shown in Figs. 18 and 20 can be extended upward to any levels. The number of components (e.g., classes in Fig. 18 and cells in Fig. 20) in each level and the number of levels depend on the complexity of the desired application. One advantage of the present invention is that the complexity of communication increases only slowly with the number of components and levels. On the other hand, the complexity of communication in prior art systems increases drastically with the number and level of classes.

An example of designing an multi-computer application using the above described system is described below. Fig. 21 shows a plurality of computers 902-904 connected to a data network 906. These computers can execute applications having similar structure as application 850 of Fig. 20 and are designed using programming structure 820 of Fig. 18. As an example, two computers, such as computers 902 and 904, execute an application comprising a portion 910a in computer 902 and a portion 910b in computer 904. Portion 910a comprises one or more cells, such as cells 912 and 913. One of these cells such as cell 912, is a controller cell. Portion, 910b may also comprises one or more cells, such as cells 916 and 918. One of these cells, such as cell 916, is a controller cell. When portion 910a needs to use cell 918 in computer 904, controller cell 912 sends a command, via data network 906, to controller cell 916. Controller cell 816 then delivers the command to cell 918. It should be noted that the cell-to-cell communication protocol described here is slightly different from the cell-to-cell communication protocol (called DSF) described in the above mentioned published PCT patent application number PCT/JP96/00821. It should also be noted that the extension is not limited to the DCT technology. The extension can be applied to conventional programming architecture.

The communication protocol of this embodiment is suitable to the second embodiment. Fourth Embodiment

Figs. 22A and 22B illustrate the scrolling of a text image of a prior art scrolling system. Components that are common in these two figures use the same numeral references. In Fig. 22A, a text image 1002 is shown in a window 1000. Image 1002 contains ten lines, each starts with 'This is line" and follows with a number. Fig. 22A also shows a vertical scroll bar 1006 containing two scroll arrows 1008 and 1009. A user can click on these two arrows to scroll text image 1002 upward or downward. It should be noted that the number of lines and the use of vertical scrolling (instead of a combination of scrolling directions) are for illustrative purposes only. Typically, the text image is generated by a computer system from a text-based file (e.g., ASCII file).

Fig. 22B illustrates the change in text image 1002 when arrow 1009 is clicked once. Specifically, a whole line is scrolled because the scrolling algorithm used in most computer system allows this kind of scrolling only. Thus, the first line from the top in Fig. 22B is "This is line 2", which is the second line from the top of the text image shown in Fig. 22A. It can be seen from Figs. 22A and 22B that the granularity in scrolling text image of the prior art system is one line. Under Microsoft's MS Windows, the resolution of VGA display is 640 by 480 pixels. The number of lines displayed in a full-screen window under VGA is less than fifty (for normal font size). Thus more than ten pixels are changed in scrolling one line. The result of this rough granularity is that scrolling text images produces jerky images. Some users may find the jerky images annoying, thereby reducing their propensity to use text image-based software running under graphic user interface ("GUI") environment.

Even though only vertical scrolling is illustrated in Figs. 22A and 22B, the same effect can also be seen in horizontal scrolling in which a character (instead of a line) is scrolled at a time. For the same reasons as described above, horizontal scrolling could be jerky. One of the reasons for the rough granularity is that many GUI-based operating systems provide line-based and character-based application program interface ("API") scrolling functions for scrolling text images. An example is the "LineScroll" function in Microsoft's Windows operating system. This function has parameters for specifying the number of lines to be scrolled vertically and the number of character positions to be scrolled horizontally. When this function is used, the vertical and horizontal scrolling have granularity of one line and one character, respectively. As a result, the text image is jerky during scrolling. There are good reasons for programmers to use the "LineScroll" (or similar) functions. The first reason is that it is the most efficient way to scroll a text image. All a programmer needs to do is to issue a simple "LineScroll" function. The programmer does not have to write a complicated routine for displaying text in a window. The second reason is that this may be the only way to scroll certain text images. This would he the case if the format of the drawing operation of an operating system is unknown. Typically, a text image consists of alphanumeric characters in various fonts and sizes. A drawing routine needs to read the underlying text file and draw, at an appropriate window, an image showing the correct font size and formatting details. However, the size, location, and style of a display window and the font rasterizer may be controlled by the operating system. The operating system may not give a programmer sufficient information and control to write his/her own scrolling routine.

The present invention allows a programmer to scroll a text image pixel - by-pixel instead of line-by-line using commonly available GUI-based APIs. A pixel is the smallest unit of display. Thus, this scrolling method represents the finest granularity in scrolling.

Fig. 23 is a schematic diagram showing the scrolling operation of the present invention. It shows an application window 1050 comprising an information area 1052 and a client area 1054. Information area 1052 is generated by the operating system, and typically contains the title, menu bar, and tool bar related to the window. Client area 1054 is used to display information provided by the programmers and users. For example, the above-described text image is normally displayed on client area 1054 of application window 1050.

Fig. 23 also shows a child window 1060 of application window 1050. The concept of a "child" window and a "parent" window is well known in. GUI-based system. In the present invention, child window 1080 has a client area that is slightly larger than client area 1054 of application window 1050. Windows 1060 and 1050 are arranged such that only the portion of child window 1060 overlapping client area 1054 of application window 1050 is displayed on a computer screen. In the present invention, the text image is drawn on the client area of child window 1060 instead of application window 1050. Client area 1054 of application window 1050 merely serves as a frame for allowing a user to see the portion of text image within this frame.

The text image 1002 of Figs. 22A and 22B is again used to illustrate the present invention. Text image 1002 is drawn on child window 1060. Initially, the position of the child window 1060 is arranged such that the first line, i.e., the line 'This is line 1", appears at the top of client area 1054 of application window 1050. Child window 1060 is then caused to move up, one pixel at a time. Under MS Windows, this can be accomplished using a "MoveWindow" API function. Because only the portion of child window 1060 surrounded by client area 1054 of application window 1050 is displayed on the computer screen, text image 1002 appears to scroll upwards pixel by pixel (instead of line by line). When child window 1060 has moved up by one full line (i.e., the line "This is line 1 " would disappear from the computer screen), it clears itself immediately and re-draws itself at the original position. At about the same time, a "LineScroll" Windows API function is invoked to scroll one line of the text image in child window 1060. As a result, the line "This is line 2" would replace the line "This is line 1 ". Because child window 1060 is back to its original position, this line appears at the top of client window 1054 of application window 1050. If further scrolling is desired, child window 1060 moves up again pixel by pixel.

The size of child window 1060 is determined from the following considerations: (1) Child window 1060 may need to move up one line or down one line before returning to its original position. Thus, child window 1060 should be larger than application window 1050 by at least two lines vertically if vertical scrolling is desired. (2) Child window 1060 may need to scroll to the left by one character and to the right by one character before returning to its original position. Thus, child window 1060 should be larger than application window 1050 by at least two characters horizontally if horizontal scrolling is desired.

Fig. 24 is a flow chart 1100 showing the above described steps. In step 1102, a child window is created by the present scrolling system at appropriate location on a computer screen. This location must be coordinated with the location of the application window so that appropriate portion of the text image appears inside the application window. In step 1104, the operating system and application software determine whether the user desires to scroll the text image. If the answer is negative step 1104 branches back to itself to wait until the user desires scrolling. If the answer is positive, flow chart 1100 branches to step 1106where the child window is moved one pixel in accordance with a scrolling direction desired by the user. At step 1108, flow chart 1100 determines whether the user desires more scrolling. If the answer is negative, scrolling is halted (step 1110). Flow chart 1100 branches back to step 1104 and wait for further action by the user. If the answer is positive, now chart 1100 determines whether a full line (for vertical scrolling) or a full character (for horizontal scrolling) has been scrolled (step 1112). If the answer is negative, flow chart 1100 branches back to step 1106 (i.e., scroll one more pixel). If the answer is positive, flow chart branches to step 1116 where the child window clears itself and then redraws itself at the original position. The text image is scrolled using a line-based or character-based scrolling API function (step 1118). Flow chart 1 100 branches to step 1106 where scrolling is again performed one-pixel at a time.

In an alternative embodiment, a different operation could be performed at step 1116. The child window could be moved rapidly back to its original position, and either simultaneously or at about the same time, step 1118 (i.e. , scroll one line) is executed. Thus, instead of a "clear and re-draw", step 1116 becomes a "move" performed rapidly.

It can be seen from the above description that pixel by-pixel scrolling can be performed using APIs typically available in a GUI-based operating environment. As a result, programming can be accomplished easily. Because scrolling is performed a pixel at a time (instead of a line or a character at a time), the movement of the text image is very smooth.

It should be noted that the number of lines shown in Figs. 22A and 22B is for illustrative purposes only. A text image could contain any number of lines each having any number of characters. This APIs used in the above examples are also for illustrative purposes only. The invention has Been described with reference to a specific exemplary embodiment thereof. Various modification and changes may he made thereunto without departing from the broad spirit and scope of the invention. The specification and drawings are, accordingly, to he regarded in an illustrative rather than a restrictive sense; the invention is limited only by the provided claims.

The invention has been described with reference to specific exemplary embodiments thereof. Various modification and changes may be made thereunto without departing from the broad spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense; the invention is limited only by the provided claims.