WO2005038662A2 - Betriebsverfahren für einen server und hiermit korrespondierende gegenstände - Google Patents

Betriebsverfahren für einen server und hiermit korrespondierende gegenstände Download PDF

Info

Publication number
WO2005038662A2
WO2005038662A2 PCT/EP2004/011489 EP2004011489W WO2005038662A2 WO 2005038662 A2 WO2005038662 A2 WO 2005038662A2 EP 2004011489 W EP2004011489 W EP 2004011489W WO 2005038662 A2 WO2005038662 A2 WO 2005038662A2
Authority
WO
WIPO (PCT)
Prior art keywords
server
übld
client
page
transmitted
Prior art date
Application number
PCT/EP2004/011489
Other languages
English (en)
French (fr)
Other versions
WO2005038662A3 (de
Inventor
Badreddine Douiri
Thomas Gysser
Frank HACKLÄNDER
Arno Pernozzoli
Original Assignee
Siemens Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to DE502004005722T priority Critical patent/DE502004005722D1/de
Priority to JP2006534674A priority patent/JP4402115B2/ja
Priority to US10/575,980 priority patent/US7702776B2/en
Priority to EP04765951A priority patent/EP1673915B1/de
Publication of WO2005038662A2 publication Critical patent/WO2005038662A2/de
Publication of WO2005038662A3 publication Critical patent/WO2005038662A3/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/957—Browsing optimisation, e.g. caching or content distillation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • the present invention relates to an operating method for a server which communicates with a client, the server transmitting the requested page to the client when the client sends it a request for a page.
  • the present invention further relates to a data carrier with a computer program stored on the data carrier for carrying out such an operating method.
  • the present invention further relates to a server with a mass storage device in which a computer program is stored, so that when the computer program is called up, such an operating method can be carried out by the server computer.
  • Such methods, computer programs and servers are generally known. They are used particularly in web applications, e.g. used in Internet and intranet applications.
  • Web applications are relatively anonymous.
  • clients know very little about each other.
  • the server it is generally not possible for the server to easily determine on the basis of a request for a page from which client the request was transmitted to it and from what state the client made the request.
  • Each request made to the server must therefore usually contain complete information about the requesting client and the requested page.
  • presettings e.g. a selection of a language that will always be used in the following
  • the server transmits an attachment file (a so-called cookie) to the client.
  • the attachment file is attached by the client to every request made to this server. It is therefore sent back from the client to the server.
  • the attachment file is specific to the server. It is therefore sent to the server by the client for every request made to this server.
  • the attachment file is transmitted until either the attachment file on the client side is deleted or a new attachment file is transmitted from the server to the client, so that the previous attachment file is overwritten.
  • the default settings to be made can be contained in the attachment file itself.
  • the attachment file can also contain a link to a memory area in the server.
  • the default settings are stored as such in the server, while in the former case they are stored in the client.
  • the state of the session is usually related to the session in the sense of the existence of the corresponding client-side communication program, e.g. an Internet browser such as Microsoft's Internet Explorer.
  • the procedure of the prior art therefore works without problems as long as the communication process is retained on the client side and the communication with the server takes place via a single window
  • attachment file does not help here either. Because a new window on the client side is just a separate window, but not a separate process. So the windows use the same tag files.
  • the object of the present invention is to create an operating method for a server, a corresponding computer program and the corresponding server, by means of which such presettings can be made individually for each client-side window.
  • the task is solved by an operating method for a server that communicates with a client, in that the server transmits the requested page to the client when the client sends it a request for a page,
  • the server attaches identification data to the page in such a way that the identification data are sent back to the server by the client in the event of a further request for a page and only if the request on the part of the client is based on this transmission of the page,
  • the identification data comprise at least one transmission identifier specific to the transmission of the page, that the server stores the identification data transmitted by it,
  • the server saves the newly transmitted transmission identifier instead of the transmitted transmission identifier when the further request is received, if the transmitted transmission identifier matches a stored transmission identifier
  • That the server saves the newly transmitted transmission identifier in addition to the back transmitted transmission identifier on receipt of the further request, if the returned transmission identifier does not match any previously stored transmission identifier.
  • This procedure does not allow the server to recognize when a second window is opened on the client side (more on this later). However, he can recognize when the client sends "outdated" identification data. Based on this circumstance, namely that the identification data is already outdated or outdated, he can therefore recognize that a second window must have been opened. From the time of this knowledge, the server is thus able to manage this second window separately from the first window.
  • the transmission identifier can be a serial number or the like.
  • the transmission identifier is preferably a unique identifier worldwide.
  • the transmission identifier can be a so-called GUID.
  • a GUID global universal identifier
  • server identification data for example an identification number of the network card of the server or the processor of the server that is assigned only once.
  • the procedure according to the invention makes it possible, for example, for selection data to be associated with the identification data and for the page newly transmitted to the client from the server to be assigned to the matching transmission identifier on the basis of the further request if the transmission identifier returned matches one of the stored transmission identifiers Selection data depends.
  • a predetermined start page can be transmitted to the client. Preferably, however, it depends on the server due to the further request
  • Client transmitted side from the selection data assigned to one of the stored transmission identifiers.
  • the server then naturally also assigns this selection data to the additionally stored transmission identifier.
  • the identification data preferably also comprise a window identifier. If the returned transmission identifier matches one of the stored transmission identifiers, it is stored in this
  • the server assigns a new window identifier to the additionally stored transmission identifier.
  • This procedure in particular enables efficient management of more than two client-side windows. Because of this procedure, the server can see which window has been duplicated on the client side. On the basis of this procedure, it is also possible that, if the transmitted transmission identifier matches with none of the stored transmission identifiers, the page newly transmitted to the client by the server on the basis of a further request depends on the selection data which are assigned to that of the stored transmission identifiers. whose window identifier matches the returned window identifier.
  • the new window identifier can - like the transmission identifier - be a serial number again. However, it is also preferably designed as a GUID. It can alternatively be designed as an independently generated GUID or be identical to the transmission identifier generated immediately before.
  • the test sequence (first the transmission identifier or only the window identifier) is in principle at the discretion of the specialist. Preferably, however, the window identifier is first checked and then the transmission identifier stored for this window identifier. The window identifier sent back by the client is always saved. The transmission identifier returned by the client, however, could already be overwritten.
  • Post requests are based on the principle that the client fills in the input fields on the page and then the completed input fields are sent back from the client to the server. In the case of post requests, all input fields are always sent back to the server by the client.
  • the transmitted data include the request for the new page.
  • the server it is therefore possible, for example, for the server to add the identification data of the transmitted page as hidden input fields which are not shown on the client side.
  • hidden input fields are added to the page, which are not displayed in a window of the client when the page is normally displayed.
  • the server has already stored the identification data in advance in these input fields. They are therefore sent back to the server by the client when the client sends a post request.
  • Link address usually a so-called URL, transmitted back to the server.
  • the link address is part of the previously transmitted page and is displayed as such in the window in which the client displays the page. If the client user selects this link address, the link address itself and immediately represents a request for another page.
  • server-side handling of such a get request in the sense of the present invention can be achieved in that the server uses the identification data of the transmitted page as parameters assigned to the address, so-called query parameters , adds.
  • a special case of a reaction of the server to the receipt of a request is a so-called server-side response redirect.
  • a server-side response redirect exists if the server does not transmit the requested page to the client on the basis of a request transmitted to it, but first receives a third request to be sent back to the server by the client when the further request is received sent the client. The server then only transmits the requested page on the basis of the transmission of the third request to the server. In this case, there are two ways of ensuring that the request is handled correctly on the server side in the sense of the present invention.
  • the server it is possible for the server to add the identification data to the third request as assigned parameters.
  • the identification data is attached to the request itself.
  • the server it is also possible for the server to attach the identification data to the third request as an attachment file, which the client does not transmit back to the server with the third request.
  • the server adds the identification data to the third request as a so-called transfer cookie.
  • the identification data is attached to the page as hidden data, as is the case with post requests.
  • the program extracts the identification data and inserts it into the attachment file.
  • the server together with the page which it sends to the client on the basis of the third request, sends a delete command for this attachment file to the client.
  • transfer cookie is also generated.
  • the transfer cookie is not generated on the server side, but on the client side.
  • the server cannot immediately recognize if the client is duplicating a page that has already been transferred to the client. Therefore, if the client user duplicates a page and then works with only one of the two versions of the duplicated page for a long time, but the other version of the duplicated page does not change, this other version remains unchanged for the time being. In this case, if the client user then sends a request to the server from the other, still unchanged version of the duplicated page at a considerably later time, the server takes over the selection data which are assigned to the changed version of the duplicated page at this time. The selection data may have already been changed considerably at this point. Restoring the state of the other version of the duplicated page that is actually desired by the user can therefore be relatively complex for the user. For this reason, it is advantageous to detect as early as possible when a page already transmitted to the client is duplicated on the client side.
  • Such a duplication can be recognized immediately by that the server also includes a variable with an initial value and a program to be executed by the client when the page is displayed in a window,
  • the client repeats the previous request to transmit the page on the basis of the program, so that the client, if the variable does not have the initial value, transmits the identification data transmitted in the previous request to the server a second time.
  • the server then repeats the previous request immediately when the page is duplicated, so that the server can immediately recognize the duplication as such.
  • the server also recognizes (incorrectly) a duplication if the client user - without duplicating the page - only updates it or accesses a page that is still saved on the client side but is no longer displayed in this window.
  • this is not critical, since in this case only a window is managed on the server side, which in reality does not exist on the client side. On the other hand, it cannot happen that a window is duplicated on the client side and the server does not recognize this.
  • the request can be sent to the server in the form of a post request or a get request. This also applies if the page was loaded for the first time on the basis of a post request.
  • the operating method according to the invention is implemented as a computer program that is fed to the server.
  • the computer program is fed to the server via a data carrier. Examples of such a data carrier are a CD-ROM or a streamer cassette.
  • the computer program is stored on the data carrier in (exclusively) machine-readable form.
  • the computer program can be ger stored alternatively in compressed or uncompressed form.
  • the data carrier with the computer program stored thereon is inserted into a reading device, by means of which the server can read the computer program stored on the data carrier. It therefore reads the computer program from the data carrier and stores it in a mass storage device, for example on a hard disk.
  • the server is therefore able to carry out the operating method according to the invention.
  • a server 1 is connected to a client 3 via a computer-computer connection 2.
  • the computer-computer connection 2 can be designed in various ways. As a rule, however, it is designed as an Internet or intranet connection.
  • the server 1 and the client 3 can communicate with one another in accordance with a web protocol via the computer-computer connection 2.
  • the server 1 has a plurality of components 4 to 8 which are connected to one another via a bus 9.
  • the components 4 to 8 include in particular a processor 4, a mass memory 5 (typically one or more hard disks), a reader 6, a timer 7 and a network card 8.
  • a data carrier 10 can be inserted into the reading device 6, on which a computer program 11 is stored in an exclusively machine-readable form.
  • This computer program 11 is read from the data carrier 10 and, as indicated by the dashed line in FIG. 1, is stored in the mass storage device 5.
  • the server 1 is therefore able to execute the computer program 11.
  • the server 1 executes an operating method which is described in more detail below in connection with FIG. 2.
  • the server 1 receives a registration and a first request for a page from the client 3 in a step S1.
  • the server 1 determines a transmission identifiercommunld in a step S2.
  • the transmission identifiercommunld is preferably unique worldwide. For example, it can consist of a combination of the time output by the timer 7 and the code of the network card 8 and / or the processor 4.
  • a window identifier field is then set equal to the transmission identifiercoastld that has just been determined.
  • the two identifiersdaleld, field are then entered in the first line of a table 12 - see FIG. 3 in addition.
  • selection data SD can also be assigned to each row of table 12 in addition to the two identifiersfelld, field. The meaning of the selection data SD will be discussed below.
  • a step S5 the server 1 adds the identification data fieldontld to the requested page.
  • the attachment takes place in such a way that the identification data field,vinld in the case of a further request for a page is then transmitted back from the client 3 to the server 1 only when the request on the part of the client 3 starts from the transmission of this page.
  • the server 1 continues to add a variable and a program to the requested page.
  • the variable has an initial value.
  • the program is designed in such a way that when the transferred page is copied on the client side, it triggers a new request for the previous page. This will be discussed in more detail later.
  • Step S6 is only optional and is therefore only shown in broken lines in FIG.
  • the server 1 transmits the requested page, including the information attached to this page, to the client 3.
  • the attached information is, in particular, the two identifiersfelld, field, their additions, as well as the variable and the program.
  • step S8 the server 1 receives a further input from the client 3.
  • the server 1 then first checks in a step S9 whether the client 3 has logged off. If this is the case, it deletes table 12 in step S10 and ends the execution of the method.
  • step S8 If the entry of step S8 was not a deregistration, it was a new request. In this case, the server 1 extracts the returned identifierrodld, field and the selection data SD from the transmitted request.
  • step S12 the server 1 then checks whether the transmission identifierrodld transmitted back matches the transmission identifierrodld, which in table 12 is assigned to the window identifier field transmitted back.
  • step S12 in FIG. 2 is divided into two substeps S12a, S12b.
  • sub-step S12a a logical variable is assigned in accordance with the test to be carried out
  • sub-step S12b the logical variable is queried. If a match was determined in step S12, the request transmitted by the client 3 is based on a window of the client 3 that has already been detected and managed on the server side.
  • a new transmission identifiertungld is determined in a step S13 analogously to step S2 and stored in table 12 in the line in which the window identifier field transmitted back is also stored.
  • the server 1 therefore stores the newly determined transmission identifiercontactedld instead of the back-transmitted transmission identifierrodld in table 12.
  • step S14 is carried out.
  • the transmission identifierrodld is also newly determined analogously to the procedure in step S2.
  • the window identifier field is set in the same way as in step S3 to the newly determined transmission identifierloisld.
  • Both identifiers field,grownld are entered by server 1 in a new row of table 12.
  • the selection data SD which are assigned to the window identifier field transmitted back, are copied into the now newly occupied line in table 12.
  • step S15 the selection data SD which are assigned to the current window identifier field.
  • this is the window identifier field transmitted back or the newly determined window identifier field.
  • a step S1 the server 1 next checks whether it can transmit the requested page directly or whether it has to carry out a so-called response redirect. If he If a response redirect has to be carried out, it carries out a step S17 in which it transmits a new address, usually a URL address, plus the current window identifier field and the current transmission identifierrodld to the client 3. Then he jumps back to step S8.
  • the server 1 uses the selection data associated with the current window identifier field and the current transmission identifierrodld in table 12 to determine which page is to be transmitted to the client 3. As an alternative or in addition, the content of the page can also be modified. The server 1 then jumps back to step S5.
  • the server 1 initially adds the identifiersfelld, field in a step S19 as hidden input fields. This has the effect that the identifiersfelld and field are transmitted from the client 3 to the server 1 with each post request from the client 3 that originates from this side.
  • step S20 the server 1 then checks whether the page to be transmitted contains a URL address to which the identifiersfelld and field have not yet been added as query parameters. If this is the case, the server 1 executes a step S21 in which it adds the identifiersfelld and field to this address as query parameters. The server then returns from step S21 to step S20.
  • Step S20 in FIG. 4 - analogous to step S12 in FIG. 2 - is divided into two substeps.
  • the server 1 adds the identifiersfelld and field to the page as included data. Analogous to step S19 in FIG. 4, these can be hidden input fields. However, this is not absolutely necessary.
  • the server 1 then adds a program to the page, which is executed when the client 3 requests this page. Based on the program, the client 3 then extracts the identification datarodld, Feld from this page and integrates it into a cookie to be created by it. The client 3 sends the cookie together with the request to the server 1.
  • FIG. 6 shows the possibilities that exist for implementing step S17 of FIG. 2, in which the identifiers field andrierld are added to the URL to be transmitted. According to FIG. 6, it is possible to configure step S17 in such a way that the identifierswovenld and field - analogous to the step
  • server 1 may add a tag file (cookie) to the URL address in step S17, which file contains the identifiersfelld, field.
  • cookie the information to the client 3 added to the requested page in step S7 (see FIG. 2) should contain a delete command, on the basis of which this attachment file on the client 3 side is immediately deleted again.
  • FIG. 7 now shows the method that the client 3 executes on the basis of the program that the server 1 adds to the requested page in the step S6 (see FIG. 2).
  • the program is always executed by the client 3 when the page is displayed by it in a window.
  • the program is therefore executed both when the client 3 receives the page for the first time and also then, if the client 3 duplicates the page, for example with "control N".
  • the client 3 first extracts the transmitted variable from the page. In a step S25, he then checks whether the variable still has its initial value. If this is the case, he sets the variable to its final value in a step S26. The final value must of course be different from the initial value. Otherwise it can be chosen arbitrarily. If the check in step S25 did not find a match, the client 3 executes a step S27 in which it repeats the previous request. The repetition of the request in particular has the effect that the identification dataplanld, field that has already been transmitted back to the server 1 is transmitted to the server 1 a second time. As a result, the server 1 is immediately able to recognize that a new window has been opened on the client side.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Data Mining & Analysis (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

Ein Server (1) kommuniziert mit einem Client (3), indem er diesem vom Client (3) angeforderte Seiten übermittelt. Er fügt den Seiten aber Identifizierungsdaten (ÜbId, FeId), die zumindest einen für die Übermittlung der Seite spezifischen Übermittlungsidentifizierer (ÜbId) umfassen, derart bei, dass sie bei einer weiteren Anforderung für eine Seite vom Client (3) dann und nur dann an den Server (1) zurück übermittelt werden, wenn die Anforderung auf Seiten des Clients (3) von dieser Übermittlung der Seite ausgeht. Ferner speichert der Server (1) die von ihm übermittelten Identifizierungsdaten (ÜbId, FeId) ab. Stimmt der zurück übermittelte Übermittlung­sidentifizierer (ÜbId) mit einem abspeicherten Übermittlung­sidentifizierer (ÜbId) überein, so speichert der Server (1) bei Erhalt der weiteren Anforderung den von ihm neu übermittelten Übermittlungsidentifizierer (ÜbId) anstelle des zurück übermittelten Übermittlungsidentifizierers (ÜbId) ab. Ande­renfalls speichert er ihn zusätzlich zum zurück übermittelten Übermittlungsidentifizierer (ÜbId) ab.

Description

Beschreibung
Betriebsverfahren für einen Server und hiermit korrespondierende Gegenstände
Die vorliegende Erfindung betrifft ein Betriebsverfahren für einen Server, der mit einem Client kommuniziert, wobei der Server, wenn ihm vom Client eine Anforderung für eine Seite übermittelt wird, die angeforderte Seite an den Client über- ittelt.
Die vorliegende Erfindung betrifft ferner einen Datenträger mit einem auf dem Datenträger gespeicherten Computerprogramm zur Durchführung eines derartigen Betriebsverfahrens.
Die vorliegende Erfindung betrifft weiterhin einen Server mit einem Massenspeicher, in dem ein Computerprogramm hinterlegt ist, so dass bei Aufruf des Computerprogramms von dem Server Rechner ein derartiges Betriebsverfahren ausführbar ist.
Derartige Verfahren, Computerprogramme und Server sind allgemein bekannt. Sie werden insbesondere bei Web-Anwendungen, z.B. bei Internet- und Intranet-Anwendungen, eingesetzt.
Web-Anwendungen sind relativ anonym. Der Server und der
Client wissen in aller Regel sehr wenig voneinander. Insbesondere ist es dem Server in aller Regel nicht möglich, anhand einer Anforderung für eine Seite ohne Weiteres zu ermitteln, von welchem Client ihm diese Anforderung übermittelt wurde und aus welchem Zustand des Clients heraus die Anforderung erfolgte. Jede an der Server gerichtete Anforderung muss daher in der Regel eine vollständige Information über den anfordernden Client und über die angeforderte Seite enthalten.
Um innerhalb einer Sitzung zwischen Server und Client (= Session) serverseitig dennoch gewisse Voreinstellungen (z.B. eine Auswahl einer Sprache, die im Folgenden stets benutzt wer- den soll) treffen zu können, ist es insbesondere bekannt, dass der Client sich zu Beginn der Sitzung beim Server anmeldet und dieser zusätzlich zur angeforderten Seite eine Anhängseldatei (ein sogenanntes Cookie) an den Client übermit- telt. Die Anhängseldatei wird vom Client jeder an diesen Server gerichteten Anforderung beigefügt. Sie wird also vom Client an den Server zurück übermittelt. Die Anhängseldatei ist dabei spezifisch für den Server. Sie wird vom Client also bei jeder an diesen Server gerichteten Anforderung mit an den Server übermittelt. Die Übermittlung der Anhängseldatei erfolgt so lange, bis entweder die Anhängseldatei auf Seiten des Clients gelöscht wird oder vom Server eine neue Anhängseldatei an den Client übermittelt wird, so dass die bisherige Anhängseldatei überschrieben wird.
Die Voreinstellungen, die getroffen werden sollen, können in der Anhängseldatei selbst enthalten sein. Alternativ kann die Anhängseldatei auch einen Link auf einen Speicherbereich im Server enthalten. In diesem Fall sind die Voreinstellungen als solche im Server gespeichert, während sie im erstgenannten Fall im Client gespeichert sind.
Der Zustand der Sitzung ist üblicherweise an die Sitzung im Sinne der Existenz des korrespondierenden clientseitigen Kom- munikationsprogramms, z.B. eines Internetbrowsers wie dem Internetexplorer von Microsoft, gebunden. Die Vorgehensweise des Standes der Technik funktioniert daher problemlos, solange auf Seiten des Clients der Kommunikationsprozess erhalten bleibt und die Kommunikation mit dem Server über ein einziges Fenster erfolgt
Es ist aber allgemein bekannt, dass es möglich ist, in ein und demselben Internetbrowser parallel mehrere Fenster zu nutzen. Die Erzeugung mehrerer Fenster kann z. B. beim Inter- netexplorer von Microsoft durch Betätigen der Tastenkombination "Steuerung N" oder durch Wählen der Option "Öffnen in neuem Fenster" erfolgen. Auch in diesem Fall bereitet der Standes der Technik noch keine Probleme, wenn auf Seiten des Clients zwar mehrere Fenster genutzt werden, in allen Fenstern aber stets dieselben Voreinstellungen benutzt werden.
Die Vorgehensweise des Standes der Technik versagt aber, wenn auf Seiten des Clients mit mehreren Fenstern gearbeitet wird und in den Fenstern voneinander verschiedene Voreinstellungen getroffen werden sollen. Denn wie bereits erwähnt, ist der Server nicht in der Lage, zu unterscheiden, von welchem der Fenster die jeweilige Anforderung an ihn übermittelt wurde.
Dabei hilft auch die Verwendung der Anhängseldatei nicht weiter. Denn ein neues Fenster auf Seiten des Clients ist eben nur ein eigenes Fenster, nicht aber ein eigener Prozess. Somit benutzen die Fenster die gleichen Anhängseldateien.
Die Aufgabe der vorliegenden Erfindung besteht darin, ein Betriebsverfahren für einen Server, ein hiermit korrespondierendes Computerprogramm und den entsprechenden Server zu schaffen, mittels derer derartige Voreinstellungen individu- eil für jedes clientseitige Fenster vorgenommen werden können.
Die Aufgabe wird durch ein Betriebsverfahren für einen Server, der mit einem Client kommuniziert, dadurch gelöst, - dass der Server, wenn ihm vom Client eine Anforderung für eine Seite übermittelt wird, die angeforderte Seite an den Client übermittelt,
- dass der Server der Seite Identifizierungsdaten derart beifügt, dass die Identifizierungsdaten bei einer weiteren An- forderung für eine Seite vom Client dann und nur dann an den Server zurück übermittelt werden, wenn die Anforderung auf Seiten des Clients von dieser Übermittlung der Seite ausgeht,
- dass die Identifizierungsdaten zumindest einen für die Übermittlung der Seite spezifischen Übermittlungsidentifizierer umfassen, - dass der Server die von ihm übermittelten Identifizierungsdaten abspeichert,
- dass der Server bei Erhalt der weiteren Anforderung den von ihm neu übermittelten Übermittlungsidentifizierer anstelle des zurück übermittelten Übermittlungsidentifizierers abspeichert, wenn der zurück übermittelte Übermittlungsidentifizierer mit einem abspeicherten Übermittlungsidentifizierer übereinstimmt, und
- dass der Server bei Erhalt der weiteren Anforderung den von ihm neu übermittelten Übermittlungsidentifizierer zusätzlich zum zurück übermittelten Übermittlungsidentifizierer abspeichert, wenn der zurück übermittelte Übermittlungsidentifizierer mit keinem zuvor abspeicherten Übermittlungsidentifizierer übereinstimmt.
Durch diese Vorgehensweise kann der Server nämlich zwar noch nicht erkennen, wenn auf Seiten des Clients ein zweites Fenster geöffnet wird (dazu später) . Er kann aber erkennen, wenn ihm vom Client "veraltete" Identifizierungsdaten übermittelt werden. Anhand dieses ümstands, nämlich dass die Identifizierungsdaten bereits veraltet bzw. überholt sind, kann er daher erkennen, dass ein zweites Fenster geöffnet worden sein muss. Ab dem Zeitpunkt dieser Erkenntnis ist der Server somit in der Lage, dieses zweite Fenster getrennt vom ersten Fenster zu verwalten.
Der Übermittlungsidentifizierer kann im einfachsten Fall eine laufende Nummer oder dergleichen sein. Vorzugsweise aber ist der Übermittlungsidentifizierer ein weltweit einmaliger Iden- tifikator. Beispielsweise kann der Übermittlungsidentifizierer ein sogenannter GUID sein. Ein GUID (global universal identifier) wird auf die - in der Regel auf eine Millisekunde genaue - Zeit des Servers sowie Identifikationsdaten des Servers gebildet, beispielsweise eine nur einmal vergebene Iden- tifikationsnummer der Netzwerkkarte des Servers oder des Prozessors des Servers. Durch die erfindungsgemäße Vorgehensweise ist es beispielsweise möglich, dass den Identifizierungsdaten Selektionsdaten zugeordnet sind und dass im Falle der Übereinstimmung des zurück übermittelten Übermittlungsidentifizierers mit einem der abgespeicherten Übermittlungsidentifizierer die vom Server auf Grund der weiteren Anforderung neu an den Client übermittelte Seite von den dem übereinstimmenden Übermittlungsidentifizierer zugeordneten Selektionsdaten abhängt.
Im Falle der Übereinstimmung des zurück übermittelten Übermittlungsidentifizierers mit keinem der abgespeicherten Übermittlungsidentifizierer sind verschiedene Vorgehensweisen möglich. So kann beispielsweise eine vorbestimmte Startseite an den Client übermittelt werden. Vorzugsweise aber hängt die vom Server auf Grund der weiteren Anforderung neu an den
Client übermittelte Seite von den einem der abgespeicherten Übermittlungsidentifizierer zugeordneten Selektionsdaten ab. Diese Selektionsdaten ordnet der Server dann selbstverständlich auch dem zusätzlich abgespeicherten Übermittlungsidenti- fizierer zu.
Vorzugsweise umfassen die Identifizierungsdaten auch einen Fensteridentifizierer. Im Falle der Übereinstimmung des zurück übermittelten Übermittlungsidentifizierer mit einem der abgespeicherten Übermittlungsidentifizierer wird in diesem
Fall der Fensteridentifizierer beibehalten. Wenn hingegen der zurück übermittelte Übermittlungsidentifizierer mit keinem der abgespeicherten Übermittlungsidentifizierer übereinstimmt, ordnet der Server dem zusätzlich abgespeicherten Übermittlungsidentifizierer einen neuen Fensteridentifizierer zu.
Auf Grund dieser Vorgehensweise ist insbesondere eine effiziente Verwaltung von mehr als zwei clientseitigen Fenstern möglich. Denn auf Grund dieser Vorgehensweise ist für den Server erkennbar, welches Fenster clientseitig dupliziert wurde. Auf Grund dieser Vorgehensweise ist es weiterhin möglich, dass im Falle der Übereinstimmung des zurück übermittelten Übermittlungsidentifizierers mit keinem der abgespeicherten Übermittlungsidentifizierer die vom Server auf Grund einer weiteren Anforderung neu an den Client übermittelte Seite von den Selektionsdaten abhängt, die demjenigen der abgespeicherten Übermittlungsidentifizierer zugeordnet sind, dessen Fensteridentifizierer mit dem zurück übermittelten Fensteridentifizierer übereinstimmt.
Der neue Fensteridentifizierer kann - analog zum Übermittlungsidentifizierer - im einfachsten Fall wieder eine laufende Nummer sein. Vorzugsweise ist aber auch er als GUID ausgebildet. Dabei kann er alternativ als eigenständig generierter GUID ausgebildet sein oder mit dem unmittelbar zuvor generierten Übermittlungsidentifizierer identisch sein.
Der Server verwaltet die Identifizierungsdaten vorzugsweise in Form einer Tabelle, die pro Zeile die Einträge Fenster- identifizierer, Übermittlungsidentifizierer und Selektionsdaten enthält. Anstelle der Selektionsdaten selbst kann in der Tabelle selbstverständlich auch ein Verweis (= Pointer) auf die Selektionsdaten gespeichert sein.
Die Prüfungsreihenfolge (erst die Übermittlungsidentifizierer oder erst die Fensteridentifizierer) ist prinzipiell in das Belieben des Fachmanns gestellt. Vorzugsweise wird aber zuerst der Fensteridentifizierer überprüft und dann der für diesen Fensteridentifizierer gespeicherte Übermittlungsiden- tifizierer. Denn der vom Client zurück übermittelte Fensteridentifizierer ist stets abgespeichert. Der vom Client zurück übermittelte Übermittlungsidentifizierer hingegen könnte bereits überschrieben sein.
Bei Web-Anwendungen sind im Wesentlichen zwei Arten der Anforderungsübermittlung bekannt, nämlich die sogenannten Post- Requests und die sogenannten Get-Requests . Post-Requests beruhen auf dem Prinzip, dass der Client Eingabefelder der Seite ausfüllt und dann die ausgefüllten Eingabefelder vom Client an den Server zurück übermittelt werden. Bei Post-Requests werden dabei vom Client stets alle Eingabe- feider an den Server zurück übermittelt. Die übermittelten Daten enthalten unter anderem die Anforderung für die neue Seite. Für eine im Sinne der vorliegenden Erfindung ordnungsgemäße serverseitige Behandlung solcher Post-Requests ist es daher beispielsweise möglich, dass der Server die Identifi- zierungsdaten der übermittelten Seite als versteckte, auf Seiten des Clients nicht mit angezeigte Eingabefelder beifügt. Erfindungsgemäß werden also der Seite versteckte Eingabefelder beigefügt, die bei einer üblichen Darstellung der Seite in einem Fenster des Clients nicht mit angezeigt wer- den. In diesen Eingabefeldern sind von Seiten des Servers bereits vorab die Identifizierungsdaten hinterlegt worden. Sie werden daher vom Client an den Server zurück übermittelt, wenn der Client einen Post-Request sendet.
Bei Get-Requests hingegen wird vom Client unmittelbar eine
Linkadresse, in der Regel eine sogenannte URL, an den Server zurück übermittelt. Die Linkadresse ist dabei Bestandteil der zuvor übermittelten Seite und wird in dem Fenster, in dem der Client die Seite darstellt, als solche mit angezeigt. Selek- tiert der Benutzer des Clients diese Linkadresse, stellt die Linkadresse selbst und unmittelbar eine Anforderung für eine weitere Seite dar.
Wenn die Seite mindestens eine derartige Adresse für eine weitere Seite enthält, kann eine im Sinne der vorliegenden Erfindung ordnungsgemäße serverseitige Behandlung eines solchen Get-Requests dadurch erreicht werden, dass der Server die Identifizierungsdaten der übermittelten Seite als der Adresse zugeordnete Parameter, sogenannte Query-Parameter, bei- fügt. Ein Spezialfall einer Reaktion des Servers auf den Erhalt einer Anforderung ist ein sogenannter serverseitiger Response- Redirect. Ein serverseitiger Response-Redirect liegt vor, wenn der Server auf Grund einer an ihn übermittelten Anforde- rung nicht die angeforderte Seite an den Client übermittelt, sondern bei Erhalt der weiteren Anforderung zunächst eine dritte, vom Client wieder an den Server zurück zu sendende Anforderung an den Client übermittelt. Erst auf Grund der Übermittlung der dritten Anforderung an den Server übermit- telt der Server dann die angeforderte Seite. In diesem Fall gibt es zwei Möglichkeiten, serverseitig eine im Sinne der vorliegenden Erfindung ordnungsgemäße Behandlung der Anforderung zu gewährleisten.
Zum einen ist es möglich, dass der Server die Identifizierungsdaten der dritten Anforderung als zugeordnete Parameter beifügt. In diesem Fall werden die Identifizierungsdaten der Anforderung selbst beigefügt. Alternativ ist es auch möglich, dass der Server die Identifizierungsdaten der dritten Anfor- derung als Anhängseldatei beifügt, die vom Client nicht der dritten Anforderung an den Server zurück übermittelt mit. In diesem Fall fügt der Server die Identifizierungsdaten der dritten Anforderung also als sogenanntes Transfercookie bei. Die Identifizierungsdaten sind der Seite dabei wie auch bei Post-Requests als versteckte Daten beigefügt. Das Programm extrahiert die Identifizierungsdaten und fügt sie in die Anhängseldatei ein. Weiterhin übermittelt der Server zusammen mit der Seite, die er auf Grund der dritten Anforderung an den Client übermittelt, einen Löschbefehl für diese Anhäng- seldatei an den Client.
Es gibt Sprachen, bei denen den vom Server an den Client übermittelten Seiten Programme beigefügt bzw. die Programme in diese Seiten eingebettet sein können. Ein Beispiel einer solchen Sprache ist JavaScript. In diesem Fall gibt es eine weitere Möglichkeit, zu gewährleisten, dass die Identifizierungsdaten zusammen mit der Anforderung vom Client an den Server übermittelt werden. Denn in diesem Fall ist es möglich, dass der Server die Identifizierungsdaten der Seite dadurch beifügt, dass er der Seite ein Programm beifügt, auf Grund dessen der Client einer Anforderung für eine Seite dann und nur dann eine die Identifizierungsdaten enthaltende Anhängseldatei beifügt, wenn die Anforderung von dieser Übermittlung der Seite ausgeht.
In diesem Fall wird also ebenfalls ein sogenanntes Transfer- cookie erzeugt. Die Erzeugung des Transfercookies erfolgt aber im Gegensatz zum Response-Redirect nicht serverseitig, sondern clientseitig.
Der Server kann nicht unmittelbar erkennen, wenn auf Seiten des Clients eine Duplizierung einer bereits an den Client übertragenen Seite erfolgt. Wenn daher der Benutzer des Clients eine Seite dupliziert und danach längere Zeit mit nur einer der beiden Versionen der duplizierten Seite arbeitet, die andere Version der duplizierten Seite aber nicht verän- dert, bleibt diese andere Version vorerst unverändert erhalten. Wenn der Benutzer des Clients dann zu einem erheblich späteren Zeitpunkt von der anderen, noch unveränderten Version der duplizierten Seite eine Anforderung an den Server sendet, übernimmt der Server in diesem Fall die Selektionsdaten, die der veränderten Version der duplizierten Seite zu diesem Zeitpunkt zugeordnet sind. Die Selektionsdaten können zu diesem Zeitpunkt aber bereits erheblich geändert worden sein. Die Restaurierung des vom Benutzer eigentlich gewünschten Zu- stands der anderen Version der duplizierten Seite kann für den Benutzer daher relativ aufwändig sein. Aus diesem Grund ist es von Vorteil, so früh wie möglich zu erkennen, wenn auf Seiten des Clients eine bereits an diesen übermittelte Seite dupliziert wird.
Ein sofortiges Erkennen eines solchen Duplizierens ist dadurch möglich, - dass der Server der Seite auch eine Variable mit einem Anfangswert und ein vom Client beim Darstellen der Seite in einem Fenster auszuführendes Programm beifügt,
- dass der Client auf Grund des Programms den Wert der Vari- able, wenn sie den Anfangswert aufweist, abändert und
- dass der Client auf Grund des Programms die vorherige Anforderung zur Übermittlung der Seite wiederholt, so dass der Client, wenn die Variable nicht den Anfangswert aufweist, die bei der vorherigen Anforderung übermittelten Identifizierungsdaten ein zweites Mal an den Server übermittelt.
Denn dann wiederholt der Client die vorherige Anforderung sofort beim Duplizieren der Seite, so dass der Server die Dup- lizierung als solche sofort erkennen kann. Der Server erkennt bei dieser Vorgehensweise zwar auch dann (fälschlicherweise) eine Duplizierung, wenn der Benutzer des Clients - ohne die Seite zu duplizieren - diese nur aktualisiert oder auf eine clientseitig noch gespeicherte, in diesem Fenster aber nicht mehr angezeigte Seite zurück greift. Dies ist aber unkritisch, da in diesem Fall auf Seiten des Servers lediglich ein Fenster verwaltet wird, das auf Seiten des Clients in der Realität gar nicht existent ist. Hingegen kann es nicht geschehen, dass auf Seiten des Clients ein Fenster dupliziert wird und der Server dies nicht erkennt. Die Anforderung kann dabei je nach Anwendungsfall in Form eines Post- oder in Form eines Get-Requests an den Server übermittelt werden. Dies gilt auch dann, wenn das erstmalige Laden der Seite auf Grund eines Post-Requests erfolgte.
Das erfindungsgemäße Betriebsverfahren ist als Computerprogramm realisiert, das dem Server zugeführt wird. Das Computerprogramm wird dem Server dabei über einen Datenträger zugeführt. Beispiele eines derartigen Datenträgers sind eine CD-ROM oder eine Streamerkassette. Auf dem Datenträger ist das Computerprogramm in (ausschließlich) maschinenlesbarer Form gespeichert. Das Computerprogramm kann auf dem Datenträ- ger dabei alternativ in komprimierter oder in unkomprimierter Form gespeichert sein.
Der Datenträger mit dem darauf gespeicherten Computerprogramm wird in ein Lesegerät eingeführt, mittels dessen der Server das auf dem Datenträger gespeicherte Computerprogramm lesen kann. Er liest daher das Computerprogramm vom Datenträger aus und speichert es in einem Massenspeicher ab, beispielsweise auf einer Festplatte. Bei Aufruf des Computerprogramms von der Festplatte (alternativ auch vom Datenträger) ist der Server daher in der Lage, das erfindungsgemäße Betriebsverfahren auszuführen.
Weitere Vorteile und Einzelheiten ergeben sich aus der nach- folgenden Beschreibung eines Ausführungsbeispiels in Verbindung mit den Zeichnungen. Dabei zeigen
FIG 1 einen Rechnerverbund,
FIG 2 ein Ablaufdiagramm, FIG 3 eine Tabelle und
FIG 4 bis 7 weitere Ablaufdiagramme .
Gemäß FIG 1 ist ein Server 1 über eine Rechner-Rechner-Verbindung 2 mit einem Client 3 datentechnisch verbunden. Die Rechner-Rechner-Verbindung 2 kann dabei auf verschiedene Art ausgebildet sein. In der Regel ist sie jedoch als Internetoder als Intranet-Verbindung ausgebildet. Über die Rechner- Rechner-Verbindung 2 können der Server 1 und der Client 3 gemäß einem Web-Protokoll miteinander kommunizieren.
Der Server 1 weist, wie allgemein üblich, mehrere Komponenten 4 bis 8 auf, die über einen Bus 9 miteinander verbunden sind. Die Komponenten 4 bis 8 umfassen insbesondere einen Prozessor 4, einen Massenspeicher 5 (typisch eine oder mehrere Fest- platten) , ein Lesegerät 6, einen Zeitgeber 7 und eine Netzwerkkarte 8. In das Lesegerät 6 ist ein Datenträger 10 einführbar, auf dem in ausschließlich maschinenlesbarer Form ein Computerprogramm 11 gespeichert ist. Dieses Computerprogramm 11 wird von dem Datenträger 10 ausgelesen und, wie in FIG 1 gestrichelt ange- deutet ist, im Massenspeicher 5 hinterlegt. Bei Aufruf des Computerprogramms 11 ist der Server 1 daher in der Lage, das Computerprogramm 11 auszuführen. Bei Aufruf des Computerprogramms 11 führt der Server 1 dabei ein Betriebsverfahren aus, das nachfolgend in Verbindung mit FIG 2 näher beschrieben wird.
Gemäß FIG 2 nimmt der Server 1 in einem Schritt Sl vom Client 3 eine Anmeldung und eine erste Anforderung für eine Seite entgegen. Der Server 1 ermittelt daraufhin in einem Schritt S2 einen Übermittlungsidentifizierer Übld. Der Übermittlungsidentifizierer Übld ist dabei vorzugsweise weltweit einmalig. Beispielsweise kann er aus einer Kombination der vom Zeitgeber 7 ausgegebenen Zeit und dem Code der Netzwerkkarte 8 und/oder des Prozessors 4 bestehen.
In einem Schritt S3 wird sodann ein Fensteridentifizierer Feld gleich dem soeben ermittelten Übermittlungsidentifizierer Übld gesetzt. Die beiden Identifizierer Übld, Feld werden sodann - siehe ergänzend FIG 3 - in die erste Zeile einer Ta- belle 12 eingetragen. Gemäß FIG 3 können dabei jeder Zeile der Tabelle 12 außer den beiden Identifizierern Übld, Feld auch noch Selektionsdaten SD zugeordnet werden. Auf die Bedeutung der Selektionsdaten SD wird nachstehend noch eingegangen werden.
In einem Schritt S5 fügt der Se,rver 1 der angeforderten Seite die Identifizierungsdaten Feld, Übld bei. Die Beifügung erfolgt dabei derart, dass die Identifizierungsdaten Feld, Übld bei einer weiteren Anforderung für eine Seite vom Client 3 dann und nur dann an den Server 1 zurück übermittelt werden, wenn die Anforderung auf Seiten des Clients 3 von der Übermittlung dieser Seite ausgeht. Gemäß einem Schritt S6 fügt der Server 1 weiterhin der angeforderten Seite eine Variable und ein Programm bei. Die Variabel weist einen Anfangswert auf. Das Programm ist derart ausgestaltet, dass es bei einem clientseitigen Kopieren der übertragenen Seite eine Neuanforderung der bisherigen Seite auslöst. Hierauf wird später noch näher eingegangen werden. Der Schritt S6 ist dabei nur optional und daher in FIG 2 nur gestrichelt dargestellt. In einem Schritt S7 übermittelt der Server 1 sodann die angeforderte Seite einschließlich der dieser Seite beigefügten Informationen an den Client 3. Bei den beigefügten Informationen handelt es sich insbesondere um die beiden beigefügten Identifizierer Übld, Feld, deren Ergänzungen sowie die Variable und das Programm.
In einem Schritt S8 nimmt der Server 1 vom Client 3 eine weitere Eingabe entgegen. Der Server 1 überprüft daraufhin zunächst in einem Schritt S9, ob der Client 3 sich abgemeldet hat. Wenn dies der Fall ist, löscht er in einem Schritt S10 die Tabelle 12 und beendet die Ausführung des Verfahrens.
Wenn die Eingabe des Schrittes S8 keine Abmeldung war, war sie eine neue Anforderung. In diesem Fall extrahiert der Server 1 aus der übermittelten Anforderung die zurück übermittelten Identifizierer Übld, Feld sowie die Selektionsdaten SD.
In einem Schritt S12 überprüft der Server 1 sodann, ob der zurück übermittelte Übermittlungsidentifizierer Übld mit dem Übermittlungsidentifizierer Übld übereinstimmt, der in der Tabelle 12 dem zurück übermittelten Fensteridentifizierer Feld zugeordnet ist. Der besseren Übersichtlichkeit halber ist der Schritt S12 in FIG 2 dabei in zwei Teilschritte S12a, S12b aufgeteilt. Im Teilschritt Sl2a wird eine logische Variable entsprechend der vorzunehmenden Prüfung belegt, im Teil- schritt S12b die logische Variable abgefragt. Wenn im Schritt S12 eine Übereinstimmung ermittelt wurde, geht die vom Client 3 übermittelte Anforderung von einem ser- verseitig bereits erfassten und verwalteten Fenster des Clients 3 aus. In diesem Fall wird in einem Schritt S13 ana- log zum Schritt S2 ein neuer Übermittlungsidentifizierer Übld ermittelt und in der Tabelle 12 in der Zeile abgespeichert, in der auch der zurück übermittelte Fensteridentifizierer Feld abgespeichert ist. Der Server 1 speichert also den neu ermittelten Übermittlungsidentifizierer Übld anstelle des zu- rück übermittelten Übermittlungsidentifizierer Übld in der Tabelle 12 ab.
Wenn im Schritt S12 hingegen keine Übereinstimmung festgestellt wurde, wird ein Schritt S14 ausgeführt. Im Schritt S14 wird ebenfalls der Übermittlungsidentifizierer Übld analog zur Vorgehensweise von Schritt S2 neu ermittelt. Sodann wird aber der Fensteridentifizierer Feld analog zum Schritt S3 gleich dem soeben neu ermittelten Übermittlungsidentifizierer Übld gesetzt. Beide Identifizierer Feld, Übld werden vom Ser- ver 1 in eine neue Zeile der Tabelle 12 eingetragen. Ferner werden im Rahmen des Schrittes S14 noch die Selektionsdaten SD, die dem zurück übermittelten Fensteridentifizierer Feld zugeordnet sind, in die nunmehr neu belegte Zeile der Tabelle 12 kopiert.
Falls der Server 1 neue Selektionsdaten SD erhalten hat, ändert er ferner in einem Schritt S15 die Selektionsdaten SD ab, die dem aktuellen Fensteridentifizierer Feld zugeordnet sind. Je nach dem, ob auf Grund der Prüfung im Schritt S12 der Schritt S13 oder der Schritt S14 durchlaufen wurde, handelt es sich dabei um den zurück übermittelten Fensteridentifizierer Feld oder um den neu ermittelten Fensteridentifizierer Feld.
In einem Schritt Slβ überprüft der Server 1 als nächstes, ob er die angeforderte Seite direkt übermitteln kann oder ob er ein sogenanntes Response-Redirect durchführen muss. Wenn er ein Response-Redirect durchführen muss, führt er einen Schritt S17 aus, in dem er eine neue Adresse, in der Regel eine URL-Adresse zuzüglich des aktuellen Fensteridentifizie- rers Feld und des aktuellen Übermittlungsidentifizierers Übld an den Client 3 übermittelt. Sodann springt er zum Schritt S8 zurück.
Anderenfalls ermittelt der Server 1 anhand der Selektionsdaten, die dem aktuellen Fensteridentifizierer Feld und dem ak- tuellen Übermittlungsidentifizierer Übld in der Tabelle 12 zugeordnet sind, welche Seite an den Client 3 übermittelt werden soll. Alternativ oder ergänzend kann auch der Inhalt der Seite modifiziert werden. Sodann springt der Server 1 zum Schritt S5 zurück.
FIG 4 zeigt eine erste Möglichkeit, die Identifizierungsdaten Übld, Feld der zu übermittelnden Seite beizufügen. Gemäß FIG 4 fügt der Server 1 der Seite die Identifizierer Übld, Feld in einem Schritt S19 zunächst als versteckte Eingabefelder bei. Dadurch ergibt sich die Wirkung, dass die Identifizierer Übld und Feld bei jedem Post-Request des Clients 3, der von dieser Seite ausgeht, vom Client 3 an den Server 1 übermittelt werden.
In einem Schritt S20 überprüft der Server 1 sodann, ob die zu übermittelnde Seite eine URL-Adresse enthält, der die Identifizierer Übld und Feld noch nicht als Query-Parameter beigefügt wurden. Wenn dies der Fall ist, führt der Server 1 einen Schritt S21 aus, in dem er dieser Adresse die Identifizierer Übld und Feld als Query-Parameter beifügt. Vom Schritt S21 geht der Server dann zum Schritt S20 zurück. Der Schritt S20 ist dabei in FIG 4 - analog zum Schritt S12 von FIG 2 - in zwei Teilschritte unterteilt.
FIG 5 zeigt eine weitere Möglichkeit, die Identifizierungsdaten Übld, Feld der Seite beizufügen. Gemäß FIG 5 fügt der Server 1 der Seite die Identifizierer Übld und Feld als ver- steckte Daten bei. Dabei kann es sich - analog zum Schritt S19 von FIG 4 - um versteckte Eingabefelder handeln. Dies ist aber nicht zwingend erforderlich. Sodann fügt der Server 1 der Seite ein Programm bei, das bei einer Anforderung des Clients 3, die von dieser Seite ausgeht, ausgeführt wird. Auf Grund des Programms extrahiert dann der Client 3 aus dieser Seite die Identifizierungsdaten Übld, Feld und bindet sie in ein von ihm zu kreierendes Cookie ein. Das Cookie sendet der Client 3 zusammen mit der Anforderung an den Server 1.
FIG 6 zeigt die Möglichkeiten, die bestehen, um den Schritt S17 von FIG 2, in dem die Identifizierer Feld und Übld der zu übermittelnden URL beigefügt werden, zu implementieren. Gemäß FIG 6 ist es möglich, den Schritt S17 derart auszugestalten, dass die Identifizierer Übld und Feld - analog zum Schritt
S21 von FIG 4 - der URL-Adresse als Query-Parameter beigefügt werden. Alternativ ist es möglich, dass der Server 1 im Schritt S17 der URL-Adresse eine Anhängseldatei (Cookie) beifügt, welche die Identifizierer Übld, Feld enthält. In diesem letzteren Fall sollten die im Schritt S7 (siehe FIG 2) der angeforderten Seite beigefügten Informationen an den Client 3 einen Löschbefehl enthalten, auf Grund dessen diese Anhängseldatei auf Seiten des Clients 3 sofort wieder gelöscht wird.
Von den in FIG 6 dargestellten Schritten S17 wird stets nur einer ausgeführt. Die beiden Schritte S17 sind daher in FIG 6 gestrichelt dargestellt.
FIG 7 zeigt nun der Vollständigkeit halber das Verfahren, das der Client 3 auf Grund des Programms ausführt, das vom Server 1 im Rahmen des Schrittes S6 (siehe FIG 2) der angeforderten Seite beigefügt wird. Das Programm wird dabei vom Client 3 stets ausgeführt, wenn die Seite von ihm in einem Fenster dargestellt wird. Das Programm wird also sowohl dann ausgeführt, wenn der Client 3 die Seite erstmals erhält, als auch dann, wenn der Client 3 die Seite beispielsweise mit "Steuerung N" dupliziert.
Gemäß FIG 7 extrahiert der Client 3 zunächst aus der Seite die übermittelte Variable. In einem Schritt S25 überprüft er dann, ob die Variable noch ihren Anfangswert hat. Wenn dies der Fall ist, setzt er die Variable in einem Schritt S26 auf ihren Endwert. Der Endwert muss dabei selbstverständlich vom Anfangswert verschieden sein. Ansonsten kann er beliebig ge- wählt sein. Wenn die Prüfung im Schritt S25 keine Übereinstimmung ergeben hat, führt der Client 3 einen Schritt S27 aus, in dem er die vorherige Anforderung wiederholt. Die Wiederholung der Anforderung bewirkt dabei insbesondere, dass die bereits an den Server 1 zurück übermittelten Identifizie- rungsdaten Übld, Feld ein zweites Mal an den Server 1 übermittelt werden. Dadurch ist dann der Server 1 sofort in der Lage, zu erkennen, dass clientseitig ein neues Fenster geöffnet wurde.
Mittels des erfindungsgemäßen Betriebsverfahrens ist es somit auf einfache Weise möglich, dass der Server 1 individuell mehrere Fenster des Clients 3 verwaltet.

Claims

Patentansprüche
1. Betriebsverfahren für einen Server (1), der mit einem Client (3) kommuniziert, - wobei der Server (1) , wenn ihm vom Client (3) eine Anforderung für eine Seite übermittelt wird, die angeforderte Seite an den Client (3) übermittelt,
- wobei der Server (1) der Seite Identifizierungsdaten (Übld, Feld) derart beifügt, dass die Identifizierungsdaten (Übld, Feld) bei einer weiteren Anforderung für eine Seite vom Client (3) dann und nur dann an den Server (1) zurück übermittelt werden, wenn die Anforderung auf Seiten des Clients (3) von dieser Übermittlung der Seite ausgeht,
- wobei die Identifizierungsdaten (Übld, Feld) zumindest ei- nen für die Übermittlung der Seite spezifischen Übermittlungsidentifizierer (Übld) umfassen,
- wobei der Server (1) die von ihm übermittelten Identifizierungsdaten (Übld) abspeichert,
- wobei der Server (1) bei Erhalt der weiteren Anforderung den von ihm neu übermittelten Übermittlungsidentifizierer (Übld) anstelle des zurück übermittelten Übermittlungsidentifizierers (Übld) abspeichert, wenn der zurück übermittelte Übermittlungsidentifizierer (Übld) mit einem abspeicherten Übermittlungsidentifizierer (Übld) übereinstimmt, und - wobei der Server (1) bei Erhalt der weiteren Anforderung den von ihm neu übermittelten Übermittlungsidentifizierer (Übld) zusätzlich zum zurück übermittelten Übermittlungsidentifizierer (Übld) abspeichert, wenn der zurück übermittelte Übermittlungsidentifizierer (Übld) mit keinem zuvor abspeicherten Übermittlungsidentifizierer (Übld) übereinstimmt .
2 . Betriebsverfahren nach Anspruch 1 , d a d u r c h g e k e n n z e i c h n e t , dass den Identifizierungsdaten (Übld, Feld) Selektionsdaten (SD) zugeordnet sind und dass im Falle der Übereinstimmung des zurück übermittelten Übermittlungsidentifizierers (Übld) mit einem der abgespeicherten Übermittlungsidentifizierer (Übld) die vom Server (1) auf Grund der weiteren Anforderung neu an den Client (3) übermittelte Seite von den dem übereinstimmenden Übermittlungsidentifizierer (Übld) zugeordneten Selektionsdaten (SD) abhängt.
3. Betriebsverfahren nach Anspruch 2, d a d u r c h g e k e n n z e i c h n e t , dass im Falle der Übereinstimmung des zurück übermittelten Übermittlungsidentifizierers (Übld) mit keinem der abgespeicherten Übermittlungsidentifizierer (Übld) die vom Server (1) auf Grund der weiteren Anforderung neu an den Client (3) übermittelte Seite von den einem der abgespeicherten Übermittlungsidentifizierer (Übld) zugeordneten Selektionsdaten (SD) abhängt und dass der Server (1) diese Selektionsdaten
(SD) dem zusätzlich abgespeicherten Übermittlungsidentifizierer (Übld) zuordnet.
4. Betriebsverfahren nach Anspruch 1, 2 oder 3, d a d u r c h g e k e n n z e i c h n e t ,
- dass die Identifizierungsdaten (Übld, Feld) auch einen Fensteridentifizierer (Feld) umfassen,
- dass der Server (1) im Falle der Übereinstimmung des zurück übermittelten Übermittlungsidentifizierers (Übld) mit einem der abgespeicherten Übermittlungsidentifizierer (Übld) den Fensteridentifizierer (Feld) des übereinstimmenden Übermittlungsidentifizierers (Übld) beibehält und
- dass der Server im Falle der Übereinstimmung des zurück übermittelten Übermittlungsidentifizierers (Übld) mit kei- nem der abgespeicherten Übermittlungsidentifizierer (Übld) dem zusätzlich abspeicherten Übermittlungsidentifizierer (Übld) einen neuen Fensteridentifizierer (Feld) zuordnet.
5. Betriebsverfahren nach Anspruch 3 und 4, d a d u r c h g e k e n n z e i c h n e t , dass im Falle der Übereinstimmung des zurück übermittelten Übermittlungsidentifizierers (Übld) mit keinem der abgespei- cherten Übermittlungsidentifizierer (Übld) die vom Server (1) auf Grund einer weiteren Anforderung neu an den Client (3) übermittelte Seite von den Selektionsdaten (SD) abhängt, die demjenigen der abgespeicherten Übermittlungsidentifizierer (Übld) zugeordnet sind, dessen Fensteridentifizierer (Feld) mit dem zurück übermittelten Fensteridentifizierer (Feld) übereinstimmt .
6. Betriebsverfahren nach einem der obigen Ansprüche, d a d u r c h g e k e n n z e i c h n e t , dass der Server (1) die Identifizierungsdaten (Übld, Feld) der übermittelten Seite als versteckte, auf Seiten des Clients (3) nicht mit angezeigte Eingabefelder beifügt.
7. Betriebsverfahren nach einem der obigen Ansprüche, d a d u r c h g e k e n n z e i c h n e t , dass die Seite mindestens eine Adresse für eine weitere Seite enthält und dass der Server (1) die Identifizierungsdaten (Übld, Feld) der übermittelten Seite als der Adresse zugeord- nete Parameter beifügt.
8. Betriebsverfahren nach einem der obigen Ansprüche, d a d u r c h g e k e n n z e i c h n e t , dass der Server (1) bei Erhalt der weiteren Anforderung zu- nächst eine dritte, vom Client (3) wieder an den Server (1) zurück zu sendende Anforderung an den Client (3) übermittelt und dass der Server (1) die Identifizierungsdaten (Übld, Feld) der dritten Anforderung als zugeordnete Parameter beifügt.
9. Betriebsverfahren nach einem der obigen Ansprüche, d a d u r c h g e k e n n z e i c h n e t , dass der Server (1) bei Erhalt der weiteren Anforderung zunächst eine dritte, vom Client (3) wieder an den Server (1) zurück zu sendende Anforderung an den Client (3) übermittelt, dass der Server (1) die Identifizierungsdaten (Übld, Feld) der dritten Anforderung als Anhängseldatei beifügt, die vom Client (3) mit der dritten Anforderung an den Server (1) zurück übermittelt wird, und dass der Server (1) zusammen mit der auf Grund der dritten Anforderung an den Client (3) übermittelten Seite einen Löschbefehl für diese Anhängseldatei an den Client (3) übermittelt.
10. Betriebsverfahren nach einem der obigen Ansprüche, d a d u r c h g e k e n n z e i c h n e t , dass der Server (1) die Identifizierungsdaten (Übld, Feld) der Seite dadurch beifügt, dass er der Seite ein Programm beifügt, auf Grund dessen der Client (3) einer Anforderung für eine Seite dann und nur dann eine die Identifizierungsdaten (Übld, Feld) enthaltende Anhängseldatei beifügt, wenn die Anforderung von dieser Übermittlung der Seite ausgeht.
11. Betriebsverfahren nach einem der obigen Ansprüche, d a d u r c h g e k e n n z e i c h n e t ,
- dass der Server (1) der Seite auch eine Variable mit einem Anfangswert und ein vom Client (3) beim Darstellen der Sei- te in einem Fenster auszuführendes Programm beifügt,
- dass der Client (3) auf Grund des Programms den Wert der Variable, wenn sie den Anfangswert aufweist, abändert und
- dass der Client (3) auf Grund des Programms die vorherige Anforderung zur Übermittlung der Seite wiederholt, so dass der Client (3) , wenn die Variable nicht den Anfangswert aufweist, die bei der vorherigen Anforderung übermittelten Identifizierungsdaten (Übld, Feld) ein zweites Mal an den Server (1) übermittelt.
12. Datenträger mit einem auf dem Datenträger gespeicherten Computerprogramm (11) zur Durchführung eines Betriebsverfahrens nach einem der obigen Ansprüche.
13. Server mit einem Massenspeicher (5), in dem ein Computer- programm (11) hinterlegt ist, so dass bei Aufruf des Computerprogramms (11) von dem Server ein Betriebsverfahren nach einem der Ansprüche 1 bis 11 ausführbar ist.
PCT/EP2004/011489 2003-10-17 2004-10-13 Betriebsverfahren für einen server und hiermit korrespondierende gegenstände WO2005038662A2 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE502004005722T DE502004005722D1 (de) 2003-10-17 2004-10-13 Betriebsverfahren für einen server und hiermit korrespondierende gegenstände
JP2006534674A JP4402115B2 (ja) 2003-10-17 2004-10-13 サーバのための作動方法及びサーバと通信する対象
US10/575,980 US7702776B2 (en) 2003-10-17 2004-10-13 Operating method for a server communicating with a client
EP04765951A EP1673915B1 (de) 2003-10-17 2004-10-13 Betriebsverfahren für einen server und hiermit korrespondierende gegenstände

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10349015A DE10349015A1 (de) 2003-10-17 2003-10-17 Betriebsverfahren für einen Server und hiermit korrespondierende Gegenstände
DE10349015.9 2003-10-17

Publications (2)

Publication Number Publication Date
WO2005038662A2 true WO2005038662A2 (de) 2005-04-28
WO2005038662A3 WO2005038662A3 (de) 2005-06-23

Family

ID=34442179

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/011489 WO2005038662A2 (de) 2003-10-17 2004-10-13 Betriebsverfahren für einen server und hiermit korrespondierende gegenstände

Country Status (6)

Country Link
US (1) US7702776B2 (de)
EP (1) EP1673915B1 (de)
JP (1) JP4402115B2 (de)
CN (1) CN1954575A (de)
DE (2) DE10349015A1 (de)
WO (1) WO2005038662A2 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7565538B2 (en) * 2004-04-05 2009-07-21 Microsoft Corporation Flow token
EP2008060A4 (de) 2006-02-21 2010-08-25 Us Postal Services Systeme und verfahren zum erzeugen von routen für angetriebene industrielle fahrzeuge
US20110057402A1 (en) * 2009-09-09 2011-03-10 Keith Jewell Multi-functional and convertible hand truck
US9232011B2 (en) * 2010-03-26 2016-01-05 Microsoft Technology Licensing, Llc Tracking navigation flows within the same browser tab
US8892635B2 (en) 2011-01-06 2014-11-18 Oracle International Corporation Techniques for detecting inactive browser windows
US9015226B2 (en) * 2011-01-06 2015-04-21 Oracle International Corporation Techniques for detecting new browser windows
US8924934B2 (en) 2011-02-04 2014-12-30 Oracle International Corporation Automated test tool interface
US9424236B2 (en) 2011-04-26 2016-08-23 Oracle International Corporation Filtered Stylesheets
JP5397419B2 (ja) * 2011-06-16 2014-01-22 コニカミノルタ株式会社 端末装置、ウェブページ表示方法、およびコンピュータプログラム
US9250872B2 (en) 2011-10-19 2016-02-02 Oracle International Corporation Task flow interface in a popup region
US10691299B2 (en) 2014-09-25 2020-06-23 Oracle International Corporation Display of hierarchical datasets using high-water mark scrolling

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5708780A (en) * 1995-06-07 1998-01-13 Open Market, Inc. Internet server access control and monitoring systems
US5774670A (en) * 1995-10-06 1998-06-30 Netscape Communications Corporation Persistent client state in a hypertext transfer protocol based client-server system
US6047268A (en) * 1997-11-04 2000-04-04 A.T.&T. Corporation Method and apparatus for billing for transactions conducted over the internet
US20020099936A1 (en) * 2000-11-30 2002-07-25 International Business Machines Corporation Secure session management and authentication for web sites

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5937160A (en) * 1997-05-01 1999-08-10 Reedy Creek Technologies, Inc. Systems, methods and computer program products for updating hypertext documents via electronic mail
US7246147B2 (en) * 1997-08-07 2007-07-17 Canon Kabushiki Kaisha Upload and retrieval by an image device of a scanned image to and from a web file server
US6366947B1 (en) * 1998-01-20 2002-04-02 Redmond Venture, Inc. System and method for accelerating network interaction
US6456307B1 (en) * 1998-09-09 2002-09-24 International Business Machines Corporation Automatic icon generation
AU2001231259A1 (en) * 2000-02-04 2001-08-14 America Online Incorporated System and process for delivering and rendering scalable web pages
US6313855B1 (en) * 2000-02-04 2001-11-06 Browse3D Corporation System and method for web browsing
US20020111879A1 (en) * 2001-02-13 2002-08-15 Antonio Melero Method and system for selecting and purchasing products via a communications network
US6915482B2 (en) * 2001-03-28 2005-07-05 Cyber Watcher As Method and arrangement for web information monitoring
US20020184632A1 (en) * 2001-05-30 2002-12-05 Reitmeier Glenn A. Computer peripheral device for web-enhanced media services
WO2003017123A1 (en) * 2001-08-16 2003-02-27 Redline Networks, Inc. System and method for maintaining statefulness during client-server interactions
JP2003085091A (ja) * 2001-09-10 2003-03-20 Hibiya Kadan:Kk ウエブページ管理支援システム
EP1315349B1 (de) * 2001-11-21 2008-03-19 Sun Microsystems, Inc. Verfahren um einen Lastverteiler in ein Client- Server- System zu integrieren
US20040030719A1 (en) * 2002-02-13 2004-02-12 Jie Wei Web page based dynamic book for document presentation and operation
US7389343B2 (en) * 2002-09-16 2008-06-17 International Business Machines Corporation Method, system and program product for tracking web user sessions
US20040255240A1 (en) * 2003-06-10 2004-12-16 Charlie Udom Image selection for variable documents

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5708780A (en) * 1995-06-07 1998-01-13 Open Market, Inc. Internet server access control and monitoring systems
US5774670A (en) * 1995-10-06 1998-06-30 Netscape Communications Corporation Persistent client state in a hypertext transfer protocol based client-server system
US6047268A (en) * 1997-11-04 2000-04-04 A.T.&T. Corporation Method and apparatus for billing for transactions conducted over the internet
US20020099936A1 (en) * 2000-11-30 2002-07-25 International Business Machines Corporation Secure session management and authentication for web sites

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DAVID LANE ET AL: "Web Database Applications with PHP & MySQL passage" WEB DATABASE APPLICATION WITH PHP AND MYSQL, XX, XX, März 2002 (2002-03), Seiten 1-26, XP002283237 *

Also Published As

Publication number Publication date
US20070271382A1 (en) 2007-11-22
EP1673915B1 (de) 2007-12-12
EP1673915A2 (de) 2006-06-28
JP4402115B2 (ja) 2010-01-20
DE502004005722D1 (de) 2008-01-24
US7702776B2 (en) 2010-04-20
JP2007510200A (ja) 2007-04-19
WO2005038662A3 (de) 2005-06-23
DE10349015A1 (de) 2005-05-19
CN1954575A (zh) 2007-04-25

Similar Documents

Publication Publication Date Title
DE69832786T2 (de) Vorrichtung und verfahren zur identifizierung von klienten die an netzwer-sites zugreifen
DE60130633T2 (de) Gesicherte Internet-Zwischenablage
EP1430369B1 (de) Dynamischer zugriff auf automatisierungsressourcen
EP1746502A1 (de) Technik zur Migration einer Host-Umgebung auf eine neue Systemplattform
DE10392438T5 (de) Vorrichtung und Verfahren zur zentralen Überwachung und Steuerung von Anlagen
DE4420451A1 (de) Sperrmechanismus für ein CHECK-IN/CHECK-OUT-Modell
EP1673915B1 (de) Betriebsverfahren für einen server und hiermit korrespondierende gegenstände
EP0990984B1 (de) Verfahren zum Vermitteln von Prozessdaten sowie Verfahren zum Erstellen von anwenderspezifischen Daten und mit diesem Verfahren erstellte Daten
DE112012007196T5 (de) Parametereinstellungssystem, Programmverwaltungsvorrichtung, und Informationsverarbeitungsvorrichtung
DE3842286C2 (de) Verfahren zur Verarbeitung von Daten in einem verteilten Verarbeitungssystem
DE10244459A1 (de) Rechner- und/oder Software-Architektur unter Verwendung von Micro-Kernel- und Multi-Tier-Konzept mit Komponententechnik
DE102006027664A1 (de) Kommunikationssystem zum Verarbeiten von Daten
EP1374111A2 (de) Verfahren, computerprogramm und system zum abwickeln eines projektes
EP1435025B1 (de) System und verfahren zum zugriff auf ein gerät, insbesondere ein automatisierungsgerät mit einer standardisierten schnittstelle
EP1435026B1 (de) System und verfahren zur datenausgabe eines geräts, insbesondere eines automatisierungsgerät über eine standardisierte schnittstelle mit variablenersetzung über einen echoserver
DE10319887B4 (de) Verfahren zum Angleichen eines auf einer Client-Datenverarbeitungseinrichtung angezeigten Datenbestandes an einen auf einer Server-Datenverarbeitungseinrichtung gespeicherten Quelldatenbestand
EP1331789B1 (de) Zentrale Konfigurierung von aktiven Geräten im Netz
EP1316898A2 (de) Einfache und sichere Methode zum Sperren von Datensätzen aus CGI-Scripten heraus
DE602004001793T2 (de) Verfahren zum Durchtesten des Zustandes der Anbindung zwischen einem Klient und einem Server über ein digitales Netzwerk
EP1379945A2 (de) Durchführung eines updates in einem programmgesteuerten gerät und in einem web-browser ausführbarer programmkode
DE10163468A1 (de) Übermittlungsverfahren für eine komprimierfähige Datei
DE10241543A1 (de) Datenverarbeitungssystem zur eingabemaskengestützten Prozessüberwachung und/oder -steuerung
DE102006050978B3 (de) Verfahren und Serversystem zum Ausliefern von Hypermedia-Seiten
DE10203775A1 (de) Verfahren und Systemkonfiguration zum Verarbeiten von Daten eines Online-Systems
EP2629216A2 (de) Verfahren und Anordnung zur Verwaltung von Daten sowie ein entsprechendes Computerprogramm und ein entsprechendes computerlesbares Speichermedium

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200480038061.1

Country of ref document: CN

AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004765951

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2006534674

Country of ref document: JP

WWP Wipo information: published in national office

Ref document number: 2004765951

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10575980

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 10575980

Country of ref document: US

WWG Wipo information: grant in national office

Ref document number: 2004765951

Country of ref document: EP