PCT
`
`WORLD INTELLECTUAL PROPERTY ORGANIZATION
`International Bureau
`
`
`
`INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`(51) International Patent Classification 6 i
`G06F 3/14
`
`(11) International Publication Number:
`_
`(43) International Publication Date:
`
`W0 9906130
`
`27 May 1999 (27.05.99)
`
`(21) International Application Number:
`
`PCP/US98/24342
`
`(22) International Filing Date:
`
`13 November 1998 (13.11.98)
`
`(81) Designated States: AU, CA, CN, IL, JP, KR, NO, N2, 50,
`European patent (AT, BE, CH, CY, DE, DK, ES, FI. FR,
`GB, GR, IE, IT, LU, MC, NL, PT, SE).
`
`Published
`With international search report.
`Before the expiration of the time limit for amending the
`claims and to be republished in the event of the receipt of
`amendments.
`
`(30) Priority Data:
`08/970,709
`
`14 November 1997 (14.1 1.97)
`
`US
`
`(71) Applicant: E—PARCEL, LLC [US/US]; Suite 300, 29 Crafts
`Street, Newton, MA 02158 (US).
`
`(72) Inventors: KOBATA, Hiroshi; Apartment 201, 50 Watenown
`Street, Watertown, MA 02172 (US). GAGNE, Robert, A,;
`995 Southern Artery, Quincy, MA 02169 (US). TONCH'EV,
`Theodore, C.; 162 5th Street, Cambridge, MA 02141 (US).
`
`(74) Agent: TURANO, Thomas, A.; Testa, Hurwitz & 'I‘hibeault,
`LLP, High Street Tower, 125 High Street, Boston, MA
`02110 (US).
`
`into the quickest screen refresh time for the remote control operation.
`
`(54) Title: REMOTE CONTROL SYSTEM WHICH MINIMIZES SCREEN REFRESH TIME BY SELECTING COMPRESSION
`ALGORITHM
`
`GUARANTEES
`SUCCESSFUL
`
`(57) Abstract
`
`A system is provided for the remote control of one computer from another in which selectable compression speeds are utilized to
`minimize overall screen refresh time. In one embodiment, an algorithm selection module at one computer chooses the highest compression
`available con'esponding to a worst case scenario, followed by measurement of the compression time and the transmission time, with the ratio
`of compression time to transmission time being used to select a decreased compression, thereby to lower compression time and consequently
`lower the overall screen refresh time. By adjusting both the send time and the compression time on the transmit side, the above ratio can be
`made to equal one, which corresponds to the most efficient utilization of the available bandwidth and CPU power, which in turn translates
`
`l of 196
`
`GOOGLE EXHIBIT 1010
`
`

`

`FOR THE PURPOSES OF INFORMATION ONLY
`
`Codes used to identify States party to the PCT on the front pages of pamphlets publishing international applications under the PCT.
`
`Singapore
`
`Albania
`Armenia
`Austria
`Australia
`Azerbaijan
`Bosnia and Herzegovina
`Barbados
`Belgium
`Burkina Faso
`Bulgaria
`Benin
`Brazil
`Belants
`Canada
`Central African Republic
`Congo
`Switzerland
`COte d’lvoire
`Cameroon
`China
`Cuba
`Czech Republic
`Germany
`Denmark
`Ettonia
`
`F5
`FI
`FR
`GA
`GB
`GE
`GI-l
`GN
`GR
`HU
`IE
`IL
`IS
`IT
`JP
`KE
`KG
`KP
`
`KR
`KZ
`LC
`Ll
`LK
`LR
`
`Spain
`Finland
`France
`Gabon
`United Kingdom
`Georgia
`Ghana
`Guinea
`Greece
`Hungary
`Ireland
`Israel
`Iceland
`Italy
`Japan
`Kenya
`Kyrgyzstan
`Democratic People’s
`Republic of Korea
`Republic of Korea
`Kazakatan
`Saint Lucia
`Liechtenstein
`Sri Lanka
`Liberia
`
`Lesotho
`Lithuania
`Luxembourg
`Latvia
`Monaco
`Republic of Moldova
`Madagascar
`The former Yugoslav
`Republic of Macedonia
`Mali
`Mongolia
`Mauritania
`Malawi
`Mexico
`Niger
`Netherlands
`Norway
`New Zealand
`Poland
`Portugal
`Romania
`Russian Federation
`Sudan
`Sweden
`
`LS
`LT
`I.U
`LV
`MC
`MD
`MG
`MK
`
`ML
`MN
`MR
`MW
`MX
`NE
`NL
`N0
`NZ
`PL
`P'I‘
`R0
`RU
`SD
`SE
`80
`
`SI
`SK
`SN
`82
`11)
`TG
`TJ
`TM
`TR
`1'I‘
`UA
`UG
`US
`UZ
`VN
`YU
`ZW
`
`Slovenia
`Slovakia
`Senegal
`Swaziland
`Chad
`Togo
`Tajikistan
`Turkmenistan
`Turkey
`Trinidad and Tobago
`Ukraine
`Uganda
`United States of America
`Uzbekistan
`Viet Nam
`Yugoslavia
`Zimbabwe
`
`2 of 196
`
`

`

`WO 99/26130
`
`PCT/US98/24342
`
`REMOTE CONTROL SYSTEM WHICH MINIMIZES SCREEN REFRESH TIME BY SELECTING COMPRESSION
`ALGORITHM
`
`FIELD OF INVENTION
`
`This invention relates to the remote control of computers and more particularly to an
`
`emulation system in which screen refresh times associated with one computer controlling another
`
`computer are minimized taking into account the demographics of the network and the sending
`
`machine.
`
`BACKGROUND OF THE INVENTION
`
`One of the main problems for a consumer is oftentimes incompatibility of his equipment
`
`and the programs sought to be run. For instance, an individual may have a printer that is
`
`incompatible with the driver loaded to operate it. Typically, the user calls an administrator who
`
`telephonically instructs the individual as to how to program his computer in order to make the
`
`printer work. This may involve downloading printer drivers or other sofiware in a time
`
`consuming process in which the administrator must ask the user questions. The user‘ on the other
`
`hand, may be insufficiently knowledgeable to answer the administrator’s Questions, resulting in
`
`frustration on both the user’s part and that of the administrator.
`
`In an effort to minimize such frustrations, systems, referred to herein as emulation
`
`systems, have been developed so that the administrator can “see” what is happening at the user’s
`
`terminal.
`
`In order to do this in the past remote control programs have been developed which
`
`capture the low level graphic calls and send them to the administrator’s computer for display. At
`
`the administrator’s side these low level graphic calls are utilized to provide the screen at the
`
`administrator’s side with an exact duplicate of the user’s screen. Such a system is commercially
`
`available as model pcANYWI—[ERE from Symantec of Cupertino, California.
`
`In this system the
`
`I()
`
`15
`
`20
`
`3 of 196
`
`SUBSTITUTE SHEET (RULE 25)
`
`

`

`WO 99/26130
`
`PCT/U 598/24342
`
`administrator can understand what is happening at the user’s side and verbally instruct the user
`
`-2-
`
`what to do.
`
`One of the problems with prior emulation systems is that the screen refresh at the
`
`administrator’s side is slow, or in general not optimized to the demographics of the network and
`
`the users machine. For instance, if the user has a relatively slow modem connected to the
`
`network, but is utilizing a compression algorithm that emphasizes compression speed over
`
`efficiency, this would have a negative impact on the screen refresh rate. The result for the
`
`administrator is that the administrator would select or click on an icon and have to wait an
`
`inordinate amount of time for a response. The reason for such delays has to do with the
`
`demographics of the network and the two machines in that inappropriate compression algorithms
`
`are chosen.
`
`In an effort to speed up the response of such systems, various techniques have been
`
`utilized. One of these techniques involves the use of low level drivers to capture graphics calls.
`
`However, these drivers can make the system unstable and require much disk and RAM memory
`
`space. As a result, oftentimes the screen refresh is often corrupted when moving graphics are
`
`encountered and has a stilted appearance.
`
`The artifacts are in general caused by the order in which the graphic calls are trapped, and
`
`the different levels of graphics calls which are available. These systems are also inferior in
`
`displaying bitmapped graphics and moving images. The largest problem with the above systems is
`
`that they can take as much as 10 megabytes of disk space on both sides, and require a reboot after
`
`10
`
`15
`
`20
`
`installation before using.
`
`In the prior systems there is another problem in that by relying on the graphics calls the
`
`images are taken in parts and are displayed on the administrator's side in unnatural fashion due to
`
`the arbitrary order in which the graphics calls are trapped. These systems have to wait for other
`
`4 of 196
`
`

`

`WO 99/26130
`
`PCT/US98/24342
`
`-3-
`
`applications to make graphic calls in order to know what to update and rely on the applications to
`
`make graphics calls known to the systems. If an application performs a graphics operation not
`
`known to the system, that information is not transferred over to the administrator.
`
`As a result, the image the administrator sees is incorrect, since the entire system is
`
`dependent on other applications to perform known operations with the operating system. For
`
`applications that perform operations that are unknown, the system ignores what could potentially
`
`be the problematic area.
`
`Thus, for the newer peripherals coupled to the user‘s computer, in the past the problem
`
`could be ignored since the administrators system could not see it.
`
`SUMMARY OF THE INVENTION
`
`In order to speed up the screen refresh potion of the system, low level drivers trapping
`
`graphics calls are eliminated in favor of increasing speed through the alteration of the compression
`
`and decompression algorithms used at the user and administrator sides to choose the appropriate
`
`ratio of transmission time and compression time which matches the demographics of the network
`
`and that of the user‘s computer.
`
`In one embodiment, the speed of the refresh at the
`
`administrator's side is increased to the maximum extent possible to eliminate delays in presenting
`
`the results of an operation on the user's computer.
`
`For instance, assuming that the user's computer has a CPU speed of 200 mhz and further
`
`assuming a local area network with a mean transmission rate of ~800 kilobytes per second, best
`
`compression algorithm would provide a full screen refresh in less than 0.7 seconds including
`
`compression and transmission. If an incorrect algorithm for modem speed were chosen at the
`
`user's side, such as 28 kilobytes per second, then the refresh time at the administrator's side would
`
`be 2.5 seconds, clearly 300% longer than that achievable if the appropriate compression ratewere
`
`10
`
`20
`
`chosen.
`
`5 of 196
`
`

`

`WO 99/26130
`
`PCT/US98/24342
`
`-4-
`
`In the above case it would be desirable to choose the lowest compression rate, eq. one
`
`that emphasizes compression speed over resulting size. In this case, e.g., for a local area network,
`
`a compression rate of 13% would yield the above 0.7 second refresh time, given a transmission
`
`speed of ~800kb.
`
`In the subject invention there are four different compression algorithms from which to
`
`choose. The first is the lowest compression rate algorithm comprising a run length encoding
`
`algorithm. This algorithm converts a run of the same byte with a count of that byte. A second
`
`algorithm selectable by the subject system for the next higher compression rate is a Huffman
`
`compression algorithm preceded by run length encoding, or RLE. A third algorithm selectable by
`
`the subject system for the next higher compression rate is a modified adaptive Huffman
`
`compression algorithm using a 9 bit tree entry size, again preceded by RLE. Finally, a fourth
`
`compression algorithm is identical to the above but with 13 bit tree entry sixes, for the highest
`
`compression rate.
`
`The first algorithm is characterized by it‘s speed. Typically, this algorithm will compress a
`
`megabyte in less than 0.2 seconds. This algorithm is to be selected when network bandwidth is
`
`not a problem.
`
`The second algorithm is also characterized by it's speed, but with more resulting data size
`
`efficiency, and is to be used in high speed networks with heavy traffic.
`
`The third algorithm is characterized by its data size efficiency, in which a megabyte is
`
`compressed down to 4 kilobytes. This algorithm is usefiil for intemet applications because of the
`
`intemet's heavy traffic and latency.
`
`The fourth algorithm is characterized by its extreme data size efficiency in that it can
`
`compress a megabyte of screen data down to approximately 2 kilobytes or less. However, the last
`
`two algorithms are relatively slow, eg. 3 seconds vs. 0.2 seconds.
`
`10
`
`15
`
`20
`
`6 of 196
`
`

`

`W0 99/26130
`
`PCT/US98/24342
`
`While the above describes four different compression algorithms, other
`
`-5-
`
`compression/decompression algorithms are within the scope of this invention. Regardless, the
`
`compression algorithm selected is based on the rate of send time to compression time, with the
`
`selection seeking to cause this ratio to equal one. In order to select the decompression algorithm
`
`at the user's side, the transmission from the user to the administrator is monitored and the
`
`transmission time is measured for every single refresh.
`
`In one embodiment, this involves
`
`measuring the start of the send and end of the send for a TCP network transmission. Likewise,
`
`the actual compression is measured for every single refresh in which the CPU tick count is taken
`
`at the start of the compression and at the end of the compression; and the end of the compression;
`
`10
`
`and the difference is used to calculate the compression speed in milliseconds.
`
`In one embodiment, the screen is divided into grids and a checksum recorded for each
`
`grid. This check sum is compared to the previous check sum, and when it differs, the grid is
`
`marked as "dirty". Once the entire screen has been checked, all the dirty grids are collected and
`
`compressed. This is one refresh. This process is done on a grid by grid basis until the whole
`
`15
`
`screen has been checked.
`
`The selection process operates as follows. After an initial measurement has been made of
`
`compression time and transmission time, the ratio is calculated, and if less than one, the algorithm
`
`having a lower compression rate is selected, thereby decreasing compression time.
`
`In one embodiment, the first algorithm selected is the one having the highest compression
`
`20
`
`rate, assuming the worst case scenario. Thereafler, through an iterative process the selection
`
`settles on the optimal algorithm given the demographics of the network and the user's computer.
`
`The compression time and the transmission time is averaged out from refresh to refresh so
`
`that the ratio reflects the overall demographics. The algorithm chosen is that for which the-ratio
`
`is as close to one as possible.
`
`7 of 196
`
`

`

`WO 99/26130
`
`PCT/US98/24342
`
`-6-
`
`A system is provided for the remote control of one computer from another in which
`
`selectable compression speeds are utilized to minimize overall screen refresh time.
`
`In one
`
`embodiment, an algorithm selection module at one computer chooses the highest compression
`
`available, corresponding to a worst case scenario followed by measurement of the compression
`
`time and the transmission time, with the ratio of compression time to transmission time being used
`
`to decrease compression, thereby to lower compression time and consequently lower the overall
`
`screen refresh time. By adjusting both the send time and the compression time on the transmit
`
`side, the above ratio can be made to be equal to one, which corresponds to the most efficient
`
`utilization of the available bandwidth and CPU power, which in turn translates into the quickest
`
`screen refresh time for the remote control operation.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`These and other features of the Subject Invention will be better understood with reference
`
`to the Detailed Description taken in conjunction with the Drawings, of which:
`
`Figure l is block diagram of two networked computers, with one computer
`
`corresponding to that of the user, and the other computer corresponding to that of the
`
`administrator;
`
`Figure 2 is a block diagram of the computers of Figure 1 illustrating the
`
`transmission of the information on the screen of the user’s computer to the screen of the
`
`administrator’ 3 computer;
`
`Figure 3 is a block diagram of the transmission of modifications specified at the
`
`administrator’s screen to that of the user’s screen indicating the control of the user’s computer by
`
`the administrator’s computer;
`
`Figure 4 is a block diagram of the subject system in which the compression ~—
`
`algorithm to be used by the user’s computer is automatically selected based on the demographics
`
`10
`
`15
`
`20
`
`8 of 196
`
`

`

`WO 99/26130
`
`PCT/US98/24342
`
`-7-
`
`of the network and the user’s computer, which selection is transmitted to the administrator’s
`
`computer for use in the corresponding compression algorithms therein;
`
`Figure 5 is a table illustrating the header portion for the data transmitted for a
`
`single screen cycle indicating identification of the compression algorithm used;
`
`Figure 6 is a flowchart illustrating the derivation of a ratio of send time to
`
`compression time used in the algorithm selection module of figure 4; and,
`
`Figure 7 is a graph illustrating a comparison of compression algorithms in terms of
`
`transfer speed vs. compression speed.
`
`DETAILED DESCRIPTION
`
`10
`
`Referring now to Figure 1 in a typical networked situation a network 10 is used to
`
`connect a terminal A, herein referred to as terminal 12, to terminal B, herein referred to as
`
`terminal 14.
`
`Each of these terminals has a CPU coupled, thereto referred to as 16 and 18, with
`
`keyboards 20 and 22 coupled to respective CPUs. Mice 24 and 26 are coupled to respective
`
`15
`
`CPUs 16 and 18 as illustrated.
`
`Referring now to Figure 2, in an emulation system, terminal 14 transmits its screen
`
`30 over network 10 to terminal 12, such that its screen is duplicated as 30’ at terminal 12.
`
`It is
`
`the purpose of this transfer to alert the administrator to exactly what is displayed at the user’s
`
`terminal so that corrective action can be taken by the user either through verbal instructions given
`
`20
`
`to the user by the administrator or, as illustrated in Figure 3, by the transmission of modifications
`
`34 from terminal 12 to terminal 14 over network 10.
`
`As mentioned hereinbefore, it is important that there be minimal delay between
`
`actions taken by the administrator via keyboard 20 or mouse 24 and a resulting operation on—
`
`terminal 14 which change is immediately displayed on terminal 12. The ability to quickly display
`
`9 of 196
`
`

`

`WO 99/26130
`
`PCT/US98/24342
`
`-3-
`
`operations and results on the administrator’s terminal significantly reduces administrator
`
`frustration and fatigue, while at the same time providing more efficient transfer of information to
`
`the user or more particularly to the user’s terminal. Regardless of whether or not information is
`
`verbally communicated to the user or is automatically downloaded to the users terminal it is
`
`5
`
`important that the administrator’s screen be refreshed in the shortest possible time.
`
`Factors which afiect the screen refresh are the characteristics of the network, herein
`
`referred to as demographics, which includes bandwidth, transmission speed, traffic and other
`
`factors. Likewise, the screen refresh rate at the administrator’s side is intimately connected with
`
`the demographics of the user’s computer, namely CPU speed, modem speed, available memory,
`
`10
`
`and other factors.
`
`Referring to Figure 4, as can be seen, each of the CPUs 16 and 18 is provided with a
`
`selectable number of compression and decompression algorithms, with the compression
`
`algorithms at the user’s side bearing reference characters 40, 42, 44 and 46. These algorithms, in
`
`one embodiment, are ordered from the highest to the lowest compression, the purpose of which
`
`15
`
`will be hereinafier. The algorithm selected at the user’s side is accomplished through the
`
`utilization of an algorithm selection module, 50, which is coupled not only to CPU 18, but also to
`
`each of the algorithms 40-46.
`
`Likewise, at the administrator’s side corresponding decompression algorithms 52, 54, 56
`
`and 58, are coupled with CPU 16 in accordance with algorithm selection module 60, upon
`
`20
`
`detection at 62 of the compression algorithm carried by the transmitted data over network 10.
`
`In operation, each screen refresh cycle is provided with a header containing the type of
`
`compression algorithm selected at the users side by module 50. The data format of the
`
`transmitted data is illustrated in Figure 5 to indicate that as part of the header information the
`
`10 of 196
`
`

`

`WO 99/26130
`
`PCT/US98/24342
`
`algorithm selected is identified, with the remainder of the data being that associated with a screen
`
`-9-
`
`refresh cycle.
`
`This header is detected at 62 and the appropriate algorithm is introduced to CPU 16 for
`
`appropriate decompression.
`
`5
`
`Referring to Figure 6, in one embodiment, algorithm selection module 50 initially chooses
`
`for transmission that algorithm which possesses the highest compression. The reason this is done
`
`is to be able to accommodate the worst case scenario in which the transmission speed is limited to
`
`that of the slowest modem reasonably calculated to be included at the receiver’s CPU. Algorithm
`
`select module 50 then computes how long it takes to compress a refresh cycle and how long it
`
`10
`
`takes to send this refresh cycle. It does this each and every refresh cycle to permit a ratio of send
`
`time to compression time to be calculated for each refresh cycle.
`
`Ifthe ration is equal to 1, then this highest compression algorithm is permitted to
`
`continue. If the ratio R of send time to compression time is less than 1 then the algorithm having
`
`the next lower compression is selected, which lowers the compression time while at the same time
`
`15
`
`increasing the send time. Measurements are again taken for the next cycle and the ratio
`
`recomputed. This iterative process finally settles upon an algorithm which optimally minimizes
`
`screen refresh time at the administrator’s side.
`
`It will be noted that, as mentioned above, the compression algorithms are ordered
`
`according to compression so that the iterative process can settle upon the optimal algorithm.
`
`20
`
`Referring now to Figure 7, what is shown is a comparison of tradeoffs in compression
`
`speed and transfer speed for four different compression algorithms having a descending value of
`
`compression from the highest to the lowest. As can be seen the highest transfer speed is for a
`
`local area network at about 800 kilobytes per second, followed by a wide area network at about
`
`11 of 196
`
`

`

`WO 99/26130
`
`PCT/US98/24342
`
`- 10 -
`
`500 kilobytes per second, followed by the internet at about 80 kilobytes per second, and finally
`
`followed by modems which operate at about 10 kilobytes per second.
`
`As can be seen, given the lowest compression algorithm, the transfer time is off the chart
`
`for a modem and barely usable for the internet, while being satisfactory both for wide area
`
`5
`
`networks and for local area networks, since the transfer time is under 1.0 seconds. On the other
`
`hand, for the highest compression algorithm, it can be seen that the overall transfer time varies
`
`little such that few improvements can be made in terms of the type of network over which the
`
`data is transmitted. For algorithms having intermediate compression rates, while the chart
`
`indicates modest improvement in certain instances, significant improvement in refresh times can
`
`l0
`
`nonetheless be effectuated in certain circumstances.
`
`It will be appreciated that the graph shows
`
`averages, and that certain screen data compresses better with one or the other middle algorithms.
`
`The dynamic algorithm switching ensures that the most appropriate algorithm is always chosen.
`
`What is presented below is a program listing in C++ which describes the operation not
`
`only of the automatic selection module but also of the operation of the entire system in the
`
`15
`
`selection of optimal compression and decompression algorithms based on system demographics.
`
`12 of 196
`
`

`

`WO 99/2613!)
`
`PCT/US98/24342
`
`11
`
`w
`
`// Handshake information
`REJECT
`OXOOOO
`#define
`VERSION
`0x0106
`#define
`
`#define
`
`WAIT_TIME 15000
`
`// Input codes
`#define
`INPUT_MOUSE
`#define
`INPUT_KEYBOARD
`#define
`INPUT_DOUBLE_CLICK_MOUSB
`#define
`INPUT_REFRESH
`#define
`INPUT_CLOSE_CONNECTION
`#define
`INPUT_HOTKEY
`#define
`INPUT_PAINTING_PAUSE
`#define
`INPUT_PAINTING_RESUME
`
`0x01
`0x02
`
`0x04
`0x05
`0x06
`
`0x03
`
`0x07
`0x08
`
`// hot keys
`#define
`HOTKEY_ALTTAB
`#define
`HOTKEY_CTRLESC
`#define
`HOTKEY_CTRLALTDEL
`
`// video codes
`#define
`#define
`#define
`#define
`
`VIDEO_PAINT
`VIDEO_NO_PAINT
`VIDEO_CLOSE_CONNECTION
`VIDEO_PAUSE
`
`#define
`#define
`
`CONNECTION_TRANSFER
`CONNECTION_PAUSE
`
`0x01
`
`OxOOlO
`OxOOll
`0x0012
`
`0x01
`0x02
`0x03
`0x04
`
`0x00
`
`#define
`#define
`#define
`#define
`#define
`#define
`#define
`#define
`#define
`
`MONITOR_EXIT_SUCCESS
`VIDEO_EXIT_SUCCESS
`INPUT_EXIT_SUCCESS
`VIDEO_EXIT_HANDSHAKE_ERROR
`VIDEO_EXIT_HARDWARE_ERROR
`VIDEO_EXIT_DIRECT_DRAW_ERROR
`6
`INPUT_EXIT_HANDSHAKE_ERROR
`VIDEO_EXIT_CLIENT_DOESNT_SUPPORT
`VIDEO_EXIT_HANG
`
`5
`
`7
`
`// Max mouse movement for mouse_event
`#define
`MOUSE_X Oxffff
`#define
`MOUSE_Y Oxffff
`
`l3of196
`
`

`

`W0 99/26130
`
`PCT/US98/24342
`
`12
`
`#define
`
`PADDING_DIVISOR 401
`
`// Misc
`#define
`#define
`
`Defines
`
`DIB_HEADER_MARKER
`BITS_BYTE
`8
`
`((WORD)
`
`('M' << 8)
`
`'B')
`
`// these are for changing the cursors to
`// windows defaults
`
`in any headers
`
`32512
`32513
`32514
`32515
`32516
`32642
`32643
`32644
`32645
`32646
`32648
`32650
`
`_T("Waiting for Administrator
`
`_T("Administrator
`
`T("Administrator
`
`// these are not
`#define
`#define
`#define
`#define
`#define
`#define
`#define
`#define
`#define
`#define
`#define
`#define
`
`OCR_NORMAL
`OCR_IBEAM
`OCR_WAIT
`OCR_CROSS
`OCR_UP
`OCR_SIZENWSE
`OCR_SIZENESW
`OCR_SIZEWE
`OCR_SIZENS
`OCR_SIZEALL
`OCR_NO
`OCR_APPSTARTING
`
`#define
`
`AGENT_UI_WAITING
`to connect.")
`#define
`
`AGENT_UI_CONNECTING
`reuqesting connect...")
`#define AGENT_UI_CONNECTED
`connected.")
`
`////////////////////////////////////////
`
`// Custom windows messages
`
`#define
`#define
`#define
`
`USER_EXITLOOP
`USER_PAUSE
`USER_RESUME
`
`WM_USER+1
`WM_USER+2
`WM_USER+3
`
`////////////////////////////////////////
`defines
`// Grid
`
`#define
`#define
`#define
`#define
`
`12 //12 //6
`GRID~HEIGHT
`16 //16 //8
`GRID_WIDTH
`GRID_COUNT (GRID_WIDTH*GRID_HEIGHT)
`OFFSCREEN_WIDTH 8 //8 //1
`
`14 of 196
`
`

`

`WO 99/26130
`
`PCT/US98/24342
`
`#define PADDING 8
`
`//8 //4
`
`13
`
`////////////////////////////////////////////////////
`// Error codes
`
`#define CONNECT_SUCCESS
`#define CONNECT_INCORRECT_VERSION
`#define CONNECTfiNOTrAVAILABLE
`#define CONNECT_AGENT_REJECT
`#define CONNECT_HARDWARE_INCOMPATIBLE
`#define CONNECT_CLIENT_INCOMPATIBLE
`#define CONNECT_VIDEO_HANG
`
`0x02
`0x03
`0X04
`0x05
`
`0x01
`
`0X06
`0X07
`
`cons:
`
`int STATIC BUFFER = 256;
`
`// Structures for sending a keyboard or mouse event over
`the connection
`
`// implementation notes:
`needed for
`
`these contain for information then
`
`inplementation
`// a minimal
`// they are the parameters from keydb_event and mouse_event
`
`// Description of the protocol
`// Video Loop
`// Input Loop
`
`struct KeyboardEvent
`{
`
`BYTE Vk;
`
`// ** fields that are part of the func **//
`BYTE Scan;
`
`DWORD dwFlags;
`DWORD dwExtraInfo:
`
`DWORD dwRepeat;
`
`}:
`
`struct OtherEvent
`
`{
`
`);
`
`int HotKeyId:
`
`struct MouseEvent
`
`--
`
`SUBSTITUTE SHEET (RULE 26)
`
`15 of 196
`
`

`

`WO 99/26130
`
`PCT/US98/24342
`
`M
`
`DWORD dwFlags;
`DWORD dx;
`
`DWORD dy:
`// ** fields that are part of the func **//
`DWORD deata;
`DWORD dwExtraInfo;
`
`DWORD dwRepeat;
`
`};
`
`struct InfoBlock
`
`{
`
`long chompressedSize;
`long chullSize;
`long nDirtyCount;
`DWORD fCompression;
`DWORD fStatus;
`DWORD fCommands;
`
`// utilities
`InfoBlock ()
`I
`
`Clear
`
`void Clear
`
`(
`
`(
`
`)7
`
`)
`
`chompressedSize
`chullSize
`=
`
`nDirtyCount
`fStatus
`
`=
`=
`
`fCommands = 0;
`
`OOOII
`
`\-
`
`} e
`
`l;
`
`num ( PALETTE_AVAIL = 0x01 };
`
`struct Status
`
`{
`
`Status (
`{
`
`)
`
`fStatus = O;
`
`oid SetPause (
`
`)
`
`} v
`
`{
`
`fStatus l= PAUSE;
`
`SUBSTITUTE SHEET (RULE 26)
`
`16 of 196
`
`

`

`WO 99/26130
`
`PCT/059834342
`
`15
`
`void SetRefresh (
`
`)
`
`fStatus |= REFRESH;
`
`bool Refresh (
`
`)
`
`if ( fStatus & REFRESH )
`return true;
`
`else return false:
`
`bool Pause (
`
`)
`
`if ( fStatus & PAUSE )
`return true:
`else return false;
`
`I v
`
`oid Clear
`
`[1
`
`DWORD fStatus;
`
`enum { PAUSE = 0x02, REFRESH = 0x04 };
`
`l;
`
`struct DirtyBlock
`{
`
`short xPos:
`
`short yPos;
`
`// utilities
`
`void Mark (
`{
`
`int x,
`
`int y )
`
`xPos =
`
`(short) x;
`
`yPos =
`
`(short) y;
`
`};
`
`struct Hardwarelnfo
`{
`
`long ScreenWidth;
`long ScreenHeight;
`long MaxGridCount;
`long ByteCount;
`bool bFail;
`
`Hardwarelnfo (
`
`)
`
`SUBSTHUTESHEET(RULEZQ
`
`17 of 196
`
`

`

`WO 99/26130
`
`PCT/US9804342
`
`16
`
`{
`
`} v
`
`{
`
`bFail = false;
`
`oid SetFail ()
`
`bFail = true;
`
`} b
`
`l;
`
`ool GetFail
`
`(
`
`)
`
`{ return bFail;
`
`}
`
`// Global Utilities
`
`//void ResourceMessageBox (UINT, UINT=IDS_CAPTION,
`DWORD=MB_OK);
`
`// clientvideo.h
`
`// July 30, 1997
`// Rob Gagne
`
`// Purpose: Does the job of working with the display in the
`form of
`
`// a Video object, calcs the checksum, builds the dirty
`buffer and
`
`// compresses it.
`
`class ClientVideo
`
`{ p
`
`ublic:
`ClientVideo (
`~ClientVideo (
`
`):
`);
`
`bool OpenSession ( HWND );
`void CloseSession ( );
`bool ProcessFrame (
`InfoBlock&, DirtyBlock*, const
`LPBYTE, DWORD );
`
`long TotalBufferSize (
`
`)
`
`i return m_chotalBufferSize;
`
`void QueryHardware ( HardwareInfo& );
`long GridCount
`(
`)
`{ return GRID_WIDTH * GRID_HEIGHT:
`
`int MaxPalSize (
`
`)
`
`{ return m_display.MaxPalSize (
`
`);
`
`bool GetPalette (
`
`InfOBlock8, LPPALETTEENTRY );
`
`// Process iteration commands
`
`-_
`
`SUBSTITUTE SHEET (RULE 26)
`
`180fl96
`
`

`

`WO 99/26130
`
`PCT/US98/Z4342
`
`17
`
`enum { FORCE_PAINT = 0x01 };
`private:
`bool ProcessIteration (
`
`InfoBlock&, DirtyBlock*, DWORD
`
`);
`
`bool ProcessIterationNoLock ( InfoBlock5, DirtyBlock*,
`DWORD );
`
`(
`bool CompressBuffer
`bool CollectInfo ( );
`
`InfoBlock&, const LPBYTE );
`
`// hardware information
`
`bool m_bSupportLocking;
`
`// screen & buffer dimensions
`
`long m_ScreenHeight;
`long m_ScreenWidth;
`long m_OffscreenHeight;
`long m_OffscreenWidth;
`Rec: m_rCtScreen;
`Rect m_rctOffscreen;
`long m_padding;
`long m_ByteCount;
`
`// hardware interface
`
`Video m_display;
`
`// buffer size info
`
`DWORD m_chotalBufferSize;
`WORD m_chowBufferSize;
`int m_BitsPerPel;
`HWND m_hWnd;
`
`// checksum class
`
`CheckSum m_checksum;
`
`// compression
`CompressionEngine m_compressionEngine;
`
`};
`// adminvideo.h
`
`// August 4, 1997
`// Rob Gagne
`
`// manages the admin side of the video transaction
`
`_A
`
`class Adminvideo
`
`l p
`
`ublic:
`
`SUBSTITUTE SHEET (RULE 26)
`
`19 of 196
`
`

`

`W0 99/2613!)
`
`PCT/US98/24342
`
`18
`
`);
`AdminVideo (
`~AdminVideo ( );
`
`const Hardwarelnfo&, HWND,
`
`bool OpenSession (
`LPPALETTEENTRY );
`void
`CloseSession ( );
`bool
`
`ProcessFrame (
`
`InfoBlock&, DirtyBlock*, LPBYTE,
`
`DWORD )7
`
`long
`
`long
`
`int
`
`bool
`bool
`
`TotalBufferSize (
`
`)
`
`{ return m_chotalBufferSize;
`
`GridCount
`
`(
`
`)
`
`{ return GRID_WIDTH * GRID_HEIGHT;
`
`MaxPalSize (
`
`)
`
`{ return m_display.MaxPalSize ( );
`
`SetPalette ( LPPALETTEENTRY );
`RestoreLostSurface ( );
`
`bool
`bool
`
`Pause
`
`)
`(
`Refresh (
`
`{
`);
`
`return m_bLost;
`
`}
`
`private:
`bool
`
`);
`
`bool
`void
`
`ProcessIteration (
`
`InfoBlock&, DirtyBlock*, DWORD
`
`InfoBlock&, LPBYTE );
`(
`ExpandBuffer
`ProcessInfo ( const HardwareInfo& );
`
`// screen & buffer dimensions
`
`long
`long
`
`m_ScreenHeight;
`m_ScreenWidth;
`long m_OffscreenHeight;
`long
`m_OffscreenWidth;
`Rect
`m_rctScreen;
`Rect
`m_rctOffscreen;
`long
`m_padding;
`int m_ByteCount;
`
`// hardware interface
`
`Video m_display;
`HWND m_hWnd;
`
`// buffer size info
`
`DWORD m_chotalBufferSize;
`DWORD m_chowBufferSize;
`int m_BitsPerPel;
`
`// surface lost
`
`-—
`
`20 of 196
`
`

`

`WO 99/26130
`
`PCT/US98/24342
`
`19
`
`bool m_bLost;
`bool m_bRefresh;
`
`// compression
`CompressionEngine m_compressionEngine;
`
`};
`
`inline bool AdminVideo::Refresh (
`{
`
`)
`
`if (m_bRefresh)
`{
`
`m_bRefresh = false;
`return true;
`
`} r
`
`eturn false;
`
`// ahuff.h
`
`// header for adaptive huffman class
`
`#define END_OF_STREAM
`#define ESCAPE
`
`256
`257
`
`#define SYMBOL_COUNT
`#define NODE_TABLE_COUNT
`#define ROOT_NODE
`#define MAX_WEIGHT
`#define TRUE
`#define FALSE
`
`258
`(
`( SYMBOL_COUNT * 2 )
`0
`0X8000
`1
`0
`
`- l
`
`)
`
`class AdaptHuffComp
`
`{ p
`
`ublic:
`AdaptHuffComp ( );
`~AdaptHuffComp ( );
`
`long CompressBuffer
`bool=false);
`
`(LPBYTE, LPBYTE,
`
`long,
`
`bool ExpandBuffer
`bool=false);
`
`(LPBYTE, LPBYTE,
`
`long,
`
`long,
`
`private:
`// internal structures
`struct Tree
`
`{
`
`int leaf[ SYMBOL_COUNT ];
`
`“
`
`210f196
`
`

`

`WO 99/26130
`
`PCT/US98/24342
`
`20
`
`int next_free_node;
`struct Node
`
`{
`
`unsigned int weight;
`int parent;
`
`int child_is_leaf;
`int child;
`
`} nodes[ NODE_TABLE_COUNT ];
`
`);
`
`Tree m_tree;
`
`void InitializeTree(
`
`);
`
`void EncodeSymbol( unsigned int c, BIT_MANIP *output
`
`int DecodeSymbol( BIT_MANIP *input );
`void UpdateModel(
`int c
`void RebuildTree(
`);
`
`int j
`void swap_nodes( int i,
`void add_new_node(
`int c J;
`
`);
`
`};
`
`//** winsockZ defines **//
`
`#define SD_RECEIVE
`#define SD_SEND
`#define SD_BOTH
`
`0x00
`0x01
`0x02
`
`class Except
`
`{ p
`
`ublic:
`( LPCTSTR );
`Except
`void Trace ( );
`
`private:
`
`m_LastError;
`DWORD
`LPCTSTR m_pError;
`
`};
`
`class BaseSocket
`
`{ p
`
`ublic:
`// interface
`BaseSocket
`( );
`~BaseSocket
`(
`);
`
`22 of 196
`
`

`

`WO 99/26130
`
`PCT/US98/24342
`
`21
`
`(
`int Send
`(
`int Recv
`int SendFull
`int Rechull
`
`void EmptyRe
`bool CanRead
`bool CanWrit
`
`int ) const;
`LPBYTE,
`int ) const;
`LPBYTE,
`y
`( LPBYTE,
`int
`) const;
`y
`( LPBYTE,
`int
`) const;
`chuffer (
`) const;
`(
`int = 30 ) const;
`( int = 30 ) const;
`
`e
`
`void Shutdow
`
`void Close (
`
`n (
`);
`
`int=SD_SEND );
`
`protected:
`// data
`SOCKET
`
`sockaddr_in
`int
`
`bool
`bool
`
`m_socket;
`m_addr;
`m_nPort;
`m_bCreated;
`m_bConnected;
`
`// protected
`void InitCla
`void Resolve
`
`void Bind (
`void Create
`
`methods
`
`):
`88 (
`( int, LPCTSTR );
`Name
`int, LPCTSTR=NULL ):
`();
`
`int&);
`( sockaddr_in*, LPTSTR,
`IPFromAddr
`bool
`bool NameFro
`int&);
`mAddr
`( sockaddr_in*, LPTSTR,
`r
`( LPCTSTR, unsigned char*);
`
`bool IstAdd
`
`};
`
`class ServerSocke