The present application relates to enhanced web browsing, and in particular, to a method and system for enhanced web browsing for mobile devices.
Mobile devices are becoming increasingly sophisticated. In addition to providing voice communication capabilities, devices are increasingly being used for data communications. This includes electronic mail messages but also includes browsing networks such as the Internet.
A mobile device will generally communicate wirelessly through a radio frequency communication channel. Various standards for radio frequency communications are known to those in the art. Browsing the Internet over mobile devices is problematic for a number of reasons. The connection speed between the mobile device and the wireless network is relatively slow, and the loading and updating time for web pages is considerably slower with mobile devices compared to conventional browsing on a personal computer. Additionally, bandwidth is expensive and limitations exist in many cases for the total download size of files over the air. Due to the nature of mobile wireless coverage, connectivity is not as reliable as in conventional wire line networks. When a connection is lost in the middle of loading of a web page, the whole page needs to be requested and reloaded once the connection is restored. Solutions to optimize web page loading from mobile devices have been previously introduced. For example, compression techniques are used to minimize the amount of data being sent over the air in order to optimize bandwidth usage and increase transfer speed. Reliable protocols guarantee that data can be delivered over unreliable networks. While these solutions provide some enhancements, further enhancements are required.
The present disclosure will be better understood with reference to the drawings in which:
The present system and method seeks to enhance a browsing experience for a mobile device user through the introduction of a wireless page fragmentation server proxy (WPFS proxy). All data pass between a mobile device and the Internet for web browsing will flow through the WPFS proxy.
The WPFS proxy is designed to fragment a web page and assign unique identifiers to the fragments. Two approaches are outlined. A first is a design time approach in which various tags can be added to a web page to indicate to the WPFS proxy how the web page should be broken down. A designer of a web page can rank various fragments of the web page to be higher priority than others, thereby allowing a mobile device to receive only fragments of a certain priority. For example, devices with a smaller screen size (form factor) may choose to render only high priority fragments.
A second approach is a run time approach in which the WPFS proxy fragments web pages that do not have special tags embedded within them. Thus, the WPFS proxy could scan a web page and identify certain HTML tags for HTML frames, frame sets, tables, forms, objects, images and scripts and enclose these various tags with tags for fragmentation. The fragmented page would then be sent to the browser on the mobile device.
The use of fragments provides several advantages. Fragments allow the refreshing of a web page by only passing to the mobile device portions of the web page that have been updated or that are no longer stored in the mobile device's cache. This thereby decreases the amount of data that is transferred to a device. Minimizing data transfer decreases the cost for data transfer and increases the speed at which a page can get refreshed, thereby allowing the user to have a faster browsing experience at a lower cost.
Other advantages include the ability to resend only fragments that have not yet been loaded if a connection is lost part way through a download of a web page. Further, fragments with low priority items or with certain content types can be blocked before being sent over the air. Other advantages will be apparent when considering the detailed description herein.
Both the design time approach and the run time approach can be used in conjunction with each other, and the two solutions are not mutually exclusive. A preferred embodiment allows a WPFS proxy to use both approaches to cover a wider variety of web pages.
The present disclosure therefore provides a web page fragmentation server proxy communicating with a mobile device over wireless network and receiving from the mobile device requests for a web page along with fragment identifiers of the web page stored on the mobile device; the web page fragmentation server proxy further communicating with web servers over the Internet, said web page fragmentation server proxy comprising: communication means for communicating with the wireless network and the Internet; memory for storing web page fragments; and a processor adapted to fragment all web pages destined for said mobile device creating received fragments, said processor further adapted to compare stored web page fragments with received fragments, wherein the web page fragmentation server proxy sends web page fragments not already stored on the mobile device to the mobile device.
The present disclosure further provides a method, in a web page fragmentation server proxy having a processor, communication means and memory, of providing new and updated fragments to a mobile device, the mobile device requesting a web page with the request including identifiers for fragments of the web page already stored by the mobile device, the method comprising the steps of: receiving a web page from the internet corresponding with the web page requested by the mobile device; fragmenting the received web page, creating received fragments; comparing received fragments with fragments stored in the memory, the fragments not matching the memory being new fragments; storing new fragments; and passing new fragments to the mobile device.
The present disclosure still further provides a method of browsing on a mobile device comprising the steps of: sending, from the mobile device, a web page request with fragment identifiers of fragments stored on the mobile device; receiving, at a web page fragmentation server proxy the web page request; sending the web page request to the internet; receiving the web page at the web page fragmentation server proxy; fragmenting the web page at the web page fragmentation server proxy; comparing fragments with those stored on the web page fragmentation server proxy; returning any new or updated fragments to the mobile device; and refreshing the web page display based on both received fragments and stored fragments.
The present disclosure further provides a system for providing enhanced web browsing to a user of a mobile device, comprising: a wireless network; the mobile device, said mobile device communicating with the wireless network; and a web page fragmentation server proxy communicating with said wireless network and further communicating with web servers over the internet, said web page fragmentation server proxy processing all web traffic to and from said mobile device, said web page fragmentation server having: memory for storing web pages fragments; and a processor adapted to fragment web pages received from said web servers, the processor further adapted to compare stored web page fragments with web page fragments generated by the processor, wherein the mobile device has a browser adapted to receive fragments of web pages and to request web pages utilizing fragment identifiers, said web page fragmentation server proxy being adapted to send web page fragments not already stored on the mobile device to the mobile device.
Reference is now made to
Each mobile device 120 may be provided with various applications, including, without limitation, one or more existing applications that enable communications with other mobile devices 120, such as wireless telephone applications, e-mail applications, short message service (SMS) applications, multi-media messaging service (MMS) applications among others. Further, each mobile device 120 is also provided with software that enables browsing of the Internet, such browsing applications being known in the art. The term “application” as used herein shall include one or more programs, routines, subroutines, function calls or other type of software or firmware and the like, alone or in combination.
System 110 also includes a wireless network 130 with which mobile device 120 communicates. Wireless network 130 may be any wireless communication network or combination of interconnected networks, including, without limitation, Mobitex™, DataTAC™, TDMA, CDMA/1×RTT/EVDO, GSM/GPRS/EDGE/UMTS, PCS, EMTS or CDPD. As is known, wireless network 130 includes a plurality of base stations that perform radio frequency protocols to support data and voice exchanges with mobile device 120. A network node 140 communicates with wireless network 130 and controls communication to and from mobile device 120.
A wireless page fragmentation server (WPFS) proxy can exist as part of network node 140 or as a separate server 142 as illustrated in
WPFS proxy 142 performs several functions in order to enhance browsing from mobile device 120. WPFS proxy 142 acts as an intermediary between Internet 150 and a browser on mobile device 120. All web traffic going to mobile device 120 is routed through WPFS proxy 142 and all requests for web pages from mobile device 120 flow through WPFS proxy 142.
WPFS proxy 142 receives web pages requested by mobile device 120. In order to benefit from the present method, WPFS proxy 142 then preferably fragments the web page that was received. As will be appreciated, this can be done in one of several ways.
In a first embodiment, if a designer has designed his or her web page to be mobile device friendly, special tags could be inserted into the web page that are recognizable by the WPFS proxy and by an adapted browser on mobile device 120.
Specifically, web pages are written in various languages including hypertext mark-up language (HTML) or extensible hypertext mark-up language (XHTML). Other languages for web pages would be known to those skilled in the art and the present application is not meant to be limited to HTML or XHTML.
In the HTML example, the structure of the HTML code may be as follows:
A design time option for a designer who is targeting mobile users could be to include a new tag within the HTML or XHTML tags that will be used to identify fragments within the page and further to set priority and a unique identifier for each fragment. An exemplary modified HTML code would be as follows:
The new tag has been designated as “FR” to indicate a fragment. This is, however, not limiting, and the name of the fragment tag can be any combination of letters or numbers.
in the preferred embodiment, the fragment tag includes several parameters. The first is the identifier for the fragment. Each fragment within a web page needs to have a unique identifier. The reason for this is for the updating of web pages or the loading of web pages on a fragment-by-fragment basis as described in more detail below. Thus, the WPFS proxy 142 will store a unique identifier. In one example, the unique identifier comprises the name of the web page (URI or URL—uniform resource identifier or uniform resource locator) along with the fragment identification. Other unique identifiers are possible.
The second parameter identified above for the fragment tag includes the priority. A designer could assign various priorities to various fragments. For example, if the user is accessing a site that gives stock quotes, the actual stock symbol and stock price could be in a fragment that has a very high priority, whereas background material and perhaps advertising on the page could be given a lower priority.
A further parameter for the fragment tag above is the version number of the fragment. As will be appreciated by those skilled in the art, a web page that periodically updates could assign a subsequent version number to each fragment that is being updated. Only the fragments that have been updated can then be downloaded to mobile device 120 in order to save the bandwidth and costs of downloading the entire web page. For example, in the stock quote web page, a stock symbol and a price could be given a first version number. When the stock price changes, then the fragment with that stock price in it could be given a subsequent version number.
The above fragment tag and the exemplary parameters that are associated therewith is meant to be illustrative of a preferred fragment tag but is not meant to be limiting. Other parameters could be added to the fragment tag and further the parameters identified above, including the unique identifier, priority value and the version number could be omitted in some cases. For example, the identifier could be omitted completely and the WPFS proxy 142 could assign its own identifiers to the fragments based on the order that they appear within the web page source code. Alternatively, a fragment identifier could include both the unique identifier and version number together.
When WPFS proxy 142 receives a web page designed with fragments in it, it can break the web page into the fragments as designed by the web page designer and pass these fragments to the mobile device in accordance with the mobile device's preferences. For example, the mobile device may indicate that only fragments with the priority higher than a value X are to be passed to the mobile device. Such a request could be made if, for example, the device has a smaller form factor or operates on slower networks.
WPFS proxy 142 further receives web pages that are requested by mobile devices 120 that were not designed for fragmentation as described above. In this case, WPFS proxy 142 can render the web page on the fly and fragment it. In a preferred embodiment, WPFS proxy 142 scans the web page and identifies tags within the web page that may be useful for fragmentation. Such tags include, but are not limited to, frames, frame sets, tables, forms, objects, images and scripts. WPFS proxy 142 embeds fragmentation tags into the page based on these tags and forwards the fragmented page to the browser on mobile device 120 on a fragment-by-fragment basis. As with the above, each fragment is assigned a unique identifier, which can then be used by WPFS proxy 142 to refresh the specific fragment when it needs updating.
Further, a priority may be assigned to the fragments based on the HTML tag linked to the fragment. Thus, for example, text could be assigned a higher priority for a mobile device than images. Such preferences can be universal or can be set on a device-by-device basis.
For a device specific embodiment, a device profile from mobile device 120 could be sent to WPFS proxy 142, for example, during registration of the mobile device, which would indicate the profile of the device. The device can specify whether it wants to receive images, tables, text or some combination of these, among others. It is possible that a user of mobile device 120 could set these parameters or the parameters could be pre-configured based on the type of mobile device 120 that is browsing the Internet.
In an alternative embodiment, a content type field could be added to the fragmentation tag. Specifically, instead of or in addition to using a priority to specify which types of content the mobile device 120 should receive, a content type tag could be added to the fragment. In this case, the mobile device could specify that it wants to receive a certain content type rather than fragments above a preset priority threshold.
In a preferred embodiment, regardless of whether the fragmentation is done by a web page designer or WPFS proxy 142, WPFS proxy keeps a copy of the last page sent to the browser on mobile device 120 and either adds a version number or utilizes the passed version number, along with the unique identifier when storing the fragment. Thereafter, and as described in more detail below with reference to
Reference is now made to
WPFS proxy 142 includes at least a processor 410 and memory 420. Communication means 430 allow communication with both the wireless network 130 and Internet 150 as illustrated in
Various other components could exist on WPFS proxy 142 and the diagram of
As will be appreciated, a browser on mobile device 120 will also need to be updated in order to support the fragmentation of web pages. This can be done either through a plug-in module with existing browsers or with a redesigned browser. The updated browser needs to recognize that fragments exist, and thus when requesting a web page it will know to go to the memory of mobile device 120 to see whether any of the fragments of the page being requested are cached. A request from the modified browser could include fragment identifiers containing unique identifiers and version numbers of any fragments stored for the desired URL.
In a preferred embodiment, the fragment version would be included in the request header for any web page request. As will be appreciated, the request headers are part of the HTTP standard and are commonly used for communicating request parameters to a server proxy. Thus the request header could include the unique identifiers and version numbers for fragments stored on the mobile device.
The above fragment request is only an example, and other request structures and semantics are foreseen.
Reference is now made to
A mobile device 120 in step 210 generates a request for a web page at a new URL. As will be appreciated, this is likely the result of a user browsing to a web page and requesting the web page. In accordance with the above, the browser in mobile device 120 sends the new URL to WPFS proxy 142.
In a preferred embodiment, step 210 includes the modification of a traditional URL request to include any fragment identifiers (containing unique identifiers and versions) of the requested web page for fragments that are stored within the memory of mobile device 120. Specifically, if the user has previously requested the URL and subsequently gone to a different page, the web page may still be stored in the mobile device's cache. In this case, the mobile device will only be interested in an update of the web page and can therefore include, with the URL, the fragment identifiers that are stored within the memory of mobile device 120 when it sends the URL to WPFS proxy 142.
Alternatively in step 212, the browser may request a refresh of the URL. In certain situations, the user may stay on a web page in order to receive specific Information that it wants updated periodically. For example, if the mobile user is on a stock market page, the user may request that a stock price be updated every three minutes. This can be done either through pushing from the content provider or a pull request from the browser on mobile device 120. Step 212 illustrates the latter in which a pull request is being made.
In one embodiment, a browser could allow a JavaScript subscription to a fragment within a page. Thus, the user could identify which fragments he or she wanted updated and then ignore the remainder of the web page or maintain the web pages already stored in cache with the exception of the one or more fragments that are being updated, according to the JavaScript subscription.
Step 212 could also be the case where a user hits a refresh button on a web page.
The URLs and fragment identifiers from steps 210 and 212 are sent to WPFS proxy 142. In step 220, WPFS proxy 142 forwards the URL to the Internet 150 and ultimately to the server for the web page being requested. In some embodiments, WPFS proxy 142 also forwards fragment identifiers in addition to the URL.
The server on Internet 150 receives the URL in step 230 and returns HTML (or XHTML, etc.) code in step 232.
WPFS proxy 142 receives the HTML code, sent in step 232, in step 240 and in step 250 proceeds to parse fragments and compare the content with the cached content on WPFS proxy 142. In addition, the fragments are also compared with the fragments identified in the page request sent from device 120 in step 210.
Step 250 is described in more detail with reference to
A comparison with the cache on WPFS proxy 142, or with the fragment identifiers sent in step 210 is performed to check whether the version that is stored on mobile device 120 is the same as the fragment that WPFS proxy 142 has received.
In step 260, WPFS proxy 142 returns updated fragments that are different from those already stored within mobile device 120. In some embodiments, only some of the updated fragments may be returned to device 120, based on the fragments that were requested to be updated as part of the page request in step 210. These fragments are then passed over the air through wireless network 130 to the browser on mobile device 120.
In step 270, the mobile device opens or updates the fragment that has been received from the WPFS proxy 142.
In one embodiment, a content provider on Internet 150 could push content to the mobile device 120. In this case, a push server could generate a message in step 234, which could be then passed to WPFS proxy 142 and received in step 240. The pushed content will be treated as if the content that has been received from step 232 and will thus proceed through steps 250, 260 and 270.
Reference is now made to
In step 310, WPFS proxy 142 receives content. Such content is either an entire web page or a fragment of a web page—for example if a web server is pushing fragments individually.
The process in WPFS proxy 142 proceeds to step 312 in which it checks to see whether the received content includes fragmentation tags. As described above, a designer may insert fragmentation tags to indicate where a page should be fragmented, and further assign a priority to each fragment. In step 312, the process on WPFS proxy 142 checks whether or not such tags exist within the message.
If not, the process proceeds to step 314 in which the content is parsed. In other words, the content is analyzed for its particular contents.
The process next proceeds to step 316 in which the content is fragmented using content type tags. As indicated above, such tags include, but are not limited to, tags representing frames, frame sets, tables, forms, objects, images and scripts. Each of these content types can be broken into a separate frame, given a unique frame identifier for the URL and further given a priority or a content type parameter to facilitate the passing of the information.
From step 316, the process proceeds to step 318 in which each fragment created in step 316 is compared with any fragments that exist within the cache of WPFS proxy 142. This is done in order to see whether changes exist within the content received with the content cached.
In a preferred embodiment, step 318 will discard fragments that are identical to those that are already stored on WPFS proxy 142. Those fragments that are different are assigned a unique version number in step 320 and are stored in WPFS proxy 142 in step 322.
If, in step 312, the WPFS proxy 142 finds that fragmentation tags are included within the content, then the process proceeds to step 330. In step 330, the WPFS proxy 142 fragments the content using the fragmentation tags provided by a developer.
The process next proceeds to step 332 in which the fragments are checked for their version number. If the version number of the fragments is the same as the version number of fragments that are already stored on WPFS proxy 142, in a preferred embodiment such fragments are discarded. The fragments that contain new version numbers are preferably stored in step 322.
The process next proceeds from step 322 to step 340. In step 340, the fragment identifiers containing the unique identifiers and version numbers for the URL requested by mobile device 120 are compared with the unique identifiers and version numbers of the content received from Internet 150. Any new content meeting the predefined criteria for mobile device 120 is passed in step 340 to mobile device 120. As will be appreciated by those skilled in the art, new content as referred to herein means fragments not already stored on mobile device 120 which can include updated fragments. The determination of whether the fragment is already stored on the mobile device is done based first on the unique identifier and second on the version number of the fragment.
The above allows for several scenarios. Specifically, a first scenario is when a user requests a page update or a server pushes an update. The browser could send to the WPFS proxy 142 a version for each fragment that is stored on mobile device 120 and the WPFS proxy 142 will send back only the fragments that need to be updated, if any. This provides the advantage that not all content needs to be passed over the air, saving both network resources and battery life, and providing the user with cost savings, since in many cases the costs for browsing are related to the number of bytes downloaded.
In a further scenario, if the mobile device is in the middle of opening a new page when a data connection to the wireless network 130 is lost, when the data connection is re-established only fragments that were not previously loaded need to be sent. This is contrasted with the prior art in which the entire page would have to be resent.
In a further scenario, the browsing of a mobile device can be customized for particular content type based on the fragments that are desired by the user. The WPFS proxy can strip off low priority fragments or specific content type selectively based on the device type, device screen size or user preferences, among others.
As will further be appreciated, updates to the web page will be faster since only a portion of the web page may need to be passed. This allows content that is already stored on the mobile device to be shown to the user quickly and only the portion of the page that is updated needs to be refreshed.
Other exemplary scenarios for the advantages of the fragmentation of web pages exist and the above scenarios are meant as examples only.
As will be appreciated, the above can be implemented on any mobile device with a browser modifier for fragments. One exemplary mobile device is described below with reference to
Where mobile station 500 is enabled for two-way communication, it will incorporate a communication subsystem 511, including both a receiver 512 and a transmitter 514, as well as associated components such as one or more, preferably embedded or internal, antenna elements 516 and 518, local oscillators (LOs) 513, and a processing module such as a digital signal processor (DSP) 420. As will be apparent to those skilled in the field of communications, the particular design of the communication subsystem 511 will be dependent upon the communication network in which the device is intended to operate.
Network access requirements will also vary depending upon the type of network 519. In some CDMA networks network access is associated with a subscriber or user of mobile station 500. A CDMA mobile station may require a removable user identity module (RUIM) or a subscriber identity module (SIM) card in order to operate on a CDMA network. The SIM/RUIM interface 544 is normally similar to a card-slot into which a SIM/RUIM card can be inserted and ejected like a diskette or PCMCIA card. The SIM/RUIM card can have approximately 64K of memory and hold many key configuration 551, and other information 553 such as identification, and subscriber related information.
When required network registration or activation procedures have been completed, mobile station 500 may send and receive communication signals over the network 519. As illustrated in
Signals received by antenna 516 through communication network 519 are input to receiver 512, which may perform such common receiver functions as signal amplification, frequency down conversion, filtering, channel selection and the like, and in the example system shown in
Mobile station 500 preferably includes a microprocessor 538 which controls the overall operation of the device. Communication functions, including at least data and voice communications, are performed through communication subsystem 511. Microprocessor 538 also interacts with further device subsystems such as the display 522, flash memory 524, random access memory (RAM) 526, auxiliary input/output (I/O) subsystems 528, serial port 430, two or more keyboards or keypads 532, speaker 534, microphone 536, other communication subsystem 540 such as a short-range communications subsystem and any other device subsystems generally designated as 542. Serial port 530 could include a USB port or other port known to those in the art.
Some of the subsystems shown in
Operating system software used by the microprocessor 538 is preferably stored in a persistent store such as flash memory 524, which may instead be a read-only memory (ROM) or similar storage element (not shown). Those skilled in the art will appreciate that the operating system, specific device applications, or parts thereof, may be temporarily loaded into a volatile memory such as RAM 526. Received communication signals may also be stored in RAM 526.
As shown, flash memory 524 can be segregated into different areas for both computer programs 558 and program data storage 550, 552, 554 and 556. These different storage types indicate that each program can allocate a portion of flash memory 524 for their own data storage requirements. Microprocessor 538, in addition to its operating system functions, preferably enables execution of software applications on the mobile station. A predetermined set of applications that control basic operations, including at least data and voice communication applications for example, will normally be installed on mobile station 500 during manufacturing. Other applications could be installed subsequently or dynamically.
A preferred software application may be a personal information manager (PIM) application having the ability to organize and manage data items relating to the user of the mobile station such as, but not limited to, e-mail, calendar events, voice mails, appointments, and task items. Naturally, one or more memory stores would be available on the mobile station to facilitate storage of PIM data items. Such PIM application would preferably have the ability to send and receive data items, via the wireless network 519. In a preferred embodiment, the PIM data items are seamlessly integrated, synchronized and updated, via the wireless network 519, with the mobile station user's corresponding data items stored or associated with a host computer system. Further applications may also be loaded onto the mobile station 500 through the network 519, an auxiliary I/O subsystem 528, serial port 530, short-range communications subsystem 540 or any other suitable subsystem 542, and installed by a user in the RAM 526 or preferably a non-volatile store (not shown) for execution by the microprocessor 538. Such flexibility in application installation increases the functionality of the device and may provide enhanced on-device functions, communication-related functions, or both. For example, secure communication applications may enable electronic commerce functions and other such financial transactions to be performed using the mobile station 500.
In a data communication mode, a received signal such as a text message or web page download will be processed by the communication subsystem 511 and input to the microprocessor 538, which preferably further processes the received signal utilizing a modified browser for output to the display 522, or alternatively to an auxiliary I/O device 528. A push client 560 could also process the input.
A user of mobile station 500 may also compose data items such as email messages for example, using the keyboard 532, which is preferably a complete alphanumeric keyboard or telephone-type keypad, in conjunction with the display 522 and possibly an auxiliary I/O device 528. Such composed items may then be transmitted over a communication network through the communication subsystem 511.
For voice communications, overall operation of mobile station 500 is similar, except that received signals would preferably be output to a speaker 534 and signals for transmission would be generated by a microphone 536. Alternative voice or audio I/O subsystems, such as a voice message recording subsystem, may also be implemented on mobile station 500. Although voice or audio signal output is preferably accomplished primarily through the speaker 534, display 522 may also be used to provide an indication of the identity of a calling party, the duration of a voice call, or other voice call related information for example.
Serial port 530 in
Other communications subsystems 540, such as a short-range communications subsystem, is a further optional component which may provide for communication between mobile station 500 and different systems or devices, which need not necessarily be similar devices. For example, the subsystem 540 may include an infrared device and associated circuits and components or a Bluetooth™ communication module to provide for communication with similarly enabled systems and devices.
The embodiments described herein are examples of structures, systems or methods having elements corresponding to elements of the techniques of this application. This written description may enable those skilled in the art to make and use embodiments having alternative elements that likewise correspond to the elements of the techniques of this application. The intended scope of the techniques of this application thus includes other structures, systems or methods that do not differ from the techniques of this application as described herein, and further includes other structures, systems or methods with insubstantial differences from the techniques of this application as described herein.