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) ?

Wednesday, May 05, 2010

Online Filing Woes - get thee away Satan

It seems that life is full of little setbacks at the moment, what with my previous rant on French PTO fax machines and now my latest encounter with the French trademark filing authorities. Being of moderately good cheer despite the wintry weather, I thought I'd cock a snoop at the snow falling outstide my office today and attempt to file a trademark online via the INPI's spankingly refurbished website (which is an ultimately very frustrating experience, but more of that later).

Aside from the fact that you have to trawl through several pages of information which are more or less useful depending on the extent of your trademark knowledge, I can safely say that online trademark filing via the INPI is not at all obviously pointed out on its web site, and the overall impression that this gives is that the INPI is only really looking to attract the absolutely motivated individual who has time to spare, or the professional who has finally exclaimed "at last" when the link to the online filing section of the site is found. Just to make it easier for anyone reading this blog, the current address is :

For the non-French speakers there are several alternative languages for the interface available, one of which being English, but it has to be said that some of the translations of the fields into which data is to be entered appear somewhat... unusual, to the native English speaker. In any event, the non-French user is forewarned in advance that the application will have to be filed in French come what may, or else it will be rejected. This doesn't appear obvious to the English speaking user until you have filled in the applicant and contact details and actually get around to typing in the definition of classes and goods and services for which protection is sought. The page where you fill in these details is entirely in French, which I suppose stands to reason seeing as the aim is to file a French trademark application after all. However, considering that the trademark classification system also exists in English, it would have been a nice touch to provide that translation as a guide to the would-be non-francophonic applicant.

After having selected your classes and associated products from the list, or having typed in your own definitions, one can then proceed to the "Special Cases" page, where it is possible to choose whether the application is linked to a renewal of an existing French trademark, to a divisional filing, to a collective certification mark, or to a claim to Paris Union priority.

Once sorted, you can proceed to the signatory page, where the name and contact details of the person signing the application (aka the representative) are given. This then takes you to the form validation page, and from there onto the payment page (because online payment by credit/debit card, is also possible). However, this is where I came unstuck, and was doled out a rather terse error message :

Votre configuration actuelle ne vous permet pas de certifier le formulaire
Acrobat NaN
Java Sun Microsystems Inc. Version : 1.6.0_20
Système d'exploitation Linux
Navigateur Accepté

Which basically means that my computer setup did not allow for certification of the form. Hmm, I don't recall seeing any certification requests or the like indicating that a secure certificate was to be installed on my computer.

Whilst the INPI has helpfully indicated what the minimum computer software requirements are (via an icon click in a little corner of the screen), it still left me dumbfounded because my system actually meets all of those requirements, including the allegedly "absent from my system" Adobe Acrobat Reader. Thus stymied, I am given the option of saving all I have done so far, in which case you receive an access code in order to try again with the application data being stored temporarily (2 weeks) on the INPI's server - this function does actually work - or else saving the generated form to disk via the, wait for it, "unfindable" Adobe Acrobat Reader which opens up on clicking on the link to display the form and its relevant data...

So that basically was it. Stuck for now, other than filing 5 paper copies of the application via post and paying an extra 25€ filing fee, until someone, somewhere within the arcanes of INPI IT support can actually help me out (or not, as the case may be).

Deflated, but not defeated, I shall wait to hear from them to get to the bottom of the problem and report back. Sometimes you just can't beat those good old fax machines...(don't get me started on them again...)

Sunday, May 02, 2010

Anyone for CML ?

Today's post is not about medical nasties such as chronic myelogenous leukemia, but rather Chemical Markup Language (here), or even more generally, the representation of chemical structures and other chemical data such as spectra in patent applications.

Way back in 2006, I raised this issue in the online filing forum of the EPO (here). As I later discovered, CML was in fact already being considered by the EPO, as evidenced by a report published by Dr. Wendy Warr in 2004 (here, p.49-50). Since then, unless I'm very much mistaken, no progress seems to have been made whatsoever. Am I to understand that the filing powers that be and industry still have come to no agreement, or is it that, as I was led to believe, the USPTO is so entrenched in its use of TIFF that it can not adapt to a recognised standard for the representation of chemical formulae ? If so, then it really is a pretty poor show all round. After all, it is not as if there is no software around capable of converting a graphically driven interface rendering of a structure into compliant CML - there are now several, both proprietary and open source, and additionally capable of running on multiple operating systems (see herehere, and  here).

So what is holding back the adoption of CML directly in patent applications, instead of the current practice of having to draw the structures and save them as bitmap images, which are then copied into the word processing document, saved, recompressed and rendered un-reusable thereafter  ? How significant is the reticence or lack of knowledge on the part of patent attorneys or the subcontractors who prepare chemical drawings ?

If anyone has any gems of information on the subject, I would be interested to know.