ECLI:NL:RBDHA:2026:1322

1. De procedure

Het verloop van de procedure blijkt uit:

- de beschikking van de voorzieningenrechter van deze rechtbank van 21 november 2023

waarbij verlof is verleend te dagvaarden volgens de regeling voor de versnelde bodemprocedure in octrooizaken

- de dagvaarding

- de akte houdende producties van Squeezely met de producties EP1 t/m EP 33 van 1 mei 2024

- de akte ter correctie van de dagvaarding van Squeezely van 1 mei 2024

- de conclusie van antwoord van 10 juli 2024 met de producties GP1 t/m GP 14

- de akte in reactie op de ingediende hulpverzoeken van Squeezely van 4 september 2024

- de rolbeslissing van 6 november 2024 waarbij de antwoordakte hulpverzoeken van Insite is geweigerd

- de akte overlegging producties van Squeezely van 13 november 2024 met producties EP34 t/m EP43

- de akte overlegging producties van Insite van 13 november 2024 met producties GP15 t/m GP17

- de akte houdende overlegging producties van Squeezely van 11 december 2024 met de producties EP 44 t/m EP47

- de akte overlegging producties van Insite van 11 december 2024 met producties GP18 en GP19

- het proceskostenoverzicht van Squeezely

- het als productie GP20 ingediende proceskostenoverzicht van Insite

- de pleitnota van Squeezely

- de pleitnota van Insite

- de reactieve pleitnota van Insite

- de mondelinge behandeling van 10 januari 2025.

Ten slotte is vonnis bepaald.

2. De feiten

Squeezely is een lT-bedrijf dat aan bedrijven oplossingen biedt voor het optimaal benaderen van klanten via digitale kanalen. Met haar software en systemen kunnen klantprofielen worden opgebouwd en gepersonaliseerde webpagina's worden getoond.

Insite houdt zich bezig met het (doen) ontwikkelen, beheren en exploiteren van intellectuele eigendom en knowhow, onder meer met betrekking tot computerprogrammatuur.

Het octrooi

Insite is houdster van EP 29 97 500 B1 (hierna EP 500 of het octrooi) voor een “System and method for processing web-browsing information”, aangevraagd op 16 mei 2014 en verleend op 2 december 2020. Het octrooi roept prioriteit in van NL 2010823 van 17 mei 2013 (hierna: de prioriteitsdatum). EP 500 is van kracht in onder meer Nederland.

Conclusies

Het octrooi kent de volgende conclusies (met kenmerkindeling van conclusie 1 zoals door partijen gehanteerd; de Nederlandse vertaling is aangehecht als Bijlage A)

1.1

Information processing platform (100, 200) comprising:

- a web server (20);

- an auxiliary web server (11, 110);

- a back-end server (12, 120),

- a database (130),

1.2

wherein the web server is configured to include an executable code in a web page requested by a web client,

1.3

said executable code containing instructions which cause the web client to send a code request to the auxiliary web server, wherein the code request is a request for programming code that is specific to the web client;

1.4

wherein the auxiliary web server is configured to:

- receive the code request; and

- forward the code request to the back-end server, and

1.5

wherein the back-end server is configured to:

- after receiving the code request from the auxiliary server, obtain platform code to be executed for the requesting web client from the database (130);

1.6

wherein the auxiliary web server or the back-end server is further configured to:

i. based on the platform code obtained from the database, build client-specific code which, when executed on the web client, causes the web client to collect data and send the data to the information processing platform (100, 200);

ii. deliver the client-specific code to the web client;

iii. receive data collected and sent to the information processing platform by the web client executing the client-specific code;

iv. process the data according to the platform code.

2

Platform (100, 200) according to claim 1, wherein the back-end server is configured to:

- provide the processed information to a recommender system for generating additional data to be sent to the web client (10, 150).

3

Platform (100, 200) according to claim 1 or 2, wherein the back-end server is configured to:

- provide the processed information to a data storage interface for partially or completely storing the processed information.

4

Platform (200) according to any of the previous claims, further comprising a proxy server (15), the proxy server (15) configured to:

- forward a request from a web client (10, 150) to the web server (20);

- receive a reply from the web server for the web client;

- by executing the executable code, send the code request to the auxiliary web server (11, 110).

5

Platform (100, 200) according to any of the previous claims, wherein the auxiliary web server is configured to receive the data collected and sent to the information processing platform by the web-client, and to forward said data to the back-end server conditional on a check, by the auxiliary web server, of a privacy setting relating to the web client (10, 150), such as the contents of a cookie.

6

Platform (100, 200) according to any of the previous claims, wherein the platform code is embodied in a configuration file and the back-end server is configured to obtain the configuration file (14, 140) from the web server (20).

7

Platform (100, 200) according to claim 6, wherein the configuration file specifies which elements of the information relating to the web client query are to be aggregated in the processed information.

8

Platform (100, 200) according to claim 6 or 7, wherein the configuration file references data elements identified by HTML element identification.

9

Platform (100, 200) according to any of the previous claims, wherein the auxiliary web server (11, 110) is configured to request additional data from the web server (20).

10

Platform (100, 200) according to any of the previous claims, wherein the auxiliary web server (11, 110) is configured to send additional HTML data based on data received from the web server (20) or the back-end server (12, 120) to the web client (10, 150).

11

Method for processing information, the method comprising:

- including, by a web server, an executable code in a web page requested by a web client, said executable code containing instructions which cause the web client to send a code request to an auxiliary web server (11, 110), wherein the code request is a request for programming code that is specific to the web client;

- receiving (500), by the auxiliary web server (11, 110), the code request;

- sending (504), by the auxiliary web server, the code request to a back-end server (12, 120);

- after receiving the code request from the auxiliary server at the back-end server, Z obtaining, by the back-end server, platform code to be executed for the requesting web client from the database (130);

- based on the platform code obtained from the database, building, by the auxiliary web server or the back-end server, client-specific code which, when executed on the web client, causes the web client to collect data and send the data to the information processing platform (100, 200);

- delivering, by the auxiliary web server or the back-end server, the client-specific code to the web client;

- receiving, by the auxiliary web server or the back-end server, data collected and sent to the information processing platform by the web client executing the client-specific code, and

- processing (603), by the auxiliary web server or the back-end server, the data according to the platform code.

12

Method according to claim 11, wherein the platform code is embodied in a configuration file (14, 140), the method further comprising:

- obtaining, by the back-end server (12, 120) the configuration file (14, 140) from the web server.

13

Method according to claim 12, wherein the configuration file specifies which elements of the information relating to the web client query are to be aggregated in the processed information.

14

Method according to claim 12 or 13, wherein the configuration file references data elements identified by HTML element identification.

De beschrijving en de tekeningen

De beschrijving van het octrooi bevat, voor zover hier relevant, de volgende passages:

Field of the invention

[0001] The invention relates to system and method for processing web-browsing information. The invention also relates to a platform comprising an auxiliary web server and a back-end server, a method for processing information in an auxiliary web server, and a method for processing information in a back-end server.

Background of the invention

[0002] In principle, a single web server can provide all functionality to allow web browsers (clients) to access a web site. However, in recent years web sites have grown more complex, and so have web server systems.

[0003] For some years already it is customary to store the web site’s content in a database, from which HTML pages are generated on the fly in response to a request. The system for serving web pages thus comprises a web server combined with a database backend. A different system may provide templates that indicate the look and feel of the website.

[0004] For large-scale web sites, in order to have redundancy and/or geographic distribution, distributed servers and database systems may be used, which adds

further complexity to the design.

[0005] In recent years, more and more regulation relevant for web sites has appeared. National or trans-national regulation may stipulate if and how a web site may handle information related to people browsing the web. A common motivation of the regulation is to safeguard privacy of the people surfing the World Wide Web. For example, recent European regulation specifies the conditions for web sites to store so-called "cookies" (persistent information related to browsing) using a user's web browser.

[0006] Since the Internet does not generally stop at national borders, a web server administrator has to deal with many different regulations. It is naturally difficult for

a web server to adhere to all regulations that may be relevant to any of its users. Accordingly, there is a need to handle personal or privacy related information in a

structured fashion.

[0007] An article by R.J. Schloss, "Novel business uses of independently created hyperlinks in the World Wide Web: basic mechanism and examples" (Proceedings of the annual Hawaii international conference on system sciences, 1996) pp. 137-146, discloses an advisory server which, when provided with an URL of a page visited by a browser, can provide additional data on said visited page. The browser can then present the additional data along with the visited page. A disadvantage of this system is that it must be supported by the browser - in other words, the browser must, at its own initiative, explicitly request the additional information from the advisory server, using the Web Advisory Transmission Protocol (WATP). This requirement severely limits the use of the advisory servers, in particular for commodity devices with "off-the-shelf" browser software, such as connected appliances (so-called "Internet of Things" loT devices).

[0008] Published US application US 2004/0054784 discloses a system for tracking web user sessions. Web user sessions are tracked on an analytics system based upon a unique identifier assigned to a requested web page and asession cookie that identifies a particular web user session. By tracking web user sessions in this manner, web page data transmitted during a particular web user session can be efficiently and accurately correlated for analysis. The application does not disclose any details relating to processing the collected data. The main feature is storing data while keeping track of the user session

Summary of the invention

[0009] The invention provides an information processing platform as defined in claim 1.

[0010] The platform may also comprise a data interface for providing processed data to e.g. a data storage for storing or a module for further processing, such as a recommender system. Information relating to a web client query can be personal or privacy-related information, relating to the user of the web client. In an embodiment, the web client requests a web page from a web server. The reply by the web server includes a web tag (for example, a piece of JavaScript code) that causes the receiving web client to contact the auxiliary web server.

The information relating to a web client query can also include the URL of the requested web page and/or (parts of) the requested page. The processed information may be stored in memory of a back-end server, BES. The processed information may be provided to a data interface for further processing or storage, either internally or externally. In particular, the BES may provide the processed information to a data storage interface for storing the processed information.

[0011] It is to be understood that the entities of a platform according the invention (for example the auxiliary web server (AWS), back-end server (BES), data storage interface, etc) are logical entities and need not be physically separated. For example, it is possible to combine the AWS and BES in a single computer server, even in a single process on a single server. However, in order to clearly explain the invention, the AWS and BES will be discussed as logically separate entities. The data storage interface provides an interface for storing information in for example a local or remote data storage, such as a database unit. The data storage can be associated with the web server, for example it may be operated by the provider of the web server.

[…]

[0014] In an embodiment according the invention, forwarding of information to the back-end server by the auxiliary web server is conditional on a check, by the auxiliary web server, of a privacy setting relating to the web client, such as the contents of a cookie. As part of this check, the AWS may also apply any relevant (local) legal requirements, thus removing the need for the operator of the web server to implement all legal requirements. Alternatively, the BES may implement the legal requirements check.

[…]

[0024] Figure 1 schematically shows an information-processing platform 100 according to an embodiment of the invention. The platform 100 comprises an auxiliary web server AWS) 11, a back-end server (BES) 12 and a data storage or database (DB) 13. The entities indicated in figure 1 are logical entities. It is quite possible to integrate the entities in a single computer server, even implemented in a single software package. The platform 100 can also comprise separate devices, even multiple AWS and BES devices in order to create redundancy and/or increased processing power. The logical components of the platform 100 can be implemented using a wide array of hardware, operating system software, web server platforms, database systems, etc, available to the skilled person. The BES 12 is provided with a data storage interface for storing data. The data storage interface can be connected with data storage, such as a local or remote data storage. For example, data may be stored in a database unit 13 or in a server associated with the web server 20.

[0025] The network between the components can be any type of data network, such as a TCP/IP packet switched network. The web client 10 is typically a user terminal (e.g. a desktop computer, laptop, tablet, or other (portable) communications device) with web browser software (i.e. software able to interpret HTML and related standards, and able to communicate with a web server using HTTP). The web client 10 is able to communicate with a web server 20, preferably via HTTP over a TCP/IP network such as the Internet. Both the web client 10 and the web server 20 are able to communicate with auxiliary web server (AWS) 11.

[0026] The AWS 11 in turn is connected to a Back-end Server (BES) 12, which is configured to store data in and retrieve data from database (DB) 10. The Back-end Server receives as input a configuration file 14. The network connecting the AWS 11 to BES 12 and BES 12 to DB 13 does not need to be directly accessible by client 10, and can thus be an intranet or virtual private network.

[…]

[0031] Figures 3 and 4 schematically show communications between various entities in an information-processing platform 100 and 200, respectively, according to an embodiment of the invention.

[0032] In step 300, the web client requests a page from a web server 20. In step 302, the web server 20 responds with the requested page, which includes a web tag element. The web tag element can for example be a piece of JavaScript code, included in appropriate HTML tags, to be executed by the web client 10. More generally speaking, a web tag element is an element that causes a web client 10 or suitable adapted proxy server 15 to web tag will typically be provided by the service provider of platform 100, 200 for inclusion in pages generated by the web server 20. The web client 10 evaluates the web tag (for example, it executes the JavaScript code of the web tag), and as a result of the evaluation is caused to send, in step 303, a request to the auxiliary web server 11. The request may for example include personal data (such as a user name, real name, email address, cookie contents, etc) or session data (for example cookie contents, page URL, elements of the currently requested web page, etc). The request can include data related to browser events (e.g. Ul interactions by the user).

[0033] As a result of the request by the client device, in step 304 the AWS 11 may retrieve further data from the web server. The further data can include for example any one or more of: a configuration file 14 for later use by the BES, further personalized data (e.g. a real name based on a supplied username), and privacy permission settings. In step 305, the web server 20 supplies the requested data.

[0034] In step 306, the AWS 11 checks the privacy settings, for example by checking the contents of a cookie obtained via reply 303 or by checking the further data received in step 305. If the privacy settings allow the AWS 11 to continue, a request is submitted, also in step 306, to the Back-End Server 12 to process the information included in the request. The request may include all personal data available to the AWS 11, i.e. the sum of replies 303 and 305 if available.

[0035] The BES 12 evaluates the configuration file 14 in order to determine which information to process and/or store. In an advantageous embodiment of the invention, the configuration file 14 is a program script comprising rules on selecting data items and processing rules.

[0036] In step 307, the processed information is sent, via a storage interface, to DB 13 for storage. The processed data is not necessarily stored, it is also possible that the processed data is used as input in a recommender system and then discarded. Alternatively, only an excerpt of the processed data is stored, for example in the form of a log entry. In step 309, the DB may sent back additional data, for example, a confirmation, or statistical data related to the data just stored The BES 12 sends additional data, which may be based on the data received in step 309, to the AWS 11 in step 310. In step 311, the AWS may formulate a suitable HTML response to the request 303 received from the web client 10 and return it. The additional data in steps 309 or 310 may comprise statistical data from the database 13, an advertisement, or generally the output of a recommender system that

operates on the basis of the processed information.

[…]

[0041] Figure 5 schematically shows a flow chart for information processing by an auxiliary web server 11 according to an embodiment of the invention. In step 501, the AWS 11 receives a request based on a web tag (compare steps 303 and 404). The AWS 11 then checks, in step 502, the consent of the user. This may be done by checking a cookie. There are also other ways available to a skilled person for providing a user preference such as the user consent. The preference may for example be coded in the URL used in the request by the web client.

[0042] In step 503, the AWS 11 requests additional data from web server 20 (see steps 304, 405). Based on the received data and the outcome of the user consent check, the AWS 11 willsend data (such as personal data) to the Back-end Server (504). The data may include a configuration file 14.

[0043] in step 505 data is received from the BES 12 (compare steps 310 and 410). In step 506, this data is converted to HTML and sent to source of the original request (either a web client 10 or a proxy 15, compare steps 311 and 411 respectively).

[0044] Figure 6 schematically shows a flow chart for information processing by a back-end server 12 according to an embodiment of the invention.

[0045] In step 601, data (such as personal data) is received from AWS 11 (compare steps 306, 407). In step 602, the configuration file 14 is retrieved and interpreted (for more details see the description in reference to figure 7).

[0046] According the configuration file 14, the data is processed and may be partially or completely stored in database 13 in step 604. In step 605, a reply is received from the database 13, and in step 606 data, which may be based on the reply from the database, is sent to the AWS 11. Step 604 may also include sending the processed data to a recommender system for obtaining additional information based on the processed information. This additional information is then sent to the AWS in step 606. The recommender system can provide output based on various attributes, e.g. type of OS used (mobile, tablet, desktop/laptop, etc), browser type, user information, etc.

[…]

[0055] Figure 8 schematically shows an information processing platform according to an embodiment of the invention. In this embodiment, the web client 150 is a device in the so-called "Internet of Things", for example an appliance. The platform comprises an auxiliary web server 110, a connected back end server 120, and a connected code database 130. A configuration file 140 may be comprised anywhere in the platform, e.g. in the AWS 110, in the BES 120, or as part of the code in the code database 130.

[0056] In operation, the platform can be used as follows. Individual devices in the Internet of Things (loT) regularly reports its status to the AWS 110 via a request (action S101). The request comprises a code request, which is a request for programming code that is specific to the requesting device.

[0057] After receiving the request via the AWS 110, the BES 120 contacts the code database 130 for platform code to be executed for the requesting device (action S102). The database 130 provides the platform code, which is then interpreted by the AWS 110 or the BES 120 (action S103). The platform code may be embodied in configuration file 140. Based on this platform code, the AWS 110 or BES 120 builds client-specific code that is delivered to the device (action S104). This built code, which is client and device specific, instructs the device to execute specific behaviour and/or collect data (e.g. execute a defined sensor measurement). The collected data is pushed back to the platform for processing (action S105). The AWS 110 or BES 120 processes the collected data according to platform code, for example in an in stream fashion (action S106). The processed data may be redistributed for storage or 3rd party services (action S107).

[0058] In this manner, an IoT platform service can be developed in a single compact code base, without the overhead of dealing with integrating many heterogeneous devices and dealing with the scalability of the system.

[0059] An embodiment of the invention can also be understood from the following. In an embodiment, the invention provides an environment including a (cloud based) computing system (AWS 11, 110 and BES 12, 120) with an associated platform language specification (the language of the configuration file 14, 140). A number of programs are stored in a code repository 13, 130. Challenges in the domain of Internet of Things (IoT) include communication and integration of functionalities, particularly over a heterogeneous array of devices towards a common system goal. In this setting the environment can provide strong advantages in dealing with the scalability of communication of a large number of devices and integration of a diverse set into a common platform. An individual device (web client) reports its status to the computation platform regularly. The logic behind this coupling of devices with the platform is done through a file, written in the platform language. Each report is accompanied by a code request. After receiving a request from the device, the platform contacts the code repository for platform code containing logic to be executed specific for this system. The repository provides the code, which is interpreted by the computing platform. Based on the code definition the platform builds client specific code that is delivered to the device. This code (which is client and device specific) instructs the device to execute specific behavior and/or collect data e.g. to execute defined sensor measurement. The collected data is pushed back to the computation platform for processing. The platform processes the collected data according to the defined code from the set of devices in an in-stream fashion and redistributes it further for storage or 3rd party services.

[0060] In an embodiment according the invention, the web client (or IoT device) requests a page from a web server. The web server inserts executable code in the reply. The executable code can be a single line of code (SLOC). The web client receives the reply and executes the included code. This execution can be automatic due to adherence of the web client to certain accepted standards, for example JavaScript. The execution of said code causes the web client to issue the code request (referenced above) to the computation platform. In that manner, a third party (operating the web server) can steer a web client towards the computation platform.

[…]

EP 500 bevat onder meer de volgende figuren.

Hulpverzoeken

Insite heeft een drietal hulpverzoeken ingediend, voor het geval de rechtbank tot het oordeel zou komen dat het octrooi zoals verleend geldigheid zou ontberen.

Hulpverzoek 1

Hulpverzoek 1 wijzigt kenmerk 1.6.i en het daarmee corresponderende deel uit conclusie 11 als volgt:

Hulpverzoek 2

Hulpverzoek 2 wijzigt kenmerk 1.4 en het daarmee corresponderende deel uit conclusie 11 als volgt:

Hulpverzoek 3

Hulpverzoek 3 is een samenvoeging van de hulpverzoeken 1 en 2.

3. Het geschil in conventie en reconventie

Squeezely vordert - samengevat - vernietiging van het Nederlandse deel van het octrooi, met veroordeling van Insite in kosten van het geding.

Squeezely brengt de volgende gronden naar voren:

a. Het octrooi is nietig omdat het geen technische uitvinding bevat in de zin van artikel 52 lid 1 EOV;

b. Het octrooi is niet nieuw, althans niet inventief in het licht van de stand van de techniek.

Insite voert verweer. Insite concludeert tot niet-ontvankelijkheid van Squeezely, dan wel tot afwijzing van de vorderingen van Squeezely, met uitvoerbaar bij voorraad te verklaren veroordeling van Squeezely in de kosten van deze procedure.

Op de stellingen van partijen wordt hierna, voor zover nodig, nader ingegaan.

4. De beoordeling

Partijen zijn het er over eens dat de voor het octrooi relevante vakpersoon een software-ontwikkelaar van toepassingen voor het internet is. De rechtbank zal hen daarin volgen.

Technisch karakter, artikel 52 EOV

Squeezely betoogt dat de in het octrooi beschreven toepassing niet kwalificeert als “technisch” in de zin van artikel 52 lid 1 EOV en derhalve niet octrooieerbaar is, althans dat de kenmerken die bijdragen aan het technisch effect niet inventief zijn. Volgens Squeezely is niet voldaan aan de vereisten zoals geformuleerd in TBA 26 September 2002, T641/00 (COMVIK).

Insite stelt dat de kenmerken van het octrooi wel degelijk technisch zijn. Het proces van elektronische communicatie tussen de verschillende elementen van de uitvinding is volgens Insite inherent technisch.

De rechtbank oordeelt hierover als volgt. Artikel 52 lid 1 EOV luidt als volgt:

Europese octrooien worden verleend voor uitvindingen, op alle gebieden van de technologie, mits zij nieuw zijn, op uitvinderswerkzaamheid berusten en industrieel toepasbaar zijn.

Uit deze bepaling volgt volgens vaste jurisprudentie dat het moet gaan om een uitvinding met een “technisch karakter”, oftewel een “technische leer”. Dat wil zeggen dat het octrooi een instructie moet geven aan de vakpersoon om met bepaalde technische middelen een technisch probleem op te lossen.

Niet octrooieerbaar, aldus artikel 52 lid 2 EOV, zijn:

a) ontdekkingen, wetenschappelijke theorieën en wiskundige methoden;b) esthetische vormgevingen;c) stelsels, regels en methoden voor het verrichten van geestelijke arbeid, voor spelen of voor de bedrijfsvoering, alsmede computerprogramma’s;d) presentatie van informatie.

Deze uitgesloten categorieën hebben met elkaar gemeen dat ze zien op activiteiten waarbij geen direct technisch resultaat wordt bereikt en die een abstract, intellectueel karakter hebben.

Artikel 52 lid 3 EOV zegt in dit verband:

Het tweede lid sluit de octrooieerbaarheid van de aldaar genoemde onderwerpen of werkzaamheden alleen dan uit voor zover de Europese octrooiaanvrage of het Europees octrooi betrekking heeft op een van die onderwerpen of werkzaamheden als zodanig.

Deze bepaling beoogt een te brede toepassing van het tweede lid te voorkomen door duidelijk te maken dat die categorieën als zodanig zijn uitgesloten van octrooiering, maar dat niet uitgesloten zijn onderwerpen of activiteiten die weliswaar verband houden met die categorieën maar wel een technisch karakter hebben.

In de context van informatietechnologie betekent dit dat een computerprogramma (bijvoorbeeld in de vorm van broncode, objectcode of een schematisch weergegeven algoritme) als zodanig niet kan worden geoctrooieerd wegens gebrek aan technisch karakter. Bestaat de uitvinding echter uit de implementatie van software in een hardwaretoepassing, dan is er wel sprake van een technisch karakter en wordt de uitvinding niet uitgezonderd van octrooieerbaarheid op grond van artikel 52 EOV. Aldus voldoet een uitvinding die bestaat uit een combinatie van niet-technische (software) en technische (hardware) elementen als geheel aan het vereiste dat sprake moet zijn van een technisch karakter, zelfs wanneer de niet-technische elementen domineren.

Vervolgens dient de uitvinding ook te voldoen aan het vereiste van inventiviteit. In dat verband geldt dat ook de niet-technische elementen aan inventiviteit kunnen bijdragen, tenzij:

“they do not interact with the technical subject matter of the claim for solving a technical problem, i.e. non-technical features "as such", do not provide a technical contribution to the prior art”

Kortom, ook de niet-technische elementen dragen bij aan octrooieerbaarheid mits ze, in combinatie met de technische elementen, een rol spelen in het bereiken van het door de uitvinding beoogde technische effect.

Tussen partijen is niet in geschil dat het octrooi, doordat sprake is van één of meerdere servers, minstens één technisch inherent kenmerk bevat. Daarmee is voldaan aan het vereiste dat sprake is van een technisch karakter en wordt de uitvinding niet op die grond uitgesloten van octrooieerbaarheid.

Voor zover Squeezely heeft willen betogen dat het octrooi niet inventief is vanwege een gebrek aan technisch karakter, heeft zij dat onvoldoende onderbouwd. Zij heeft immers geen inventiviteitsaanval uitgaande van specifieke stand van de techniek uitgewerkt (zie hierna onder 4.45) op grond waarvan verschilkenmerken kunnen worden geïdentificeerd waarvan de technische bijdrage kan worden beoordeeld. De enkele stelling dat geen van de kenmerken van conclusie 1 een technisch karakter heeft is, gelet op de betwisting door Insite en in het licht van hetgeen hiervoor onder 4.9 en 4.10 is overwogen, in het kader van de beoordeling van inventiviteit onvoldoende. Aan het in dit verband voor het eerst in de pleitnota gedane beroep op US 2004/0054784 wordt, om dezelfde redenen als hierna onder 4.23 ten aanzien van nieuwheid wordt overwogen, voorbijgegaan.

Uitleg conclusie 1, gescheiden infrastructuur

De beschermingsomvang van een octrooi wordt op grond van artikel 69 EOV bepaald door de conclusies, waarbij de beschrijving en de tekeningen dienen tot uitleg van die conclusies. Daarbij dient op grond van artikel 1 van het Protocol inzake de uitleg van artikel 69 EOV het midden te worden gehouden tussen een uitleg die de beschermingsomvang uitsluitend bepaalt aan de hand van de letterlijke tekst van de conclusies en een uitleg waarbij de conclusies alleen als richtlijn dienen en waarbij de bescherming zich uitstrekt tot datgene wat de octrooihouder volgens de gemiddelde vakpersoon heeft willen beschermen. Dit kader voor de uitleg van de conclusies bij het bepalen van de beschermingsomvang vindt overeenkomstige toepassing bij de beoordeling van de geldigheid van een octrooi.

In het kader van de beoordeling van de geldigheid van het octrooi, twisten partijen over de vraag welke mate van scheiding er volgens het octrooi dient te bestaan tussen de auxiliary web server (AWS) en de back-end server (BES). Kenmerk 1.1. benoemt de AWS en de BES (naast de database en de webserver) als aparte elementen van het platform en de kenmerken 1.3-1.6 beschrijven afzonderlijke stappen uitgevoerd door deze AWS en BES. Ook de figuren (zoals figuur 1 en 8, zie [0024]-[0026] en [0055]) tonen de AWS en BES als afzonderlijke entiteiten dan wel afzonderlijke stappen uitgevoerd door deze entiteiten (figuur 5 en 6, zie [0041]-[0046]). In paragraaf [0011] van de beschrijving staat echter:

“It is to be understood that the entities of a platform according the invention (for example the auxiliary web server (AWS), back-end server (BES), data storage interface, etc) are logical entities and need not be physically separated. For example, it is possible to combine the AWS and BES in a single computer server, even in a single process on a single server. However, in order to clearly explain the invention, the AWS and BES will be discussed as logically separate entities. The data storage interface provides an interface for storing information in for example a local or remote data storage, such as a database unit. The data storage can be associated with the web server, for example it may be operated by the provider of the web server.”

Volgens Insite wordt hiermee gedoeld op meerdere virtualisatielagen, die fungeren als logische eenheden. In een dergelijke opstellingen functioneren de AWS en BES technisch gezien als afzonderlijke fysieke servers.

Squeezely betoogt daarentegen dat uit paragrafen [0011] en [0024] volgt dat het onderscheid tussen AWS en BES feitelijk betekenisloos is aangezien deze in één proces of software pakket kunnen worden gecombineerd. Zij verwijst ook naar het dienovereenkomstige standpunt dat Insite in eerdere communicatie over inbreuk zou hebben ingenomen.

De rechtbank oordeelt hierover als volgt. Partijen zijn het erover eens dat niet vereist is dat de AWS en BES zich op verschillende fysieke servers bevinden. Zij kunnen opereren op één en dezelfde fysieke server. Waar zij over van mening verschillen is de betekenis van de zinsnede “a single process on a single server”. Anders dan Insite stelt, is de rechtbank van oordeel dat daarmee niet wordt bedoeld dat sprake moet zijn van twee van elkaar, middels virtualisatielagen, gescheiden virtuele servers. Paragraaf [0011] maakt immers een onderscheid tussen enerzijds het combineren van AWS en BES in “a single computer server” en anderzijds “in a single process on a single server”. Het ligt voor de hand dat met het eerste alternatief wordt gedoeld op het creëren van twee virtuele servers in één fysieke server en met het tweede alternatief (dus) op iets anders.

Anders dan Insite betoogt, is deze uitleg van paragrafen [0011] en [0024] niet inconsistent met de bewoording van conclusie 1. Paragraaf [0011] beschrijft immers: “However, in order to clearly explain the invention, the AWS and BES will be discussed as logically separate entities”. Paragraaf [0024] benoemt dat het nog steeds gaat om “logical entities”. De vakpersoon zal de afzonderlijke entiteiten zoals genoemd in conclusie 1 dan ook op die wijze, als logische maar niet noodzakelijkerwijs fysiek gescheiden entiteiten lezen.

Weliswaar nuanceren paragraaf [0011] en [0024] en conclusie 1 de strikte scheiding tussen de AWS en BES in grote mate - doordat kenmerk 6 van conclusie 1 bepaalt dat de daarin genoemde stappen door zowel de AWS als de BES kunnen worden uitgevoerd - daarmee is echter nog niet gezegd dat het octrooi moet worden gelezen alsof aan de afzonderlijke stappen omschreven in kenmerken 1.3-1.6, in het bijzonder in kenmerk 1.4, in het geheel geen betekenis toekomt. De vakpersoon begrijpt dat het onderscheid tussen de verschillende entiteiten weliswaar niet fysiek hoeft te zijn, maar hij zal de AWS en de BES wel zien als entiteiten of modules die bepaalde in de conclusiekenmerken omschreven stappen of functies uitvoeren. De vakpersoon zal begrijpen dat dit op verschillende wijzen kan worden geïmplementeerd, maar zal deze stappen of functies niet geheel wegdenken. De vakpersoon zal conclusie 1 immers uitleggen in het licht van het gehele document, dat verschillende stappen of functies uitgevoerd door de AWS en de BES omschrijft, zie bijvoorbeeld ook de uitvoeringsvormen beschreven in paragrafen [0014], [0034] en [0041]. Dergelijke functies of stappen leest de vakpersoon ook terug in de e afhankelijke conclusies, waaronder bijvoorbeeld conclusie 5:

“Platform (100, 200) according to any of the previous claims, wherein the auxiliary web server is configured to receive the data collected and sent to the information processing platform by the web-client, and to forward said data to the back-end server conditional on a check, by the auxiliary web server, of a privacy setting relating to the web client (10, 150), such as the contents of a cookie.”

Blijkens deze conclusie kan de AWS (of de in kenmerk 1.4 geopenbaarde stap in het proces die inhoudt het ontvangen en doorsturen van de code request) worden geconfigureerd om als poortwachter te dienen ten aanzien van het doorsturen van data, zoals bedoeld in stap 1.6.iii. De vakpersoon zal de stappen van conclusie 1, waaronder kenmerk 1.4, derhalve niet zien als elementen zonder zelfstandige betekenis.

Dat Insite in eerdere correspondentie mogelijk een ander standpunt over de uitleg van conclusie 1 heeft ingenomen dan zij in deze procedure doet, kan niet afdoen aan de bovengenoemde uitleg door de rechtbank van die conclusie in het licht van de beschrijving en de tekeningen.

Nieuwheid

De stand van de techniek

Squeezely beroept zich op de volgende openbaringen in de stand van de techniek om de ongeldigheid van EP 500 te betogen:

a) De openbare toepassing van de Revive Adserver/OpenX

b) US 2011/0191366 (“US 366”)

c) US 2012/0072488 (“US 488”)

d) US 2004/054784 (“US 784”)

Ad d) US 784

Voor zover Squeezely de nieuwheid van het octrooi aanvalt op grond van US 784, heeft Insite daar bezwaar tegen gemaakt omdat dit argument pas bij pleidooi voor het eerst is aangevoerd. Squeezely brengt daar tegenin dat US 784 reeds in de dagvaarding is besproken en dat het beroep daarop derhalve tijdig is.

De rechtbank oordeelt hierover als volgt. Squeezely heeft US 784 inderdaad in de dagvaarding aangehaald, maar slechts om het verloop van de verleningsprocedure te beschrijven (zie ook paragraaf [0008] van het octrooi, waarin US 784 wordt genoemd). US 784 is in de dagvaarding niet als relevante stand van de techniek aangehaald in het kader van de geldigheid van het octrooi zoals het is verleend. Doordat Squeezely pas bij pleidooi voor het eerst heeft gesteld dat US 784 nieuwheidschadelijk is, heeft Insite onvoldoende gelegenheid gehad om daarop verweer te voeren. Het zo laat aanvoeren van een beroep op stand van de techniek, die bij dagvaarding reeds bij Squeezely bekend was (zij bespreekt het immers wel), is in strijd met de goede procesorde, zeker nu het hier een procedure betreft die op verzoek van Squeezely wordt gevoerd onder het regime voor de versnelde bodemprocedure in octrooizaken. De rechtbank zal het beroep op US 784 daarom passeren.

Ad a) Revive adserver, OpenX

Revive Adserver (op de prioriteitsdatum bekend als OpenX) is een toepassing die een websitehouder de mogelijkheid geeft om bezoekers van zijn website gepersonaliseerde advertenties te serveren en data te verzamelen over de bezoeker van de website. Wanneer de bezoeker de website benadert, wordt de website vanuit de webserver geladen in de browser van de bezoeker. In die website zit een code-regel verwerkt die de browser ertoe beweegt een advertentie op te vragen bij de Revive Server. Bij het opvragen van de advertentie wordt informatie over de bezoeker meegezonden, zoals het besturingssysteem, de browserversie en de taalinstelling. Aan de hand van deze informatie over de bezoeker, haalt de Revive Server uit een database de te serveren advertentie om naar de browser van de gebruiker te sturen en in de daar getoonde website te laden. OpenX biedt daarbij de mogelijkheid om code mee te sturen die het verzamelen van tracking-informatie door de Revive Server mogelijk maakt.

Squeezely stelt dat OpenX, zoals hier omschreven, openbaar is voorgebruikt voor de prioriteitsdatum van het octrooi, zodat het octrooi niet nieuw is. Om dit aan te tonen, heeft Squeezely een dummy opstelling gemaakt op basis van de versie van de code van OpenX die beschikbaar was op 26 september 2012, zoals blijkt uit het online open-source platform GitHub.

Insite heeft betwist dat OpenX ooit openbaar is voorgebruikt in de configuratie zoals die blijkt uit de dummyopstelling van Squeezely. Met het enkele gegeven dat het, op basis van de toen beschikbare softwareversie, mogelijk was om die configuratie toe te passen (ook dit betwist Insite), is niet aangetoond dat die configuratie ook daadwerkelijk is toegepast, aldus Insite. Daarnaast heeft zij betwist dat op basis van GitHub betrouwbaar kan worden vastgesteld welke versie van de code op 26 september 2012 beschikbaar was.

4.27.De rechtbank oordeelt hierover als volgt. Een octrooi is niet nieuw indien het behoort tot de stand van de techniek (artikel 54 lid 1 EOV). De stand van de techniek wordt gevormd door al hetgeen vóór de datum van indiening van de Europese octrooiaanvrage openbaar toegankelijk is gemaakt door een schriftelijke of mondelinge beschrijving, door toepassing of op enige andere wijze (artikel 54 lid 2 EOV).

Squeezely heeft in deze procedure gesteld dat OpenX, in de configuratie zoals die blijkt uit haar dummy opstelling, voor de prioriteitsdatum is toegepast. Uit artikel 155 Rv volgt dat op Squeezely in dit verband de stelplicht en (zo nodig) de bewijslast rust. Squeezely heeft in dit verband gesteld dat op de prioriteitsdatum OpenX veelvuldig werd toegepast en dat de code van OpenX, zoals die bestond op de prioriteitsdatum, de door Squeezely gemaakt dummy opstelling mogelijk maakte, waarin de kenmerken van conclusie 1 worden geïmplementeerd.

Ten aanzien van de AWS en de BES heeft Squeezely in de dagvaarding verwezen naar figuur 3 van het door haar ter illustratie overgelegde octrooischrift US 8 255 563 (US 563), dan wel naar een volgens haar goed denkbare uitvoeringsvorm van OpenX, kenbaar gemaakt in het “OpenX Cluster Handbook” dat in 2011 is opgesteld door een bedrijf met de naam “Syslint”. Bij akte heeft Squeezely verder nog verwezen naar diverse andere bronnen betreffende (voorbeelden van) het gebruik van een ‘web-server’-component dan wel processen die de functie van een AWS of BES zouden vervullen.

Met de verwijzing naar verschillende servers in figuur 3 van US 563 en de mogelijkheid om een aparte server als “load balancer” te gebruiken conform het handbook van Syslint, heeft Squeezely wellicht mogelijke toepassingen van OpenX in haar dummy opstelling getoond, echter heeft Squeezely geen enkel concreet voorbeeld gegeven van een daadwerkelijke toepassing van een dergelijke opstelling op die wijze door een partij op of voor de prioriteitsdatum en dit is door Insite gemotiveerd betwist. Squeezely heeft daarvan ook geen gespecificeerd bewijs aangeboden. Dit geldt ook ten aanzien van de andere mogelijkheden die Squeezely bij akte nog heeft aangedragen.

Het voorgaande brengt de rechtbank tot het oordeel dat Squeezely onvoldoende onderbouwd heeft gesteld dat een openbare toepassing in de zin van artikel 54 lid 2 EOV van OpenX heeft plaatsgevonden die voldoet aan alle kenmerken van conclusie 1 van het octrooi.

Ad b) US 366

US 366 is gepubliceerd op 4 augustus 2011 en ziet op een system om targeted content aan te bieden op websites. Volgens het octrooi wordt in een door de browser opgevraagd websitebestand een script geplaatst dat bepaalde informatie verzamelt over de browser en browser device (deze verzamelde informatie aangeduid als “identification device”) en deze doorstuurt naar een server (de “message server”). De message server

omvat een script writer (114), die na ontvangst van deze informatie een message server script creëert dat uniek is voor de ontvangen identification device.

Dit script wordt gegenereerd met inachtneming van rule policies vastgelegd in een database, zoals opgevraagd en toegepast door de script writer. Het gecreëerde message server script wordt opgeslagen in een script storage. Vervolgens zet een zogenaamd configuration device (117) het message server script om in een “message device” – kort gezegd de code die zal worden teruggestuurd naar de browser. Daartoe zoekt

de configuration device in de eerdergenoemde database een message file die de gewenste

targeted content bevat, bijvoorbeeld een advertentie, passend bij de unieke informatie zoals op dat moment bekend. De message device met message file worden vervolgens door de server naar de browser gestuurd en daar verwerkt, met als resultaat dat de gewenste content op de betreffende webpagina wordt getoond.

Bij het verwerken van de message device door de browser komt vervolgens een proces op gang waarin additionele informatie wordt verzameld door die message device, zoals URL logs, activiteiten van de browser, in de browser ingevoerde zoektermen en nadere locatiegegevens. De message device zet deze om in een bestand (aangeduid als call device) en zorgt ervoor dat de browser deze terugstuurt naar de server. De (unieke) additionele gegevens bevinden zich in een zogenaamd campaign article in het call device. De configuration device gebruikt de campaign article als input voor een nieuw selectieproces (met gebruikmaking van de rule policies en message files in database) voor het creëren van een message file dat weer wordt gestuurd naar de browser. Zo ontstaat een repetitief proces met telkens geactualiseerde targeted content die wordt getoond door de betreffende browser.

Squeezely betoogt dat alle kenmerken van conclusie 1 van EP 500 worden geopenbaard in US 366. Volgens Insite wordt geen enkel kenmerk geopenbaard, uitgezonderd kenmerk 2.

Partijen twisten onder meer over de vraag of US 366 (de functionaliteit van) een AWS en een BES openbaart. Squeezely stelt dat US 366 een systeem beschrijft waarin de AWS en de BES gecombineerd zijn in de message server device. Deze vervult beide functies, waarbij de extension handler de functie van de AWS vervult en de script writer en configuration device de functie van de BES, aldus Squeezely. Insite betwist dat de extension handler gelijkgesteld kan worden met de AWS en stelt dat US 366 geen proces openbaart waarin een AWS een codeverzoek ontvangt en doorstuurt naar een BES.

De rechtbank constateert dat de beschrijving van US 366 het volgende bevat over de (stappen uitgevoerd door de) extension handler

“The extension handler 112 detects incoming communications to the message server device 102 over the network 104, identifies any of the identification device 126

(and any call device(s) 138, as later described) received from the browser device 118 over the network 104, parses each identification device 126 (and each call device 138, as may be applicable) that is received, and directs commencement of

operation by the script writer 114 in response to the identification device 126.”

(paragraaf [0028])

“The extension handler 112 detects the identification device 126 so received, parses the identification device 126 for portions for the script writer 114 representing unique data or information of the browser 119 and browser device 118, and inputs the parsed result to the script writer 114.” (paragraaf [0045])

Uit deze tekst volgt dat de functie van de extension handler niet hetzelfde is als de functie van de AWS in het octrooi. Squeezely zelf omschrijft deze functie als het detecteren en vervolgens analyseren/verwerken van de identification device en het in werking zetten van de script writer en de configuration device om daarop te reageren, en als het doorzetten (na parsing). Volgens kenmerk (1.3 en) 1.4 ontvangt de AWS de door de web client verzonden code request en geeft deze door aan de BES. De AWS, zoals weergegeven in conclusie 1, voert zelf in deze fase geen bewerkingstappen uit. Voor zover de extension handler al gelijkgesteld kan worden met de AWS, is in ieder geval niet voldaan aan kenmerk 1.4 (“wherein the auxiliary webserver is configured to receive the code request and forward the code request to the back-end server”), omdat de extention handler niet de identification device doorgeeft, maar het bewerkte resultaat (parsed result).

Het voorgaande brengt mee dat US 366 niet nieuwheidsschadelijk is voor het octrooi.

Ad c) US 488

US 488 (productie 25) is gepubliceerd op 22 maart 2012. US 488 beschrijft, kort gezegd, een tag management systeem, waarmee o.a. trackingcodes (tags) op een website kunnen worden geïmplementeerd en ge-update voor (bijvoorbeeld) analytische doeleinden.

Meer in het bijzonder beschrijft US 488 een platform (300), welke een client server 303 omvat die fungeert als webserver (figuur 3 en paragraaf [0030] van US 488:

US 488 beschrijft een server weergegeven in figuur 4 van US 488 als server component 413:

Ook ten aanzien van US 488 twisten partijen over de vraag of voldaan is aan de in het octrooi geopenbaarde van elkaar te onderscheiden functies van een AWS en een BES. Squeezely stelt in dit verband in de dagvaarding dat het server component 413 in US 488 de functionaliteiten van zowel de AWS, als de BES in zich heeft. Zij wijst in dit verband naar paragraaf [0044] van US 488:

“As mentioned earlier, it should be noted that the executable code running on the server component 413 may be written in a server-side scripting language such as PHP. Use of a server-side (rather than client-side) scripting language such as PHP ensures that when the server component 413 is called, code is actually run on the server component 413 itself. The results of the executed code (a JavaScript™ file)

may then be sent back to the tag manager program 204. Meanwhile, the files containing data for use by the tag manager 204 and/or the server component 413 may be written in a markup language such as XML.”

Nadat de server component 413 het verzoek om de webpagina en/of browser specifieke code heeft ontvangen zoals verzocht bij de user terminal 301, wordt door dezelfde server een server-side script (executable code) verkregen en uitgevoerd om uitvoerbare (Javascript) code terug te sturen naar het tag manager program. Aldus wordt volgens Squeezely voldaan aan kenmerk 1.4.

Zoals ook volgt uit hetgeen hierboven reeds is uiteengezet, gaat Squeezely in dit verband uit van een onjuiste uitleg van in elk geval kenmerk en 1.4 van conclusie 1. US 488 openbaart immers niet een functionaliteit waarin een code request wordt ontvangen en vervolgens doorgegeven. Ook de bij pleidooi aangevoerde - gewijzigde - redenering van Squeezely op basis van US 488 kan niet slagen. Dat volgens Squeezely in US 488 enerzijds de user terminal (web client) een verzoek doet aan het tag/content management system (paragraaf [00037]: user terminal 301 may request the tag manager program 204 from cloud 305) en anderzijds de tag manager een verzoek doet om code bij het server component (paragraaf [0043]: (the tag manager 501 may send out a request for page specific code/content to the server component), vormt geen directe en ondubbelzinnige openbaring van het doorgeven van een van de web client ontvangen code request. US 488 is daarmee niet nieuwheidsschadelijk voor conclusie 1 van het octrooi.

Inventiviteit

Met betrekking tot de inventiviteit van conclusie 1 van het octrooi heeft Squeezely niet meer aangevoerd dan dat, voor zover er sprake is van additionele maatregelen ten opzichte van de stand van de techniek, die additionele maatregelen niet inventief zijn. Dit heeft Squeezely verder niet nader uitgewerkt of onderbouwd en het is door Insite weersproken. Squeezely heeft in dit verband daarom onvoldoende gesteld, zodat haar beroep op gebrek aan inventiviteit van conclusie 1 zal worden gepasseerd.

Overige geldigheidsbezwaren

Voor zover in nrs. 5.5 en 5.6 van de pleitnota van Squeezely een (ander) geldigheidsbezwaar ten opzichte van conclusie 1 zou moeten worden gelezen, is dit - zoals Insite ook heeft gesteld - te laat aangevoerd en zal het om die reden worden gepasseerd.

Conclusie en proceskosten

Uit het voorgaande volgt dat conclusie 1 van EP 500 nieuw en inventief moet worden geacht. Hiermee zijn ook de afhankelijke conclusies (2-10) nieuw en inventief, zodat de afzonderlijke nieuwheids- en inventiviteitsbezwaren van Squeezely daartegen niet verder hoeven te worden besproken. Tegen de (onafhankelijke en afhankelijke) werkwijzeconclusies (11-14) heeft Squeezely dezelfde argumenten aangevoerd als tegen de voorgaande conclusies. Deze conclusies moeten dan ook eveneens geldig worden geacht. Om deze reden wordt aan de hulpverzoeken niet toegekomen.

Het voorgaande brengt mee dat de vordering van Squeezely om het octrooi nietig te verklaren niet kan slagen. Squeezely zal als de in het ongelijk gestelde partij worden veroordeeld in de redelijke en evenredige proceskosten aan de zijde van Insite. Deze zijn te begroten conform artikel 1019h Rv omdat de vordering van Squeezely strekkende tot vernietiging van het octrooi is te beschouwen, hetgeen tussen partijen ook niet in geschil is, als een vooruitgeschoven inbreukverweer.

Insite heeft deze kosten begroot op € 81.613,50 aan advocaatkosten en € 3.051,00 aan verschotten (inclusief het griffierecht ad € 676,00). Deze kosten zijn te begroten conform artikel 1019h Rv omdat de vordering van Squeezely strekkende tot vernietiging van het octrooi is te beschouwen, hetgeen tussen partijen ook niet in geschil is, als een vooruitgeschoven inbreukverweer. Ter zitting heeft Insite haar proceskostenvordering beperkt tot € 75.000, te vermeerderen met de wettelijke rente.

Squeezely heeft bezwaar gemaakt tegen de € 5.100,00 aan kosten die door Insite zijn opgevoerd met betrekking tot de geweigerde “antwoordakte hulpverzoeken”’. In het licht van de voornoemde beperking van de proceskostenvordering door Insite, behoeft dit bezwaar geen bespreking.

Teneinde de redelijkheid en evenredigheid van de opgevoerde kosten te kunnen beoordelen, wordt aansluiting gezocht bij de Indicatietarieven in octrooizaken rechtbank Den Haag (versie 1 september 2020). De daarin vermelde tarieven worden geacht redelijk en evenredig te zijn. Onderhavige zaak valt naar het oordeel van de rechtbank onder de categorie normaal met een maximumtarief van € 75.000,00. Dit bedrag zal worden toegewezen, vermeerderd met de verschotten ad € 3.051,00 en de nakosten van € 178,-- (plus de verhoging zoals vermeld in de beslissing).

5. De beslissing

wijst de vorderingen van Squeezely af,

veroordeelt Squeezely in de proceskosten, aan de zijde van Insite begroot op € 78.051,00, te vermeerderen met € 92,-- plus de kosten van betekening als Squeezely niet tijdig aan de veroordeling voldoet en het vonnis daarna wordt betekend, een en ander te vermeerderen met de wettelijke rente indien Squeezely de proceskostenvergoeding niet binnen veertien dagen na betekening van het vonnis heeft voldaan,

verklaart dit vonnis voor zover het betreft de onder 5.2 vermelde beslissing uitvoerbaar bij voorraad.

Dit vonnis is gewezen door mr. M.J.J. Visser, mr. H.F.R. Heemstra en mr. A.J.W. Hooiveld en in het openbaar uitgesproken op 28 januari 2026. In afwezigheid van de voorzitter is het vonnis ondertekend door de oudste rechter.

BIJLAGE A

1

Informatieverwerkingsplatform (100, 200) omvattend:

- een webserver (20);

- een hulpwebserver (11, 110);

- een achtergrondserver (12, 120),

- een database (130),

waarbij de webserver is ingericht om een uitvoerbare code in een door een web client verzochte webpagina in te voegen, waarbij genoemde uitvoerbare code instructies omvat die veroorzaken dat de web client een codeverzoek naar de hulpwebserver stuurt, waarbij het codeverzoek een verzoek is om programmacode die specifiek voor de web client is; waarbij de hulpwebserver is ingericht om:

- het codeverzoek te ontvangen; en

- het codeverzoek door te sturen naar de achtergrondserver, en

waarbij de achtergrondserver ingericht is om

- na het ontvangen van het codeverzoek van de hulpwebserver, uit de database (130) platformcode om uitgevoerd te worden voor de verzoekende web client te verkrijgen;

waarbij de hulpwebserver of de achtergrondserver voorts ingericht is om:

- op basis van de platformcode verkregen uit de database, client-specifieke code te vormen, die, wanneer deze uitgevoerd wordt op de web client, veroorzaakt dat de web client data verzamelt en de data naar het informatieverwerkingsplatform (100, 200) stuurt;

- de client-specifieke code aan de web client te leveren;

- data te ontvangen, die door de web client die de client-specifieke code uitvoert, verzameld en naar het informatieverwerkingsplatform verstuurd is;

- de data in overeenstemming met de platformcode te verwerken.

2

Platform (100, 200) volgens conclusie 1, waarbij de achtergrondserver is ingericht voor:

- het aanbieden van de verwerkte informatie aan een aanbevelingssysteem voor het genereren van additionele data die naar de web client (10, 150) gestuurd dient te worden.

3

Platform (100, 200) volgens conclusie 1 of 2, waarbij de achtergrondserver is ingericht voor:

- het aanbieden van de verwerkte informatie aan een data-opslaginterface voor het gedeeltelijk of geheel opslaan van de verwerkte informatie.

4

Platform (200) volgens een van de voorgaande conclusies, verder omvattende een proxy server (15) ingericht voor

- het doorsturen van een verzoek van een web client (10) aan een web server (20);

- het ontvangen van een antwoord van de web server voor de web client;

- het sturen van het codeverzoek naar de hulpwebserver (11) door de uitvoerbare code uit te voeren.

5

Platform (100, 200) volgens een van de voorgaande conclusies, waarbij de hulpwebserver is ingericht om de data, die door de web client verzameld en naar het informatieverwerkingsplatform verstuurd zijn, te ontvangen en om genoemde data naar de achtergrondserver door te sturen onder voorwaarde van een controle, door de hulpwebserver, van een privacy-instelling die gerelateerd is aan de web client (10, 150), zoals de inhoud van een cookie.

6

Platform (100, 200) volgens een van de voorgaande conclusies, waarbij de platformcode is uitgevoerd als een configuratiebestand en de achtergrondserver is ingericht om het configuratiebestand (14, 140) van de web server (20) te verkrijgen.

7

Platform (100, 200) volgens conclusie 6, waarbij het configuratiebestand specificeert welke elementen van de informatie die gerelateerd is aan het verzoek van de web client opgenomen dienen te worden in de verwerkte informatie.

8

Platform (100, 200) volgens conclusie 6 of7, waarbij het configuratiebestand aan data-elementen refereert volgens een HTML elementidentificatie.

9

Platform (100, 200) volgens een van de voorgaande conclusies, waarbij de hulpwebserver (11, 110) ingericht is om aanvullende data van een web server (20) aan te vragen.

10

Platform (100, 200) volgens een van de voorgaande conclusies, waarbij de hulpwebserver (11, 110) ingericht is om additionele HTML data gebaseerd op data die ontvangen is van de web server (20) of de achtergrondserver (12, 120) te sturen aan de web client (10, 150).

11

Werkwijze voor het verwerken van informatie, de werkwijze omvattende:

- het invoegen, door een web server, van een uitvoerbare code in een door een web client verzochte webpagina, waarbij genoemde uitvoerbare code instructies omvat die veroorzaken dat de web client een codeverzoek naar een hulpwebserver (11, 110) stuurt, waarbij het codeverzoek een verzoek is om programmacode die specifiek voor de web client is;

- het ontvangen (500), door de hulpwebserver (11, 110) van het codeverzoek;

- het sturen (504), door de hulpwebserver, van het codeverzoek naar een achtergrondserver (12, 120);

- het verkrijgen, door de achtergrondserver, van platformcode om uitgevoerd te worden voor de verzoekende web client uit de database (130), na het door de achtergrondserver ontvangen van het codeverzoek van de hulpwebserver;

- op basis van de platformcode verkregen uit de database, het door de hulpwebserver of de achtergrondserver vormen van client-specifieke code, die, wanneer deze uitgevoerd wordt op de web client, veroorzaakt dat de web client data verzamelt en de data naar het informatieverwerkingsplatform (100, 200) stuurt;

- het leveren, door de hulpwebserver of de achtergrondserver, van de dient-specifieke code aan de web client;

- het ontvangen, door de hulpwebserver of de achtergrondserver, van data, die door de web dient die de client-specifieke code uitvoert, verzameld en naar het informatieverwerkingsplatform verstuurd is;

- het verwerken (603), door de hulpwebserver of de achtergrondserver, van de data in overeenstemming met de platformcode.

12

Methode volgens conclusie 11, waarbij de platformcode is uitgevoerd als een configuratiebestand (14, 140) en de methode voorts omvat:

- het verkrijgen, door de achtergrondserver (12, 120), van het configuratiebestand (14, 140) van de web server (20).

13

Methode volgens conclusie 12, waarbij het configuratiebestand specificeert welke elementen van de informatie die gerelateerd is aan het verzoek van de web dient opgenomen dienen te worden in de verwerkte informatie.

14

Methode volgens conclusie 12 of 13, waarbij het configuratiebestand aan data-elementen refereert volgens een HTML elementidentificatie.