JP2003524843A - Method and system for controlling a complementary user interface on a display surface - Google Patents

Abstract

(57) [Summary] An alternative display content controller provides a technique for controlling video display that is separate from and added to content displayed on a display surface of an operating system. If the display is a computer monitor, the alternative display content controller interacts with a computer utility operating system and hardware drivers to control the allocation of display space and to one or more parallel display systems adjacent to the operating system desktop. Create and control a graphical user interface. The alternative display content controller may be implemented as either hardware or software.

Description

Detailed Description of the Invention

TECHNICAL FIELD The present invention relates to methods and systems for controlling the display of information on a display surface, and more particularly, one or more that may exist with a native user interface provided by a computer system. The present invention relates to computer software that displays a user interface.

SUMMARY OF THE INVENTION According to embodiments of the present invention, a computer-based method and system for displaying information on a display surface is provided. If a native (resident) operating system is present, these embodiments display information in a manner that is complementary to the native operating system. The displayed information may be present with a user interface provided by the native operating system. Further, these embodiments can be incorporated into a native operating system to provide a primary interface to the display surface.

Embodiments also include allocation of display space between one or more user interfaces and content, operating system, or application or concurrent graphical user interface (GUI) off-desktop (ie, native operating system interface, and Also provided is a technique for controlling an application that allows it to operate in the area allocated for the display of the application associated with it. In an exemplary embodiment, Microsoft Windows (R), Linux, Appl.
A computer operating under the control of any utility operating system such as the Macintosh O / S or Unix (R) of e may have a visual display assignment controlled by the techniques of the present invention. The operating system user interface (native GUI) may be expanded and / or moved to a specific area of the display that allows a parallel (or complementary) GUI to operate in an open area. An exemplary embodiment of the invention may be an application running under a primary or utility operating system, or in combination with an operating system kernel, distributed as a function of controlling display and content on a parallel display. (Eg, distributed as a microkernel).

Also provided in some embodiments are techniques for adding and using a parallel graphical user interface adjacent to a primary graphical display user interface (eg, within a boundary that extends beyond the standard screen display area). VG
Conventional video systems such as the A, SVGA, XGA, SXGA and UXGA video systems include a defined border around the display area. The original purpose of this boundary was to allow adequate time for horizontal and vertical retrace of the electron gun of a cathode ray tube display. However, with the advent of LCD displays, the retrace speed in modern monitors has become ever faster, and it is now possible to present user interface displays at this boundary. The boundaries that can be controlled as the user interface are part of what is known as the "overscan" area. Example embodiments include methods and systems for presenting one or more additional or secondary user interfaces, for example, in an overscan area around a native user interface display (desktop).

When the electron gun of a CRT reaches the left side of the screen or the top of the screen, sufficient time is required for the presentation of scan lines of data. The electron gun is turned off ("disappears") while it is returning. If the erase time required for retrace is equal to the available time, there is no overscan available. However, the retrace speed of modern monitors is much faster, leaving ample time when the electron gun does not have to be extinguished, thus allowing a visible border. In the prior art, the boundaries are usually "black" (the gun is turned off), but it is well known how to identify that the boundary exhibits any of the six colors. Standard BIOS can specify this color. The desired color is easily specified in one register of the video controller. Typically, this color data is not stored in the video memory buffer for display. An exemplary embodiment of the invention is
It establishes a further video buffer for the border and allows to write to this buffer with the display data, like a normal display buffer. Additional video buffers are often provided, but are not used in many computer graphics systems. This is typically achieved with video memory sized to a power of two (eg, “512K”), but the dimensions of a standard desktop are “eg 640 × 480 = 300K” rather than a power of two. Therefore, the display area extends at one or more edges, making previously invisible areas visible. Pixels within this new visible area of the display become accessible to the program through the application programming interface (API) component of the exemplary embodiment of the invention. A program that incorporates a parallel graphical user interface can be displayed in a previously erased area of the display so that the accessible area of the display can be functionally increased without changing the hardware. In other cases, the desktop may be increased or decreased to a non-standard size, opening up the display area for a parallel graphical user interface.

An exemplary embodiment of the present invention adjusts the video display area to include a display memory outside of a predefined video mode, thereby creating an area outside the primary display area generated by the video display system. Including a method and system for displaying images on a video display system. The two dimensions define the standard display area, and each dimension specifies the number of pixels. Choosing a video "mode" identifies these dimensions. The method may be accomplished by adjusting the parameters for the video display system to increase the number of pixels in at least one dimension of the display system. The number of pixels added is less than or equal to the difference between the number of pixels specified in the video mode and the maximum number of pixels that the video display system can efficiently display. In the present specification, any such difference is referred to as an overscan area. Therefore, the overscan area may be the difference between the current desktop video mode and the display capabilities of the display device. This difference is more specifically any portion of unused video memory for the given operating system screen size. Since many interface displays are created by writing the desired image into a buffer or memory for the video display, the above method requires the allocation of additional video display memory for the added pixels. The image written to such memory is then displayed by the system alongside the original display area.

In another exemplary embodiment, increasing only the vertical dimension, a parallel or complementary user interface is presented above or below the primary display area. Alternatively, the horizontal dimension may be increased and a parallel user interface displayed on the right or left side of the primary display area. Similarly, the parallel user interface may be displayed on any or all of the four sides of the primary display area.

In yet another exemplary embodiment, a parallel (or complementary) GUI is provided that includes access to existing search engines and browsers. In another embodiment, the parallel GUI includes a search engine and / or browser. Search engine and /
Alternatively, the browser may be opened in the overscan area, or space within or on the user interface of the native operating system.

In yet another exemplary embodiment, a technique is provided for adding and using a parallel graphical user interface adjacent to a primary graphical display user interface even though the overscan area is unused. This technique can be used to increase the overall display area, which causes the desktop to be reduced, expanded, or to match a smaller or newer portion of the overall display area, or , Will be moved. The parallel user interface may then be displayed in the remainder of the overall display area, or in space within or on the desktop. In one embodiment, by blocking the call to the video display driver, this technique is accomplished transparently to the native operating system user interface.

These and other features and advantages of the embodiments of the present invention will become more apparent from the detailed description and the accompanying drawings.

DESCRIPTION OF THE INVENTION Embodiments of the present invention provide methods and systems for displaying information on a display surface in a manner that complements the display metaphors and technologies provided by native operating systems. By using the techniques of the embodiments of the present invention, the complementary user interface can be operated within an existing system or provided as a stand-alone environment. The complementary user interface may exist as one or more secondary graphical user interfaces (“GUI”) with a primary user interface such as a conventional desktop GUI provided by a native operating system. The complementary user interface provided by such embodiments may be used to provide additional display screen area, or quick or continuous ("sticky") to selected applications.
) May provide access. The complementary user interface may provide a wide range of access capabilities, including, for example, continuous access to a user's favorite network locations on the Internet. For example, continuous access to applications such as personal information management, calendar, telephone, video conferencing, television programming, etc. may be provided.

Next, please refer to FIG. 1 and FIG. In a preferred embodiment, programming mechanisms and interfaces in a video display and control system such as computer system 7 or set top box 8 provide access to a portion of the display and provide visibility to display area 1 or A display area such as display area 9 is provided with one or more parallel GUIs such as space 2C and / or space 4. Some such displays are areas that are otherwise ignored and / or inaccessible ("overscan areas").
). A display area such as the display area 1 or the display area 9 may be a CRT, a TFT, an LCD.
And can be made on any type of analog or digital display hardware including, but not limited to, flat panel displays.

Another display content controller 6 interacts with the computer utility operating system 5B and the hardware driver 5C, controls the allocation of the display space 1 and is adjacent to the operating system desktop 3, a context sensitive network browser (CSNB) 2 And generate and control one or more concurrent graphical user interfaces such as Internet pages 2A and 2B. Another display content controller 6 may be incorporated in either hardware or software. When incorporated into software, another display content controller may be an application running on a computer operating system, or one that is dependent on the native operating system for hardware system services, and thus not dependent on the native operating system. ,
And may include various complex operating system kernels that span concurrent systems that may support specialized applications. Applications that can be used with other display content controllers can also be incorporated into various devices. Another display content controller may also include content distributed over Internet I or any other network and operating software such as JAVA®.

Another display content controller may also be included in a television decoder / set top box, such as Box 8, to simultaneously display two or more parallel graphical user interfaces, such as pages 9A and 9B. . The method and system of the present invention is based on NTSC, PAL, PAL-C, SEC.
It may be compatible with conventional television systems such as AM and MESECAM. In the case of this configuration, the contents and software are the radio broadcast signal 10A and the cable 10
It may be delivered via any conventional transmission medium 10 including, but not limited to, C, fiber optics and satellites 10B.

[0015]   It will be described in more detail below with reference to FIGS. 1 and 2.

FIG. 15 shows an example of a conventional standard display desktop produced by the Microsoft Windows® 95 operating system. Inside the desktop 31, there are a taskbar 32 and a desktop icon 33.

In one embodiment of the invention, the complementary graphical user interface image is
Painted on one or more sides of the overscan area as shown in FIG. FIG. 3 is a diagram of a Super VGA (SVGA) display with a further graphical bar user interface displayed in the overscan area. The overscan user interface bar 30 is defined to be located outside the boundaries of the “desktop” display area 31. In FIG. 16, the display has been modified to include the graphical user interface 30 in a bar 20 pixels high from the bottom. In FIG. 3, the display is graphical user within four bars (ie, bottom bar 30, left bar 34, right bar 36 and top bar 38) each 25 pixels high / width from each of the four edges of the display. Changed to include the interface. Complementary interfaces may include, but are not limited to, buttons, menus, application output controls (eg, “ticker windows”), animations, user input controls (eg, edit boxes). The complementary interface may be visible at all times because it is invisible to other applications running within the standard desktop, or visible and invisible based on any of multiple programming parameters. Can be switched between states. Multiple programming parameters include active window states, toggle button states, network messages, user favorites, etc.
It is not limited to this.

In addition, by assigning an overscan area or by using another method, (
Increasing the total display area (even if the size of the display area does not change) may cause the native desktop to be reduced or moved to fit a smaller or newer portion of the total display area. As a result, the complementary user interface can be displayed, leaving any sides or other areas. FIG. 22
˜30 illustrate some possible display area configurations and allocations to include one or more complementary user interfaces. These figures show that the complementary user interface may have non-uniform types and sizes and may reside on one or more overscan areas and in the native GUI (on the GUI) (eg, FIG. 2).
3 menu 2301). Further, as shown in FIGS. 25 and 30, the desktop may be moved or made smaller and may be used with a modified user interface that resides outside or within the desktop. FIG. 25 also illustrates how the complementary GUI content can be dynamically driven by connecting to a network such as the Internet. It will be apparent to those skilled in the art that any combination of these features is possible in practicing the embodiments of the present invention and additional features may be added within the scope of the present invention.

1. Video Display System Environment FIG. 4 is a block diagram of the basic components of a computer system video display environment that interacts with the method and system of the present invention. Within software component 5 are one or more applications, such as native operating system 63 and application 61. Within the protected mode of the modem system, the application 61 does not directly access hardware components such as the video or graphics driver 64 or the video card 66 including the video chipsets 66A, 66B, 66C. Extraction layers such as application programming interfaces (APIs) 60 and / or Direct X APIs 62 are often restricted in access through operating system 63. Such an exemplary API is Mi
Microsoft's GDI that provides graphical display capabilities to applications running in the Microsoft Windows (R) environment.

Embodiments of the present invention provide techniques for painting and accessing areas of the computer display that are either inaccessible or in use in native desktop graphics mode. Microsoft
Windows (R) environment (Microsoft Windows (R) 95
And its derivatives, including Microsoft Windows (R) NT 4.0 and its derivatives), and other modern operating environments, primary display area desktops are typically described in Tables 1 and 2 below. Assigned by the operating system to be any of a set of predetermined video "modes". Each of these tables is predefined with a particular pixel resolution. Therefore, the accessible area of the computer display cannot be changed, except when selecting other than the predefined modes available.

[0021]

[Table 1]

[0022]

[Table 2] As shown in FIG. 6, when the image is displayed on the computer display,
"Overscanned". That is, the displayed video buffer data occupies a size smaller than the overall drivable screen size. The drivable screen size is determined by the total amount of video memory and operable video display characters. The width of the overscan boundaries that can be used in the complementary user interface depends on the amount of horizontal overscan 52 reduced by horizontal blanking 54 and the amount of vertical overscan 53 reduced by vertical blanking 55.

In one embodiment, only the lower border of the standard display area is used to support the complementary user interface. Therefore, the control register (CR) in FIG.
Cathode ray tubes (designated as 6H, 16H, 11H, 10H, 12H and 15H (
Only the vertical control parameters of the CRT) controller need to be adjusted. These and other parameters are in Table 3 below. Table 3: Vertical timing parameters for CR programming

[0024]

[Table 3] In standard 640x480 graphics mode, the nominal horizontal scan rate is 31.5 KHz (60 frames per second) at a vertical scan rate of 60 Hz (60 frames per second).
It is 31,500 times per second). Therefore, the number of lines per frame is 31,
It is 500/60, that is, 525. Since only 480 data lines are needed to be displayed, the available lines for vertical overscan are 525-480,
That is, it is 45. The preferred embodiment uses 25 lines in the case of another display, since there remains more than an adequate margin for retrace, which requires only 2 lines per unit time. Therefore, you can increase the size of your native operating system desktop to some size other than the standard size, allowing another two lines, such as a blank line, with another 18 lines available but unused. It may be left blank, or it may be used for one or more additional concurrent user interface displays. Similarly, the 1024x768 graphics mode has a vertical scan rate of 85Hz.
May have a nominal horizontal scan rate of 68.7 KHz. This is calculated as 808 lines per frame, or 40 lines available for vertical overscan. By changing the vertical scan rate to 60 Hz, the frame size is increased to 1145 lines, including 377 lines available for vertical overscan.

(2. Change video display area to support complementary GUI) The information display method of the embodiment of the present invention, which increases the display screen by using the physical overscan area, provides three capabilities. Can be achieved by (1) Ability to specify and change the visible resolution of the video display system such that some parts of the overscan area are visible, as shown in FIG. 6, (2) Video of the visible part of the overscan area. Ability to specify and modify display content (3) Provide an application programming interface (API) or other mechanism for an application to perform this function. Further details and steps provided in FIGS. 7 and 8-13 are: , Provides an exemplary flowchart of an implementation of an embodiment of the present invention that meets the above capabilities. The environment for this exemplary implementation is an M, with Microsoft's standard platform software developer kit (SDK) and device driver kit (DDK) for development platforms.
A standard Microsoft Windows (R) 95 operating in an environment using Microsoft Visual C and Microsoft MASM. One of ordinary skill in the art will appreciate that other embodiments can be performed on other platforms and in other environments. For example, X-Windows (R), OSF
Motif, Apple Macintosh OS, Java (R) OS
, And similar video standards (VGA, SVGA, XGA, SXGA, UXGA
, 8514 / A) may be implemented in any graphical interface environment such as others. Richard Wilton
PC Video System published by Microsoft Publishing by
s and Richard F.S. Addison We by Ferrano
Programmer's Guide to the issued by sley
See EGA, VGA, and Super VGA Cards.
All of the above references are incorporated herein by reference. The above references are Wi
It provides more pertinent background information for implementing embodiments in the Windows (R) environment.

As mentioned above, the method and system of the present invention also provide other techniques such as emulation mode. Such an emulation mode allows another display content controller to share the available display area between the native GUI and the concurrent user interface, thereby effectively sizing the available display area for the concurrent user interface. increase. The emulation mode effectively reduces the portion of the display area allocated to the primary GUI, or effectively increases the resolution to standard or non-standard resolutions, any of which is increased to the primary GUI. It works by utilizing this increment without providing it. The emulation mode detailed with reference to FIG. 14 provides hooks to the video driver so that what part of the screen resolution is the primary G.
Controls what is assigned to the UI and what is assigned to the parallel GUI. In that the emulation mode can be used to share the display area between the primary GUI and one or more parallel GUIs, whether or not the overscan method is used to increase the display area. Please note.

If another display content controller determines that the complementary GUI can be displayed without using either the overscan method or the emulation mode, then that controller is provided by the native operating system or the primary GUI. Try to use the standard window mode that is used.

In summary, another display content controller can either increase the addressable area of the display (eg, by using overscan areas or by using emulation mode to increase resolution), or by the primary Decreasing the portion of the display available to the GUI increases the remaining display area so that it can be used by one or more complementary GUIs, and determines how to use the complementary GUI. The use of overscan areas is not automatic, and hardware and software systems need to be somewhat accessible (by knowledge or heuristics of the video driver and hardware) to do this. Several mechanisms can be used to determine whether the overscan method can be used and are detailed below. If the overscan method is not available in a particular video display scenario, another display content controller determines if the "emulation" mode is available and determines whether the primary GUI and any parallel (complementary) G
Share the resolution of the video display with the UI. As a result, the accessible overscan area is efficiently created.

(2.1 Technology for Extending Display Area to Physical Overscan Area (Overscan Mode)) Referring now particularly to FIG. 7, the program is initialized based on user preference and program configuration. "Identify borders to display" to determine the borders of the screen to be accessed (step 106), and if necessary, enough video memory to make the necessary display changes in the overscan area. It is determined whether or not it exists (step 106). For example, the screen is now set to a resolution of 1024 x 768 with 16 bits per pixel, and the program contains four graphical interfaces, one at each end and each bar 20
Is 20 pixels deep, the program uses 1.7M of video memory.
It must be checked that it is greater than B (number of bytes required = pixel width ^* bits per pixel ^* pixel height). This calculation is only necessary if one or more bars can be displayed on the overscan screen. If the calculation fails to determine that there is enough video memory to display the bar (s) in the overscan area, the program proceeds to run in emulation mode. In the display type identification (step 102), the program
Attempts to determine the display type and the current position in memory used by the display driver to determine the size and position of any display modifications that will be made (the size and position of the overscan region (s) used). .

As described in more detail in FIG. 8, the program first attempts to query the hardware registry in the query hardware registry (step 131) to determine the registered display type. If successful, the program determines compatibility information on the supported display type (step 135) to ensure that the program supports this display type and determines memory allocation information.

If the hardware registry information determined in step 131 is not available, or if it is determined that the display type determined in step 131 is not supported by step 104, the program is the subroutine query hardware. Another approach, shown in (step 135 of FIG. 8), may be used to query the BIOS (step 134) and video chipset 66 (step 136) for information similar to that described immediately below.

When the BIOS is accessed in step 134, the physical memory first
Allocate Physical Memory ”
(Step 132), and Microsoft's DPMI (
Access using the DOS protected mode interface)
Map I to the linear memory address where the BIOS resides. D in physical memory
A linear address of the BIOS is assigned to the physical memory using the PMI (step 133).

Thereafter, the program queries the BIOS in the read BIOS block,
The VGA / XVA type and manufacturing ID are retrieved (step 134). If successful, the driver and chipset are further queried to determine the display type and the exact chipset inquiry driver / chipset memory location (step 136).

Compatibility information is standard VGA, SVGA, XGA, SXGA, UXGA or 8
If it does not indicate a 514 / A signature (step 134), this routine returns failure. If a known chipset manufacturer identification is found, the driver and / or chipset is queried with a manufacturer specific routine (step 136) to identify and initialize the particular chipset, if necessary. obtain.

If the program identifies the video device driver supported by the xSides ^™ Video Driver Extensions (VDE) in determining the display type, the program uses VDE to implement overscan mode. And proceed to execution. The xSides ^™ VDE is an extension that can be implemented more transparently by video device driver vendors and jointly supports the xSides ^™ environment.

If, in step 104, the program was unable to finally identify the display type, then either the registry inquiry in step 131 or the hardware inquiry in step 135 failed, causing the program to Proceed to run in "emulation" mode.

Returning to FIG. 7, if the program has not yet determined that it needs to go to “emulation” mode, the program needs to determine if it can go to “overscan” mode. (Step 104). There are several mechanisms by which this can be done. A set of classes is used, all derived from a common base class that corresponds to the VGA generic technology described below.

The first mechanism is an implementation of VGA generic technology. With this mechanism,
No video card specific information is needed other than to guarantee VGA support. Assign the first side and the second side using standard application programming interface (API) routines.

The first side assignment is always based on a full screen display. Given the linear address of the assigned first side, a physical address may be obtained, which linear address is directly adjacent to the first side and is therefore the video memory immediately below the desktop display. The physical address of the location in is the physical address of the first side,
It can be deduced to be represented by the sum of the bytes of memory used to maintain the first side in memory.

After knowing the physical address of the first side, the size of the first side represented in the video memory can be determined.

For example, the system looks like a CR with a resolution of 800 × 600 screens for bits per pixel, or bytes per pixel. Then, any data stored in the CR that represents any horizontal length is included. This is the actual scanline length.

Next, the assigned second side physical address is obtained from the linear address.
The allocated second surface is actually allocated in the memory space following the first surface (the value of the physical address of the second surface is the same as the value of the physical address of the first surface. The second side is determined at the position of the overscan display in memory.

However, if this is incorrect and the second side does not follow the first side, another approach mechanism is needed. For example, a mechanism may be used that "frees" memory from the video device driver, effectively modifying or moving the video device driver data to obtain contiguous memory. This mechanism may use an interrupt routine to transparently move driver data.

For example, if the program is Intel 80386 (or higher compatible)
When the interrupt descriptor table (IDT) can be identified from the processor, the program uses the debug register (DR) to display the driver data found between the first display surface and the second display surface in the video memory. To a position further below to make contiguous memory space available to the program.

The IDT associates each interrupt with a descriptor of the instruction that handles the associated event. For example, if a software interrupt (INT3) is generated (and the interrupt is enabled), the Intel processor will stop what it is currently doing and the appropriate code address to execute to handle this interrupt. Examine the input (ie interrupt vector) in the IDT. The code is known as an interrupt service routine (ISR). The code begins executing the ISR. When the instruction that returns from the interrupt (IRET) is executed by the ISR, the processor resumes what it was doing before the interrupt.

The Intel 80386 microprocessor (or higher compatible microprocessor) provides a set of system registers commonly used for debugging purposes. These are technically called debug registers (DR). DR allows control over the execution of code and access to data. DR is used with the exception code. Four address registers (ie
There are four different places of code and / or data) (DR0, DR1, DR2 and DR3).

The control register (DR7) may be programmed to selectively enable the address register. In addition, DR7 is used to control the type of access to the memory location that generates the interrupt. For example, exceptions may be raised to read and / or write to a particular memory location, or to execute a memory location (ie code execution).

Finally, using the status register (DR6), the debug exception (that is,
And in which address register the exception was generated). If the x86 processor is enabled and the data criteria are met, the x86 processor will generate an interrupt 1 (INT1).

An exemplary implementation of the alternative display content controller preferably first sets the IDT to indicate the new ISR and handles the INT1 interrupt. The address of the hooked code (ie, the memory location of the data) is then programmed into one of the address registers to set the appropriate bits in the control register.
When the x86 processor executes this instruction (ie, touches the memory location of the data), it generates INT1. The processor then calls the Interrupt 1 ISR (as described above). At this point, the ISR can perform almost any type of processor, code or data operation. When done,
The ISR executes the IRET instruction and the processor begins execution after the time when INT1 occurs. The interrupt code has no knowledge of interrupts. This mechanism used in the exemplary implementation moves the memory addresses of the video cache and the hardware cursor.

In summary, the first mechanism for determining whether overscan is supported determines how much physical area is allocated to the desktop, and thus the parallel GUI below the physical area. It is possible to display the area adjacent to the two spaces in the overscan area. The newly allocated area is just the first block of available memory. If this block immediately follows the first side, the physical address corresponds to the value associated with the physical address of the first side plus the size of the first side. If this is the case, the memory block is contiguous and it is possible to go into overscan mode using this VGA generic mechanism and the program returns true in step 104 of FIG.

If this first VGA generic mechanism cannot be used, the video card and driver name and version information retrieved from the hardware registry or BIOS, as described above, is used with the look-up table. Determine the best alternative mechanism among the mechanisms. The table contains a set of standards that are key to the list of driver names found in the hardware registry. An example of a class of objects specific to a video chipset, either directly or indirectly, based on VGA generic objects.

If the hardware lookup does not give a reliable match result, a reliable or reliable correction factor may be used. For example, if a hardware lookup determines that a given type of XYZ brand device is being used, but the particular specified XYZ device is not found in the lookup table, then a generic chipset manufacturer Models are often available. If the information on the video card is not available, the program returns false (f
return) and do not proceed to overscan mode.

The next alternative mechanism for determining support for overscan mode uses surface overlays. The first step to this approach is to determine if the system supports surface overlays. Call the video driver,
Determine which features are supported and which other elements are needed. If surface overlays are supported, for example, a scaling factor may be needed.

For example, a particular video card in a given machine that uses 2 megabytes of video RAM will only draw an overlay over the full bandwidth of the video card's bandwidth or card speed combined with a relatively small amount of video memory. Since it is not enough, it may support an unscaled surface overlay to 8 bits per pixel 1024x768 instead of 16 bits per pixel 1024x768. Often the problem is horizontal scaling, which prevents the driver from drawing a full width overlay. The overlay is literally an image drawn on the first side. This is not the second aspect mentioned above. Usually the system sends that signal from the video driver to the hardware, and then
The hardware merges the two signals, which overlays the first signal with the second signal.

If the system is unable to support unscaled overlays, this mechanism is not desirable, probably due to bandwidth or memory issues. This mechanism is not rejected, but it is a low priority option. For example, if the magnification is less than 0.1, a normal bar can be drawn and this bar clipped proximal to the end. If the magnification is higher than 10%, another approach mechanism is needed.

In another mechanism of the next set, a second sufficiently sized to include an area of a normal desktop display plus an overscan area used to display the overscan bar (s). Faces are assigned. With these mechanisms, it is not necessary to place the assigned second side in memory in a contiguous manner with the first side. However, these approaches use more video memory than other approaches.

The first step is to allocate a second surface of sufficient size to contain the video display (first surface) plus the overscan area used. If the allocation fails, it means that there is not enough video memory to accomplish the task and this set of mechanisms is skipped and the next alternative mechanism is tried. After the new memory block is allocated, a very small granularity timer is used to simply copy the memory of the content of the first side onto the appropriate location of this second side. This timer runs about 85 copies per second.

Another mechanism that determines support for overscan mode is a variable that uses the system's page table to find the address that corresponds to the native operating system's graphical display interface, such as Windows® GDI. Those skilled in the art will appreciate that similar methods can be used in the system with other graphical display interfaces to video device drivers. The system page table mechanism queries the system page table to determine the current GDI plane address, ie, the physical address of the first plane in the page table. The second surface is then made large enough to hold all of the video memory plus the memory required for the displayed overscan area. This face is then pushed into the system's page table and asserted as the GDI face address.

Thereafter, when the GDI reads from or writes to the first surface via the driver, the GDI actually reads from or writes to a new larger in-plane location. Subsequently, the program may modify the surface area that is not addressed by GDI. It may deallocate the original first side and improve memory usage. This mechanism is more memory efficient than the mechanism described above and is the preferred embodiment. However, this mechanism of modifying the page table does not work properly on chipsets that include coprocessor devices. If the initial device query indicates that the device contains a coprocessor, this deformation mechanism is not tried.

Another variation of the above mechanism for determining support for overscan mode is handled by the resulting class object. For example, if the video card requires more than 10 bits in the CR to represent the resolution of the video, the VGA generic mechanism may change. Some instances may require 11 bits. Such registers typically do not use contiguous bytes, but extension bits to specify higher order bits of address information. In this example, 11
The second bit is usually specified in the extended CR register, which is usually chip-specific.

Similarly, variations of the surface overlay mechanism include magnification as described above. This alternative embodiment is processed in a particular implementation via the resulting class object and may be the preferred solution in a particular situation.

If any of the above mechanisms used to determine whether overscan mode is supported and subsequently initialize overscan mode returns a failure, another mode (eg, , "Emulation" mode or "window" mode).

If the program goes to “overscan” mode, step 10 of FIG.
The controller register, or CR, must first be unlocked and the CR made writable, as shown in the CRTC Register Release of 8. Shown in FIG. 4 and Table 3
Controller registers 6H, 16H, 11H, 10H, 12H and 15H described in
Can be accessed through standard input / output ports using standard input / output functionality. The controller register is unlocked by clearing bit 7 in controller register 11H.

Video memory addressing (step 112) is one of several means.
Achieved through one. One uses a standard VGA 64Kb "hardware window," along with the video memory buffer 66B (FIG. 4) as needed.
It is to move in increments of 4 Kb. One exemplary method is to enable linear addressing by querying the linear window position address video chipset of step 138 of FIG. This 32-bit offset in memory allows the program to map linear memory to physical addresses that can be manipulated by programming (FIG. 11).
Steps 140 and 142).

At this point, the program may resize the display (step 114 in FIG. 7) to include the border area. Changing the display resolution to change the display size is shown in detail in FIG. In FIG. 9, the routine first checks to determine if the system is running in "emulation" mode (step 144) and, if so, returns true.
If not, the routine resets all registers and values to their original state, effectively returning the display to its original appearance (steps 148-).
154) or not. This decision is based on several parameters, such as whether the current resolution (step 146) reflects a standard value or a previous program operation (step 148). If the standard resolution is already set, the variable is reset to include the specified border area (step 150). If not set, reset register to standard value. In both cases, the CR register is adjusted (step 154) to modify the scanned and blanked areas of the display. If the top or side areas have not been modified, the existing video memory is moved accordingly in step 162 of FIG.

If any of the above routines returns failure, the program proceeds to run in "emulation" mode (step 113 of FIG. 7) or window mode (step 116 of FIG. 7) if possible. obtain.

In the present invention, the overscan mode is modified to the actual display mode again, and the modified non-standard GUI mode (standard display size or resolution is adjusted to be added to the first display). The second GUI can be considered as a technique for adding a second GUI. For example, a standard 640x480 display is modified by the techniques of the present invention into a larger display. One of these choices is the original 640x4
Corresponding to 80 displays, another choice may correspond to a 640x25 second GUI display.

In another embodiment of the system of the present invention, resources are assigned to the second GUI by tricking the video driver into a higher resolution. This technique ensures that enough video memory is allocated and not enough is used because the video driver allocates system resources with a resolution that the video driver believes is running at this resolution. To operate the one or more second user interfaces within the one or more screen areas, free the memory in the video memory or frame buffer associated with successive display positions below the first surface. Need to be available to. Utilizing a series of small routines specific to hardware known to have system resource allocation problems for the second user interface, the program executes such routines whenever the resolution is switched. To initialize the chipset for a particular routine. If the program finds a routine for the current particular chipset, this routine is invoked. The routine initializes itself, makes the necessary changes to the driver's video resolution table, re-enables, and then sufficient space is available to one or more second user interfaces.

When re-enabled, the video driver allocates video memory for the first display as required by the data in the video resolution table.
Therefore, the modified value results in a larger allocation. After the video driver allocates the required memory for the first side, the driver does not allow modification outside the allocated memory. Therefore, by making the driver believe that the driver needs to allocate enough memory for a resolution that is just x bytes larger than the current resolution (where x is the size of one or more second user interfaces), the program will , It may be ensured that neither internal nor external use of the allocated memory space can conflict with the second user interface.

Tricking the driver into allocating additional resources further modifies each instance of the known video mode table of the video driver, thus creating a screen size larger than the screen size of the first user interface. It can also be done by This technique eliminates the need to prevent the driver from actually moving to the specified higher resolution and imparting a larger display surface resolution to the first user interface. If the video driver verifies the new resolution, the video driver checks the hardware mode table that has not been updated with the new resolution. (The "hardware mode table" is a variation of the video resolution table described above, and is neither known nor accessible.) Therefore, this verification will always fail and the video driver will be forced to transition to this resolution. Refuse. However, because this technique modifies the table of known video modes (resolutions) early enough in the driver's process, it modifies the amount of allocated memory before the failure occurs during the verification process, changing the memory address. Is set. Subsequently, if the CRTC is modified (step 114), the driver has already reserved sufficient memory for one or more second user interfaces, which is not available for any other process or purpose. .

In yet another embodiment of the invention, enveloping.
ng) the driver as if it were on the actual (first) video driver and shim the enveloping driver between the hardware abstraction layer and the first video driver to create the first driver. To be able to handle all calls to. This technique modifies the first driver and its table in a rather general way rather than a chipset specific way. The enveloping driver is embedded within the first video driver to transparently handle calls going to and from the first video driver. The enveloping driver looks for a resolution table for the video in the first video driver (which may be in multiple locations within the driver). The envelop driver modifies the table (e.g.
0x625). An entry in the 1024 × 768 table can be, for example, a 1024 × 800 entry.

Fooling the Video Driver Similar to the techniques described above, the first video driver cannot verify the new resolution and, therefore, cannot actually change the resolution setting of the display. As a result, the first video driver allocates memory, allocates cache areas, determines memory addresses, moves the cache, and moves off-screen buffers as needed, but with all the allocated space. It cannot be used or drawn into this space.

(2.2 Technology for Sharing Display Area (Emulation Mode)) The emulation mode is reallocated by using the display area and the driver resource by using the “hooking” mechanism shown in FIG. As mentioned above, the video device driver may be a hardware registry or a BIOS.
Once identified, such as through, the entry point of a particular programming interface into the driver is hooked (eg, step 117) to control parameters to and from the driver. When an operating system graphical device interface, eg, GDI, calls an input point to a video device driver, an alternative display content controller modifies the parameters communicated to the driver and / or the value returned from the driver, Controls the attributes of the display that are communicated to the native operating system's graphical device interface. Thus, the program "hooks" (ie, intercepts) calls to and from the graphical device interface to the video device driver.

The program may allocate the screen area differently (step 119), for example by hooking a “re-enable” function into the display driver (step 117).

(1) In setting mode (step 121), intercept the resolution change request and identify the next higher supported screen resolution, and inform the video device driver of the higher resolution, and If the driver approves the change, it intercepts the value returned (which reflects the new resolution) and instead returns the original requested resolution. For example, if GDI requests a change from 640x480 resolution to 800x600 resolution, the program intercepts the request and modifies it to make the video device driver 80
Change to the next supported resolution higher than 0x600 (eg, 1024x768). The driver changes the screen resolution to 1024x768 and returns this new resolution. The program intercepts the returned request and, instead, passes the original request 800x600 to GDI. 102 video device drivers
Allocate a 4x768 memory area and display it. GDI and the native OS display the desktop in an 800x600 area of the display, leaving areas at the right and bottom edges of the screen available to the program.

(2) In shared mode (step 123), the program intercepts only the request coming back from the video device driver and modifies the value to change the understanding of the graphical device interface regarding the actual screen resolution.
For example, if GDI requests a change from a resolution of 800x600 to a resolution of 1024x768, the program intercepts the returned authorization and sends a predetermined amount ( For example, 32) is subtracted. The video device driver allocates and displays a memory area of 1024 × 768.
GDI displays the desktop in a 1024 × 736 area of the display, leaving the area at the bottom of the screen available to the program.

(3) In step down mode (step 125), the program performs the reverse of step up mode. That is, the program intercepts the resolution change request and requests a resolution change, but returns the next lower resolution to the graphical device interface. For example, if GDI requests a change from 640x480 resolution to 800x600 resolution, the program intercepts the request and modifies it to change the video device driver to 800x600. The video device driver changes the screen resolution to 800x600 and returns the new resolution. The program intercepts the returned request and, instead, tells GDI the next lower resolution 640x480 (denies the request).
. The driver allocates 800 × 600 memory area and displays it. GDI
And the native OS displays the desktop in a 640x480 area of the display, leaving areas at the right and bottom edges of the screen available to the overscan program.

Another embodiment of these hooking mechanisms is the X used for specific GDI functions.
, Hooks all video device driver functions needed to modify the Y offset. Effectively, this moves the GDI display area within the larger screen display area. This mechanism allows creating emulation mode space on the top and left edges by sharing some or all of the space originally created at the bottom and / or right edges.

As mentioned above, if the video device driver cannot be hooked, the “emulation” mode cannot be supported and the program will proceed to step 116 of FIG.
Proceed to execution in "window" mode as described with reference to. Window mode is established for native operating system GUIs.
It runs as an "application toolbar" within the display area of a standard window using a PI routine. Running as a standard application allows the program to take advantage of the mechanisms available to all applications on the native OS (eg window creation, toolbar interface docking, etc.), and the program under standard conditions. It becomes possible to carry out.

In summary, the alternative display content controller may increase the addressable area of the display (eg, by using overscan areas or by using emulation mode to increase resolution), or By reducing the portion of the display available to the first GUI so that the remaining display area can be used by one or more complementary GUIs, the display area can be increased to provide complementary GUI. Decide whether to use. If the overscan technique is not available in a particular video display scenario, the alternative display content controller may be in an "emulation" mode, which is between the first GUI and any second (complementary) GUI. Share resolution of video display at) can be used.

3. Providing an Image to a Modified Display Area As described with reference to FIG. 10, the second stage of the exemplary embodiment of the present invention involves painting a new image into an off-screen buffer, which is commonly used in the art. (Step 118), and the content is made visible (step 120).
Start with that.

After determining and initializing the program mode, the program may display the data as appropriate by any of these techniques.

(1) Use standard API calls, as described in the next section, to provide data to an off-screen buffer, then hook the input point of the "BitBlt" function into the display driver, Modifying the offset and size parameters causes the program to subsequently redirect BitBlt to an area outside the area that the API believes is on-screen.

(2) Using the first side address and second side address mechanisms described above, the program determines the linear address of the off-desktop memory location (s) at which the program remains available. And may be provided directly to memory locations as shown in steps 158 and 142 of FIG. 11 and step 154 of FIG.

(3) With video device driver escape, standard mechanisms within the domain of the device driver interface directly blit (bl) to the video buffer.
it)

(4) If the program is in "window" mode (step 156), the off-screen buffer is painted in standard window client space (step 166) and made visible using the generic windowing system routines. (Step 164).

4. Event Handling with Modified Video Display Area A preferred embodiment of the program includes a standard application message loop that handles system and user events (step 122). An example of a minimally functional process loop is in FIG. Here, the alternative display content controller may request a paint request (step 170), change system resolution (step 170).
Process a minimal set of system events such as step 172) and activation / deactivation (step 174). Again, user events (e.g., key events or mouse events) detailed in Figure 13 may be processed (step 1).
84). As for the system paint message, the inside of the off-screen buffer is appropriately painted (step 178) as described above with reference to FIG.
Paint the window or display buffer (step 18)
0) is processed. System resolution messages are received whenever the system or user changes screen or color resolutions. The program resets all registers and / or if appropriate for the current mode,
Hook to the correct new value and then change the resolution of the display (step 182) to reflect the modified new resolution, as previously described in FIG. User messages may be ignored if the program is not an active application.

FIG. 13 illustrates one method of implementing a user input event. In this embodiment, there are three different mechanisms used to implement cursor support or mouse support so that the user has a pointing device input tool within the user interface in the area of the alternative display content controller.

According to one preferred mechanism, GDI's “cliplect”
To include the display area of the bar. This prevents the operating system from clipping the cursor as it moves into the overscan area. This modification does not necessarily make the cursor visible or provide event feedback to the application, but it is the first step.

Some current Windows® applications continually reset Cliplect. Resetting the cliplect after using or losing input focus is a standard programming procedure. Some applications use cliplect to limit the mouse to a particular area when needed by an active application.
Whenever the program receives input focus, the program reasserts cliprect, which causes the input focus to be large enough to move the mouse into the display space of the program.

After the cliplect is magnified, the mouse may generate a message to the operating system that reflects movement within the magnified area. GDI does not draw the cursor outside the understanding it is in GDI resolution and does not convey to the application an "out of bounds" event message. The preferred program uses the VxD device driver and associated recall functions to make hardware driver calls on ring 0 to monitor actual physical delta or mouse position and state changes. Each mouse position or state change is returned as an event to the program, which may graphically represent the position in display space.

Another mechanism facilitates panning of the virtual display, eliminating the need to magnify the cliplect so that it does not conflict with a class of device drivers that use it. When directly queried with a mouse input device, the program may determine a "delta" or change in position and state. Whenever the cursor touches the very last row or column of pixels on a standard display, the cursor is restricted to that location by setting the cliplect to a rectangle consisting of this last row or column only. The "virtual" cursor position is obtained from the delta available from the input device. The actual cursor is hidden and the virtual cursor display is clearly displayed at the virtual coordinates to provide the user with accurate feedback. When the virtual coordinates move from the overscan area onto the desktop, the cliplect is cleared, the virtual display is removed, and the actual cursor is restored on the screen.

A third alternative mechanism creates a transparent window. This window occupies the display area of the actual Windows (R) desktop by a predetermined number of pixels (for example,
2 or 4 pixels). When the mouse enters this small, transparent area, the program hides the cursor. Next, the cursor image is displayed in the overscan bar area with the same X coordinate, and in the Y coordinate with a corresponding offset in the overscan area. The method uses a granularity of 2 when using an overlapping region of two pixels. Therefore, this API-only approach provides only limited vertical granularity. This alternative mechanism ensures that all implementations have a certain degree of mouse input support, even if the cliprect and input device driver solutions fail.

Similarly, keyboard input can be trapped whenever the mouse is determined to be in the program's display space. If the program decides to catch and process key events using the standard hooking mechanism available for native OS and graphical user interfaces or hooks directly on the keyboard driver (for example, the user can move the mouse over the display space of the program). Key events can be captured and processed at any time. If the keystroke is captured, other applications may be prevented from viewing the keyboard event. Even GDI does not get keystroke events if the keyboard driver itself is hooked.

FIG. 7 further illustrates the cleanup mechanism performed when the program is closed (step 124). The display is reset to its original resolution (step 126) and the CR register is reset to its original value (step 1).
28) and locked (step 130).

5. Further / Alternative Embodiments 5.1 Further Embodiments of Overscan Techniques that Modify Display Areas to Support Complementary GUIs The following embodiments are used to size or display the display areas. The area allocation is modified to support complementary user interfaces.

1. Instead of the CRT controller register (Figure 5), the VESA BIOS extension (V
BE) to determine the linear window position address and / or
Alternatively, it is accessed (step 138).

2. Instead of the CRT controller register (Figure 5), the VESA BIOS extension (V
BE) is used to increase the visible display area drawn by the CRT.

3. Instead of direct access to the CRT controller registers and / or the display buffer, Microsoft's DirectX and / or Direct
Direct driver such as Draw and / or API that can operate hardware (
An application programming interface) 62 is used.

4. A second virtual display surface is created on the first display using an API (application programming interface) 62 such as Microsoft DirectX and / or DirectDraw, which allows direct driver and / or hardware operation, for the same purpose. To display a separate and clear graphical user interface.

5. Dir to CRT controller register and / or display buffer
Instead of ctX access, a modification is made to the operating system 63 shell or tray window component of the shell.

6. A modification is made to the shell of the operating system 63 or the tray window component of the shell to create a second virtual display surface on the first display to display a separate and unambiguous graphical user interface for the same purpose.

7. This functionality is built into the actual video driver 64 and / or minidriver. Microsoft Windows (R) is a virtual device driver, VxD
, And / or support system services that may interface more directly with hardware and drivers. These may further include APIs to provide the application with an interface to the modified display.

8. Incorporating the same functionality into the BIOS with or without VGA registers,
It then provides an API to allow the application to interface to the modified display.

9. The same function, for example, a hardware interface to the CPU and / or
Or embedded within a hardware device such as the monitor itself with a software interface.

10. The same functionality is built into the overlay device, with or without the video device system, overlaying the display and providing the interfaced application to the display.

Embodiments of the present invention do not rely solely on the ability to modify the CRTC to modify the visible display area. As mentioned above, additional mechanisms are provided that define other ways of creating and accessing the visible area of the screen outside the dimensions of the desktop, which is accessed by the native operating system user interface. Various other embodiments of the method and system of the present invention will be further apparent to those skilled in the art.

5.2 Driving a Native Desktop with an Alternate Display Content Controller Using the techniques of the present invention, a desktop (eg, Windows) can be controlled only by the capabilities of the display's hardware. It easily enables the desktop to operate in virtually any non-standard size that is limited. It may be combined with a parallel graphical user interface display or used independently to maximize the desktop display area of the first operating system. This may not require any modification to the operating system.

For example, the visual display area is traditionally maintained in a CRTC register on the chip and is defined by the values available to the driver. The area normally displayed is VG
A preset number of modes is defined by the A standard, followed by the SVGA standard, each mode including a particular display resolution that specifies an area of the display on which the desktop can be displayed.

Normal native operating system (eg Windows®)
Desktops, the operating system directly reads the video memory /
It does not write, but rather uses programming interface calls to the video driver, so it can only be displayed in this area. The video driver simply reads / writes using any address in video memory. Therefore, this mechanism requires that the video card and driver asserts know the value (eg, address) available for painting. This value is queried from the register, modified by the specified amount to increase the display area, and then overwritten on the card. Thus, the exemplary embodiment provides writable attributes and visible display areas,
Changes may be made without notifying the display interface of the operating system.

Embodiments of the present invention do not necessarily modify the CRTC to add only the bottom. Preferably, the upper part also moves a little higher. This keeps the displayed interface centered within the drivable display area. For example, instead of simply adding 32 scan lines to the bottom, move the top of the display area up by 16 lines.

5.3 Further Embodiments for Locating Concurrent User Interfaces One of ordinary skill in the art will appreciate that any number of concurrent GUIs may be located in areas that would not normally be considered overscan areas in the past. To do. For example, a second GUI could be positioned in a small square just in the middle of a regular display to provide the services required by a particular system and application. In fact, the technique of reading and overwriting the screen display information is used to selectively select the first GUI information or part thereof in additional memory on a time-based, arithmetic-based, interactive-based or any other basis. Keep the first G
A portion of the UI may be replaced with a second GUI such as a pop-up, window or any other display space. Those skilled in the art will appreciate that the techniques described may be used to effectively position the second GUI on any display screen addressable by the alternative display content controller. Use the controller to specify what you want to see, where, when, and the native (first) GUI and optional second
Can also control the relationship between the GUI and.

As a simple example, a security system may require the ability to display information to the user regardless of the state of the computer system, and / or the user may click “911?” To invoke help, etc. May need to be made. Embodiments of the present invention may provide a video display buffer in which a portion of the first GUI interface is continuously recorded and displayed in the second GUI, eg, in the center of the screen. The second GUI in a non-emergency state
Is effectively invisible in that the user is unaware of anything other than the first GUI.

In a suitable emergency situation, the alarm monitor causes the second GUI to
By overwriting the copy of the first display stored in the I memory, "911
? Is presented to the user. Alternatively, you can store a database of photos and call one photo in response to an incoming call (the caller's ID identifies the phone number associated with the photo entered in the database). obtain.

In general, embodiments of the invention may provide one or more second user interfaces. The second user interface may time-division multiplex out a portion of the entire display outside the first display in an unused area, such as an overscan area, or even directly in a portion of the first GUI. By;
It may be useful whenever control is more convenient and desirable, by communicating directly with the video memory; or by bypassing at least a portion of the video memory and creating a new video memory. That is, the methods and systems of the present invention may provide one or more second user interfaces that are outside the control of the native system (eg, the native operating system that controls the first GUI).

Additional user interfaces may be used for a variety of different purposes. For example,
A second user interface may be used to provide simultaneous Internet access, full motion video and conference channels. The second user interface may be dedicated to the local network, or multiple second user interfaces may provide simultaneous access and data for one or more networks to which a particular computer may be connected.

6. Initiate Alternate Display Content Controller In another embodiment of the invention, the launch or initiation of a program may be modified and controlled. For example, the alternative display content controller 6 may be launched as a service, application or user application. As a service, the alternative display content controller 6 is used as a utility operating system 5B.
It can be started as a service in the registry. The first type of application launches in the execution section in the registry and the user application may start from the startup group in the start button. Therefore, the alternative display content controller 6 may be started at any time between the first one started after enabling the graphics mode and just the last one.

If the alternative display content controller 6 is activated as a service, it can actually become visible shortly after the utility operating system 5B, such as Windows®, addresses the display.
The time to reach the visible state depends on the order in which the alternative display content controller 6 orders everything that is launched as a service and places the utility operating system 5B. It is possible to provide the alternative display content controller 6 so that the alternative display content controller 6 basically starts as a first service, and therefore, immediately after the driver is driven, it starts almost simultaneously with the driver. May be possible. So you have a screen change from text mode to graphics, color the background, overscan addressed, and CS
It is possible to re-display almost immediately at the same time as the taskbar using a parallel GUI such as NB2 display. The alternative display content controller 6, when launched as a run-line application, may be visible in the display space 1 shortly after the icon appears.

7. Illustrative Complementary User Interface Support The following description provides certain exemplary user interface features that may be implemented using the methods and techniques of the present invention. xSides Corporation
XSides ^TM application environment realized by
des ^™ )) provides a complementary user interface that can co-exist with native desktops such as Windows® 95 using the techniques of the present invention. The complementary user interface includes, among other features, a cylindrical visualization of the second user interface, a portal function, and a web jump (network browser) function that provides browsing and searching functions for the Internet. Portal features may include any type of textual or graphical content embodied by a person implementing a complementary user interface. One exemplary use of the portal area is as a personal information manager (PIM).

XSides ^TM also creates these interfaces via application programming interface (API) components,
And includes the ability to execute. The xSides ^™ API supports the creation and maintenance of a second GUI, such as the exemplary cylindrical user interface described below with reference to FIGS. 19-21.

Those skilled in the art will appreciate that many other user interfaces can be implemented by the methods, systems and techniques of the present invention and that these interfaces can be used together with each other.

7.1 Overview of xSides ^™ Application Environment The xSides ^™ environment is an embodiment of the method and system of the present invention.
The xSides ^™ environment is always visible and accessible, technically sizable, can “replace” the desktop, and can be merged; provides secure data transmission Get; Easy to use and support small (<1.5MB to download) user interface.

The xSides ^™ is implemented by software that is independent of the user interface of any underlying system (eg, the alternative display content controller described above). The xSides ^{™ (} when looking at the system architecture from driver to application software) resides "below" the operating system and "above" the driver. The xSides ^™ software communicates directly to the driver level and adjusts video display parameters. The xSides ^™ further enables keyboard and mouse events outside the first user interface supported by the native operating system described above in the previous section.

The technology may deliver internet content and services, third party applications, web browsers, personal internet portals, advertising, web-based client-server applications and electronic program guides (EPGs), among others. The xSides ^™ technology allows content and features to physically reside externally and be controlled independently of the existing operating system so that such content and features reside on the desktop. It does not interfere with and cannot be covered by this operating system or application. Since the xSides ^™ technology is outside the control of the operating system, it is possible to support interactive content and applications in a permanent form outside the operating system. Since xSides ^™ resides within the abstraction layer "below" the operating system and "above" the device driver, xSides ^™ can adjust the parameters of the video display system to increase the number of pixels and scanlines. And can allow keyboard and mouse events within the overscan area. This gives xSi
Des ^™ will be able to dynamically resize an existing desktop and, if desired, “uncover” most of the display area around any or all four sides of the desktop. ) ”Is possible. The desktop can then be used to display complementary content and applications. The application programming interface (“API”) to the xSides ^™ technology allows developers to rapidly develop applications that take advantage of these unique features of the technology. The technology could potentially address any user of Internet enabled computers or TVs around the world. In addition, the increasing operating system (ie, Microsoft CE) of consumer electronics products in devices such as portable daily planners and set-top boxes further expands the market opportunity for this technology.

An exemplary product using xSides ^™ technology is a portable mini-portal variant that resides on the user's display area and features partner vendor content and applications. These products initially appear at the bottom of the computer screen as a thin cylinder icon ("control bar") containing a series of control buttons. The control bar is composed of multiple faces called "Sides ^™ ". "Sides ^TM", respectively, the content may include different combinations of applications and graphics (hence, the name is xSides ^{T M).} The user clicks from one Side ^TM to the next Si by clicking the mouse.
You can easily rotate to a de ^™ to browse and access different content on a given Side ^™ . The ability to rotate the xSides ^™ interface to different faces expands the available computer display location, allowing compatibility between products authorized by different partners. This allows the user to easily browse and access any content he or she desires. The control buttons may perform a variety of tasks including launching a web connection or application and displaying a ticker and banner of content delivered by the server, or the user may have an additional xSides ^™ display area called the xSides ^™ portal. It may be possible to activate the function to be executed in.

The xSides ^™ portal displays any image or application, including email and instant message input and output, calendar and address book information, ISP controls, advertising banners, electronic program guides and web-based client-server applications. An internet display area that may be included. The portal can be independent of the xSides ^™ control bar, and x
It may co-exist (at the top, bottom or by) with the Sides ^™ control bar. In one embodiment, the images and applications are html-based, but one of ordinary skill in the art will be able to program the portal support to render the data / content in Java (
R) -based content or may be displayed in any programming language or format such as XML. In each case, modify portal support to interpret the source's selected content language. In addition, the portal content source is
It may be from a remote network such as the Internet or an intranet, or it may be from a local device storage such as a hard disk. The xSides ^™ portal may be used, for example, to build a personal “desktop” Internet portal. In one embodiment, preferably only one portal is displayed with the xSides ^™ control bar (there may be multiple bars on the screen), but each portal is accessible via a user interface component such as a button or menu. , Multiple portals may be associated with a side.

7.2 xSides ^™ Architecture In a preferred embodiment, the xSides ^™ technology is implemented by a distributed architecture consisting of a client computer system and a server computer system.

In one embodiment, the content (sides) of the user control bar is stored on one or more xSide ^™ servers and the user communicates with these servers via a network connection. FIG. 31 includes an exemplary block diagram of an implementation of the xSides ^™ architecture. The server computer system 3101 is connected to the client computer system 3102 via a set of communication mechanism 3103 and a set of configuration mechanism 3104. The set of communication mechanism 3103 and the set of configuration mechanism 3104 are xSi.
It interfaces to the client side application 3105 which is responsible for the display of the des ^™ control bar. (Although not shown in FIG. 31, those skilled in the art understand that the communication mechanism 3103 and the configuration mechanism 3104 have server-side equivalents (these are components of the server 3106).) if the server computer system 3101 and a client computer system 3102, in the practice, xSides ^{T M} server may be distributed across several system layout or xS,
The ids ^™ server may exist in multiple distributed layouts, including layouts that may reside on the same machine as client components, or non-distributed layouts. One of ordinary skill in the art will further appreciate that other configurations and components are possible and can be used to implement the techniques described herein.

Referring to FIG. 31, the user may select xSid on the user's client machine.
When you install es ^TM, you first download the partner's content from the server machine. Content is initially stored in a database or file system, such as database 3107 or file system 3108. The xSides ^™ server machine 3106 delivers the content to the communication layer 310.
Client computer system 3102, after sending it to the xSides ^™ application 3105 via a local database / file system 3 of the user's control bar and configuration information.
It may be stored on 109.

The communication layer 3103 serves to simplify communication between the client computer system 3102 and the server computer system 3101, and supports modularized updating of client-side information. The communication is preferably performed using an encrypted markup (eg SGML) file, which is sent over the network connection using standard HTTP packet processing. The communication layer 3103 includes various dynamic link libraries (“
DLL ") to combine the requests from each other to simplify the requests. The DLL processes the client-side functionality into a single request packet, which is sent to the xSides ^™ server. For example, the side management function allows users to add and remove sides, and various statistical functions are preferably handled using separate DLLs. When these DLLs need to make a request, the DLL sends the request to the communication layer 3103, which combines the requests into a single packet by tagging each request with a corresponding packet. Transferred to the server. Then
The server parses each packet and handles the actual request. This simplification of communication minimizes network traffic and network delays.

Furthermore, the communication layer (client part and server part) enables the function of scheduling server communication (function of pinging the server for information),
And it will be possible to schedule server-side task completions instead of client-side dependent components. For example, the status / login mechanism described below may periodically schedule updates of server-side login information. Additionally, the client-side xSides ^™ process components (eg, the DLLs described above) may be downloaded at the beginning of each xSides ^™ session. In addition, "hot swap" to this component
To download updated system components in the background. This allows the xSides ^™ to dynamically configure and update itself invisibly to the user. Those skilled in the art can configure the polling of the server for update frequency and information in any manner-for example randomly or explicitly or implicitly by the user or by the application (client-side or server-side). Understand what you get. Further, the ping and download sources and destinations are configurable-thus allowing the configuration of server-side components to be dynamically configured as well.

7.2.1 User Configuration Each xSide ^™ user is identifiable by a unique global identifier (“GUID”). The GUID serves multiple purposes, including identifying request and response packets communicated by the communication layer. Furthermore, each G
The UID uniquely identifies each user, so that regardless of the user's physical location and the machine used by the user to execute the xSides ^TM , the xSid is configured according to the user's preferred configuration.
xSides ^™ configuration profiles may be associated with one another so that es ^™ can be used. Thus, the user initiates the xSide ^™ session from a remote location (eg, the user's home computer) and the user views the same side (application) as seen from the user's normal machine (eg, the user's work machine). Look to the side. Changes made by a user on any machine under the user's GUID are automatically synchronized on the server system, even when multiple instances of an xSides ^™ session under the same GUID are running concurrently.

To provide this functionality, xSides ^™ provides a user registration client / server application. The user registration client / server application is preferably implemented as an extractable component such as a DLL, which collects information from the user and stores it on a server-side file storage (eg, database). When a user initiates an xSides ^™ session, the user performs a login and the user's configuration profile is downloaded (and cached) on the client system. Based on the configuration profile, xSides ^™ determines which side needs to be downloaded and cached on the client system and puts the control bar in the manner desired by the user. Even if the machine that initiated the request has a version of xSides ^™ installed from a different partner, this operation is performed transparently to the user, providing the environment desired by the user. That is, the cache mechanism and the general component replacement mechanism work in conjunction with the merge function to provide this configuration function.

7.2.2 Merging Function (AllSides) An important feature of the xSides ^™ technology is the ability to “merge” content from multiple partners. Merging is the process of merging content from one control bar into another. The merge allows the user to add their existing x
The Sides ^™ product can be updated to the next version, and sides (or faces) can be freely added or removed from the user's control bar. Preferably, when the merge occurs, the original distributor's logo and unique content retain their position on the user's bar, and one or more new sides of information are added. Basically, the merge allows the user to add their xSid
Allows es ^™ products to be a convenient, one-touch destination for all of your favorite content and services. This is not only important and attractive to users, but also to strategic partners who can introduce multiple faces and update users with new applications and features over time. Is. Although merging provides a convenient and flexible product for both users and strategic partners, in a preferred embodiment, both the original face and the permanent logo on the xSides ^™ product can be “unmerged”.
This provides strategic partners with the additional incentive to distribute their products.

[0135] The xSides ^™ technology also allows, for example, websites (eg All
sides. com), and when a newer version is available through the use of the user registration / configuration mechanism, the user can automatically update the side of the user's control bar. After the user installs the side, xSides ^™ automatically updates the side's content automatically on a regular basis (eg, by polling the server machine, whether new content is available, and whether new content is available). Determines whether or not to download the side definition file). The automatic update is more preferably performed when the partner changes sides and notifies the server machine. As part of these updates, dependent files-such as new component DLLs-may be downloaded to the client machine using the "hot swapping" mechanism described above. Furthermore, the user is registered with the user configuration application, and when a user logs in to xSides ^TM, xSides ^TM is a user configuration profile, to create a control bar with the merge technique. This feature is particularly useful when users move between different computer systems. After the sides are merged or downloaded, the sides are cached on the client system for efficient access. The side indefinitely, only during the period of use,
Or it may be cached in another expiration-based manner. In addition, the server system may be notified of any changes to the user's configuration profile.

(7.2.3 xSides ^TM Filtering) Dynamically add / drop configuration profile and side for each user
In addition to the ability to remove, sides can be filtered by vendor (partner / supplier) and by user class. This function is, for example, xS
The ides ^™ server is useful in determining what to display in a user's initial configuration, what a particular user may modify, and tracking information for partners. Assuming that the side of the partner's control bar is stored in the database (other realizations are possible), the database will
Stored procedures may be maintained that correlate the class of a particular user with the side available to the user. The vendors in this example are associated with a list of user classes, and each user class is associated with a list of user GUIDs and a list of sides, respectively. Those skilled in the art will appreciate that other organizations that classify such information are possible and can use data structures other than lists or stored procedures.

7.2.4 Statistics and Login Facilities xSides ^™ also provides statistical and login facilities. Preferably, the statistical facility is implemented as a DLL component of the xSides ^™ application on the client computer system. The purpose of the statistical equipment is to collect and record activity and to send it to the logged server computer system. After being logged in, the login facility uses the data to generate accounting reports and perform other accounting functions.

The statistical facility provides “clicks” and “impressions” (impr) for user activity.
recorded from the point of "session)". A click is a mouse click on the xSides ^™ side or portal, and an impression is the amount of time a given area of xSides ^™ software is displayed to the user. Therefore, M
If the side of yExampleSide is shown to the user, the impression is the time this side is displayed and the click is the user pressing the mouse button My.
Occurs when pushing on a portion of the side of the ExampleSide. Application of xSides ^{T M,} every time the side is displayed (or which activity is recorded), and if the mouse click is pressed (or should activity is when recorded)
Notify the statistical equipment. The statistics DLL prepares a markup string, encodes the recorded data, and sends this data to a regularly logged server system. (In one embodiment, another DLL is responsible for retrieving data from the statistical DLL on a regular basis (eg, every minute) and sending the data to the server system.) The markup string is user and vendor information. , And thus user activity may also be tracked by the vendor. The logger facility parses the markup string and populates the database with the appropriate data.

Typically, the impression time for a side starts when the side is first displayed to the user and ends when the side is switched to another display. However, it leaves the user executes xSides ^TM, it is possible not to perform any function using xSides ^TM. The statistical facility uses timeout heuristics to distinguish between impressions and simple idle time. In particular, each impression time is compared to a timeout value, and if the impression time exceeds this timeout value, the impression time is interrupted. One of ordinary skill in the art will appreciate that other techniques may be used to limit the impression duration and set a minimum duration for the impression duration.

7.2.5 Instant Alert Mechanism The xSides ^™ also provides a means for partners to send high priority messages to users via a mechanism known as instant alert. The instant alert facility is preferably a DLL component and thus communicates with the xSides ^™ server via the communication layer described above. The instant alert facility can also be updated automatically. Instant alerting facilities allow partners to send messages to specific users or broadcast them to groups of users (classes). The content of the message is preferably HTML and is displayed in a browser window on the user's client machine. Each message is markup-based with a tag that identifies the partner, user GUID, etc., and thus each message can be processed using the xSides ^™ communication layer packet transport mechanism. Furthermore, because the message is markup-based and thus contains embedded identification information, an appropriate acknowledgment may be returned to the server when the message is displayed or received.

When using messages repeatedly, partners can use template type messages, which include the ability to specify the attributes that will be filled in when the message is sent. These specified attributes act like macros in that their values are calculated at the time the message was sent. This value is the user's G
It may be a UID and thus provides each user with a unique identification mechanism. The instant alert facility provides tools to create and manage such template messages. The tool may be form-based or it may provide an API for message management.

7.3 Example xSides ^™ Cylindrical User Interface Referring now to FIG. 19, the display area 26 is a parallel G according to an embodiment of the present invention.
It includes the UI 28. The display area 26 may be located anywhere on the screen 24S of the video monitor 24. For example, when oriented parallel to the long axis L, the display area 26 may be provided adjacent the end 24T or end 24B. Alternatively, when oriented perpendicular to the long axis L, the display area 26 may be provided adjacent the end 24L or the end 24R.

The aspect ratio 34 of the parallel GUI 28 is the relationship expressed as 34: 1 between the dimension 32 and the dimension 30 measured along the long axis L, and the aspect ratio 34 is determined by equation 36.

36 → Aspect Ratio 34 = Dimension 32 ÷ Dimension 30 According to a preferred embodiment of the present invention, the parallel GUI 28 includes a bar 38 surrounded by an area 28A. Bar 38 may include one or more containers or cartridges such as cartridge 86 of FIG. Area 28A can be any color, and in the illustrated embodiment area 28A is black. Bar 38
One or more help areas such as title area 40, help area 42 and / or help area 56, one or more rotor areas such as rotor 44 and / or rotor 48, and button 46, button 50, ticker 52 and It may be composed of separate elements, such as one or more buttons, such as button 54. The button may be depressible, such as button 46, or non-depressible, such as button 40. A push button, such as button 46, may perform the associated action and display a highlight when selected and clicked using any conventional pointing device, such as mouse 22. Non-push buttons, such as button 40, may act as labels and / or all associated sounds, distinct movements, described below.
And with highlighting, one may begin to rotate the elements of bar 38 clearly to the right of button 40.

During the “mouse over” state, ie arrow 64
When a pointer, such as, is moved over a push button, such as button 46, the depiction of button frame 62 may be changed, for example, by changing its color, and thus the apparent intensity of the light emitted. Changes induced in a button frame, such as button frame 62, may be localized to a portion of the button frame, such as corner 62A. Preferably, the "mouse over" condition causes light to be clearly emitted from the lower left corner of the button frame, such as corner 62B.

Clicking, that is, the push button such as the button 46 is “mouse down (m
In the "use down)" state, a distinct movement of the button may be triggered and / or a distinct light alters the adjacent, affected button. Preferably, the "mouse down" of a push button, such as button 46, is
Is clearly moved into the bar 38 and the light from behind the button frame 62 is clearly increased. Clear movements and changes in emission can be achieved by any conventional means.

Therefore, clicking a push button, such as button 46, ie, a “mouse down” state, is followed by a “mouse up (m
"use up)" state is initiated. The "mouse up" state may initiate an action, such as a hyperlink, or launch an application associated with an action button, such as button 46. Further, the "mouse up" state may cause a button, such as button 46, to reverse the apparent movement caused by the previous "mouse down" state, and thus, as in the previous example, button 46 causes bar 38 to move.
And from the state of being aligned in a line, it clearly bounces out of the bar 38. At the end of the button selection cycle, it may further include changing the highlighting of the selected button. In one embodiment, the post-selection highlighting is the same as the "mouse-over" highlighting described above, with another button selected, such as button 54, or a parallel G
It is maintained until another predetermined operation in the UI 28 is started.

Non-press buttons such as the button 50, title buttons such as the title area 40,
Or actuation of a full button selection cycle on a rotor, such as rotor 44, may initiate rotation about the long axis L of the display area. In one embodiment, the right mouse button 2
Clicking on 2R starts 38 rotations in the first direction D, and clicking left mouse button 22L starts 38 rotations in the second direction U (opposite the first direction D).

Sound, along with the full button selection cycle described above, can be used to enhance the experience and thus the virtual metaphor's similarity to a real 3D device. In one embodiment, sound 66 may be emitted from a computer system. The sound 66 may be similar to the sound (s) emitted from the actual device, such as a delicate mechanical click. Any other suitable sound (s) may be used.

Non-pressed buttons, such as button 50, may be used as title buttons or placeholders, and therefore cannot invoke a utility, URL or any other function when affected by a full button selection cycle. . Therefore, the highlighting or other special display does not involve the "mouse over" state of an unpressed button, such as button 50. In another embodiment, non-push buttons, such as button 50, may include the functionality of a rotor, such as rotor 44 or 48. Thus, a full button selection cycle on such an unpressed button will cause all elements of the unpressed button 50 and bar 38 (such as ticker 52 and button 60) to rotate sharply to the right.

A ticker, such as ticker 52, can be a dynamic read area within a cartridge, such as cartridge 86 shown in FIG. A scroll of updatable text, such as text 53, may be displayed and the text reading area may be further dynamically linked to launch an application or URL. A ticker, such as ticker 52, may be as long as a single button or any combination of buttons. Text such as the displayed text 53 may be scrolled or otherwise moved through the ticker window 52A. In this preferred embodiment of the invention, the text is on the right side 52 of the ticker window 52A.
Enter R and scroll left to left 52L. Scrolling text, such as text 53, may loop and repeat at the end of the text string. The ticker text, such as text 53, may be updated locally or over the network. A ticker such as ticker 52 is a ticker 52
A hyperlink may be activated over the network if is clicked or if the ticker 52 is affected by the entire button cycle.

Referring now to FIG. 20, there is shown one example of a pedigree of menus that may be displayed and accessed via the parallel GUI 28. Menu 70 includes title bands 72, 74, 76, 78 and 80, which correspond to title area 40, button 46, button 50, ticker 52 and button 54, respectively. Rotors 44 and 48 are represented by bands 82 and 84, respectively. In this example, title area 40 includes six containers or six cartridges (cartridges 86, 87, 88, 89, 90 and 91). Many additional cartridges and titles may be available. The number of available cartridges or titles may be limited only by computer resources. Cartridges, such as cartridge 90 or cartridge 91,
It may include accessories such as a web browser or media player or any other accessory. A cartridge accessory, such as cartridge 90, may be installed for use with system software, or the accessory may be a component of software that implements a parallel GUI, or the accessory may be available over a network. It may be.

Referring now to FIG. 21, there is shown a parallel GUI 28 with the accessory cartridge 90 in the visible state. The accessory cartridge 90 may include the functionality of a particular actuator such as fast forward or next track for a CD player.
A section of accessory cartridge 90, or any other cartridge of choice, may also be dedicated to a single function, such as web browser 92, so that the browser remains visible all the time the concurrent GUI software is running. Can enable that.

Cartridges, such as cartridges 86-91, may be preloaded with links and accessories. Alternatively, the cartridge element or button is
It can be blank for the user to load via the "merge" function. User cartridge (s) is an application, document, file, or U
It may include access to network links such as RL and / or embedded functionality. Certain built-in features that may be activated from the cartridge may include a browser, MP3 player, instant messaging, market trade notification features, auction results and / or trade alerts, agent checks for price comparison searches. User items such as applications, documents, files or network links may be added to user buttons via any conventional method such as system software or any web browser copy and paste function, or drag and drop function. Suitably, the user button may be renamed or cleared in any conventional manner.

A parallel GUI, such as parallel GUI 28, may further include help functionality. The help screen or menu may be implemented in any conventional manner. The map of content and organization of bars 38 may be provided in the form of a menu or pedigree, such as menu 70 in FIG. The menu 70 and other help screens may extend from the display area 26 in any conventional manner. In one embodiment where the menu 70 is visible and extends away from the end 26T, which allows the bar 38 to remain visible, all buttons on a title, such as title 87C. The operation of the cycle starts the rotation of the bar 38, and the cartridge 87 and the title 87C become visible on the bar 38.

In one embodiment of the invention, the display area 26 includes four preset actuators 94. Activating a full button cycle on an actuator, such as actuator 96, causes bar 38 to rotate to a preselected position. A user may first load, change, or delete preset settings associated with an actuator, such as actuator 96.

The software that implements the parallel GUI may further include a screen saver component, such as idle component 96. When the parallel GUI is notified that the system software is idle, rather than the blinking display area 26 of some prior art, the parallel GUI 28 will auto-rotate through the display of all possible cartridges in the menu 70. You can When the system software returns to active mode, bar 38 will automatically return to the last active position before idling.

When the parallel GUI 28 is oriented to a title cartridge, such as a cartridge 86 with a title 86A that is visible on the title area 40, the bar 38 is clearly rotated as a result of the full button cycle of the title area 40 described above. Then
Thus, adjacent cartridges such as cartridge 87 or cartridge 85 (not shown) are displayed. The title area 40 may further include all buttons and rotators to the right of the title area 40. In another embodiment, the entire button cycle of the title area 40 modifies the visible title, such as the title 86, and the bar element 38 (eg, rotor 44, rotor 48, button 46, button 50, Clearly rotate the ticker 52 and button 54) to the right of the title area 40. Since the cartridge 87 is visible as a result of changing the cartridge, and thus the visible title in the title area 40, the title 87A and one set of its subordinate titles (eg, titles 87B, 8
7C, 87D and 87E) may also be visible. As a result of the additional cycling of the title area 40, additional cartridges and thus title 88A
And additional titles for band 72, such as 89A, are displayed.

If title 89A is visible in band 72, performing a full button cycle on rotor 44 corresponding to band 82 causes the button corresponding to band 74 (including everything up to the right of button 46) to be performed. At 46, the bar 38 is clearly rotated. Subsequent button cycles of the rotor, such as rotor 44, cause the title appearing on button 46 to cycle through titles 89B, 89C, 89D, 89E and 89F, with a new title appearing after each button cycle. In a preferred embodiment, a merging function may be included to allow cartridges such as cartridges 86-91 to be added to an existing parallel GUI such as parallel GUI 28. Cartridges, such as cartridge 86, may be added or may be parallel G using any conventional technique such as copy and paste or drag and drop.
It may be merged with any existing cartridge in a parallel GUI such as UI 28. The merged cartridge, such as cartridge 86, is replaced by cartridge 88.
And may be added between any two adjacent cartridges such as 89. Similarly, existing cartridges may be recorded using the conventional sort function.

A new cartridge can be merged or added to an existing concurrent GUI from any conventional media such as magnetic storage media, optical storage media, or from network resources such as the Internet or any local or intranet network. Good. Further including delete and / or sort functionality allows the user to organize or personalize bars, such as bar 38 in the parallel GUI, as desired by the user consistent with the parallel GUI software.

For example, a user may go to a particular internet site and ask for an application that can be merged into a parallel GUI. One such application is an application that provides access to weather information on the web. When the user selects the application to be merged, the parallel GUI automatically determines the set of cartridges provided by the application.
The parallel GUI software then merges the determined set of cartridges into the currently used data structure to store the data on the currently loaded cartridge. Those skilled in the art will appreciate that any conventional data structure may be used including arrays, hash tables, linked lists and genealogy. Preferably, a data structure is used that allows easy replacement of all cartridges (eg, cartridges stored as branches in the pedigree). The parallel GUI software can then update any relevant data structures, the information of which is dependent on the knowledge of the current set of available cartridges.

7.4 Network Browser Referring again to FIG. 1, in another embodiment of the present invention, a desktop 3 and / or concurrent graphical user of an operating system may be implemented using techniques to control the allocation of display area 1. Opens a context sensitive network browser (CSNB) 2 adjacent to, but not interfering with, interface 4. Display controllers, such as alternative display content controller 6, may include CSNB2,
This may allow the browser to create and control on the display 1 its own space that cannot be overwritten by the utility operating system 5B. The combined controller / browser may be an application running on a computer operating system, or may include an operating system kernel of varying complexity. Operating system kernels of varying complexity range from relying on utility operating systems for hardware system services to concurrent systems that are independent of utility operating systems and capable of supporting specialized applications. The alternative display content controller / browser also includes content and operating software (e.g., JAVA (R)) distributed over Internet I or any other LAN.
) Can also be included. Further, in addition to the operating system desktop, there may be more than one context sensitive network browser and more than one concurrent graphical user interface.

A context sensitive interface such as the network browser 2 may respond to cursor 1C controlled by a pointing device such as mouse 1M being moved and placed anywhere on display area 1. The generation and control of cursors across two or more concurrent graphical user interfaces has been described above. The position of cursor 1C triggers CSNB2 to retrieve the appropriate and relevant network page, such as web page 2A. CSNB2 is C
The last number X of network addresses enabled by the SNB may be stored for offline display. In the currently preferred embodiment of the present invention, X is 10 pages. When a user inspects a saved CSNB-enabled offline page, a mouse click on this page or a link on this page will initiate the user's dial-up sequence and establish an online connection.

In another embodiment, the alternative display content controller 6 may include a browser or search engine. In another embodiment of the invention, the space 2C may include an edit input box 2D. The edit input box 2D may include conventional functions such as edit, copy and paste. The user enters the URL into the edit input box 2D using any conventional input device and then selects, as a browser, the button to activate or start the alternative display content controller 6. This can be accomplished by using objects and / or drivers from the utility operating system 5B. Starting the alternative display content controller 6 as a browser includes a simple window for displaying the URL as a live HTML document with all conventional functionality. By implementing the alternative display content controller 6 as a small applet using its DLL, the alternative display content controller can be slid on or off. Therefore, starting the alternative display content controller 6 as a browser is like a window to the Internet.

Second, the user can enter any text into the edit input box 2D using any conventional input device, and then the alternative display content controller 6
You can select a button to launch or start as a search engine. A string is passed from 1 to any number of existing search engines by entering a search string and selecting "Search" or by entering any string and clicking "Search", and Subsequently, the search string is activated by one or more selected search engines and / or the alternative display content controller 6 as a search engine. The resulting different windows are
Appearing in certain types of stack format, cascade format, or tile format, different search results are displayed in each window.

Using the alternative display content controller 6 as a search engine or browser, results or HTML documents may be displayed within any overscan or desktop.

Referring now to FIG. 17, a context sensitive network browser such as CSNB13 may further include a set of tools, such as tool 14, that may or may not be fixed in position in the browser space. Can be included. Such tools may include, but are not limited to, email, chat, buddy lists and voice. As shown, the space of desktop 14A, web page 14B, second GUI 14C, browser 13, etc. may be arranged in any conventional manner.

While particular embodiments and examples of the invention have been described herein for purposes of illustration, the invention is not intended to be limited to these embodiments. Equivalent methods, structures, processes, steps and other modifications within the spirit of the invention are within the scope of the invention. Furthermore, those of ordinary skill in the art will understand how to modify and modify the invention to meet the particular requirements or conditions of the invention. For example, the teachings provided herein of the invention may be applied to other types of computer systems, including computer systems that control non-integrated display surfaces. In addition, the teachings may be applied to other types of devices having display surfaces and other organizations of computer operating systems and environments. These and other changes can be made to the invention from the above detailed description. Therefore, the present invention is not limited by the present disclosure.

[Brief description of drawings]

[Figure 1]   FIG. 1 is a block diagram of the first embodiment of the present invention.

[Fig. 2]   FIG. 2 is a block diagram of the second embodiment of the present invention.

FIG. 3 is a diagram of a standard display with an overscan user interface on all four boundaries of the display.

FIG. 4 is a block diagram of the basic components of a computer system video display environment that interacts with the method and system of the present invention.

FIG. 5 is a diagram of a cursor or pointer in an overscan user interface and hotspots on the overscan user interface in a standard display.

FIG. 6 is a diagram of usable boundaries within a vertical overscan and a horizontal overscan surrounding a standard display.

FIG. 7 is a schematic diagram of a flow chart showing the operation of the preferred embodiment of the present invention.

FIG. 8 is a flowchart of the sub-steps of step 102 of identifying the display type of FIG.

9 is a flowchart of a sub-step of step 114 of changing the display resolution of FIG.

10 is a flowchart of substeps of step 120 of painting the display of FIG.

11 is a flowchart of the substeps of step 112 of enabling linear addressing of FIG. 7.

12 is a flowchart of the sub-steps of step 122 of processing the message loop of FIG.

FIG. 13 is a flowchart of the substeps of step 184 of checking for mouse and keyboard events of FIG.

FIG. 14 is a flowchart of substeps of step 115 of changing the emulation resolution of FIG.

FIG. 15   FIG. 15 is a diagram of a prior art standard display.

FIG. 16 is a diagram of a standard display with an overscan user interface in the lower overscan area.

FIG. 17 is a diagram of a standard display including a desktop, an overscan user interface in the lower overscan area, and a browser on the side that changes according to operating conditions.

FIG. 18 is a diagram of a standard display with an overscan user interface in a lower overscan region and a right overscan region.

FIG. 19   FIG. 19 is a diagram of a parallel GUI according to an example embodiment.

FIG. 20   FIG. 20 is a simplified example of a menu tree.

FIG. 21 is a diagrammatic view of a parallel GUI with an accessory container or cartridge.

FIG. 22 is an example of an exemplary screen display of multiple complementary user interfaces present with a native GUI.

FIG. 23 is an example of an exemplary screen display of multiple complementary user interfaces present with a native GUI.

FIG. 24 is an example of an exemplary screen display of multiple complementary user interfaces present with a native GUI.

FIG. 25 is an example of an exemplary screen display of multiple complementary user interfaces present with a native GUI.

FIG. 26 is an example of an exemplary screen display of multiple complementary user interfaces present with a native GUI.

FIG. 27 is an example of an exemplary screen display of multiple complementary user interfaces present with a native GUI.

FIG. 28 is an example of an exemplary screen display of multiple complementary user interfaces present with a native GUI.

FIG. 29 is an example of an exemplary screen display of multiple complementary user interfaces present with a native GUI.

FIG. 30 is an example of an exemplary screen display of multiple complementary user interfaces present with a native GUI.

FIG. 31 is an exemplary block diagram incorporating the xSides ^™ architecture.

─────────────────────────────────────────────────── ─── Continued front page    (81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, I T, LU, MC, NL, PT, SE, TR), OA (BF , BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, G M, KE, LS, MW, MZ, SD, SL, SZ, TZ , UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AE, AG, AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, B Z, CA, CH, CN, CR, CU, CZ, DE, DK , DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, J P, KE, KG, KP, KR, KZ, LC, LK, LR , LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, PL, PT, R O, RU, SD, SE, SG, SI, SK, SL, TJ , TM, TR, TT, TZ, UA, UG, US, UZ, VN, YU, ZA, ZW (72) Inventor Brooks, Philip             United States Washington 98199,             Seattle, 23 Rd Avenue               Waist 3238 (72) Inventor Khan, Carson             United States Washington 98115,             Seattle, 18T Avenue               North East 6856 (72) Inventor Aurok, Thomas C.             United States Washington 98112,             Seattle, East Roanoke 2409 (72) Inventor Warnock, James             United States Washington 98133,             Seattle, Densmore North 10346 (72) Inventor Easton, John             United States Washington 98070,             Bastion, 135 ave avenue             -Southwest 28224 F-term (reference) 5E501 AA01 BA03 CA02 FA06 FA07                       FA08 FA09

Claims (67)

[Claims] 1. A computer-based method for handling communication between a client system and a server system, the method comprising: integrating a plurality of data requests individually operating on the client system from a plurality of modules. Making a single transaction and sending the single transaction to the server system over a single communication connection. 2. Receiving a single transaction from the server system via a single communication connection, decomposing the received transaction into a plurality of data responses, and each data response to the plurality of modules. The method of claim 1, further comprising: transferring to a corresponding module of the. 3. The method of claim 2, wherein the plurality of data responses are used in selectively updating the plurality of modules. 4. The plurality of data responses is based on a unique user identifier,
The method of claim 2. 5. A request from a second client system to the server system based on the same unique user identifier, a data response received by the second client system and a plurality of requests received by the client system. The method of claim 4, further comprising a second client system that makes the data response the same.
The method described in. 6. The method of claim 1, wherein each data request in the single transaction corresponds to a different type of data. 7. The data request is used to control an application on the client system, receiving data for the application from the server system, and transferring the received data to the application. The method of claim 1, further comprising: 8. The method of claim 7, wherein the application is a user interface located outside a desktop user interface displayed by a resident operating system of the client system. 9. The method of claim 7, wherein the received data provides for automatic updating of the application in a manner transparent to the user of the application. 10. The method of claim 7, wherein the received data provides an updated version of the application. 11. The method of claim 7, wherein the received data causes a merge of existing application data and new application data to be performed in a manner transparent to a user of the application. 12. The method of claim 7, wherein data received for the application is merged into the application based on a unique user identifier. 13. The method of claim 7, wherein the portion of data received for the application is filtered based on a unique user identifier. 14. The method of claim 7, wherein the received data comprises a message displayed on the client system in a non-overwriteable manner. 15. The method of claim 14, wherein the message encodes specific information targeted to a message for a user. 16. The method of claim 14, wherein the message encodes information used in broadcasting the message to a group of users based on sharing characteristics. 17. The method of claim 14, wherein the message comprises a template message containing attributes, the value of the attribute being calculated when the message is sent from the server system. 18. The client system and the server system are
The method of claim 1, wherein the methods reside on the same computer system. 19. The method of claim 1, wherein the transaction is sent using an encrypted markup file. 20. Sending a request to the server system to schedule a task on behalf of the client system as one of the integrated data requests, and receiving the result of scheduling the task. The method of claim 1, further comprising: 21. Statistics are collected by the client system,
The method of claim 1, wherein the statistical information is periodically sent to the server system as one or more data requests integrated into the single transaction. 22. The statistical information is encoded in a markup string,
The markup string is sent as one of the data requests,
The method of claim 21. 23. The method of claim 21, wherein the data request is used to control an application on the client system and the statistical information includes impression data regarding usage time of the application. 24. A communication facility on a client system that handles communication with a server system, wherein multiple data requests from multiple modules operating individually on said client system are combined into a single transaction. A communication facility, comprising: a request rationalization mechanism; and a transmission mechanism that sends the single transaction to the server system via a single communication connection. 25. A decomposing mechanism for receiving a single transaction from the server system, decomposing the transaction into a plurality of data responses, and forwarding each data response to a corresponding one of the plurality of modules. The communication equipment according to claim 24. 26. The communication facility according to claim 25, wherein the data response is used in selectively updating a module. 27. The communication facility of claim 25, wherein the plurality of data responses are based on a unique user identifier. 28. A data response received by a second client system in response to a request from the second client system to the server system based on the same unique user identifier. When,
28. The communication facility of claim 27, further comprising a second client system that makes a plurality of data responses received by the client system the same. 29. The data request is used to control an application on the client system, the decomposing mechanism receives data relating to the application from the server system, and transfers the received data to the application. 25. The communication equipment according to claim 24. 30. The communication facility according to claim 29, wherein the application is a user interface arranged outside a desktop user interface displayed by a resident operating system of the client system. 31. The communication facility of claim 29, wherein the received data automatically updates aspects of the application. 32. The communication facility of claim 29, wherein the received data is performed such that a merge of existing application data and new application data is made invisible to a user of the application. 33. The communication facility of claim 29, wherein the received data is merged with the application based on a unique user identifier. 34. The data portion received for the application comprises:
30. The communication facility of claim 29, filtered based on a unique user identifier. 35. The communication facility of claim 29, wherein the received data comprises a message displayed on the client system in a non-overwritable manner. 36. The communication facility of claim 35, wherein the message encodes specific information targeted to a user-oriented message. 37. The communication facility of claim 35, wherein the message encodes information used in broadcasting the message to a group of users based on sharing characteristics. 38. The communication facility according to claim 35, wherein the message is composed of a template message including an attribute, and a value of the attribute is calculated when the message is transmitted from the server system. 39. Each data request in the single transaction comprises:
25. The communication facility according to claim 24, corresponding to different types of data. 40. The client system and the server system are
25. The communication facility of claim 24, which resides on the same computer system. 41. The communication facility of claim 24, wherein the transaction is sent using an encrypted markup file. 42. The communication facility of claim 24, wherein a request is sent to the server system as one of the integrated data requests to schedule a task on behalf of the client system. 43. Statistics are collected by the client system,
25. The communication facility of claim 24, wherein the statistical information is periodically sent to the server system as one or more data requests integrated in the single transaction. 44. The statistical information is encoded in a markup string,
The markup string is sent as one of the data requests,
The communication equipment according to claim 43. 45. The communication facility according to claim 43, wherein the data request is used to control an application on the client system, and the statistical information includes impression data regarding usage time of the application. 46. A computer readable memory medium containing instructions for controlling a computer processor to process communications between a client system and a server system, the processing steps comprising: Combining a plurality of data requests operating individually on the client system into a single transaction, and sending the single transaction to the server system over a single communication connection. A computer-readable memory medium that is made by. 47. Receiving a single transaction from the server system via a single communication connection, decomposing the received transaction into a plurality of data responses, each data response being the plurality of modules. 47. The computer readable memory medium of claim 46, further comprising: transferring to a corresponding module of the. 48. The computer readable memory medium of claim 47, wherein the data response selectively updates the plurality of modules. 49. The computer readable memory medium of claim 47, wherein the plurality of data responses are based on a unique user identifier. 50. A second client system, the data response received by the second client system in response to a request from the second client system to the server system based on the same unique user identifier. When,
50. The computer-readable memory medium of claim 49, further comprising a second client system that equates a plurality of data responses received by the client system. 51. Each data request in the single transaction comprises:
47. The computer readable memory medium of claim 46 corresponding to different types of data. 52. Further comprising controlling the application on the client system using the data request, receiving data for the application from the server system, and transferring the received data to the application. 47. A computer-readable memory medium according to claim 46. 53. The computer readable memory medium of claim 52, wherein the application is a user interface located outside a desktop user interface displayed by a resident operating system of the client system. 54. The computer readable memory medium of claim 52, wherein the received data automatically updates the application. 55. The computer readable form of claim 52, wherein the received data causes a merge of existing application data and new application data to be performed such that it is invisible to a user of the application. Memory medium. 56. The computer readable memory medium of claim 52, wherein the data received for the application is merged into the application based on a unique user identifier. 57. The computer readable memory medium of claim 52, wherein the portion of data received for the application is filtered based on a unique user identifier. 58. The computer readable memory medium of claim 52, wherein the received data comprises a message displayed in a non-overwriteable manner on the client system. 59. The computer readable memory medium of claim 58, wherein the message encodes specific information targeted to a message intended for a user. 60. The computer readable memory medium of claim 58, wherein the message encodes information used in broadcasting the message to a group of users based on sharing characteristics. 61. The computer readable form of claim 58, wherein the message comprises a template message that includes an attribute, the value of the attribute being calculated when the message is sent from the server system. Possible memory medium. 62. The client system and the server system
48. The computer readable memory medium of claim 47, which resides on the same computer system. 63. The computer readable memory medium of claim 47, wherein the transaction is transmitted using an encrypted markup file. 64. The computer of claim 47, further comprising sending a request to the server system as one of the integrated data requests to schedule tasks on behalf of the client system. Readable memory medium. 65. Statistics are collected by the client system,
48. The computer readable memory medium of claim 47, wherein the statistical information is periodically sent to the server system as one or more of data requests that are combined into the single transaction. 66. The statistical information is encoded in a markup string,
The markup string is sent as one of the data requests,
A computer readable memory medium according to claim 65. 67. The computer readable form of claim 65, wherein the data request is used in controlling an application on the client system and the statistical information includes impression data regarding usage time of the application. Possible memory medium.