Systems and methods for controlling access to data maintained in a repository

[0002] U.S. patent application, Ser. No. 09/406,197 filed on the same date as this application by the same inventor.

[0003] Not applicable.

[0004] Not applicable.

[0005] This invention relates to systems and methods for storing, controlling and monitoring of digital data retrieval and presentation, and more particularly to processing of digital data to facilitate such.

[0006] With the popularity and economic frugality of disseminating information over wide area or local area networks (“WANALAN”) continually expanding, designers of data repositories existing on such networks have employed various techniques to control access by their clients or users to the content provided in such repositories. In many instances, prior art content access by any particular client is an all-or-nothing affair. If a client submits the correct credentials or originates the connection from a specific locale, the repository will provide whatever content is available. If the client fails to identify him or herself properly, the repository denies all content. In the nothing response, the presenter loses the ability to display any content, potentially losing a client. In the all response, the presenter is faced with costly and sometimes impractical solutions for determining precisely what sensitive content was accessed, downloaded or viewed and by whom. For those repository applications that do qualify content after user validation, most request additional forms of identification, generally another all-or-nothing approach applied to a sub-set of the data or, they contain client/server cooperation dependencies in order to implement security. In some cases, additional hardware or physical discontinuity is employed to regulate content retrieval but this is highly restrictive and can be financially out of reach for some.

[0007] When such prior art repositories exist on networks that employ governmental or industrial data classifications, access infractions pose an even more serious threat to the well being of the community that relies on the integrity and exclusiveness of accessible data. In situations as these, multiple users may have sufficient authority to pass through access control but may lack the need to know such information although they are qualified from a permission standpoint, to view it. Environments that process extremely sensitive data are typically restricted to one repository with no external or shared access allowed. This is the outer fringe of content control requiring a major commitment from the presenter in order to be implemented.

[0008] To illustrate some of the problems previous prior art content control techniques have encountered; a cursory look at some of the better-known methods is required. The first of these, well-known as a “cookie approach”, requires the client to accept a data structure commonly referred to as a “cookie” from the repository and further, not modify or delete it once it has been accepted. The repository then requires the client to return the cookie for each request and based on some privilege value assigned to the cookie, permits content to be transmitted to the client. This method assumes that the client has the capacity to store the cookie, something not always possible with connections that do not possess non-volatile memory. Because the cookie is connection oriented rather than content oriented, it is difficult to control the access to specific items contained within the returned content.

[0009] The implementation of a prior art certificate process typically requires the participation of a third party to inspect and guarantee the certificate and data content issued by the repository. This type of control is for the benefit of the client in that it provides an assurance that the content originated from the repository. It provides little or no dissemination control from a repository standpoint, especially in open network environments such as the Internet.

[0010] Using a prior art re-direction method, the presenter instructs the user's access mechanism to form a connection with a repository that is different from the initial. Although this method addresses content control, the method is weak for several reasons. It assumes the presenter has another location to which the connection can be re-directed and once this location is known, protecting it becomes as much of an issue as protecting the original site. Similar to cookies, re-direction is a connection-oriented mechanism and not an item oriented one.

[0011] Another common, prior art approach is data censure. In this method, the data content is examined for specific occurrences of certain terms or values. If the examination process encounters a censured term or value within the response of the repository, the content is denied to the client. When repository designers incorporate censure methods into content control schemes, problems multiply rather subside. Issues arise as to what standard should be applied for measuring the level of censure as well as how to regulate and administer those that apply the measures. In some cases, filtered material that should be available is excluded solely because it leads to irrelevant or unauthorized repositories. Censure may also have the undesired side effect of preventing proper data synchronization. Specifically, data that is censured may age or update at a rate different from that of its parent source. Lastly, censure methods are not discrete. By not discrete it is meant that prohibited values may innocuously occur in perfectly valid content; however, because the censure mechanism cannot distinguish the semantic difference, the content would be denied due, to the physical presence of the prohibited data.

[0012] What all of these previous prior art techniques share is the attribute that regulated content is assembled into a fixed form prior to its availability. This restriction requires multiple forms of the same content, with alterations to each construct made based on the level of sensitivity. This leads to the duplication of many elements used to implement the content since no mechanism exists to dynamically replace only the sensitive portions at the time of the request. With duplication, there are increased cost and service requirements.

[0013] It should be noted that other prior art access control techniques such as secure sockets, encryption, firewalls and proxy servers fall into separate categories distinct from those methods described above. Secure sockets and encryption are well-known methods that protect content during transmission while firewalls and proxy servers are well-known methods that limit direct connections with the repository.

[0014] In a protected transmission, anyone may view the connection but will lack the capacity to decipher the content. The issue then becomes controlling what content is exchanged to a privileged client rather than how it is protected during the exchange. Since encryption applies to the overall session, determining the accessibility of specific content typically requires an additional system. Again, the presenter is challenged by the same dilemma as before only now, all-or-nothing is presented over a secure channel.

[0015] By using prior art firewalls and proxy servers as software-based gateways, the repository itself is protected from unauthorized access but the ability of these technologies to selectively assign content to authorized users is relatively nil or non-existent.

[0016] All of the present prior art access control schemes for data on a repository fail to provide a simple, effective means to dynamically assign and assemble responses to users of no, equal, or disparate privilege at the time of the request.

[0017] Systems and methods are described for controlling the access, assemblage and presentation or transmission of data maintained in a computer system repository. The present invention has particular application to computer based servers that store or maintain data having varying permission, security or sensitivity requirements and which servers provide access to such data to a plurality of clients.

[0018] The present invention overcomes the deficiencies of prior schemes for controlling content dissemination by allowing the repository to dynamically construct responses. This is attained by including passive information, herein labeled as a “forresta”, within the user's request. Using the functionality provided by the forresta, each of the client requests and each of the server responses are individualized. This individualization prevents a client from obtaining a response requiring an authority level not held by the requestor or is intended for another.

[0019] This invention implements two information structures within a computer system. These structures are denoted herein as a “session node” and a “build code sequence”. A unique session node exists at the repository for each client requesting controlled content and in conjunction with the forresta, implements the determination of applicability of content to a client. Construction of content appropriate for a particular client is achieved using one or more build code sequences, whose selection is dynamic and can vary with each client request.

[0020] FIG. 1 is a block diagram. illustrating an exemplary environment used by the present invention. The relationships between the client, the repository and the content are shown.

[0021] FIG. 2 is a block diagram depicting the request/response relationship established for a client with the repository.

[0022] FIG. 2A is an exploded block diagram of elements from FIG. 2. It illustrates a greater level of detail for components of a forresting type request issued by a client.

[0023] FIG. 3 is a block diagram of the major components of the Data Access Control (“DAC”) process of the current invention. The input and output of a request and a response through this process is also shown.

[0024] FIG. 4 is a block diagram illustrating the major components of a privileged response constructed by the method of the present invention.

[0025] FIG. 5 is a block diagram depicting the structure of data as provided by the designer of the repository and its reorganization into a data structure used by the method and process of the current invention.

[0026] FIG. 5A is an exploded block diagram of elements from FIG. 5. It illustrates a greater a level of detail of components created by the repository designer and their modification into a substituted form by the method and process of the current invention.

[0027] FIG. 6 is a diagram depicting the assignment of values to form the identities of two data structures used by the method and process of the current invention.

[0028] FIG. 7 is a block diagram illustrating data structures used by the method and process of the current invention that allow for the content of the repository to be treated in a dynamic fashion.

[0029] FIG. 8 is a block diagram depicting the conversion of one data structure to another by the method and process of the current invention during the assignment of privilege information to the content by the repository designer.

[0030] FIG. 9 is a block diagram illustrating the required manipulation of values in order to form a forresta value.

[0031] FIG. 10 is a block diagram of the data structures used by the method and process of the current invention to maintain information about clients making requests of the repository.

[0032] FIG. 11 is a block diagram depicting the relationship of generated content to a client display that is sub-divided into separate display areas.

[0033] In the following detailed description of the systems and methods of the present invention, numerous specific details of an exemplary embodiment are set forth in order to provide a thorough understanding of the systems and methods of the present invention. It will be obvious to those skilled in the art to which this invention pertains that the present invention may be practiced without these specific details. In other instances well-known methods, procedures, components and circuits have not been described in detail to avoid unnecessarily obscuring aspects of the present invention.

[0034] FIG. 1 is a simplified diagram of an exemplary system embodying this invention. As shown in FIG. 1, the system includes at least one or a plurality of requestors that are represented in the diagram by a user's client computer 100. A client computer 100 is operated by a user and the terms: “client”, “user”, and “requestor” are used interchangeably herein with equivalent meaning. A data repository server computer 102 with non-volatile random access storage 103 is used in implementing the data repository with which each client computer 100 will exchange data. The server computer 102 connects with each client 100 in the system using some form of a communications link 101, typically implemented using a network. The server computer 102 connects with the random access storage 103 using some form of a communications link 112, typically implemented using a dedicated wiring arrangement. However, data transfer over a network communications link is also possible. The server computer 102 contains a prior art process that acts as the operating system 113, a prior art communication process 104 for receiving and transmitting data over the communications link 101, a prior art process 105 for authenticating each user 100 and defining their authority level; and, the data access control (“DAC”) process 106 of the present invention.

[0035] The random access storage 103 may be composed of one or more physical units remotely placed or co-located with the server 102. The storage device 103 is occupied by sensitive data 107, non-sensitive data 108 and external data 109. As a whole, data maintained on the storage device 103 is generically referred to as “content”. Sensitive 107 and non-sensitive data 108 whose creation, retrieval, modification or deletion is controlled by the method and process of the present invention is collectively referred to as “governed content” 110. Sensitive data 107 requires the client 100 to have an authority level issued by the user permission authority authentication process 105 in order to receive it while non-sensitive data 108 does not. External data 109 is all other data present on the storage device 103 that is not governed content 110.

[0036] With respect to FIG. 2, clients 100 (FIG. 1) may make one or more requests 200 of the server to have information or data content returned to them. Responses 201 returned to a client 100 when any parts of which are governed 110 is termed a “privileged response” 203. A response 201 containing only external data 109 is termed a “flat response” 202. In this embodiment of the present invention, both privileged 203 and flat 202 responses are computer data files structured using the Hypertext Markup Language (“HTML”) format. HTML is a well-known computer programming language that allows a computer to process and render data received from another computer. The HTML coding as used by the embodiment of the present invention may reference data represented using other well-known or prior art formats including those that represent visual, textual, audible or programming information.

[0037] In this embodiment of the present invention, the client 100 (FIG. 1.) uses the prior art process commonly referred to as a “browser” 111 to transmit requests 200 (FIG. 2.) and receive responses 201 across the link 101. Browser communication employs a prior art process that is also represented within communication process 104 that facilitates client/server communication using the Hypertext Transfer Protocol (“HTTP”), a well-known method of transmitting digital information. A client request 200 that is sent in this manner is assumed to be in one of the well-known representations of a Uniform Resource Locator (“URL”). The URL is an adopted standard naming convention, which encompasses several sub-classes of location names presently including HTTP. Once a client 100 has established HTTP protocol communications with the server 102, requests 200 may alternatively be expressed as hyperlink references as allowed by the syntax of HTML.

[0038] With the receipt of a request 200 (FIG. 2) by communication process 104 (FIG. 1), the authority process 105, through its own method, may immediately require verification of the client's 100 right to communicate with the server 102. This action can occur independently of the method of the present invention. The method of the authority process 105 can also defer user verification until a later time. Instances of the authority process 105 interacting with the DAC 106 of the present invention are described later.

[0039] In general, the interpretation of a request 200 (FIG. 2) by the communications process 104 (FIG. 1) determines the receiving process resident on the server 102. This is the means by which the DAC 106 is notified when a request 200 destined for it arrives at the server 102. The t communications process 104 uniquely identifies each request 200 with its client 100 either by explicit value or by thread of process operation and forwards any associated argument list as input arguments to the DAC 106.

[0040] When the request 200 (FIG. 2) does not specify the DAC 106 (FIG. 1) as the intended recipient, it is denoted as being “flat”. A response 202 to a flat request 200 is created by either IS communications process 104 or another prior art procedure. A flat type request 200 always receives external data 109 as the content of a response 201 from a repository server 102 that maintains governed content 110. A request 200 (FIG. 2) that is directed to the DAC 106 is denoted herein as a “forresting type” request 204. To retrieve governed content 110 the client 100 must at some point, make a flat type request 200 for content that contains at least one forresting type request 204 that the client 100 may subsequently invoke. A forresting type request 204 must be executed before any governed content 110 can be delivered as a response 201.

[0041] The content of the first response 201 (FIG. 2) that contains a forresting type request 204 is denoted using the common term “default page”. The location of the default page on the storage device 103 (FIG. 1) is made known to the communications process 104 by the repository designer. This allows the default page to be retrieved and transmitted to the client 100 by the communication process 104 without executing any portion of the DAC 106. This means that the default page is always considered a flat type response 202 derived from external data 109. The retrieval and transmission of the default page is a well-known, common operation for communications processes 104 that implement HTTP and provide support for data represented using CML.

[0042] A request 200 (FIG. 2) using the forresting format 204 includes at least two argument values in its representation. In this embodiment of the present invention, the actual representation of this request type conforms to the syntax rules for request specification as declared by the HTTP and HTML rules of implementation. With respect to FIG. 2, an expanded view of a request 200 in the forresting format 204 is depicted in FIG. 2A. The first field is denoted as the “reference field” 205. The value of the reference field 205 identifies the recipient of the request 204. The second field and first required argument 206 is referred to as the “forresta” and the third field and second required argument 207 is referred to as the “destination”. The fourth field and optional argument 208 is any additional information not already described that is exchanged between the client 100 and the server 102. Accordingly, the forresta argument 206 contains the “forresta value” and the destination argument 207 contains the “destination value”. Within the default page, each reference 205 in a forresting format request 204 has a forresta argument 206 set to an “anonymous user” value and a destination argument 207 whose value identifies non-sensitive content 108.

[0043] Use of the term “anonymous user” in this embodiment of the present invention should not be confused with the well-known concept of an “anonymous login”, which is a general user account type established on a multi-user computer. As used herein, “anonymous” or “anonymous use?” is strictly defined as the DAC's 106 (FIG. 1) lack of authentication information for a particular client 100 as provided by the authority process 105. The explicit value of “anonymous user” is a constant that is global to all elements of the DAC 106 and in the preferred practice of the present invention is expressed as a form of numeric value zero.

[0044] With respect to FIG. 3, the DAC 106 (FIG. 1) of the present invention is further explained. The DAC 106 is sub-divided into three sub-processes. These sub-processes are the access module 300, the session module 301 and the form module 302. The access module 300 is always the recipient of a forresting type request 204 (FIG. 2). In this embodiment of the present invention, the identifier value of the access module 300 is used as the value of the reference 205. The access module 300 also contains the methods that implement interfacing to the communications 104 and user authentication 105 processes. The session module 301 maintains and processes information about each client 100 and the form module 302 generates privileged responses 203 (FIG. 2) from governed content 110. In the preferred practice of the present invention, a privileged response 203 containing governed content 110 is passed from form module 302 to access module 300 for delivery to the client 100 via communication process 104 and communication link 101.

[0045] The form module 302 (FIG. 3) constructs a response 203 (FIG. 2) to the client 100 (FIG. 1) based on the values of the forresta 206 (FIG. 2A) and destination 207 arguments. The destination argument 207 identifies the specific governed content 110 desired. The forresta argument 206 is used to determine the authority level of the request 204 and associates the request 204 with the specific client 100 that issued it.

[0046] Governed data 110 is organized as one or more instances of the general structure classification commonly known as a “file” as it pertains to non-volatile data storage on a computer. The present invention further qualifies these files as “fragments” to uniquely identify them from other files that may be co-located on the storage device 103. With respect to FIG. 4, an exemplary privileged type response 203 is shown as being composed of one or more fragments 401 arranged to form one or more pages 402.

[0047] The process and method of the present invention further qualifies fragments 401 (FIG. 4) into “types”. These types are herein named: “body”, “target”, “frame” and “artwork”. How a fragment 401 is categorized depends on the information content of the fragment 401. A “Body” type fragment contains data that is generally not modified by the method of the current invention. A “Target” type fragment contains one or more implied references 403 to other fragments 401. A “Frame” fragment contains information that when rendered or processed by the client computer 100 (FIG. 1), divides the viewing area of the display device at the client computer 100 into regions, each of which may receive governed 110 or external 109 content independent of the other regions. Lastly, an “Artwork” type fragment contains or has references to, visual, audio or other content not categorized by the other fragment types. In the event a fragment 401 contains attributes of multiple types, a hierarchy of categorization is applied in the following order listed from highest to lowest: frame, target, body and artwork.

[0048] Typically, one privileged response 203 (FIG. 2) is represented using one page 402 (FIG. 4). When the display device of the client 100 (FIG. 1) is sub-divided into multiple viewing areas, each such area can display content supplied by a unique page 402 meaning that a privileged response 203 would be composed of multiple pages. In this embodiment of the id present invention, each page 402 or set of pages is syntactically correct in its HTML form when delivered as a response 201.

[0049] With respect to FIG. 5, the designer of the repository creates pages 402 (FIG. 4) by first delineating governed content 110 (FIG. 1) into one or more “design pages” 501. Content appearance, its design, layout, required authority and organization are attributes of design pages 501. These attributes are decided solely at the discretion of the repository designer and are developed using prior art processes that are independent of this embodiment of the current invention. The design page 501 to page 402 translation begins with the reference tool 500. The reference tool 500 is a process of the current invention that is executed by the designer as a standalone method. It is typically executed on a computer that is not the server 102 (FIG. 1) and always prior to governed content 110 being placed on the storage device 103.

[0050] The reference tool 500 (FIG. 5) begins by assigning each design page 501 a unique, integer identifier denoted as its “index” 502. A table 505, denoted as the “page table”, is created by the reference tool 500 where each entry 503 represents a design page 501 by pairing its assigned name 504 and the tool generated index 502. As design pages 501 are processed, the reference tool 500 ensures that no two design pages 501 have the same assigned name 504 by comparing entries 503 made in the page table 505. If this situation occurs, the designer must correct it by altering the assigned name 504 of at least one of the design pages 501 in order to continue and complete the process. If a design page 501 contains a reference 506 to another design page 501, the assigned name 504 is used as the object 507 of the reference 506. There is no restriction on the identity of an object 507 if the object 507 does not identify a design page 501. In this instance, the reference tool 500 assumes that such an object 507 can be resolved when the request 201 (FIG. 2) of which it will be part, is processed by communications process 104 (FIG. 1).

[0051] The reference tool 500 (FIG. 5) continues by physically separating each design page 501 into one or more fragments 401 (FIG. 4). As they are created, fragments 401 are numbered uniquely with the value being placed denoted as a “fragment identifier” 508. The integer values used for identifying fragments 401 may be similar to the integer values used for identifying design pages 501 since by context a fragment identifier 508 can be distinguished from an index 502. The index identifier 502 of a design page 501 is additionally utilized as an attribute of the design page's 501 constituent fragments 401. This permits relating a fragment 401 back to the design page 501 from which it originated. Fragments 401 are numbered sequentially, preserving their placement order within the respective design page 501. Additionally, fragment numbering is assigned continuously across all design pages 501 rather than re-setting the identifier 508 to its original starting point with each new design page 501. As a design page 501 is processed by the reference tool 500, its entry 503 in the page table 505 is modified to record the fragment identifiers 508 in the requisite re-assembly order 509. This process repeats until all design pages 501 have been processed.

[0052] The reference tool 500 (FIG. 5) does not restrict the size or content of a fragment 401 (FIG. 4) and performs the mechanics of design page 501 break-up at the designer's direction. In this preferred embodiment of the practice of the current invention, the reference tool 500 ensures that a break-up of design page 501 content does not occur at a location that would split the syntax of a single HTML tag between two fragments 401. This rule is imposed for designer convenience and is not a reflection of a design limitation for the present invention. The criteria used for deciding design page 501 fragmentation are based upon the content of the design page 501. Sections of a design page 501 that require authority levels different from those required of other sections are typically broken out as fragments 401. However, the practice of the present invention is not dependent on the criteria employed to decide how fragmentation is applied to a design page 501. In accordance with this, it is possible to have an entire design page 501 be the content of a single fragment 401 that would then be the sole component of a page 402.

[0053] When all fragments 401 (FIG. 4) have been created, the reference tool 500 (FIG. 5) displays each fragment 401 to the designer identifying all content that specifies a reference 506. This is achieved by parsing the content of the fragment 401 using syntax recognition of reference type constructs. In this preferred embodiment of the practice of the present invention, syntaxes to used in the comparison by the reference tool 500 to perform reference 506 recognition are provided from two sources. The first is a pre-defined table containing all known HTML constructs in current existence at the time the present invention was embodied. The second source is from the repository designer, who can specify additional syntaxes not found in and added to the existing table using a function of the reference tool 500. For each reference 506 so identified, the designer may instruct the reference tool 500 to delete it.

[0054] With respect to FIG. 5, FIG. 5A is an exploded view of exemplary references 506 contained within a design page 501. In this embodiment of the present invention, the order or frequency of appearance of references 506 or non-reference data elements 510 within a design page 501 is arbitrary and at the discretion of the designer. For each reference 506 that is retained by the designer the tool 500 generates a “placeholder symbol” 511. This is accomplished by the reference tool 500 searching a pre-defined table of allowable substitutions. This table is denoted as the “substitution table” 512. Each entry 513 within the substitution table 512 has three values. The first value 514 is an incomplete or syntactically invalid form of the original reference 506 and there exists one, unique value for each valid reference 506 construct. This value 514 is referred to herein as a “substitution phrase”. The second value is an example of a valid reference 506 construct, minus any explicit object 507 value, and is denoted as the “parse phrase” 515. Each table entry 513 is uniquely enumerated and the assigned number is referred to as the “substitution index” 516. Comparing the syntax of the reference 506 to each parse phrase 515 locates the substitution index 516 of the specific entry 513. If the object 507 specifies a governed content object 517, the reference tool 500 locates the page table 505 entry 503 of the design page 501 by searching on the value of the object 517, which is equivalent in value to the assigned name 504. The index 502 of the design page 501 is retrieved from the entry 503 and is paired with the substitution index 516 in replacement of the original reference 506. If the object 507 specifies an ungoverned content object 518, the tool 500 creates an entry 519 in a separate temporary table 520 in which to store the object 518. The index value 521 of the table entry 519 and the table identifier 523 are paired with the substitution index 516 in replacement of the original reference 506. If the reference 506 includes other required values, the reference tool 500 appends these values at the end of the placeholder symbol 511.

[0055] As the next step, the reference tool 500 (FIG. 5) types the fragments 401 (FIG. 4) based on parse phrase 515 (FIG. 5A) content. If the fragment 401 contained no references 506, it is typed as a body fragment. If the fragment 401 had at least one reference 506 whose object 507 was identified as governed content 517, it is typed as a target fragment. If all objects 507 within the fragment 401 were. identified as ungoverned content 518, the fragment 401 is typed as artwork.

[0056] Categorization as a frame type fragment 401 (FIG. 4) is achieved by examining the content within a fragment 401 for frame constructs. In this preferred embodiment of the practice 20 of the present invention, the frame construct provided by HTML is a well-known method by which designers can sub-divide the display of a client computer 100 (FIG. 1) into separate viewable areas, known as “frames”. Data that generates the framing on a computer display contains none of the content actually displayed within each frame. This presents a difficulty in controlling the content of a frame-based response 201 (FIG. 2). In this instance, the response 201 that is sent to the client 100 might contain only a description of the frame layout. In addition, the syntax of a frame declaration can specify an object 507 (FIG. 5) that is processed by a prior art method that involves only the browser 111 and communications process 104. In this instance, should the object 507 be a governed content object 517, control of the indicated governed content 110 by the DAC 106 would not be possible. To overcome these problems, the reference tool 500, upon the detection of framing syntax within a fragment 401, marks the fragment 401 with an additional attribute. This value indicates that references 506 that specify frames are to be handled by a recursive call of the form module 302 when it is time to use the fragment 401 in the construction of a page 402.

[0057] When substitution processing is complete, and as illustrated by FIG. 6, the reference tool 500 (FIG. 5) generates a unique “build code” 600 for each fragment 401 (FIG. 4). The reference tool 500 constructs a build code 600 by combining the symbol 602 used to represent the fragment type 601, the index 502 of the parent design page 501 and the fragment identifier 508. The reference tool 500 converts the build code 600 value into a sequence of one or more symbols. The resulting symbol sequence forms the filename string 603 of the fragment 401. A filename extension 604 may be added to the string 603 to fully qualify it for use with the file storage mechanism. The filename created from the build code 600 facilitates the accessing of a fragment 401 held on the storage device 103 by the DAC 106 (FIG. 1). When all fragments 401 of a design page 501 have been assigned build codes 600, the reference tool 500 modifies the fragment assembly list 509 of the design page entry 503 by replacing each fragment index 508 with the corresponding build code 600.

[0058] With respect to FIG. 7, the page table 505 (FIG. 5) is converted by the reference tool 500 to a data structure denoted herein as the “build code list” 700. The fragment assembly list 509 with its build code 600 (FIG. 6) content creates the “build code sequence” 703 for the design page 501, which is now represented by a response page entry 701.

[0059] The next step involves the reference tool 500 (FIG. 5) constructing a “reference map” 705 (FIG. 7) for each response page entry 701 within the list 700. A reference map 705 resolves references 506 to governed content 110 (FIG. 1) for a build code sequence 703. Each reference map 705 is assigned a unique identifier 715. The identifier 715 is recorded as map id 716 in the build code sequence 703 to which the map 705 belongs. Each build code 600 (FIG. 6) within the build code sequence 703 is given an entry 713 in the reference map 705. A unique index value 706 is created for each entry 713. The index value 706 is saved as an index notation 714 of the build code 600 representation.

[0060] When all entries 701 (FIG. 7) have been reference mapped, the reference tool 500 (FIG. 5) begins the process of “fix-up”. From the build code list 700, each entry 701 is processed in turn. From each entry 701, the tool 500 inputs the build code sequence 703. Reading each build code 600 (FIG. 6) from the sequence 703, the tool 500 identifies and inputs each fragment 401 (FIG. 4) in turn. As each fragment 401 is processed, its contents are copied into a new, empty file identified by the derived name 603. If a build code 600 appears more than once or in to multiple sequences 703, only the first occurrence of the code 600 causes the fragment 401 to be copied. As the copy is performed, the fragment 401 is parsed for placeholders 511 (FIG. 5A). If a placeholder 511 that was created from a governed object 517 is encountered, it is replaced within the new file by a substitution phrase 514. The particular substitution phrase 514 is located by using the index 516 recorded in the placeholder 511. The replacement within the new file is denoted as the link reference 403. The substitution list 707 of the map entry 713 is then accessed. An entry 708 is created in the list 707. From the placeholder 511, the substitution index 516 is recorded as the parse index 711 and the object 517 is recorded as the target 710. Any other values that are found in the placeholder 511 are stored with the target 710. The sequence count of the current placeholder 511, relative only to other placeholders 511 specifying a governed content object 517, is recorded as the position 709. If the placeholder 511 identifies an ungoverned content object 518, the table entry 519 is copied without modification as the replacement for the placeholder 511. The table entry 519 is deleted and no entry is made in the substitution list 707.

[0061] With respect to FIG. 8, when the copy process for each fragment 401 (FIG. 4) in a build code sequence 703: (FIG. 7) is complete, the reference tool 500 (FIG. 5) prompts the designer to supply “permission levels” 800. A permission level 800 can apply to each build code 600 (FIG. 6) and to the entire sequence 703. The permission level 800 is a single value taken from a set values 801 used to describe varying degrees of privilege. The actual values used are arbitrary, however, the set of values 801 must contain at least two elements and each element 800 must describe a different quality of permission.

[0062] With the addition of permission levels 800 (FIG. 8), the reference tool 500 (FIG. 5) converts each reference map 705 (FIG. 7) in turn. The data structure created by the conversion is referred to as a “jump table” 802 with each entry being denoted as a “jump table entry” 803. Each entry 803 utilizes the content of its corresponding map entry 713 and adds the assigned permission levels 804, 805. The map identifier 716 recorded with the sequence 703 is updated to reflect the value of the jump table identifier 806.

[0063] The creation of all jump tables 802 (FIG. 8) concludes the fix-up process. At this point, all fragments 401 (FIG. 4), the build code list 700 (FIG. 7) and the jump tables 802 are eligible to be placed on the storage device 103 (FIG. 1) as governed content 110 with their physical location made known to the DAC 106. Before this, and if desired, the designer can re-invoke the reference tool 500 (FIG. 5) to perform an optional additional process. The process begins with the reference tool 500 allowing the designer to create new jump tables 802 or additional entries 803 within existing tables 802. Elements so created reference existing build codes 600 (FIG. 6) or sequences 703; however, they permit the arrangement of these elements into alternate orders of sequence. Then, using any or all jump tables 802 as input, build codes 600 may have their entry within a sequence 703 modified to reflect one or more alternate choices 712 (FIG. 7). Each alternate 712 can describe another build code 600 through a particular jump table entry 803 or, an alternate sequence 703 using a different table 802. An alternate 712 is used during the construction of a privileged type response 203. In the event either permission 804,805 of the build code's 600 original entry 803 is not met; the alternate 712 will be examined to see if it qualifies as a suitable replacement.

[0064] In this preferred embodiment of the practice of the present invention, privileged type responses 203 (FIG. 2) may share fragments 401 (FIG. 4); build code sequences 703 (FIG. 7), jump tables 802 (FIG. 8) or jump table entries 803 to any extent except that any combination must form a complete syntactically valid page 403 before its delivery to the client 100 (FIG. 1) as part of a response 201. To test the validity of a response 201, the designer need only attempt to render the response 201 using the browser 111 and display device of a potential or test client 100. If the response 201 renders and functionally behaves as the designer intended, it is valid.

[0065] As described earlier, the determination of privilege associated with a forresting type request 204 (FIG. 2) is derived from the “forresta argument” 206 (FIG. 2A) with the desired content identified by the “destination argument” 207. All forresta values, except the anonymous user value, are generated utilizing a time and memory based routine that uses multiple random values. In this preferred embodiment of the present invention, the resulting format of a forresta value is an “n”-byte character sequence that has no conflicting meaning within the coding constructs of a response 201. To create a forresta value sequence requires use of the following algorithm. This algorithm is defined by the current preferred embodiment of the present invention and is referred to herein as the “fcode process” 900 (FIG. 9). In the preferred embodiment of the current invention, the fcode process 900 is a routine contained. within the session module 301 (FIG. 3).

[0066] The fcode process 900 (FIG. 9) performs a self-initialization each time the DAC 106 (FIG. 1) is initialized from start-up as an executing process on the server 102. This self-initialization facilitates the creation of a data table 901 containing sixty-one (61) values, which is illustrated in FIG. 9. This table 901 is referred to as the “forresta map table” (“FMT”). Each entry 902 in the table 901 contains one symbol, whose appearance within the table 901 is unique, that is a member of the “key set” 903. In this embodiment of the present invention, the key set 903 contains one each, of the upper-case characters “A” through “Z” inclusive, the lowercase characters “a” through “z” inclusive, and the character representations of the digits “1” through “9” inclusive.

[0067] The process of FMT 901 (FIG. 9) creation begins with the fcode process 900 querying a prior art process available through the operating system 113 (FIG. 1) for a random value. In this preferred embodiment of the current invention, the requested value is in the range of 64 to 4096 inclusive, although other bounding ranges are possible. The fcode process 900 then requests a block of memory 904 from the operating system 113 using the returned random value to specify the size of the memory block 904. In this request, the fcode process 900 specifies that the memory block 904 should not be initialized and it should not originate from memory resources already assigned to the DAC 106. By not initialized it is meant that the contents of the memory block 904 should not be altered from its pre-request state as it existed within the resources of the operating system 113. The point of origin of the memory block 904 must be common to any server 102 process requesting memory resources. A common memory resource may be identified and described using the well-known term, “global memory heap”.

[0068] The content of the memory bock 904 (FIG. 9) is accepted as input by the fcode process 900. The memory block 904 is examined for the presence of a signature value employed by the fcode process 900. The signature value identifies a memory block 904 that is not eligible for use by the fcode process 900. The signature value causes the current memory block to be discarded and a new memory block 904 to be requested. In this preferred embodiment of the present invention, the signature value is identified by examining the memory block 904 for the same value in each byte. The fcode process 900 initially sets a “comparison field” 905 equal to the first “n” bits of the memory block 904. In this preferred embodiment of the present invention, “n” is the minimum number of bits required to represent a byte on the server 102 (FIG. 1) on which the fcode process 900 is executing. If the numerical value represented in the comparison field 905 is equal to one of the values of the key set 903, it is compared against existing entries 902 in the FMT 901, if any. If the value is unique within the FMT 901, it is stored at the next, sequentially available entry 902. If the contents of the comparison field 905 duplicates an FMT entry 902 or is not a desired value, the fcode process 900 refreshes the comparison field 905 in the following manner.

[0069] A refresh of the comparison field 905 (FIG. 9) is accomplished with a logical left shift of the bits within the field 905, ignoring any carry. To replace discarded bits, new bits are serially retrieved from the next available within the memory block 904. The size of the shift is equal to a “shift count” 906 whose initial value is one. Each time a value in the comparison field 905 duplicates an entry 902 in the FMT 901, the fcode process 900 will increment the shift count 906 by one; however, if the shift count value exceeds one-half the size of the memory block 904, the fcode process 900 will reset it to one. If the size of the shift exceeds the number of bits within the comparison field 905, new bits are serially brought in from the memory block 904 until the shift is completed. If no more bits are available from the memory block 904, the fcode process 900 requests a new random number and uses it to obtain a new block of memory from the operating system 113 (FIG. 1). Any subsequent new memory block is always requested using the same initialization and allocation constraints as imposed on the first. Once the new block has been received by the fcode process 900, the previous block is cleared of its contents by setting each byte contained within it to the same, arbitrarily chosen value and returned to the memory management process of the operating system 113. The fcode process 90 will repeat these steps until all entries 902 within the FMT 901 are complete.

[0070] To create a forresta value, the session module 301 (FIG. 3) employs the following routine, which exists as a callable process included with and unique to the session module 301. This routine is denoted as the “create forresta value” (“CFV”) 907 (FIG. 9) process;

[0071] The CFV 907 (FIG. 9) accepts as input, the forresta argument 206 (FIG. 2A) of the forresting type request 204 being processed. A correct argument 206 will be, at a minimum, equivalent to the anonymous user value represented as a proper length sequence of contiguous bytes. If the CFV 907 does not recognize the format of the argument 206, it returns an access violation return code. If the argument 206 does not resolve to the anonymous user value, the CFV 907 compares the argument 206 against each entry 908 of a list 909, which it maintains, that contains all forresta values currently in use. If the argument 206 does not match any value contained within the list 909, the CFV 907 returns an access violation return code. If the argument 206 is equal to the anonymous user value, the CFV 907 proceeds without examining the list 909.

[0072] The CFV 907 (FIG. 9) proceeds to form a new forresta value by invoking the fcode process 900 for each character required by the forresta format. The number of characters required is arbitrary. However, in this preferred embodiment of the present invention, a minimum of eight (8) characters is imposed. In response, the fcode process 900 requests a random number from a prior art random number generation process in the range of one (1) to sixty-one (61) inclusive and returns the character held by the entry 902 at that relative index of the FMT 901. The CFV 907 will repeat its request until sufficient characters have been retrieved. When a new forresta value has been created, the CFV 907 compares the new value to entries 908 in the existing forresta value list 909, if any. If the new forresta value duplicates an entry 908, it is discarded and the CFV 907 will repeat the process of forresta value generation. When a new, unique forresta value is obtained, the CFV 907 discards the original argument 206 (FIG. 2A). The new forresta value is then added to the list 909 of active forresta values. When the argument 206 is not equal to the anonymous user value, the CFV 907 removes and discards the list entry 908 that the argument 206 value matched.

[0073] The CFV 907 (FIG. 9) has an additional capability that is invoked whenever an access violation is detected by any routine within the DAC 106 (FIG. 1), including the possibility that the CFV 907 will invoke itself under this condition. When a violation occurs, the detecting routine signals the CFV to perform a “rotation” of the FMT 901. The CFV 907 accomplishes this by first requesting the current time value from the operating system 113 or other prior art process in a format of hours, minutes and seconds. The portion of the time value that represents seconds is supplied as input 911 to the fcode process 900 along with a unique indicator value 910. Upon recognizing the indicator 910, the fcode process 900 changes the position of the entries 902 in the FMT 901. This is accomplished by applying a logical, circular shift to each entry's 902 position using an iterative count 911 equal to the seconds value passed by the CFV 907. If the seconds value is zero, the fcode process 900 uses the value sixty (60) as the iteration count 911.

[0074] As forresting type requests 204 (FIG. 2) are delivered from 104 (FIG. 1) to the access module 300 (FIG. 3) each is reformatted by the access module 300 into a “session node” 1000 (FIG. 10) data structure. FIG. 10 shows an exploded view of an exemplary session node 1000. The session node 1000 is then forwarded as an input argument in a process call to the session module 301. The input argument to the session module 301 is denoted as the “current” session node 1000 for convenience.

[0075] Session nodes 1000 (FIG. 10) are maintained as a set in a data structure referred to herein as a “session list” 1001. In this preferred embodiment of the present invention, the session list 1001 is implemented within a memory space assigned to the DAC 106 (FIG. 1) by the memory management process of the operating system 113. When the DAC 106 is initialized from start-up, the session list 1001 (FIG. 10) is formatted to retain zero or more session nodes 1000 by the session module 301 (FIG. 3). In the DAC's 106 initialized state after start-up there are no session nodes 1000 present within the session list 1001. Session nodes 1000 are added or removed from the session list 1001 by the session module 301, however; any component of the DAC 106 may reference the contents of the list 1001 to facilitate its function.

[0076] When the session module, 301 (FIG. 3) is invoked by the access module 300 and if the session list 1001 (FIG. 10) is not empty, the session module 301 will examine each resident node 1000 for the “time-out” condition. Timing out is a quality determined by measuring the inactivity interval of the client 100 (FIG. 1) with respect to DAC 106 interaction. In this preferred embodiment of the practice of the present invention, the time interval between successive requests 200 (FIG. 2) of a single client 100 received by the DAC 106 is the determining factor. of the time-out condition. Typically, this period is measured in units of seconds. The session node 1000, when initially created by the access module 300 is marked with a timestamp 1002 that indicates its moment of creation. In this preferred embodiment of the present invention, the explicit timestamp value is provided by a prior art process resident within the operating system 113. During the examination of a node 1000 that is list 1001 resident by the session module 301, the current value of time is retrieved from the same prior art process that provided the initial timestamp. With the assumption that time values always increase, the timestamp 1002 is subtracted from the current time value. If the result is less than a repository designer selected value, timeout has not occurred and the session module 301 proceeds to the next session node 1000 in the list 1001, if any. If the result is equal to or greater than the selected value, timeout has occurred and the session node 1000 is removed from the session list 1001. Removal of a node 1000 from the list 1001 also clears the data content of the node 1000 and removes its forresta value 1003 from the active forresta list 909 (FIG. 9) maintained by the CFV 907 process.

[0077] With the completion of time-out processing, the session module 301 (FIG. 3) performs an equivalence comparison test between the forresta value 1003 (FIG. 10) contained within the session node 1000 that is current and the anonymous user value. If the values are equal, the session module 301 forwards the current node as an input argument in a process call to the form module 302. If the result of the comparison is not equivalence, the session module 301 performs an equivalence test between the forresta value 1003 of the current node and the forresta values contained within nodes 1000 resident on the session list 1001. If the session list 1001 is empty, the current node is discarded by the session module 301 and a return of process control with a status code is made to the access module 300. If a node 1000, which is resident on the list 1001, has a forresta value 1003 that tests equally and there remain unexamined nodes 1000, the session module 301 continues the examination. If multiple nodes 1000 satisfy the comparison test with the forresta value 1003 of the current node, the session module 301 removes all such nodes 1000 from the list 1001 and clears the data content from each. The forresta value 1003 is then removed from the active forresta list 909 (FIG. 9). In this instance, the session module 301 returns an access violation value.

[0078] With the absence of an access violation, the destination value 1004 (FIG. 10) of the current node is placed into the appropriate field 1004 of the list 1001 resident node 1000. The session module 301 (FIG. 3) then forwards the address of the node 1000 that is list 1001 resident as an input argument in a process call to the form module 302. The node 1000 that is current is cleared of data content and discarded.

[0079] When the form module 302 (FIG. 3) receives a session node 1000 address (FIG. 10), it verifies the argument by requesting the address of the session list 1001 from the session module 301. The value of the input argument is then applied against the contents of the list 1001. If the input argument address references an entry within the list 1001, the form module 302 proceeds. If the input argument address does not properly reference a list 1001 entry, the form module 302 returns an access violation. With a valid address, the form module 302 accesses the referenced node 1000 and extracts the privilege value 1005, the destination value 1004 and the state table 1006. The privilege value 1005 is derived from information returned by the authority process 105 (FIG. 1). The state table 1006 is a data structure that represents the current request 200/response 201 (FIG. 2) relationship existing between the client 100 and the DAC 106. The destination 1004 is a copy of the destination argument 207 (FIG. 2A) and any other supplied values received as part of the forresting type request 204. In the following, each of these elements is described.

[0080] The notion of “privilege” is determined using the authority assigned to a user 100 (FIG. 1) by the authority process 105. Without regard to the specifics of the method of the authority process 105, the following steps occur when a destination 1004 (FIG. 10) references sensitive data 107.

[0081] If the session node 1000 (FIG. 10) does not contain a privilege value 1005 for the requesting client 100 (FIG. 1), the form module 302 (FIG. 3) returns process control to the access module 300 with a signature code indicating the absence of privilege. The signature code is a new, unique forresta value 1003 obtained by the form module 302 invoking the CFV 907 (FIG. 9). The format of the process call in conjunction with the signature code causes the access module 300 to invoke the authority process 105 and a transfer of process control is negotiated between the two routines. The transfer and subsequent return of process control between the access module 300 and the authority process 105 is dependent on the operation of the authority process 105 and the operating system 113 of the server 102 and is not unique to or described by this embodiment of the present invention. Before the access module 300 relinquishes control, it establishes a “watchdog interrupt” that is set for a pre-determined amount of time. A watchdog interrupt is a well-known method for allowing the operating system of a computer to invoke a waiting process if a specified period elapses. If the watchdog interrupt returns process control to the access module 300, the request 204 (FIG. 2) is ignored, the session node 1000 is discarded and the form module 302 is instructed to discard the outstanding signature value. If the access module 300 receives a response from the authority process 105 before the watchdog interrupt returns, the watchdog interrupt request is cancelled. If the authority process 105 denies access, the request 204 is ignored, the session node 1000 discarded and the form module 302 is instructed to discard the signature value. If authority is granted, the access module 300 forwards the authority value, the signature code received from the form module 302 and the session node 1000 to the session module 301.

[0082] Upon recognizing that an authority value has been passed to it, the session module 301 (FIG. 3) invokes the form module 302 in a process call to determine the validity of the signature code. If the form module 302 acknowledges that the signature code represents an outstanding request, the session module 301 proceeds, otherwise an access violation is generated. In the absence of an access violation, the session module 301 accesses a file that contains “criteria information”. Criteria information is defined and created by the designer using the reference tool 500 (FIG. 5) and is considered governed content 110 (FIG. 1) although it is not a fragment 401 (FIG. 4) and is never used within a response 201 (FIG. 2). Criteria information provides the mapping between values returned by the authority process 105 and permission levels 800 (FIG. 8) established for governed content 110. The criteria information value obtained in this manner becomes the privilege value 1005 (FIG. 10) of the client 100.

[0083] When a privilege value 1005 (FIG. 10) has been determined, the session node 1000 becomes an “authorized session node”. Authorized session nodes 1000 are placed on the session list 1001 by the session module 302 (FIG. 3). During processing, authorized session nodes 1000 remain list 1001 resident as long as they do not timeout or experience an access violation. Additionally, a session node 1000 will be removed from the list 1001 if the client 100 (FIG. 1) indicates that no further request 200 (FIG. 2) is forthcoming. A forresting type request 204 for governed content 110 will cause the session module 301 (FIG. 3) to index 1006 the session list 1001 using the value of the forresta argument 206 (FIG. 2A). By this mechanism, a session node 1000 for a particular client 100 (FIG. 1) is located. If the forresta argument 206 does not match a forresta value 1003 contained within any node 1000 resident on the list 1001, the request 204 is ignored.

[0084] When the session node 1000 (FIG. 10) has become list 1001 resident, the session module 301 (FIG. 3) returns control to the access module 300. The access module 300 then instructs the form module 302 to discard the signature value. The access module 300 then restarts the processing of the forresting type request 204 (FIG. 2) unencumbered by passing the session node 1000 as an input argument in a process call to the session module 301.

[0085] The state table 1006 (FIG. 10) is constructed during the creation of a page 403 (FIG. 4) is by the form module 302 (FIG. 3). This process begins after the response page entry 701 (FIG. 7) identified by the destination 1004 has been retrieved. Fragments 401 identified by the build code sequence 703 contained within the entry 701 are parsed for link references 403. This is performed using the jump table 802 (FIG. 8) identified by the map identifier 716 contained with the sequence 703. A jump table entry 803 yields the substitution list 707 of the fragment 401. Each target 710 contained within the list 707 creates an entry in the state table 1006.

[0086] The state table 1006 (FIG. 10) is used by the form module 302 (FIG. 3) to determine certain access violation conditions. These conditions determine if a forresting type request 204 (FIGS. 2, 2A) is received outside of an expected order, or there has been an alteration of the forresta value 206 (FIG. 2A) since it was assigned. Each state table entry 1008 contains one or more occurrences of the “entry field” 1009, the “sorted order field” 1010 and the “expected forresta field” 1011. The state table 1006 is modified by the form module 302 every time a privileged response 203 (FIG. 2) is created. Entries 1008 are made in the state table 1006 for each build code list index 702 ((FIG. 7) used in constructing the privileged response 203. If the destination 1004 could not be generated or executed by the client 100 using the values referenced by the state table 1006, the form module 302 raises an access violation and returns. If the destination 1004 and forresta 1003 are legitimate, the session node 1000 will be used as an input argument to the form module 302.

[0087] The legitimacy of destination 1004 (FIG. 10) and forresta 1003 values is determined in the following manner. During the creation of a page 403 (FIG. 4), the sorted order field 1010 and the expected forresta argument field 1011 are also created. This is accomplished as each substitution list 707 (FIG. 7) is processed for placeholders 511 (FIG. 5). Each position 709 and target 710 pair of an entry 708 is used to create an entry 1013 in the sorted order field 1010. The entry 1013 is indexed by a key, whose value is supplied by the target 709. The position 710 is stored as data particular to that key. Each forresta value 1003 that is used in the creation of a link reference 403 also creates an entry 1012 in the expected forresta field 1011. This entry 1012 is indexed by a key, whose value is supplied by the position 710. The specific forresta value 1003 is stored as data particular to that key.

[0088] When a forresting type request 204 (FIG. 2) is received, a specific session node 1000 (FIG. 10) is identified by the matching the forresta argument value 206 (FIG. 2A) with the contents of a forresta field 1003 contained within a session node 1000. Once found, the destination field 1004 is updated using the value of the destination argument 207. Alternatively, the session node 1000 may be located by matching both forresta 206 and destination 207 arguments before updating the destination field 1004. If a session node 1000 is not found using this search, the access module 300 (FIG. 3) generates an access violation condition. Upon a successful match, the destination value 1004 is compared against sorted order field entries 1013. If the destination value 1004 fails to match any sorted order field entry 1013, an access violation is returned. Next, the forresta value 1003 is compared against entries 1012 within the expected forresta field 1011. If no match is found, an access violation is returned. If the expected forresta field entry 1012 has already been marked as being matched against a request 204 without an intervening update of the state table 1006, an access violation is returned. If the position value of the expected forresta field entry 1012 does not match the position value of the sorted order field entry 1013, an access violation is returned. If there is no access violation, the session node 1000 is marked as “valid”. A valid session node 1000 may use the value of the list entry 1009 to retrieve a build code list entry 701 (FIG. 7).

[0089] With the receipt of a valid session node 1000 (FIG. 10), the form module 302 (FIG. 3) begins assemblage of the privileged response 203 (FIG. 2). What is to be included in the response 203 is determined by the destination value 1005. The form module 302 begins by requesting the allocation of a new, empty file, denoted herein as the “delivery file” within the governed content area 110 (FIG. 1) of the storage device 103. This is achieved using the prior art method of file management provided by the operating system 113. The name identifier assigned to this file is random and unique and in this preferred embodiment of the present invention, is provided by the file management system at the request of the form module 302. The form module 302 will request one or more, new forresta values 1003 from the CFV 907 (FIG. 9) and enter them into the session node 1000 if the privilege value 1005, using its designer assigned meaning, indicates it. The form module 302 locates the response page entry 701 (FIG. 7) using the value of the destination 1004 as the index 702. The build code sequence 703 contained within the entry 701, identifies all fragments 401 (FIG. 4) that are required to create the response 203.

[0090] As a build code 600 (FIG. 6) is processed, the form module 302 (FIG. 3) will test the privilege value 1005 (FIG. 10) against each permission value 804,805 (FIG. 8) retrieved from the jump table entry 803. If the result of the operation yields denial, the form module 302 checks the build code entry for an alternate 712 (FIG. 7). If an alternate 712 exists, the sequence 703 or build code 600 referenced by the alternate 712 is examined in the same manner to determine if it may be used in constructing the privileged response 203 (FIG. 2). If no alternates 712 exist or qualify, the form module 302 exits with an access violation. If the operation yields an affirmative result, the form module 302 will retrieve the jump table 802 or entry 803 identified by the alternate 712. If the sequence permission 804 requires more privilege than held by the client 100 (FIG. 1), the form module 302 returns an access violation. If an entry 803 specifies fragment permission 805 that is unequal to the sequence permission 804, the form module 302 may skip including the fragment 401 (FIG. 4) or return an access violation. Either action is dependent on the designer assigned meaning of the permission values 800.

[0091] If the sequence permission 804 (FIG. 8) is satisfied by the privilege value 1005 (FIG. 10), the form module 302 (FIG. 3) will permit access to the build codes 600 (FIG. 6) contained within the sequence 703 (FIG. 7). If the fragment permission 805 is satisfied by the privilege value 1005, the corresponding fragment 401 (FIG. 4) is included within the response 203 (FIG. 2).

[0092] After the form module 302 (FIG. 3) retrieves the fragment 401 (FIG. 4) from the storage device 103 (FIG. 1), it re-examines the build code 600 (FIG. 6) value to determine the fragment 401 type. If the fragment 401 is a body or artwork type, its contents are appended to the delivery file and the form module 302 advances to the next entry in the build code sequence 703 (FIG. 7). If the fragment 401 is a target, the form module 302 parses the fragment 401 for link references 403.

[0093] Because each link reference 403 (FIG. 4) does not change its position relative to other references 403 that are found within a fragment 401, the form module 302 (FIG. 3) can construct a syntactically valid page 402 by using the jump table 802 (FIG. 8). Proceeding in order through the list 707 (FIG. 7), each parse index 711 is used to retrieve the corresponding substitution phrase 514 (FIG. 5). This provides the syntax of the link reference 403 next to be encountered within the fragment 401. When the substitution phrase 514 is recognized, the form module 302 reverses the substitution supplying the parse phrase 515. In this manner, link references 403 contained in a fragment 401 are undecipherable until they are ready to be transmitted to the client 100 (FIG. 1). The target 710 is incorporated into the link reference 403 as the destination argument 205 (FIG. 2A) and the forresta value 1003 (FIG. 10) is coded as the forresta argument 206. If additional values are stored with the target 710, they are incorporated into the link reference 403 in a manner consistent with the syntax in use. When the link reference 403 is executed by the client 100 (FIG. 1), a request 200 (FIG. 2) is created.

[0094] Once all fragments 401 (FIG. 4) have been processed into a privileged response 204 (FIG. 2), the form module 302 (FIG. 3) places the name of the delivery file into the session node 1000 (FIG. 10) and updates the timestamp value 1002. If the existence of previous delivery files 1007 is indicated, the form module 302 deletes them from the storage device 103 (FIG. 1) and updates the session node 1000 before making its return. Upon receiving the session node 1000 back from the form module 302, the access module 300 identifies the delivery file to communications process 104 for transmission of its contents to the client 100 as the response 201.

[0095] As illustrated by FIG. 11, fragments 401 (FIG. 4), whose build code 600 (FIG. 6) value indicates a framing construct, are processed as follows. As the fragment 401 is parsed, a target 710 (FIG. 7) of a link reference 403 that specifies a framing sub-division. causes the form module 302 (FIG. 3) to recursively invoke itself. Before the re-invocation occurs, the form module 302 creates a primary delivery file 1100 into which the frame construct is copied up to the point of the first link reference 403 that specifies a sub-division. The form module 302 then creates a temporary session node 1000 (FIG. 10) copying all values from the original except for the destination 1004. The new destination value 1004 will contain the index 702 of the response entry 701 specified by the target 710 of the sub-division reference 403 currently being processed. The temporary session node 1000 will be used as the input argument in the re-invocation call. When the form module 302 is re-entered, it processes the temporary session node 900 (FIG. 9) as if it were the original unless another frame construct is specified by the destination 1004 contained within the temporary node 900. If this occurs, the re-invocation will repeat using the same input protocol.

[0096] Continuing with FIG. 11, frame constructs cause the form module 302 (FIG. 3) to create more than one delivery file. There will be at least one delivery file 1100 whose contents describes the framing information and, one delivery file 1101 to provide content for each created frame 1102. Assuming there is no access violation, the name of each delivery file 1102 created by a re-invocation is recorded in the session node 1000 (FIG. 10) followed by a return to the previous process instance of the form module 302. Upon its return, the form module 302 codes the name of the delivery file 1102 as the destination argument 207 (FIG. 2A) of the link reference 403 (FIG. 4) that instigated the call. The form module 302 then continues the link reference 403 parse on any remaining fragment 401 content. This process continues until the build code sequence 703 (FIG. 7) is completed. If there is an access violation, the form module 302 abandons the sequence 703 and returns to the access module 300 indicating the fault. With the absence of a violation, the name 1103 of the primary delivery file 1100, which contains the framing instructions, is indicated in the session node 1000 as the response 204 (FIG. 2) to be transmitted.

[0097] Framing constructs have one additional limitation with regards to targets 710 (FIG. 7) used in link references 403 (FIG. 4) that specify a sub-division. The target 710 of such a reference may not have a permission requirement greater than the permission 804 (FIG. 8) of the sequence 703 that created the frame construct, even if the client 100 (FIG. 1) is authorized for the higher permission. When permissions 800 are assigned by the repository designer, the reference tool 500 (FIG. 5) will not allow such a construct.