Biggest patent portfolios by company

by company

  • INTERNATIONAL BUSINESS MACHINES CORPORATION 13,899
  • CANON KABUSHIKI KAISHA 9,693
  • NEC CORPORATION 6,843
  • SAMSUNG ELECTRONICS CO., LTD. 6,726
  • KABUSHIKI KAISHA TOSHIBA 6,682
  • SONY CORPORATION 6,195
  • HITACHI, LTD. 5,935
  • FUJITSU LIMITED 5,841
  • MATSUSHITA ELECTRIC INDUSTRIAL CO., LTD. 5,735
  • MITSUBISHI DENKI KABUSHIKI KAISHA 5,253

Biggest patent portfolios by inventor

by inventor

  • Silverbrook Kia 1,860
  • Yamazaki Shunpei 1,585
  • Satake Toshihiko 905
  • Yamamoto Hiroshi 766
  • WATANABE HIROSHI 753
  • Weder Donald E. 657
  • Forbes Leonard 618
  • Tanaka Hiroshi 585
  • Suzuki Takashi 575
  • Takahashi Hiroshi 570

Patent appraised by patentsbase

$ 21000

GLOBAL PATENTRANK

# 56.000
TITLE:

Method and apparatus for serving files to browsing clients

USA PATENT RANK
Patent ID
Issue Date
#3.566.999
US-6826565-B2
30.11.2004















ABSTRACT

Output signals are served from a serving device to a plurality of browsing devices connected to a network. The output signals represent commands executable by each browsable device so as to display viewable data in accordance with specified page formatting. Requests from browsing clients are identified which contain information relating to the data itself and the display format for the data. The data is read and processed so as to combine a representation of the viewable data with executable instructions. The signals are then supplied to requesting browsing devices, after effectively being assembled as a real time on-line process.

INFORMATION

Inventor(s) BRADSHAW JONATHAN M (GB); RITCHIE ANDREW M (GB); BRADSHAW JONATHAN M.; RITCHIE ANDREW M.; Bradshaw Jonathan M. (Bracknell, GB); Ritchie Andrew M. (Sunbury-on-Thames, GB);
Applicant(s) ABLAISE LTD (GB); ABLAISE LIMITED;
Assignee ABLAISE LIMITED (Leicestershire, GB);
Assignee history
assigneesABLAISE LIMITED (THE OLD RECTORY, NOCK VERGES, STONEY STANTON, LEICESTERSHIRE, LE9 4DA, GB);assignorsGENERAL INVENTIONS INSTITUTE A, INC.;correspondence-addressNixon & Vanderhye P.C. (901 N. GLEBE ROAD, ARLINGTON, VA 22203);
assigneesGENERAL INVENTIONS INSTITUTE A, INC. (P.O. BOX 71, CRAIGMUIR CHAMBERS, Road Town, Tortola, VG);assignorsABLAISE LIMITED;correspondence-addressSHYAM REDDY, KILPATRICK STOCKTON (1100 PEACHTREE STREET, SUITE 2800, ATLANTA, GA 30309);
assigneesGENERAL INVENTIONS INSTITUTE A, INC. (P.O. BOX 71, CRAIGMUIR CHAMBERS, Road Town, Tortola, VG);assignorsABLAISE, LIMITED;correspondence-addressJOHN S. PRATT, KILPATRICK STOCKTON LLP (SUITE 2600, 1100 PEACHTREE STREET, ATLANTA, GEORGIA 30309);
assigneesGENERAL INVENTIONS INSTITUTE, INC. (CRAIGMUIR CHAMBERS, P.O. BOX 71, Road Town, Tortola, VG);assignorsABLAISE, LIMITED;correspondence-addressJOHN S. PRATT, KILPATRICK STOCKTON (1100 PEACHTREE STREET, SUITE 2800, ATLANTA, GA 30309);
assigneesGENERAL INVENTIONS INSTITUTE, INC. (P.O. BOX 71, ROAD TOWN, Tortola, VG);assignorsABLAISE LIMITED;correspondence-addressKilpatrick Stockton LLP (JOHN S. PRATT, 1100 PEACHTREE STREET, SUITE 2800, ATLANTA, GEORGIA 30309-4530);
assigneesABLAISE LIMITED (THE OLD RECTORY, NOCK VERGES, STONEY STANTON, LEICESTERSHIRE, L39 4DA, GB);assignorsBERNSTEIN, MARK;BLANCHARD, CHRISTOPHER;BRADSHAW, JONATHAN MARSDEN;COLLARD, MARCUS;RITCHIE, ANDREW MACGREGOR;correspondence-addressJOHN S. PRATT, KILPATRICK STOCKTON (1100 PEACHTREE STREET, SUITE 2800, ATLANTA, GA 30309);
assigneesGENERAL INVENTIONS INSTITUTE A, INC. (P.O. BOX 71, ROAD TOWN, Tortola, VG);assignorsABLAISE LIMITED;correspondence-addressKilpatrick Stockton LLP (JOHN S. PRATT, 1100 PEACHTREE STREET SUITE 2800, ATLANTA, GA 30309-4530);
Agent Nixon & Vanderhye, PC
Application No. US-22346702-A
Filing Date 20.08.2002
Primary Class G07F 17/30
Primary Examiner Rones Charles;
Search results 560

DETAILED DESCRIPTION OF THE INVENTION

RELATED APPLICATIONS

This is a division of our application Ser. No. 09/920,803 filed Aug. 3, 2001 which is a continuation of Ser. No. 08/647,769 filed May 15, 1996, now issued as U.S. Pat. No. 6,295,530.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagrammatic representation of part of the international data distribution network known as the Internet, having a plurality of service providers and a plurality of service users; implemented using a plurality of network topologies.

FIG. 2 shows an example of a typical service provider network of the type shown in FIG. 1; including a local area network and a serving host;

FIG. 3 details the serving host identified in FIG. 2, including a processing unit and a random access memory for storing instructions executable by said processing unit;

FIG. 4 represents a processing environment specified by the processing unit and its associated instructions created by the processing unit and its associated memory shown in FIG. 3, including a hypertext transport protocol daemon and on-line processing procedures in accordance with the present invention;

FIG. 5 illustrates the operation of the hypertext transport protocol daemon identified in FIG. 4 in response to receiving an input URL request and including an identification of initialisation procedures and procedures for performing on-line processing;

FIG. 6 shows requesting user devices, including a processing device and a visual display unit;

FIG. 7 illustrates a typical display shown on the visual display unit identified in FIG. 6, in response to instructions being supplied to the user from a server;

FIG. 8 shows an example of instructions in the form supplied to the browser, in order to generate the display shown in FIG. 7;

FIG. 9 details the initialisation procedures identified in FIG. 5;

FIG. 10 details the on-line procedures identified in FIG. 5 including an indication of procedures for generating HTML pages;

FIG. 11 illustrates the relationship between serving components when configured to supply HTML pages to a requesting device;

FIG. 12 details procedures for generating HTML pages identified in FIG. 10, including a step for executing a function string;

FIG. 13 details procedures for executing a function string, including a function execute step; and

FIG. 14 details function execution steps used to generate lines of output commands of the type identified in FIG. .

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

A diagrammatic representation of part of the Internet is shown in FIG. . An international data communication network is provided, represented diagrammatically by region . Access to this network is provided over data channels , that are in turn connected to service nodes . Service nodes allow users to gain access to the Internet with varying levels of transmission bandwidth.

In the example, a local area network is provided with a high bandwidth link to an Internet service provider . The network includes servers, that supply data to the Internet in response to requests made by users. Presently, users are given access to the Internet over channels providing traffic capacities from 14.4K bits per second (telephone dial up) to 100 M bits per second and beyond when implemented using optical techniques.

A low bandwidth user communicates with a service provider via co-operating modems , connected via a transmission cable . Many users of this type may access information from a server, such as server .

Network is detailed in FIG. . The network comprises a fibre distributed data interface (FDDI) backbone ring having four routers , , and connected thereto. Router is a token ring router which routes data between a token ring network and the FDDI backbone . In the example shown in FIG. 2, a first host processing system and second host processing system are connected to the token ring , thereby facilitating communication between said hosts and , along with communication between said hosts and the backbone ring , via token ring router .

A host processing system , and a host processing system communicate via an ethernet network . The ethernet network also allows communication between hosts and and the backbone ring via ethernet router .

The backbone ring also communicates with an asynchronous transfer mode (ATM) network, including a first ATM host and a second ATM host . Information for distribution to the Internet is generated by “serving operations” executed by host . This host communicates with the backbone ring via the ATM router , which in turn facilitates communication to the Internet itself via Internet router and an Internet line driver . This facilitates the transfer of data to an Internet service provider, as shown in FIG. .

The present embodiment is directed towards providing HTML encoded data, in accordance with the HTML recommendations implemented over the Internet as a service known as “World Wide Web”. However, the invention as a whole has broader application, particularly when it is necessary to process human viewable data in combination with signals representing a selected display structure, such that commands are executable by remote browsing clients.

Serving station , as shown in FIG. 2, serves files, processed in accordance with the established hypertext mark-up language (HTML) to browsing clients via the Internet. A browsing client makes a request for the information to be supplied and this request is identified by a serving station, such as station , which responds to said request by returning the information via the Internet connection to the browsing client device. Once a request has been received, first signals are processed by the serving station which represent the human viewable data. Second signals are received which represent a selected display structure. These two signals are processed in order to produce an HTML output. However, this processing step only takes place after the client request has been received such that the first signals and the second signals are processed to produce output signals in the form of client executable instructions which are then served as output signals suitable for execution by the requesting browser. In this way, many pages of HTML encoded data may be produced automatically without requiring manual effort for each individual page. Furthermore, pages may be tailored for specific user requirements and, in some circumstances, it may be possible to adjust the extent to which this customization takes place in response to the clients own history of use, such that topics of interest are identified automatically and this identification is used in order to direct information of interest to the calling client.

The hardware of serving network is shown in FIG. 2. A request from a browsing client would be received from the Internet provider via data link , thereby allowing the Internet router to direct the packet of information onto the backbone network . This packet would include an address so as to identify the processing environment arranged to serve the requested information.

ATM host is detailed in FIG. 3. A central processing unit provides a general purpose multi-tasking processing environment, possibly running under the UNIX operating system. The processing unit includes internal buses to facilitate communication with a mass storage device, such as a hard disk drive , and a random access memory .

Communication with external devices is facilitated through an input/output (I/O) interface which is in turn connected to typical user peripherals such as a keyboard, a monitor and a mouse etc. In addition, the I/O device is connected to ATM router via a network control circuit .

A routine is executed continually by the processing unit to identify requests made to a particular I/O port established by the I/O circuit . Thus, a packet received by the backbone includes an address that enables the network control interface such that said controller may direct the packet to the interface . Thus, the packet identified by the network controller will be supplied to a particular port of the I/O device . The processing unit will identify the fact that data has been supplied to the relevant port and establish a connection, effectively placing the system into an active mode. Once placed in its active mode, the packet of data passes through the I/O device to become a packet of information which is then held under the control of the operating system of the processing unit .

In response to receiving this information, the processing unit is arranged to perform the steps identified above, that is, it is arranged to process first and second signals to produce output signals in the form of client executable instructions. After this processing has taken place, the resulting output signal is returned for transmission to the Internet via line driver , Internet router , ATM router , network controller and the I/O device .

The processing environment provided by the processing unit is illustrated in FIG. . An HTTP daemon is executed by the processing environment in order to detect requests received by the input/output device . In response to detected requests, the processing environment is arranged to supply predetermined HTML files to the I/O device . In addition, it is also possible for the HTTP daemon to identify common gateway interface binary programs (CGI.BIN programs) which are executable instructions within the processing environment and results in identified files being supplied to the I/O device . The CGI.BIN files are capable of operating in response to variables, including information identifying the type of browser, the host name of the system and details of the client requesting information etc. Facilities of this type are available within existing HTTP servers. However, in addition, it is possible for the daemon to respond to requests where the output HTML file will be produced “on the fly” in response to instructions identified as “on-line processing”. When requested, the on-line processing will receive human viewable data from a database in combination with file structures from a file structure source . Thereafter, in response to instructions from the on-line processing system , the processing environment will process human viewable data in combination with file structure data to produce HTML output files for the I/O device .

The HTTP daemon procedures identified at in FIG. 4 are detailed in FIG. . Initialization procedures are implemented at step on start up, whereafter the appropriate port is interrogated at step after waiting for a predetermined period at step . The procedures shown in FIG. 5 are executed within a multi-tasking environment, therefore the wait period at step refers to a single task and other tasks will execute without being affected. At step a question is asked as to whether a user request, in the form of a uniform resource location (URL) is waiting at the interrogated port. If the question asked at step is answered in the negative, control is returned to step and the process repeated. Thus, as previously stated, the system operates within a multi-tasking environment, such as that provided by the UNIX operating system. Thus, while the particular tasks shown in FIG. 5 repeatedly loop until a URL is received, the system is arranged to perform other tasks.

If the question asked at step is answered in the affirmative, to the effect that a URL has been detected, the URL is processed at step , whereafter validation procedures are executed at step . Validation procedures firstly determine whether the URL satisfies an acceptable structure and thereafter, security provisions may be executed in order to establish whether the server is permitted to serve the requesting client. Assuming a valid URL has been supplied to the server, a question is asked at step as to whether the client has requested a predefined HTML file. If the question is answered in the affirmative, the requested file is supplied to the requesting client at step and control is then returned to step . Alternatively, if the question asked at step is answered in the negative, control is directed to step .

At step a question is asked as to whether the on-line processing procedures have been requested. If this question is answered in the affirmative, the requested file is prepared on-line and supplied to the browser at step . Alternatively, if the question asked at step is answered in the negative, control is directed to step .

At step a question is asked as to whether an instruction has been supplied to the effect that CGI.BIN are to be executed. If this question is answered in the affirmative, control is directed to step , resulting in the execution of the identified CGI.BIN instructions. Alternatively, if the question asked at step is answered in the negative, all possibilities will have been considered and an error message is returned at step .

Referring to FIG. 1, server network has been described with reference to FIGS. 2 and 3 and the operations executed within said server could be described with reference to FIGS. 4 and 5. Information from the server is supplied to requesting clients over the Internet and files are served to browsers in response to requests made by browsers. As previously stated, a browsing client issues requests, in the form of URLs via a modem . A browsing station is detailed in FIG. 6 connected to a modem , which is in turn connected to the Internet via communication cable . The browsing client hardware consists of a programmable device such as an IBM personal computer configured to operate as a browser in response to instructions installed from local permanent storage medium, usually a hard disk drive. The system includes a keyboard and a visual display unit . An operator issues commands via the keyboard or the mouse , causing the browser to issue a URL to the server. The browsing instructions executed by the terminal shown in FIG. 6 are configured in a form to be compatible with the serving instructions generated by the server . Thus, particular instructions would be installed on the server and in order for users to gain access to these instructions it would be necessary to install an appropriate browser for execution on the user's terminal. Thus, in response to a user issuing commands via the keyboard or mouse , the browser converts these instructions into a URL which is in turn processed by the remote server. This in turn results in HTML instructions being supplied to the browser from the network such that the browser effectively executes these instructions in order to generate a displayable video signal. The video signal is supplied to the monitor , resulting in the human viewable information being displayed on the monitor in a form derived from the HTML instructions supplied to the browser as executed by the browser itself.

Monitor is detailed in FIG. 7, showing a typical application of the system. In this example, on-line generation of HTML instructions are being used to present a home “shopping on-line” catalogue to users, so that said users may inspect available products and place orders for said products. Thus, the interactive environment ensures that users are kept up to date with available products and prices while at the same time allowing orders to be placed within a common facility.

The page shown in FIG. 7 represents an initial contents page for a service identifying itself as a “Home Shopper”, (this is a fictitious publication made for the purposes of this description and any similarities to existing publications is not intended). The contents page allows a user to quickly select areas of interest in a structured way. Thus, from the initial page, selections may be made for sports goods, electrical goods, computer goods, children's games and toys etc., gardening products or clothing. The user's terminal (shown in FIG. 6) includes a mouse and operation of this mouse results in a cursor being moved over the viewed image. The image includes a graphical icon for each of the available categories. Thus, an icon in the form of a tennis racquet identifies a region arranged to effect a call to the products relating to sports. Thus, the mouse may be manually adjusted so as to position the cursor over this icon. Thereafter, a mouse button may be operated resulting in execution of a hyperlink to another HTML page. Thus, the identification of the sports icon by the user will automatically result in a new URL being generated which is in turn supplied to the server via the network, resulting in a second page being supplied to the requesting user. Similarly, a graphical icon of an electrical drill is provided for the electrical selection. Placing the cursor over this icon and operating a mouse button will result in a new page being supplied from the server containing electrical goods. This page may take the form of a second level contents page allowing further selections to be made. Thus, the next page may identify particular types of electrical goods, electrical DIY goods, white goods or hi-fi goods etc. Similarly, a button may be selected at this second level resulting in new icons and products being displayed. Thus, electrical DIY goods may again be sub-divided down into drills, sanding machines, electric screwdrivers etc.

A third icon shows a graphical image of a computer and, similarly, selecting this icon will result in a second level contents page being supplied identifying types of computer equipment. A fourth icon shows a silhouette of children at play and operation of a mouse button with the cursor placed over this icon will result in a call being made to the server and a new page being generated identifying children's games and toys.

A fifth icon shows a pair of sacks and represents gardening supplies and products, while a sixth icon shows a smartly dressed young lady as a means of identifying a reference to clothing. Thus, in a similar way, icon or icon may be selected, resulting in a call being made to the server for an appropriate page to be supplied to the browsing client.

The icons to are high definition graphical images and are stored as. GIF files, although other types of graphical format may be employed. The information used to construct the page is derived from a database and all of the information within the database may be modified, possibly in response to changes in availability and price etc. using conventional database techniques. Previously, all HTML pages were constructed and stored as such, thereby making them available when requests were issued by clients. Such an arrangement is similar to that identified at step in FIG. 5, where a predetermined file is supplied to a requesting user. In some situations such an approach provides a perfectly adequate solution. For example, technical papers and reference books tend not to change once they have been published and thereafter reference may be made to these documents for a considerable period of time. However, shopping catalogues tend to change at least seasonally and retailers would clearly prefer to make special deals available to customers as and when they themselves can make arrangements with their suppliers. Clearly, an inability to respond to market changes in this way would place the on-line retailer at a disadvantage when compared to traditional retailing activities. In other situations the shelf-life of data may be even lower. Thus, magazines are monthly or weekly, while most newspapers are only valid for the particular day of issue. Reducing the time scale still further, is common practice for newspapers to change during production, as new news items are received and developments take place. Thus, it is advantageous for editors to be in a position to make updates to the distributed news as and when changes occur. Clearly, when news items are broadcast using conventional radio techniques, the news bulletins are continually updated, thereby placing traditional news publications at a comparative disadvantage.

In the present embodiment the viewable data is retained on a database and signals are read from the database, representing said data, for processing in combination with second signals representing the way in which the information is to be formatted on the viewed page. In a possible configuration, HTML code could be held as a template with gaps therein for the actual viewable data, such that, in response to a request being made, the viewable data could be identified and interlaced with the formatting HTML instructions. However, in the preferred embodiment, a plurality of executable functions are provided at the server such that, in response to a particular request being made a string of functions are executed resulting in calls being made to appropriate databases in order to obtain viewable information. This viewable information is then processed so as to combine it with HTML tags, to produce output signals for transmission to browsing clients.

HTML instructions for generating the viewable image displayed on monitor are detailed in FIG. . Line includes the viewable text (home shopper) and this has been embedded within tags to identify this word as being at the head of the document and as being a title for the whole page. At line the tag identifies the start of the body of the document and within the body of the document a sub-heading “Contents Page” is displayed surrounded by formatting tags H. Line consists of an HTML instruction to create a horizontal line . The instructions from line onwards create the icons to , along with the hyperlinks associated with said icons required in order to allow subsequent pages to be requested by a user.

Each icon is described by two lines, thus icon is defined by lines and , icon is defined by lines and , icon is defined by lines and , icon is defined by lines and , icon is defined by lines and and icon is defined by lines and . The viewable image is effectively constructed on a line-by-line basis, therefore the instructions effectively originate from left to right, and then from top to bottom. After the sports icon, the word “sports”, the electrical icon and the wording “electrical” have been processed, it is necessary to create a new line and paragraph breaks of this type are generated by the p tag, as present at lines , and . As previously stated, each selectable icon is generated from two lines, the first of which, for example line , defines the hyperlink to another page, by means of a URL to the server. The URL defined at line would be recognised as a request for an on-line processing by the server. Subsequent parameters increment from 1000, to 1001, to 1002, to 1003, to 1004 and to 1005, so as to uniquely identify the requested page.

The second line for each entry, for example line , specifies the location of the graphical icon, thus the sports icon has been stored in a file identified as “sport.gif”, while the electrical icon, defined at line , has been stored as “elec.gif”, the computer equipment icon has been stored as “comp.gif”, the children icon has been stored as “child.gif”, the gardening icon has been stored as “gard.gif” and the clothing icon has been stored as “cith.gif”. The subsequent coding specifies the location of the icon within the page so as to complete the overall formatting requirements.

From a user's point of view, the image displayed on monitor appears like a high-quality high-definition video image, so as to ensure that a user is not alienated by the system. However, from a transmission point of view, the image displayed on monitor is generated by the instructions shown in FIG. . This requires a sophisticated level of processing to be performed by the transmitting server and by the receiving browser but the level of bandwidth required in order to perform the transmission of information is substantially reduced. The transmitted output signal consists of eight data bits for each of the ASCII characters represented in FIG. .

Although the bandwidth requirement for transmitting an HTML file of the type shown in FIG. 8 is significantly reduced, when compared to video transmissions, it can be appreciated that the manual generation of a file of the type shown in FIG. 8 would be extremely time consuming, resulting in economic difficulties for anyone wishing to use the technology for distributing information having a short shelf-life, having relatively low value or having both a short life and a low value. In accordance with the present system, it is possible for the information to be derived from conventional databases and for the HTML instructions to be generated on-the-fly, as requests are made by browsing clients. Thus, the generation of instructions of the type shown in FIG. 8 becomes an automated technical process performed in response to strings of code generated functions stored at the server.

HTML output pages are created by assembling portions of HTML instructions, so as to create a page suitable for generating output signals, of the type shown in FIG. .

Each portion of output HTML instructions is created by executing a particular function. This function is arranged to process data from a database or databases in the form of viewable data. This viewable data is then processed under the control of the selected function in order to generate a portion of output HTML. A format function of this type may be considered as the smallest unit of instructions for producing a portion of HTML code.

The system as a whole includes a universal family set of all the available functions which may be used in order to generate portions of HTML code. As the system develops, new functions may be added to the family set and it is expected that the HTML standard will be enhanced, thereby requiring additional functions to be created. For any particular application, it is likely that not all of the possible functions will be required, therefore functions may be selected from the universal sets of all available functions. Selected functions are known to both the browser and the server. The browser issues URLs to the server that are understood by the server, resulting in the required HTML page being transmitted back to the browser.

It is possible that a particular server may be configured to run a plurality of applications and that said applications may require a different sub-set of formatting functions derived from a universal set of available functions. In order to accommodate this situation, an initialisation process is performed by the on-line processing routines in order to assemble the required formatting functions in a way which enhances on-line processing speeds.

The formatting functions are arranged to generate small portions of HTML code, such that the universal set of formatting functions is minimised and so that any required output page may be generated by stringing formatting functions together. The pre-processing initialisation procedures consist of identifying strings of formatting functions required to generate particular lines of HTML code. Thus, a particular line of HTML code is produced by sequentially executing a string of formatting functions and the pre-processing step consists of arranging such function strings such that a particular function string, arranged to generate a HTML page, may be quickly sought and executed during on-line operation.

One function string will generate a particular line of HTML code. In most applications, not all lines will take up the same format, therefore it is necessary to generate a plurality of function strings. These function strings are arranged in a string list, with an indexing pointer being provided so as to enable a particular function string to be quickly identified from the list and thereafter executed in order to generate the output HTML instructions.

Initialisation step is detailed in FIG. . At step the system is effectively activated, which may consist of applying power to the system resulting in an automatic “boot-up” or may consist of a selection being made to perform the particular task, in preference to a previous unrelated task.

At step the operating system is initialised and the system configured so as to facilitate connections to the Internet. This initialisation also includes all standard processes to load peripheral drivers etc., thereby placing the system in an operational condition.

At step conventional procedures are executed in order to initialise the HTTP daemon, whereafter procedures are performed to initialise the on-line processing procedures associated with the present embodiment.

At step a question is asked as to whether another function string is to be generated which, on the first iteration, should be answered in the affirmative. At step the functions required to create the particular string, drawn from the universal set of available functions, are identified and at step the string itself is assembled by listing the functions for sequential processing with data derived from the database or databases. Thus, at step a complete function string is created.

At step the function string generated at step is appended to the string list created for that particular application and at step an indexing reference is identified within the list of strings. Thus, when a particular call is made for formatting signals, in the form of an executable string of functions, the particular call identifies the index reference within the list of strings, resulting in the selected index being selected from the list and thereafter executed in combination with the referenced data.

Thereafter, control is returned to step thereby allowing the next function string to be processed. Eventually, all of the function strings will have been created, appended to the string list and appropriately indexed, resulting in the question asked at step being answered in the negative and control being directed to step . At step procedures are implemented to initialise databases, so that data may be accessed from said databases in accordance with conventional techniques.

The on-line file preparation steps, identified in FIG. 5, are detailed in FIG. . At step the incoming URL, previously processed by the HTTP daemon as illustrated in FIG. 5 is buffered within a data structure defined by the on-line processing routines. The URL will include an element identifying the data required, an element identifying the type of formatting required, information relating to the user and a check sum, so as to reject URLs corrupted during transmission.

At step a question is asked as to whether the check sum is valid and if this question is answered in the negative, to the effect that the check sum is invalid, control is directed to step resulting in an error message being returned to the browsing client device.

Similarly, a question is asked at step as to whether the user identification is valid. In order for this question to be answered, it is necessary for a call to be made to a user database which will return an indication as to whether the user can be identified from the database. If it is found that the user ID is not presently available from the database, routines may be called which enable a user to be treated as a new user and open an appropriate account while remaining on-line. Thus, for example, these routines may request the user to supply credit card details etc. so that an account may be established immediately.

In addition, the analysis of the user ID at step allows additional information to be drawn from the user database relating to that specific user. If a user ID has become invalid, the question asked at step may be answered in the negative, again resulting in control being directed to step and an error message being directed to the browsing client.

After the check sum has been validated and the user ID has been validated, a question is asked at step as to whether the data identifier is valid. Identifiers for data are placed within established formats, thus if the server is unable to identify the data being requested, an error message will be generated at step . Similarly, an identifier for the formatting requested is validated at step , which may again result in an error message being generated at step .

After the data identifier and the format identifier have been validated at their respective steps, the HTML page or pages are generated at step with reference to the data identifier and the format identifier. Thereafter, with reference to the user ID, the pages are supplied back to the requesting browser via the network.

After pages have been supplied back to the browsing client, the system is aware of this fact and therefore has information as to what was actually supplied to a user at a particular time. In some systems, this information may be considered as having no value and therefore no further action is taken. However, in alternative systems, particularly when products are being sold, marketing information may be considered as highly valuable, therefore provision is made for this information (i.e. an indication of what pages were viewed at what particular time) to be written back to the user database at step . Thus, over time, information will become available relating to user preferences which, under some circumstances, may be used to modify the operation of the system.

It will be appreciated that, during normal operation of the system, various portions of the data will be used on more than one occasion. Thus, in accordance with conventional techniques, data read from a database may be cached such that, on a second iteration, the data may be more readily available, thereby making it unnecessary to make an additional call to the user database . The system may be configured such that data is held in cache for a predetermined period, say thirty minutes. Thus, if no use is made of the data within thirty minutes, the cache may be flushed such that, at any time, data held in the cache represents a snapshot of users who are actually making use of the system.

A diagrammatic representation of processing unit along with its associated RAM , when configured to execute the on-line processing instructions is shown in FIG. . The hypertext transport protocol daemon is shown diagrammatically on the left of FIG. and is arranged to supply URLs to an input URL buffer and to receive output HTML data from an output HTML buffer . The on-line processor (processor of FIG. 3 arranged to execute the on-line processing procedures of FIG. 4) communicates with the user database as shown in FIG. . In addition, the processor is arranged to access strings from a string list store , to access viewable text from a text database and to access viewable graphics from a graphics database . Each of the databases and the string list store is relational, in that an index, known to the processor relates to a particular database entry. Thus, in response to the processor pointing to an index, the related data is returned back to the processor . Thus, the string list store includes a string index portion and the actual string list portion . Function strings are added to the string list portion at step of FIG. 9 with their related index reference being added to portion at step . The processor makes a request in terms of identifying a particular index reference, stored in portion . This index is related to a particular string held in portion . Thus, it is possible to adjust the relationship between indexes and strings, thereby adjusting the way in which the data is actually formatted in response to a particular request.

Similarly, text data in a text database consists of the text data itself in portion and related text data indexes in portion . Thus, data is selected from database by the on-line processor issuing a particular index to portion , resulting in the related data, from portion , being returned to the on-line processor . Thus, it is the indices that are known to the on-line processor and the relationship between indices and their related text data may be adjusted, so as to change the actual data that is returned in response to a particular request being made.

The graphics database is also divided into related portions, consisting of an index portion and a data portion . Thus, in response to the on-line processor identifying a particular reference within portion , graphical data is read from portion .

As previously stated, a string read from portion . consists of a string of executable functions. Thus, these functions are supplied to the on-line processor for execution on said processor. Execution of a function read from the string list may result in HTML tags being written directly to the output HTML buffer . Alternatively, execution of these functions may result in a call being made to the text database or to the graphics database . In either event, the call identifies an index, in portion or portion , which in turn results in the related text data or graphics data being supplied directly to the output HTML buffer .

Thus, the input URL will identify particular types of formatting and particular types of data. The formatting information for the URL will result in particular function strings being read from the string list store . Thereafter, these functions are executed, with reference to the data identifiers, resulting in text data and graphics data being read from the respective databases and . As the functions are executed, output HTML is written to the output HTML buffer and after an identified set of functions have been executed, the HTML stored in output buffer is read, so as to supply the output HTML signals to the HTTP daemon .

In addition to using the user database to confirm user validity and to record actions made by the user (possibly for billing purposes) the on-line processor may also make use of information read from the user database in order to adjust the relationship between indexes (, , ) and their associated function strings and data (, , ). Thus, it is possible for the processor to respond to a URL in one of three ways. Firstly, in a standard mode of operation, the particular output HTML produced in response to a particular input URL will remain constant. The user database is merely used to check user validity and to record user usage of the system. Thus, output data is not dependent upon user type and all users are supplied with the same data. However, adjustments may be made to the relationship within databases over time, such that updates or upgrades may be made to take account of the circumstances.

Thus, for an in-home shopping situation, the availability of goods and changes in prices may be reflected in database relationships. Similarly, in on-line journals and newspapers, the data relationship may be adjusted in response to editorial control, usually driven by news events. Thus, in a news environment, it is not necessary for editors to create new HTML documents if they wish to supply new documents in this format to users. All the formatting required to produce a page in a particular form is provided within the formatting functions. Thus, in order to update a news item, an editor is merely required to update information contained in the database (usually database ) in accordance with conventional database techniques.

As stated above, it is possible for the processor to respond to the URL in one of three possible ways. In a second enhanced mode of operation, it is possible for the user to identify information to the system as a means of expressing user preferences. Thus, in a home shopping environment for example, it is possible for a user to specify the particular goods of interest. Thus, for example, one user may only use the on-line shopping facility when shopping for gardening supplies. The user may relay this information to the system, such that the system will concentrate on gardening products. Thus, on initiating the system, the first URL will result in a reference to gardening supplies, thereby avoiding the first screen shown in FIG. 7, where the client has little interest. The client will still be able to access all of the available functions. For example, the second screen, containing predominantly gardening products, would include a link for “other areas” and on executing this button the user would be effectively supplied with the higher level page, thereby allowing his selections to branch out into the other areas of the on-line catalogue. In a more sophisticated system, the user may only be interested in electrical equipment and sports equipment, such that a first screen would display the sports icon followed by particular types of sport, in combination with the electrical icon followed by particular electrical products. Thus, it is possible for the user to specify preferences such that the system becomes more tailor-made and specific to that particular user.

Such an approach may also be used in news publications. For example, some users may be interested predominantly in financial news while others may be interested in sports news. Thus, with this information programmed into the user database, the order in which pages are supplied to a user may be adjusted in accordance with preferences specified by the user. It will also be possible for users to specify whether the material is being read by children or by adults and for appropriate page selections to be made. Pages designed for children could be written using limited vocabularies and include a higher concentration of hyperlinks, allowing children to rapidly access related information. In many situations, some pages would be appropriate for both types of users and editors would have control as to what is made available at what levels. Similarly, higher charges could be made for particular types of information and, given information derived from the user database, low priced pages or high priced pages could be supplied as appropriate.

In a third mode of operation, identified as a recursive mode of operation, it is not necessary for a user to identify their own preferences in order for adjustments to be made to the actual nature of pages returned to users. The system records a history of usage and thereafter analyses this information in order to determine the relationship between selections made by a browser and the actual data returned back to the customer. Thus, after a number of uses, it may become apparent that a user is only interested in clothing and has shown very little interest in other products available from the catalogue. On detecting this interest, it will be possible for the system to present the clothing page as the first page sent to the user on initiation. Moving on from this, it may be possible to identify particular types of clothing that are of interest to a user. Thus, for example, a user may be only interested in designer labels and having identified this information, it would be possible for the system to give a higher priority to special offers available in this area. Thus, information may be supplied to the system to the effect that a new limited edition has been produced which may be of particular interest to a minority of users of the system. A region may be provided within an initial page to provide special information or advertisements. A particular type of information or advertisement supplied to this region will depend upon customer history. Thus, if information has been supplied to the effect that a limited edition has become available, the system will automatically know which users are interested in obtaining items of this type. Thus, when this particular sub-set of users log on to the system, the relevant information will be supplied back to them automatically. Similarly, an advertisement for a designer jacket, for example, will not be sent to a user who has previously only shown an interest in computer equipment.

The system will be capable of identifying situations in which particular products have been browsed for significant periods of time by users. The system could be programmed to identify this fact and make an appropriate modification when the user next logs on to the system. For example, having detected that a particular user has shown an interest in a particular product, it may be assumed that a customer is interested in buying this product but, as yet, has not made a final decision. The system may use this information in an attempt to persuade the client to make the purchase. Thus, the system may be programmed to offer discounts to clients such that, on the next use of the system, an advertisement appears to the effect that the product of interest has been reduced by a certain amount. Thus, it is possible that users would perceive this as an offer being made to all clients, with the fact that they have a particular interest in that product being seen as a coincidence. Clearly this is not a coincidence and each user would be offered something which the system had detected as being to their liking.

It can be appreciated that the possibilities are endless. This is all provided by the fact that the actual HTML pages supplied back to users are generated “on-the-fly” by indexing locations within databases. The relationship between an index and an item may be adjusted so that the same instructions may be used to access different data with on-going changes. Similarly, the system may identify the particular user concerned and, in response to this information, select an index which differs from the normal index selected. Alternatively, a particular index identified by a user may be treated by the system as a “wild card”, with an actual selection of an index being made in response to information stored about the particular user.

Operations performed by processor , as illustrated in FIG. 11, are detailed in FIG. . At step a data string index is identified enabling the processor to make a call to an appropriate database. At step a call to the database is made, by issuing the string indexed to the appropriate database, resulting in the data string itself being returned from the database to the processor . Thus, as shown in FIG. 11, the read operation performed at step would result in an index command being issued from the processor to the indexed portion of database , whereafter the appropriate data, from portion , is returned back to the processor .

At step a function string index is identified, from the formatting information present in the URL and at step the indexed function string is read from the string list store .

At step the function string read from the string list store is executed, resulting in HTML code being written to the output HTML buffer , whereafter, at step , a question is asked as to whether another function string has been identified. If this question is answered in the affirmative, control is returned to step and the procedures identified above are repeated. Eventually, the question asked at step will be answered in the negative, resulting in the completion of procedures within step .

Step , for the execution of a string function, is expanded in FIG. 13. A string of functions has been read from the string list store and this string of functions is executed, sequentially function by function, at step .

At step the next function, i.e. the first function an the first iteration, is read from the function string. At step this particular function is executed, resulting in a unit of HTML code being written to the output HTML buffer at step . At step a question is asked as to whether a function includes a further functional step and if answered in the affirmative, control is returned to step for the next function step to be executed. Thus, a functional step may be considered as the smallest portion of a function that results in a write to the HTML buffer.

After all the executable steps of the function have been completed, the question asked at step will be answered in the negative, resulting in a question being asked at step as to whether another function is present in the string. If another function is present in the string, the question asked at step will be answered in the affirmative, thereby returning control to step . Thus, steps , , and are repeated in order to execute the next executable function within the string read from the string list store.

Eventually, all of the functions making up the string will have been executed, resulting in the question asked at step being answered in the negative so as to complete procedures within step .

The functions executed over steps to will have been created so as to generate the particular HTML code required. An example of a function is shown in FIG. and it should be appreciated that similar techniques are employed in order to generate all of the available types of HTML code. The function shown in FIG. 14, that may be considered as being executed at step of FIG. 13, is used to generate the first line of the example HTML code shown in FIG. .

A first functional step, shown as step , writes the tags “” as the start of line . These tags are written to the output HTML buffer at step and thereafter the question asked at step would be answered in the affirmative, resulting in the next functional step being executed at step . In the example shown in FIG. 14, this would consist of the execution of step , consisting of a write to the output HTML buffer of the viewable data “Home Shopper”. This particular portion of the code is derived by making a call to the text database. Thus, the write instruction consists of a database index. Database is identified, along with index position . Thus, it is known that at index position in the text database the title of the first page has been stored. Thus, as part of an editing procedure it may be decided that the title should be changed to “Shopping at Home” for example. When a change of this type is required, it is only necessary for an editor to make a change to the database entry stored at index position in database . This can be achieved using conventional database techniques, without any specialist knowledge required of the HTML language used to transmit the information over the Internet. The operation of the system is unaffected by this change of title and the procedure shown at step will execute as required, irrespective of the nature of the actual title text contained within the database.</p><p>Thus, at step database is identified, an address to that database is made in the form of identifying index and text is returned to the processor . This text is then supplied to the next location of the output HTML buffer at step and control is directed to step , where the question is again asked as to whether another functional step is present. Again, this question will be answered in the affirmative, resulting in control being returned to step so that the next functional step may be executed. As shown in FIG. 14, the next executable step consists of step which will result in “<TITLE><HEAD>” being written to the output HTML buffer at step . Again, the question will be asked at step as to whether another functional step is present an on this occasion the question will be answered in the negative, resulting in control being directed to step .</p><p>Thus, it can be seen that a particular function has resulted in three writing operations to the output HTML buffer in the form of a tag, viewable text obtained from a database, followed by another HTML tag. This process is repeated for each of the functions contained within the function string until the full page of HTML code has been generated and written to the HTML buffer . Signals from the HTML buffer are then supplied to the HTTPD which in turn supplies the signals to the browsing client via the Internet</p><p>The databases for storing text and graphics are of conventional types, having mechanisms for requests to be made for information to be supplied. In particular, requests to databases are made using the structured query language (SQL) and data is obtained from the databases by generating an SQL enquiry.</p> </div> <!-- details end --> <!-- claims --> <div class="post"> <h2>CLAIMS</h2> <p> 1. A method for serving files to browsing clients in response to requests made by said browsing clients, wherein said requests comprise a URL containing said user identification data and said URL includes a check sum, the method comprising: identifying a user by the inclusion of user identification data included in requests made by a browsing client; processing first signals which represent human viewable data; receiving second signals that represent a selected display structure; processing said first signals and said second signals to produce output signals that are served to the requesting browsing client; recording and analyzing a history of usage to identify topics of interest; prior to said first signals being processed with said second signals, selecting specific first signals in response to a user's own history of use in order to direct information of interest to a requesting browsing client; and determining whether said check sum is valid before serving output signals to said browsing client. </p><p> 2. A method according to <span class="US-6826565-B2-CLM-00001">claim 1</span>, wherein said output signals represent HTML files. </p><p> 3. A method according to <span class="US-6826565-B2-CLM-00001">claim 1</span>, wherein said first signals are derived from human viewable data read from a text and/or graphics database and a selection is made from said text and/or graphics database in response to information stored about the user. </p><p> 4. A method according to <span class="US-6826565-B2-CLM-00001">claim 1</span>, wherein user related data is drawn from a user database. </p><p> 5. A method according to <span class="US-6826565-B2-CLM-00001">claim 1</span>, wherein files comprising information of products in a shopping on-line catalogue are served. </p><p> 6. A method according to <span class="US-6826565-B2-CLM-00005">claim 5</span>, wherein said serving station detects that said user has an interest in a particular one of said products and offers a discount to said user on said particular one of said products. </p><p> 7. A method according to <span class="US-6826565-B2-CLM-00001">claim 1</span>, wherein said output signals represent HTML pages; a region is provided within a page to provide advertisements; and an advertisement supplied to the region depends upon user history. </p> </div> <!-- claims end --> <!-- attachments --> <ul> </ul> <!-- attachments end --> <!-- copyright --> <div class="post"> <h2>COPYRIGHT</h2> <p>User acknowledges that Fairview Research and its third party providers retain all right, title and interest in and to this xml under applicable copyright laws. User acquires no ownership rights to this xml including but not limited to its format. User hereby accepts the terms and conditions of the License Agreement.</p> </div> <!-- copyright end --> </div> <div class="bottom_bg"></div> </div> </div> <div class="clearfix"></div> </div> <!-- ********************************************** CONTENT END ********************************************************************** --> <!-- ********************************************** FOOTER *************************************************************************** --> <!-- ********************************************** FOOTER *************************************************************************** --> <div id="footer_top"></div> <div id="footer"> <div id="footer_1"> <ul> <li><a href="/disclaimers">Regulatory Affairs and Disclaimers</a></li> <li><a href="/terms-of-use">Terms of Use</a></li> <li><a href="/privacy-notice">Privacy Notice</a></li> <li><a href="/list">List</a></li> <li><a href="/sitemap">Sitemap</a></li> <li><a href="/methodology">Methodology</a></li> <li><a href="/contact-us">Contact Us</a></li> </ul> <p class="copyright">Copyright © 2011 Patentsbase Services LLC, Inc. All right reserved. </p> </div> </div> <!-- ********************************************** FOOTER END *********************************************************************** --> <div id="footer_bottom" style=" background:url(images/design/footer_bg_bg.png) repeat #043661; width: 100%;"></div> <script type="text/javascript"> var _gaq = _gaq || []; _gaq.push(['_setAccount', 'UA-6351271-18']); _gaq.push(['_trackPageview']); (function() { var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true; ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s); })(); </script> <!-- ********************************************** FOOTER END *********************************************************************** --> </body> </html>