Method and system for presenting on-line “Yellow...

Data processing: database and file management or data structures – Database design – Data structure types

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C707S793000, C709S203000

Reexamination Certificate

active

06665676

ABSTRACT:

FIELD OF THE INVENTION
This invention relates to transferring data over a low bandwidth network. More particularly, this invention relates to rapid transfer of large map-images in a slow network connection.
BACKGROUND OF THE INVENTION
When using the Internet, the time it takes for a web page to be loaded in the user's remote machine is highly critical. The maximum reasonable waiting time is defined to be a matter of seconds (not more than a dozen or two). Common map-transfer methods are based on a process in which the client requests a portion of the map, the server executes the request using a special engine that can dynamically create the desired portion of the map, and the result is sent to the client as an image file (gif, jpeg . . . ). This process is slow and limited, as the size of the resulting image is limited to a few KBytes (not more than several dozen). In addition, any navigation request (including zooming) requires a new ‘dialog’ with the host server, and a new waiting time for the updated result-image.
When designing a web site, there must be a correlation between the size (in KB—kilobytes) of the elements that it contains (images, sound, animations, special scripts and also the textual information) and the quality of the network connection. It makes no sense to include high-volume elements when the connection is poor and slow. Adapting the size of the web page to the quality of the network is essential in order to achieve a site that can be viewed without having a long waiting time.
Considering the following facts:
A Standard modem connection data-transfer-rate is about 3 KB/s (3 kilobytes per second)
A low detailed image comprising 4 bit color, and 400×400 pixels occupies about 100 Kb (100 kilo bytes)
A standard screen resolution is 800×600 (pixels)
Downloading a 400×400 (pixels) low detailed image, through a standard Internet modem connection takes as long as 30 seconds. A 400×400 (pixels) image is a relatively large image. It takes about 66% of the size of a standard screen. Most web sites usually contain reduced weight images (like small banners, logos or icons). Those images occupy only a few Kb (maybe a dozen), and so appear sufficiently fast on the client side so that the end user does not wait too long (typically only several seconds).
In other words, as long as a site does not contain large images, it may be viewed relatively fast by the end user (client). The current standard bandwidth (about 3 Kb/s) is fast enough to permit fairly free use of banners, icons, logos and more, on web sites without requiring the end user to wait too long.
However, this breaks down when it is desired to download much larger images from a web site. For example, an image containing 400×4000 pixels, which is ten times larger than in the previous example, would probably occupy about 1000 KB, and it would take around 5 minutes to download. It cannot reasonably expected that most users will wait so long and for this reason, most sites do not contain such large images.
This problem is particularly acute in sites that contain maps. Maps are large and highly detailed pictures. Compressing a map is not so efficient owing to the importance of almost every pixel in the picture. A monochrome GIF image of a low detailed street map of Tel-Aviv would occupy about 1000 Kb and would take some five minutes to download, as explained above.
In order to use large images over the Internet using current methods, either an improved compression algorithm or an extremely high bandwidth connection is required, or both. Neither solution is immediately apparent.
Some attempt has been made to address the need to allow fast data transfer of map data from a server to a client. For example, U.S. Pat. No. 5,966,135 assigned to Autodesk, Inc. of San Rafael, Calif., discloses a method, apparatus, and article of manufacture for a computer implemented geographic information system that enables viewing a map picture that is generated from vector-based data. Map pictures can be generated with vector-based data. Map pictures comprising map objects, such as states and cities created with vector-based data can be viewed. Map objects can be chosen to obtain additional information, for example, a different map picture. Additionally, areas of the map picture can be zoomed in on to view the areas with greater resolution or to obtain additional data about the areas. Furthermore, when a user requests to view a map picture, only the map data required to respond to the user's request is downloaded to generate a map picture. As a user makes additional requests for information, additional map data is downloaded and new map pictures are generated.
The map data may be layered so that only those layers actually requested by a user need be downloaded thereto, thus saving communication time. It appears that whilst manipulation of the map displayed on the client terminal may be effected, in most cases the actual processing of the map data is done by the map server, which generates and sends fresh map data to the client for display thereby. During the resulting hiatus, a message is presented so as to inform the user that a dynamic map is being processed. Specifically, this processing requires the transmission of complete map data relating to the newly-requested map to the client for display thereby. That this is so derives from the fact that, as noted above, when a user requests to view a map picture, only the map data required to respond to the user's request is downloaded to generate a map picture. As a user makes additional requests for information, the map data corresponding to the newly-requested map is downloaded from the map server and new map pictures are generated. Thus, after downloading an initial map, if the user wishes to view a location which is current not displayed (i.e. off screen), the displayed image can be panned left, right, up or down using navigation keys. When this is done, a request is sent to the map server, which processes the request, during which time a message is presented so as to inform the user that a dynamic map is being processed.
Likewise, the user can define a window within the displayed map area that he or she would like to see enlarged. This type of manipulation is referred to generally as “zooming” but it is important to appreciate that, in fact, two quite different manipulations may be performed. Thus, zooming can be used to increase the resolution at which graphical data is viewed in the computer display screen. Consider, for example, that a user wants to see a street map of New York City and that initially this is the only information the program knows. In this case, a complete map of N.Y. city is downloaded to the user. Clearly, even ignoring considerations of bulk data transfer, communication bandwidth, and so on, the amount of data that can be resolved on the display screen is limited. At best, all that can be seen in a large scale map covering such a large area, are the main arteries possibly including minimal textual data. Any attempt to display more data would result either in the data been miniscule or in one set data obliterating another. In either case, since the data would in any case be illegible, it is not transferred in the initial display. This, of course, accelerates the rate at which the initial map data can be transferred from the map server to the user.
If the user now marks a relatively small area of the complete city map containing a region of interest, then since data is to be displayed at greatly increased scale (i.e. covering a much reduced area), much more data can now be displayed. This data must first be extracted from the map server, and of course, this is accompanied by the usual hiatus and informative message to the user. If the user, zooms in even more, this process is repeated until eventually there comes a point when the extracted map data relates to so small an area, that all the map data relating to this area can be displayed. If the user zooms in even further at this stage, all that can be done is to display t

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Method and system for presenting on-line “Yellow... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Method and system for presenting on-line “Yellow..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for presenting on-line “Yellow... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-3132748

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.