Friday, May 21, 2010

French Trademark OLF - under the covers

This is a follow-on from my previous posting about trying to file a French trademark online via the INPI web site.

When you have a problem with the site, you can contact the INPI, via e-mail (free), or phone (pay per minute, but judging by the number it only works if you are ringing from France). Anyway, as I had complained via e-mail as to why the INPI's system seemed incapable of leading me to the promised land of electronic filing nirvana, despite my having all the required software installed, I was contacted by the INPI "helpdesk" (and I use that term very lightly), who were of absolutely no use whatsoever...below is a transcript of an excerpt of my conversation with them:

Helpdesk : you don't have the correct version of Java installed, and you don't have Adobe Acrobat Reader.

Me : errm, yes actually, I do have them because I listed them in my e-mail to you that provoked this phone call, I might add that Adobe Reader opens automatically from the browser to display the filled-out form.

Helpdesk : you need the latest version of those software products.

Me : OK, please tell me which versions then ?  It says nothing on your help page that any particular version of this or that software is required.

Helpdesk : you don't have the right version of Java, you need the latest versions of all of the required software

Me : Please tell me precisely which versions then.

Helpdesk : Sir, you are being difficult, why don't you just file your application from another machine that does have the correct versions, or file by post.

What this conversation tells me is that (1) the INPI has a log of each connection you make to their system because they knew exactly at what time I had connected, (2) the helpdesk don't read the detail of what you send them, and (3) the person you get at the end of the line hasn't got a clue what the requirements of the system really are. When I asked to talk to someone responsible for IT matters, I was told I was already speaking to such a person !!! Oh dear :-/

Not content to let matters remain in that situation, I wrote back to the INPI, via e-mail with the following information, taken from the INPI web page :

4.2 Required configuration for signing. How to check ?
Click on the icon to the right of the title bar. A window opens and will check, in the following order :
* the presence of Acrobat Reader
* the presence of a Sun JVM
* the type and version number of your browser
* the version of your operating system (windows, mac, …)
If your computer does not support the use of the signing tool, (generation and installation of the certificate, signing the form), a message will invite your to download and install the required updates (See point §4.3).

This is what I have on my computer :

1) Acrobat Reader : version 9.3.2 dated 04/01/2010

2) a JVM : version 1.6.0_20, supplied by Sun

3) a browser : Firefox 3.5.9

4) operating system : Linux Ubuntu 9.10, generic kernel 2.6

For the sake of completeness, I thought I'd run some tests to see whether any of the other browsers currently available on Linux would fare any better. The results are posted below :

Each browser was tested, prior to accessing the INPI web site, for its capacity to load a functional JVM via the official Sun test page, all of them passed, including Google Chrome : 

1) Firefox 3.5

JavaSun Microsystems Inc. Version : 1.6.0_20
Système d'exploitationLinux

2) Opera 10.10
Acrobat NaN
Java Sun Microsystems Inc. Version : 1.6.0_20
Système d'exploitation Linux
Navigateur Accepté

3) Google Chrome 5.0.375

JavaNoJVM Version : NoJVM
Système d'exploitationNoJVM

4) Seamonkey (Mozilla) 2.0.4

Acrobat NaN
Java Sun Microsystems Inc. Version : 1.6.0_20
Système d'exploitation Linux
Navigateur Accepté

From memory (and I stand prepared to be corrected), the 2.x versions of Seamonkey correspond to the 2.x branch of  Firefox.

From the testing, it is apparent that the problem does not appear to be with browser compatibility, since in all cases the INPI's detection script considered that the browser version being used was acceptable.

Apart from Google Chrome, all of the browsers tested using the INPI script returned an acceptable version of the Java VM.

This led me to believe that the problem lies in the Javascript used to test the user configuration, and that this script trips up on the detection of Adobe Acrobat on Unix-like platforms. The irony of the situation is that the form which has already been filled out by the server opens automatically in Adobe Acrobat Reader when the user is invited to check its application documents for correctness. What happens here is that the link provides a data stream bearing the PDF mime type, and thus is recognised by the plugin mechanism that is prevalent on Unix/Linux systems.

As an aside, it appears that the INPI has used the content creation and secure signing platform known as Dictao, details of which can be found here

In order to resolve the script issue, I needed to find out which script ran when I clicked the "check configuration" icon. The good (or bad depending on your point of view) thing about having web pages with scripts in them is that at some stage, they have to be loaded into the memory of the machine they are running on via the application (in this case via the browser). This leaves them open to analysis, which is exactly what I did by installing an extension module for Firefox known as a script de-obfuscator. What this does is trace the script calls loaded into the memory of the browser and make them available in human readable form - and very handy it was too !!

The result displayed is a long line of codes, routines, subroutines, etc, most of which wasn't particularly relevant to my quest, but in the end, I found a section of code which looked promising :

function eh(g, f) {
        $doc.dwe.detect = Object();
        $doc.dwe.detect.acrobatObj = new Object;
        $doc.dwe.detect.acrobatObj.installed = false;
        $doc.dwe.detect.acrobatObj.version = "0.0";
        if (navigator.plugins && navigator.plugins.length) {
            for (var h = 0, d = navigator.plugins.length; h < d; ++h) {
                if (navigator.plugins[h].description.indexOf("Adobe Acrobat") != -1 ||
                    navigator.plugins[h].description.indexOf("Adobe PDF") != -1 ||
                    navigator.plugins[h].description.indexOf("Adobe Reader") != -1) {
                    $doc.dwe.detect.acrobatObj.version = parseFloat(navigator.plugins[h].description.split("Version ")[1]);
                    if (isNaN($doc.dwe.detect.acrobatObj.version) &&
                        navigator.plugins[h].description == "Adobe PDF Plug-In For Firefox and Netscape") {
                        $doc.dwe.detect.acrobatObj.version = "8.0";
                    if ($doc.dwe.detect.acrobatObj.version.toString().length == 1) {
                        $doc.dwe.detect.acrobatObj.version += ".0";
                    $doc.dwe.detect.acrobatObj.installed = true;

Oddly enough, this code is very similar to that released by Ryan Parmann under a version of the GPL2, an example of which can be found  here - I don't recall seeing on the INPI web site anywhere that they used GPL2 code in their services, tsk, tsk, tsk. The date on the code states 1997-2003, here's hoping that Dictao did their homework beforehand...

Now I'm not an expert at scripts, but the code above looks like it is designed to search only for version 8 of Adobe Acrobat, and then only if the description found in the plugins index is identical to "Adobe PDF Plug-in for Firefox and Netscape". If not, the test fails and returns NaN. Below is some extra code, again found here which allegedly can calculate the various versions of Acrobat Reader currently in circulation (until Adobe releases version 10), but I think that it gives the gist of what should work :

acrobat.ver4=(acrobat.installed && parseInt(acrobat.version) >= 4) ? true:false;
acrobat.ver5=(acrobat.installed && parseInt(acrobat.version) >= 5) ? true:false;
acrobat.ver6=(acrobat.installed && parseInt(acrobat.version) >= 6) ? true:false;
acrobat.ver7=(acrobat.installed && parseInt(acrobat.version) >= 7) ? true:false;
acrobat.ver8=(acrobat.installed && parseInt(acrobat.version) >= 8) ? true:false;
acrobat.ver9=(acrobat.installed && parseInt(acrobat.version) >= 9) ? true:false;

This is all well and good, but until the INPI decide to correct the problem (or can get Dictao to do so, if it is their responsibility), then for the moment, it looks like online filing of trademark applications in France is going to be out of the question for many of us who prefer to use alternative operating systems.
It is noteworthy that since I first reported the incident and followed up with e-mails containing the results of my testing, I've heard nary a peep from the INPI IT helpdesk. Embarassment, confusion or just plain ignorance (close our eyes and the problem will go away) ?

No comments: