Abstract:
An apparatus, program product and method control access to linked documents on a computer based on a calculated determination of the trustworthiness of such linked documents, so that user navigation to untrusted documents from a document with which such untrusted documents are linked can be deterred. Basing link access control on document trustworthiness permits owners, authors, developers, publishers, etc. of documents, for example, to avoid potential difficulties such as embarrassment, confusion or legal liability as a result of the content of linked-to documents under the control of third parties.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application is a continuation of U.S. patent application Ser. No. 09/577,644, filed on May 24, 2000, Cary Lee Bates et al. (ROC919990227US1), the entire disclosure of which is incorporated by reference herein. 
     
    
     FIELD OF THE INVENTION 
       [0002]    The invention is generally related to computers and computer software. More specifically, the invention is related to access control of stored documents in a computer. 
       BACKGROUND OF THE INVENTION 
       [0003]    The amount and variety of information that can be accessed through a computer continues to increase at an astounding rate. The Internet, in particular, has enabled computer users to access a wide variety of information from other computers located all over the world. 
         [0004]    Much of the information accessible via the Internet is organized into hypertext documents, which are typically documents formatted in a language known as Hypertext Markup Language (HTML), and which are accessed via a segment of the Internet known as the World Wide Web. Hypertext documents typically include one or more embedded “hypertext links” that an end user can select to either jump to different documents, or to jump to different locations within the same document. Each hypertext document typically is identified by the storage location (known as a Uniform Resource Locator (URL)) at which the document is stored, with a hypertext link to a particular document, or “target”, specifying the storage location of that document so that, upon selection of the link, that document may be retrieved. 
         [0005]    A wide variety of other information such as text, graphics, video, sound, and animation may be integrated into hypertext documents, and moreover, these documents can be organized into “sites”, typically maintained by a single entity, that collect multiple related documents together in a coherent fashion. Furthermore, due to the immense popularity of the World Wide Web, many private computer networks now also support hypertext documents, as do a number of existing computer operating systems and computer software applications. 
         [0006]    A computer program, often referred to as a browser, is typically used to navigate between and through hypertext documents. With a browser, an end user can use a mouse or other pointing device to point and click on links such as highlighted text, images or other user interface components (e.g., buttons) in documents to navigate to different documents and/or to different locations within the same document. 
         [0007]    Given that any hypertext document can link to any other document accessible to a computer simply through the inclusion of an appropriate URL or other storage location identifier in the document, users are often able to navigate through an endless array of documents in an extremely flexible and intuitive manner. The free-form, decentralized linking of documents on the Internet therefore provides a powerful and useful interface through which users can locate interesting information simply by following links until desirable information is found. 
         [0008]    The decentralized and uncontrolled nature of the Internet, however, is not without its drawbacks. In particular, documents under the control of particular entities, e.g., publishers, owners or authors, often provide links to documents that are under the control of third parties. Nonetheless, by linking to third-party documents, those entities may somehow be perceived as endorsing or otherwise approving of the content of the third-party documents. 
         [0009]    As an example, an owner of a web site on a religious topic might provide links to other web sites that espouse similar religious teachings. However, the owner may not have any control over the content of the other web sites, and as a result, should any other web site change to include teachings that might be inconsistent with or offensive to the owner and his or her followers, the owner would presumably not wish for readers of the other web sites to assume that the owner endorses or approves of the content of the changed web sites. 
         [0010]    As another example, a web site dealing with providing legal, technical or medical information might link to third-party web sites to provide additional sources of similar information. Given the rapid and ongoing changes in the law, technology and medical science, however, linking to third-party web sites raises a significant concern that such third-party web sites are not kept sufficiently up to date. It would obviously be extremely undesirable for an informational web site to provide links to third-party web sites that contained incorrect or outdated information. In addition to potential embarrassment and loss of credibility, links to incorrect information could even raise the possibility of legal liability in extreme situations. 
         [0011]    Document owners, publishers and developers have traditionally attempted to avoid links to untrustworthy third-party documents through periodic monitoring of linked-to documents and web sites. Monitoring documents and web sites in this manner, however, can be relatively time consuming, as such monitoring often requires that the documents be read and analyzed manually to determine whether the content thereof is acceptable. As a result, monitoring is often only performed on a sporadic basis, if at all, thus exposing document owners, publishers and developers to the risk that third-party documents will become untrustworthy in the interim between successive checks of such documents. 
         [0012]    Therefore, a significant need exists in the art for a manner of limiting the risks associated with linking to third-party documents over which content control is not feasible, in particular to minimize the likelihood of mistaken endorsement or approval of third-party document content. 
       SUMMARY OF THE INVENTION 
       [0013]    The invention addresses these and other problems associated with the prior art by providing an apparatus, program product and method in which access to linked documents on a computer is controlled based on a calculated determination of the trustworthiness of such linked documents, so that user navigation to untrusted documents from a document with which such untrusted documents are linked can be deterred. Among other benefits, basing link access control on document trustworthiness permits owners, authors, developers, publishers, etc. of documents to avoid potential difficulties such as embarrassment, confusion or legal liability as a result of the content of linked-to documents under the control of third parties. 
         [0014]    Consistent with one aspect of the invention, document access in a computer is controlled by rendering at least a portion of a first document for display on a computer display, with the first document including a link for use in navigating to a second document. A determination is made as to whether the second document is trusted prior to a user attempt to navigate to the second document via the link in the first document, and user navigation to the second document via the link in the first document is deterred if the second document is determined to not be trusted. 
         [0015]    These and other advantages and features, which characterize the invention, are set forth in the claims annexed hereto and forming a further part hereof. However, for a better understanding of the invention, and of the advantages and objectives attained through its use, reference should be made to the Drawings, and to the accompanying descriptive matter, in which there is described exemplary embodiments of the invention. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0016]      FIG. 1  is a block diagram of a computer system consistent with the invention. 
           [0017]      FIG. 2  is a block diagram of an exemplary hardware and software environment for a computer from the computer system of  FIG. 1 . 
           [0018]      FIG. 3  is a flowchart illustrating a main routine executed by the browser of  FIG. 2 . 
           [0019]      FIG. 4  is an exemplary HTML syntax for a trusted link tag consistent with the invention. 
           [0020]      FIG. 5  is an exemplary HTML syntax for a trust exclude tag consistent with the invention. 
           [0021]      FIG. 6  is a flowchart illustrating the display document routine referenced in  FIG. 3 . 
           [0022]      FIG. 7  is a flowchart illustrating the test link routine referenced in  FIGS. 3 and 6 . 
           [0023]      FIG. 8  is a flowchart illustrating the process trust depth routine referenced in  FIG. 7 . 
           [0024]      FIG. 9  is a flowchart illustrating the compute CRC routine referenced in  FIG. 8 . 
       
    
    
     DETAILED DESCRIPTION 
       [0025]    The embodiments described hereinafter may be used to minimize the risks associated with linking to third-party documents by analyzing and monitoring the trustworthiness of linked-to documents prior to user attempts to navigate to linked-to documents from a source document. In the illustrated embodiment, each document is identified by a storage location at which the document is stored, with links defined between documents identifying the storage locations of linked-to documents. A storage location may be internal to a workstation or other single-user computer, e.g., a filename and/or path for a particular document or file stored thereon. In the alternative, a storage location may be external to a workstation, e.g., as stored on a network server, e.g., over a private LAN or WAN, or over a public network such as the Internet. As such, the storage location may be identified by an address in the form of a Uniform Resource Locator (URL), the format of which is well known in the art. However, it should be appreciated that the invention may also be used in connection with other storage location identification formats. 
         [0026]    Also, in the illustrated embodiment, documents are formatted in Hypertext Markup Language (HTML), a predominant format used for Internet documents. However, it should be appreciated that the invention may also be utilized with other document and file formats as well, including both text-based and non-text based documents, files, database records, etc., which will collectively be referred to hereinafter as “documents.” A subset of documents are referred to herein as third-party documents insofar as the contents of such documents are controlled by entities other than an entity controlling a document that provides links to such third-party documents. 
         [0027]    As will be discussed in greater detail below, “trust” for a document is determined based upon any number of metrics that individually or collectively infer the degree of confidence that a particular document still contains acceptable content in the interim since the trustworthiness of the document was last positively verified. 
         [0028]    One manner of determining trust for a document is based upon detected change in the content of the document, e.g., by comparing the current content of the document with the last known content thereof. Such a comparison may be implemented, for example, via a direct comparison, or may be estimated through the use of checksums, timestamps, or the like. 
         [0029]    Another manner of determining trust for a particular document is based upon detected change in the content of one or more documents linked directly or indirectly to that document. Moreover, in any instance where the content of a document is being analyzed for change, it will be appreciated that any portion of the document may be explicitly included or excluded from the analysis, e.g., so that change in a document that indicates possible lack of trustworthiness may be limited to select passages in the document. 
         [0030]    Yet another manner of determining trust is based upon the amount of time that has passed since the document was last verified to be trustworthy. It will be appreciated by one of ordinary skill in the art having the benefit of the instant disclosure that other manners of determining the trustworthiness of a document may also be used in the alternative. 
         [0031]    Prior to discussing specific embodiments of the invention, a brief description of exemplary hardware and software environments for use therewith is provided. 
       Hardware and Software Environment 
       [0032]    Turning to the Drawings, wherein like numbers denote like parts throughout the several views,  FIG. 1  illustrates a computer system  10  consistent with the invention. Computer system  10  is illustrated as a networked computer system including one or more client computers  12 ,  14  and  20  (e.g., desktop or PC-based computers, workstations, etc.) coupled to server  16  (e.g., a PC-based server, a minicomputer, a midrange computer, a mainframe computer, etc.) through a network  18 . Network  18  may represent practically any type of networked interconnection, including but not limited to local-area, wide-area, wireless, and public networks (e.g., the Internet). Moreover, any number of computers and other devices may be networked through network  18 , e.g., multiple servers. 
         [0033]    Client computer  20 , which may be similar to computers  12 ,  14 , may include a central processing unit (CPU)  21 ; a number of peripheral components such as a computer display  22 ; a storage device  23 ; a printer  24 ; and various input devices (e.g., a mouse  26  and keyboard  27 ), among others. Server computer  16  may be similarly configured, albeit typically with greater processing performance and storage capacity, as is well known in the art. 
         [0034]      FIG. 2  illustrates in another way an exemplary hardware and software environment for an apparatus  30  consistent with the invention. For the purposes of the invention, apparatus  30  may represent practically any type of computer, computer system or other programmable electronic device, including a client computer (e.g., similar to computers  12 ,  14  and  20  of  FIG. 1 ), a server computer (e.g., similar to server  16  of  FIG. 1 ), a portable computer, a handheld computer, an embedded controller, etc. Apparatus  30  may be coupled in a network as shown in  FIG. 1 , or may be a stand-alone device in the alternative. Apparatus  30  will hereinafter also be referred to as a “computer”, although it should be appreciated the term “apparatus” may also include other suitable programmable electronic devices consistent with the invention. 
         [0035]    Computer  30  typically includes at least one processor  31  coupled to a memory  32 . Processor  31  may represent one or more processors (e.g., microprocessors), and memory  32  may represent the random access memory (RAM) devices comprising the main storage of computer  30 , as well as any supplemental levels of memory, e.g., cache memories, non-volatile or backup memories (e.g., programmable or flash memories), read-only memories, etc. In addition, memory  32  may be considered to include memory storage physically located elsewhere in computer  30 , e.g., any cache memory in a processor  31 , as well as any storage capacity used as a virtual memory, e.g., as stored on a mass storage device  35  or on another computer coupled to computer  30  via network  36 . 
         [0036]    Computer  30  also typically receives a number of inputs and outputs for communicating information externally. For interface with a user or operator, computer  30  typically includes one or more user input devices  33  (e.g., a keyboard, a mouse, a trackball, a joystick, a touchpad, and/or a microphone, among others) and a display  34  (e.g., a CRT monitor, an LCD display panel, and/or a speaker, among others). 
         [0037]    For additional storage, computer  30  may also include one or more mass storage devices  35 , e.g., a floppy or other removable disk drive, a hard disk drive, a direct access storage device (DASD), an optical drive (e.g., a CD drive, a DVD drive, etc.), and/or a tape drive, among others. Furthermore, computer  30  may include an interface with one or more networks  36  (e.g., a LAN, a WAN, a wireless network, and/or the Internet, among others) to permit the communication of information with other computers coupled to the network. It should be appreciated that computer  30  typically includes suitable analog and/or digital interfaces between processor  31  and each of components  32 ,  33 ,  34 ,  35  and  36  as is well known in the art. 
         [0038]    Computer  30  operates under the control of an operating system  38 , and executes or otherwise relies upon various computer software applications, components, programs, objects, modules, data structures, etc. (e.g., browser  40 , among others). Moreover, various applications, components, programs, objects, modules, etc. may also execute on one or more processors in another computer coupled to computer  30  via a network  36 , e.g., in a distributed or client-server computing environment, whereby the processing required to implement the functions of a computer program may be allocated to multiple computers over a network. 
         [0039]    In general, the routines executed to implement the embodiments of the invention, whether implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions will be referred to herein as “computer programs”, or simply “programs”. The computer programs typically comprise one or more instructions that are resident at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause that computer to perform the steps necessary to execute steps or elements embodying the various aspects of the invention. Moreover, while the invention has and hereinafter will be described in the context of fully functioning computers and computer systems, those skilled in the art will appreciate that the various embodiments of the invention are capable of being distributed as a program product in a variety of forms, and that the invention applies equally regardless of the particular type of signal bearing media used to actually carry out the distribution. Examples of signal bearing media include but are not limited to recordable type media such as volatile and non-volatile memory devices, floppy and other removable disks, hard disk drives, magnetic tape, optical disks (e.g., CD-ROM&#39;s, DVD&#39;s, etc.), among others, and transmission type media such as digital and analog communication links. 
         [0040]    In addition, various programs described hereinafter may be identified based upon the application for which they are implemented in a specific embodiment of the invention. However, it should be appreciated that any particular program nomenclature that follows is used merely for convenience, and thus the invention should not be limited to use solely in any specific application identified and/or implied by such nomenclature. 
         [0041]    Those skilled in the art will recognize that the exemplary environments illustrated in  FIGS. 1 and 2  are not intended to limit the present invention. Indeed, those skilled in the art will recognize that other alternative hardware and/or software environments may be used without departing from the scope of the invention. 
       Trust-Based Link Access Control 
       [0042]    An exemplary implementation of the invention in an Internet-based computing environment is discussed in greater detail hereinafter, specifically in the context of analyzing the trustworthiness of HTML-compatible documents referenced via URL&#39;s identifying storage locations on the Internet or other form of network. In the exemplary implementation, analysis of the trustworthiness of documents is performed at the client side, i.e., within the browser. In other implementations, however, such analysis may be performed at the server side, such that documents are modified and transmitted to users with the trustworthiness of the links therein analyzed and modified as appropriate. Therefore, while the invention will be discussed hereinafter in the context of a client-side browser application, the invention is not limited to this particular implementation. 
         [0043]      FIG. 3 , in particular, illustrates a main routine  50  executed by browser  40  of  FIG. 2 . Upon startup of the browser, main routine  50  performs routine initialization in block  52 , which is well known in the art. After initialization, an event-driven loop is initiated in block  54 . In the event-driven loop, events directed for the web browser, e.g., user input, receipt of downloaded data, etc., are passed to the browser via an event protocol, as is well known in the art. Other programming models may be utilized in the alternative. 
         [0044]    In response to reception of an event, control is passed to blocks  56 - 60  to decode and handle each event as appropriate. Block  56  detects a display document event, which may be generated, for example, in response to a request to display a stored document, e.g., via a display refresh or downloading of a new document. The display document event is handled by passing control to a display document routine  62 , discussed in greater detail below in connection with  FIG. 6 . 
         [0045]    Returning to block  56 , if the event is not a display document event, control passes to block  58  to determine whether the event is a select link event. If the event is not a select link event, however, control passes to block  60  to handle the event in a conventional manner. 
         [0046]    Returning to block  58 , a select link event may be generated, for example, in response to user selection of a hypertext link in a displayed document, as well as selection of a linked image, selection of a bookmark, or direct input of a URL into an address bar, among other operations. In response to a select link event, control passes to block  64  to determine first whether the selected link is a trusted link. In the illustrated implementation, determination of whether a link is a trusted link is performed by analyzing the HTML code in the document associated with the link to determine the extent to which the document has changed since the last time the document was confirmed trustworthy. 
         [0047]      FIG. 4 , for example, illustrates one possible syntax for an anchor or link tag utilized to represent a link in an HTML environment. The syntax represented in  FIG. 4  represents an extension of the HTML standard to include a number of additional fields suitable for implementing trusted links consistent with the invention. 
         [0048]    For example, a conventional HTML anchor tag includes a location identifier represented by a URL included in an HREF field. The text to display and thereby provide a display representation of the link that may be selected by the user, is typically incorporated between opening and closing anchor tags having the format “&lt;A . . . &gt;” and “&lt;A&gt;”. 
         [0049]    A conventional HTML anchor tag may be extended to support trusted links by incorporating one or more additional fields, herein denoted by labels starting with “trust”. One extension is a TRUSTDATE field, which is used to supply a time stamp representing the last time the document was updated as of the last time the document was determined to be trustworthy. Another extension is a TRUSTCRC field, which provides a checksum, e.g., a cyclical redundancy checksum (CRC) value, used to represent the content of the document referenced by the tag. It will be appreciated, however, that other checksums, as well as direct comparison of the content of a document or any portion thereof, may be used in lieu of a CRC. 
         [0050]    A TRUSTIMAGES field provides a flag that indicates whether or not image data from a document is to be included within any CRC calculation. A TRUSTDEPTH field specifies a number of levels (chains of links) below the specified URL to check and include in the trustworthiness determination for a linked document. 
         [0051]    A TRUSTDOMAINONLY field provides a flag used in connection with the TRUSTDEPTH field to tell the web browser whether or not to include links that are not in the same domain as the URL targeted by the tag. By excluding links that are not in the same domain, it may be anticipated that only the links to documents within the same website will be analyzed for change. 
         [0052]    A TRUSTLIST field provides an alternative to the TRUSTDEPTH field, enabling a document author or certification authority to specify a list of URL&#39;s to be specifically included in determining whether a particular linked document is trustworthy. The TRUSTLIST field provides a list of URL&#39;s and associated CRC&#39;s and/or dates to be compared against each URL to determine if the document at any such URL has been changed. In the alternative, the TRUSTLIST field may simply provide a list of URL&#39;s to include in a group CRC calculation for the linked document. 
         [0053]    A TRUSTDISPLAY field enables the selection of different deterrent activities performed by the browser in response to the detection of an untrusted link. One possible indication in the field is that of deactivating a link, as represented by the “no link” value, whereby the text of the link will be displayed but the link will not be capable of being selected by a user. Another possible value is a “warning” value, whereby a user will be warned via a dialog box or other user interface mechanism that a link that a user is attempting to navigate to is untrusted. Another possible value is represented by the “prevent” value, where the user is warned that a link is untrusted, and is prevented from navigating the linked document in response to user selection of the link. 
         [0054]    Additional deterrent factors may also be utilized, as will become more apparent below. For example, an untrusted link may have a warning indicator or other form of highlighting associated therewith to indicate the untrusted status (and/or the trusted status) of a link. For example, color, icon, patterns, sounds, bubble text, etc., may be used to represent or highlight an untrusted link. Any of these deterrent operations may be used individually or in combination with one another. Moreover, rather than incorporating such parameters within a link tag, selection of such deterrent operations may be selected via local settings, cookies, etc., by either the document author or the local user. User settings may also be changeable locally upon the input of suitable authorization, e.g., so that parents could change the deterrent operations performed for their children. 
         [0055]    As shown in  FIG. 5 , an additional type of tag, referred to herein as a TRUSTEXCLUDE tag, may also be used to omit a region of document content in response to the trustworthiness of any number of links in the document. As shown in  FIG. 5 , such a tag may include a URLLIST field that provides a list of URL&#39;s and associated CRC&#39;s and/or dates used to determine whether a link and its associated content should be omitted from the display representation of the document. Starting and ending TRUSTEXCLUDE tags are placed around a region of content to be selectively displayed. In response to the determination of untrustworthiness of any of the listed URL&#39;S, the entire region is excluded from the display. 
         [0056]    Any of the above fields may be used separately or in combination with the other fields. Also, it will be appreciated that in non-HTML environments, other manners of representing both TRUSTEXCLUDE regions and the trusted link parameter information may be used in the alternative. Selection of such alternate data storage formats would be well within the ability of one of ordinary skill in the art having the benefit of the instant disclosure. 
         [0057]    Returning to  FIG. 3 , determination of whether a link is a trusted link in block  64  may be performed in a number of manners, e.g., by detecting any of the enhanced fields discussed in connection with  FIG. 4 . If a link is determined to not be a trusted link, control may pass to block  66  to navigate to the link in a conventional manner. However, if the link is determined to be a trusted link, control instead passes from block  64  to block  68  to call a test link routine and determine whether the link is trustworthy. If the link is determined to be trustworthy, control passes directly to block  66  to navigate to the link. If, however, the link is found not to be trustworthy, control passes to block  70  to determine whether the TRUSTDISPLAY field associated with the link is set to “warning”. If so, control passes to block  72  to display a warning dialog box to the user, prior to passing control to block  66  to navigate to the link. 
         [0058]    Typically, display of a warning may be in the form of a dialog box which must be dismissed prior to permitting navigation to the link. In addition, it may be desirable to permit the user to cancel navigation to the link upon display of the warning. 
         [0059]    Returning to block  70 , if the TRUSTDISPLAY field is not set to “warning”, it is assumed that the TRUSTDISPLAY field is set to “prevent”, as it would not be possible in the main routine as illustrated herein for the link to be activated if the “no link” value is set for the TRUSTDISPLAY field. As such, control passes from block  70  to block  74  to notify the user that the link is not allowed. Navigation to the link is further prohibited by bypassing block  66 , and returning directly to block  54 . In other embodiments, no prior notification to the user may be provided—only the navigation to the link may be prohibited. 
         [0060]      FIG. 6  illustrates display document routine  62  in greater detail. Routine  62  begins in block  80  by scanning through the document to process every TRUSTEXCLUDE section defined therein. A TRUSTEXCLUDE section is defined by starting and ending tags having the format described above in connection with  FIG. 5 . For each such section, control passes to block  82  to process every entry in the URLLIST field provided therein. For each such entry, control passes to block  84  to test the CRC or date (as provided in the URLLIST) against that of a current version of the document stored at the URL specified in the entry. Typically, block  84  incorporates retrieval of at least a timestamp or a CRC, or the entire document, for the URL provided in the list. Based upon this test, block  86  determines whether the document has changed. If not, control passes to block  82  to process the next entry in the URLLIST. If, however, the document has been determined to have changed, control passes to block  88  to exclude the section between the TRUSTEXCLUDE tags from the rendered page, e.g., by deleting the document content associated with the section from a temporary version of the HTML source document. Upon completion of block  88 , control passes to block  80  to process additional TRUSTEXCLUDE sections in the document. 
         [0061]    Once every TRUSTEXCLUDE section in the document has been processed, control passes to block  90  to process every anchor tag in the document. For each such anchor tag, control passes to block  92  to determine whether the anchor tag is a trusted link. If not, control returns to block  90  to process the next anchor tag. 
         [0062]    If, however, the link is a trusted link, control passes to block  68  to call the test link routine, and thereby determine if the document referenced by the link has changed, and is therefore determined to be untrustworthy. 
         [0063]    If the test link routine returns a “passed” result, control returns to block  90  to process additional anchor tags. If, however, the test link routine returns a “failed” result, control passes to block  94  to determine whether the TRUSTDISPLAY field is “no link” value. If not, control passes to block  95  to optionally add a warning indicator to the link display representation, e.g., a unique color, icon, etc., that will indicate to a user that a link is untrustworthy. Control then returns to block  90 . 
         [0064]    Returning to block  94 , if the TRUSTDISPLAY field is set to “no link”, control passes to block  96  to disable the link, but include the linked text between the opening and closing anchor tags for the trusted link. Disabling the link is typically performed by removing the anchor tags from the temporary version of the document, leaving the linked text therebetween within the document. 
         [0065]    Returning to block  90 , once every anchor tag has been processed, control passes to block  98  to render the page with the remaining document content—i.e., with any excluded sections and anchor tags associated with untrusted links removed or omitted as appropriate. Rendering a page based upon HTML-based content is an operation that is well known in the art, and will not be discussed in further detail herein. Upon completion of rendering of the page, routine  62  is complete. 
         [0066]      FIG. 7  illustrates test link routine  68  in greater detail. Routine  68  begins in block  100  by determining whether a TRUSTLIST field is specified for the trusted link. If so, control passes to block  102  to test each URL in the list to determine if any linked document in the list has changed, i.e., by analyzing the CRC or date specified in the URLLIST. 
         [0067]    Block  104  then determines whether any such referenced document has changed, and based upon the result, returns either a “failed” or “passed” indication upon termination of the routine. 
         [0068]    Returning to block  100 , if a TRUSTLIST field is not specified, control passes to block  106  to determine whether a TRUSTDEPTH value is specified—i.e., whether a non-zero value is provided in the TRUSTDEPTH field in the trusted link tag. If not, only the document referenced in the trusted link is tested in block  108 , to determine whether the document has changed, and is therefore not trustworthy. Control then passes to block  110  to determine whether the URL has changed, returning either a “failed” or “passed” result based upon the changed status of the document. 
         [0069]    Returning to block  106 , if a TRUSTDEPTH value is specified, control passes to a process trust depth routine  112 , which returns either a “passed” or “failed” result that routine  68  forwards to the calling routine as the response to the test link operation. 
         [0070]      FIG. 8  illustrates process trust depth routine  112  in greater detail, which operates by calling a compute CRC routine  120 , passing as input to the routine the URL specified in the anchor tag and the current depth specified in the anchor tag. The result returned by routine  120  is a CRC that incorporates the CRC of the current document as well as any child documents based upon the settings specified in the anchor tag, as will be discussed in greater detail below. Based upon this computed CRC, block  122  compares the computed CRC with that specified in the TRUSTCRC field of the anchor tag, returning a “passed” value if the CRC&#39;s match, and returning a “failed” value if they do not. 
         [0071]      FIG. 9  illustrates compute CRC routine  120  in greater detail, which operates as a recursive routine to process each link defined in the tree of links emanating from a linked document referenced at the anchor tag. Routine  120  begins in block  130  by calculating a CRC for the document referenced at the input URL to the routine. A local variable, referred to as SAVED CRC, is initialized with the calculated CRC value in block  132 . Next, block  134  determines whether the depth variable provided as input to the routine is greater than zero. If so, control passes to block  136  to process each link in the document referenced at the input URL. 
         [0072]    For each such link, control passes to block  138  to determine whether the TRUSTDOMAINONLY flag for the anchor is set, indicating that only URL&#39;s from the same domain as the primary URL from the anchor tag should be incorporated into the CRC calculation. 
         [0073]    Assuming first that the flag is not set, control passes to block  120  to recursively call the compute CRC routine  120 , providing the URL specified in the currently-processed link and a value equal to the depth value input to routine  120  less one as the input to the recursive function call. Upon completion of the recursive call, control then passes to block  140  to add the CRC returned from the function call to the local SAVED CRC value initialized in block  132 . Control then returns to block  136  to process each additional link in the document. Once all such links have been processed, control is passed to block  144  to return the SAVED CRC value as the result of the routine. 
         [0074]    Returning to block  138 , if the TRUSTDOMAINONLY flag is set, control passes to block  142  to determine whether the domain for the link currently being processed is the same as that specified in the anchor. If not, control returns to block  136  to process the next link in the document. If, however, the domains match, control passes to block  120  to recursively call the compute CRC routine. 
         [0075]    Returning next to block  134 , if the depth input to the CRC routine is not greater than zero, the CRC for the document itself is returned by passing control directly to block  144 . As such, it will be appreciated that recursive calls to routine  120  will result in the CRC for each document linked within the selected depth in the overall calculation of the CRC for the document referenced in the anchor tag. Other manners of calculating the CRC for a tree of documents may be used in the alternative. 
         [0076]    As discussed above, an optional TRUSTIMAGES field may be incorporated into a trusted link to indicate whether or not image data should be incorporated into CRC determinations. As such, the CRCTEST performed in blocks  84 ,  102 ,  108  and  130  of  FIGS. 6 ,  7  and  9 , may correctively incorporate or exclude image data based upon the result of the anchor tag contents. Moreover, a like algorithm may be utilized to specifically include or exclude portions of a particular document, e.g., so that only regions considered to be important will be incorporated into a CRC calculation. Other manners of modifying a CRC based upon the type of data may also be used in the alternative. 
         [0077]    Various modifications may be made to the illustrated embodiments without departing from the spirit and scope of the invention. For example, different levels of trust may be defined and reported to users, e.g., to distinguish between trustworthiness based upon changes to a document, changes to documents referenced by that document, expiration of a document, changes in a particular region of a document, etc. In addition, determination of whether a document is trustworthy based upon a CRC or date may be selectable based upon user settings. 
         [0078]    It will also be appreciated that some form of verification process may also be supported from the server side, in association with author or publisher of a particular document incorporating trusted links. For example, an automated system whereby an author or publisher could analyze links and update the CRC, date or other parameters within the links may be provided, and would be well within the ability of one of ordinary skill in the art having the benefit of the instant disclosure. 
         [0079]    In addition, trustworthiness may be based on expiration of a document, i.e., by comparing the timestamp with the current time, rather than the timestamp of a previous version of a document. It may also be desirable to provide trusted control over bookmarks, as well as to indicate the trustworthiness of a document in association with selection of a bookmarked document. Also, as discussed above, it may be desirable to perform trustworthiness testing prior to serving a document to a user, whereby untrusted links could simply be passed to users as deactivated or deleted links in the HTML text, thus requiring no modification to a conventional browser to view documents processed in such a manner. It will also be appreciated that trustworthiness checks may be performed in a background process prior to or during display of a document, and prior to actual user attempts to navigate to a document referenced by a trusted link. 
         [0080]    Other modifications will be apparent to one of ordinary skill in the art. Therefore, the invention lies in the claims hereinafter appended.