"Extract Widget" Patent FR2962237 - Process to create an application of gadget type incorporated into a container of widget type

The French version of the patent is available here

See also Patent FR2962237B1 - Main claim, scope and applications and Polymer vs Extract Widget patent - Code comparison and Components model comparison with the patent

Index

English version of the patent

The patent vs Web Components - Overview

The patent vs Web Components - Detailed comparison

The patent vs the traditional approach = the Web Components

The patent vs Polymer

The patent vs X-Tags

The patent vs React

The patent vs Microsoft universal Window app

The patent vs Delite

The patent vs AngularJS

The patent vs VanillaJS

The patent vs Ember

Conclusion

Project references

English version of the patent

Page 1

The invention aims to create mini software applications of type said "gadget" or "widget".

More precisely, the "widget" term, which is a concatenation of "windows" and "gadgets", is a generic term to designate a window displayed on a computer or a mobile containing an application. The "gadget" term designates the content of the widget, so the application running inside it.

The widgets allow the dynamic and interactif display of various information in a field (part) of a web page combined (that can interact) with other fields of the same page.

The gadget creation includes essentially two steps:

• extraction, from an already existing web page (hereafter designated as the "source web page" of an "origin site") of some elements of this web page which are integrated inside the gadget, isolating them from the other elements of the web page, and
• construction of the gadget from these elements, and insertion of the gadget in a web application, inside a page which will be designated hereafter as the "target page" of a "target application"

Numerous processes have been proposed to create gadgets, among those we can mention the following methods:

• extraction of the selected content from an origin site in an element of type iframe ("inline frame" which is an element allowing to place in a "frame" another HTML element), then dimensioningthe iframe with this content, and scrolling the page to the place where the content is in order to display it only (method used by some gadgets creation engines such as WebWag or Wozaik)
• extraction of a page where we have already selected the content and kept its properties, using the same principles as the above, the page then aligning on the gadget (example: Firefox China Edition)
• use of an iframe, the source of the iframe being the gadget (example: iGoogle)
• use of the source code of the gadget or its URL, then storage and loading of the gadget via the stored information or

Page 2

via a server acting as a proxy (as for example Widgetbox platform is doing)

• use of some features offered by some browsers such as "webslice" in Internet Explorer 8
• development of gadgets according to an already defined format (such as iGoogle, Netvibes)
• extraction of gadgets from web portals such as iGoogle or Netvibes

The first two methods are imperfect and unreliable, because the web pages change and soon or later the gadget is lost. On the other hand these methods are not optimal, because the complete source page of the origin site must be loaded, while only a small part is used.

The other methods require whether a specific browser, whether some programming skills to create gadgets, and/or they impose a strict formatted content, which can require to duplicate an already existing content on a site to turn it into a gadget.

The goal of the invention is to solve these problems and to propose an universal solution, usable by anybody without the need of any specific skills, much more reliable than what exist up to now.

More precisely, the goal of the invention is to propose a process allowing:

i) the extraction of web sites pieces from any browser, assuming that is supports features such as Javascript/AJAX (Asynchronous Javascript and XML), which is the case of most of the most widely used browsers.

ii) their storage, advantageously with an universal format such as international UTF-8; and

iii) their reconstruction real-time as gadgets ia a web application, as well in UTF-8 format to insure maximum compability.

Page 3

The goal of the invention is also to be able to display gadgets created via such a process on any device connected to the internet, especially mobile devices.

Indeed, as we will see next, one of the advantage of the gadgets created with the process of the invention is to prevent loading all the site but only the relevant part, which allow:

• to gain in speed
• to get the relevant content only
• to use an optimal display format adapted to the device, such as personal digital assistants and other mobiles such as "smartphones" which have more limited display capacities and where a gadget will be more user friendly than a whole site.

In particular, the goal of the invention is to allow the creation of a gadget that can be integrated directly inside an application, without the need of a browser to render it after it has been created and integrated inside the application.

For a mobile use, the device just has to receive the gadget and it can be used quite simply, assuming that the mobile has the necessary internet connection to be used with the application.

To achieve this, the invention proposes a process to create such an application of gadget type, defined by the following steps:

a) individualization of different objects contained in the source page, each of them being defined by a proper content and proper description properties describing a structure of the object

b) selection of at least one of the object in the source page

c) selective extraction, for the selected object, of its description properties and its content

d) storage of the description properties and content in a database of a server;

e) construction of a gadget from the description propperties and content; and

Page 4

f) inclusion of the gadget in a container of type widget inside the web page of the target application

According to some advantageous subsidiaries methods:

• step c) includes the research of the parent objects of the object individualized at step a), and the extraction of it description properties as well as those inherited from its parents, said description properties being able to describe styles associated to the parents of selected object;
• the description properties describe also the styles associated to the selected object

As a first implementation, the selective extraction in step c) includes the extraction of the HTML code of the object selected at step b), and step e) is a phase of construction of a static gadget, from its description parameters and the HTML code previously extracted at step c).

As a second implementation, the selective extraction in step c) includes the storage of the information including the hyperlink toward the origin site, and step e) is a phase of construction of a dynamic gadget from the description properties via a call to a server which will insert a script in the target application in order for the server to load the source page of the origin site using the above hyperlink, and the insertion on server side in the loaded page of a script of type "server side javascript" that will reconstruct the gadget extracting the HTML code of the gadget as well as the description properties and will send the result to the target application.

According to different subsidiaries characteristics associated to this second implementation:

• step e) includes the research of the parent objects of the object individualized in step a), and the extraction of the description properties of the object as well as those inherited from its parents, said descriptors being able to describe styles associated to the parents of the selected object;

Page 5

• step e) is a phase of construction of a dynamic gadget from the description properties and the HTML code sent back by the server.
• the information stored in step c) include : the URL of the origin site, id, name and size of the selected object in the source page of the origin site, and a reference to the browser used to execute steps a)-c);
• the above information give also an identifier of the designated object;
• step e) includes the search among the objects of the web page of the origin site designated by the hyperlink, of at least one object whose content or structural intrinsic characteristics match a set of predined crtiteria.

Advantageously, for one or other of the methods implemented above:

• the files stored at step d) are files encoded in international format UTF-8
• the description parameters include the parameters of type: BASE, HTML, styles and size;
• the server is a distant server, distinct from the platform implementing steps d) and e) of the process, and the step d) of storage of the description properties and the content inside the database includes the transmission of these description parameters and the content to the server via a request of type "cross-domain"

We are now going to describe a detailed example of implementation of the invention, which refers to the drawings in the annexes.

Figure 1 schematically describes with functional blocks the different elements involved in the process described by the invention.

Figures 2a and 2b illustrate two ways to isolate on the user's screen the fields (parts) in the origin page that will be extracted to create the widget.

Page 6

We are now going to give a detailed example of the gadget creation process from the invention.

As shown in Figure 1, this process can be implemented by an user (herefafter called "conceptor" to differentiate it from the final user) from a computer 10 connecting to an origin web site 12, to extract from a source page the elements required for the creation of the widget.

The process involves a server 14 which will store the extracted elements in a database 16. The widget created by the conceptor will be integrated in a target web application 18 loaded by a device 20, which can be a mobile device.

The gadget creation involves mainly two steps:

• the extraction from the source page of the origin site of the elements required to create the gadget, and
• the construction of the gadget from these extracted elements, and their integration in a target web application

Extraction of the gadgets' elements

This step involves the execution of a script, for example a Javascript/AJAX script.

The conceptor of the gadgets first loads the origin site where he wants to extract the elements from until it reaches the relevant page (source page). He then calls the gadget creation tool, for example cliking on a bookmarklet installed in his browser's personnal bar.

This will insert an extractor script in the active page of the browser. The script will give the choice to the conceptor, to start capturing the content using selection fields in the source page that remains displayed in background, or to manually enter the code or text of his gadget.

Page 7

The capture of the relevant content is made by selecting the relevant field, identified by a border which appears or disappears according to the location of the mouse.

The initial phase of the capture includes the operation of scanning all the objects of the page and for each object:

• add a mouseover and mouseout event (or, more precisely, implement a mechanism similar to mouseenter and mouseleave not implemented by all browsers) to add, or remove, a border at the object to indicate which one is active.
• add a mousedown event to launch the gadget creation when you clik on the selected object, and stop the propagation of the mousedown event in the DOM (structure Document Object Model) to the objects before it in the hierarchy.
• remove and keep all the target links, in order not to leave the page when you click.
• set wmode to 'transparent' to all objects where it applies in order for these objects not to appear in front of the extraction script dialog box
• remove the functions associated to onmousedown on the objects, to avoid conflicts with the mousedown of the gadget creation

Then, by moving the mouse on the source page, the conceptor will see the borders indicating a particular field of the page. When he will reach the relevant field, he will just have to click to indicate this field to the gadget creation tool.

Advantageously, it is foreseen to have two modes of capture as illustrated in Figures 2a and 2b.

For the first mode, the border is added to the element behind the mouse (as shown by A on Figure 2a).

The second one does the same but add also a border to all the parents of the selected element (as shown by A and B on Figure 2b). Indeed the fact to add a border only to the element behind the mouse can cause the objects in the page to move away, making sometimes impossible to reach the desired object,

Page 8

this one going away constantly each time the mouse comes over (successive detection of mouseenter and mouseleave events when the object moves out). The second mode of capture allows to solve this issue since adding a border to all the parents will cause the objects to move all together, eliminating the "blink effect" for the object behind the mouse, allowing the conceptor to choose the desired object.

Once the conceptor has chosen the content that he wants to extract, he clicks to start the extraction process executed by the script.

The script gives to him two options: creation of a static gadget or a dynamic gadget:

• the static gadget will allow to capture the HTML code of the selected content, which will allow to restitute identically the content: the code of the gadget itself will not change, but the ojects included inside such as images, flash animations, video or other linked resources will continue to update from the sites they belong to;
• the dynamic gadget will allow to capture a content that will be dynamically reconstructed identically from the origin site when it is used.

For example if you wish to create a gadget from a site containing a real time map (weather map, alert map, etc):

• if you decide to create a static gadget, the HTML code will contain an image of the map at the time it was created, and when the gadget will be used it will show always the same map;
• if you decide to create a dynamic gadget the content of the map will be updated real time when you use the gadget.

For a video or animation like Flash object, the HTML code of the object will always be dynamically updated according to its origin site, in that case it is recommended to create a static gadget.

Page 9

Some examples of metalanguage algorithms for gadgets creation, static or dynamic, are given in ANNEXES A and B, respectively, at the end of the below description.

The elements that have been extracted by the process are sent to the server 14, via a request using the HTML5 postMessage allowing a "cross domain POST request" encrypted with SSL.

For a static gadget, two files encoded with the UTF8 international format to allow maximum compability are created:

• a .html file containing mtchtml (to open the gadget, just call the url of the .html); and
• a .json file (Javascript Object Notation) which returns: var gadget = {base: the base of the source site, html: the HTML code (note: typo in the French patent)}(for the reconstruction in a web application, the .json file will be integrated as a Javascript script and instantiate the gadget gobal variable).

The conceptor access to the server after an authentication phase with his login/password.

The following elements are stored in the database 16 of the server 14:

• the .html file
• the .json file
• the references to the gadget and its dimension width/height; and
• a screenshot of the gadget

The screenshot of the gadget is processed asynchronously by reconstructing the gadget on the server 14 and taking a screenshot of the rendering.

For a dynamic gadget, the process is the same, the stored elements are:

• URL, id, name, position and dimensions of the selected object in the source page, and
• reference of the browser used

Reconstruction of the static and dynamic gadgets

The static gadget can be reconstruced by calling directly their URL. Nevertheless the goal of the invention is to allow the reconstruction of gadgets directly in a web application.

To do so, the web application will inject a script whose source is, for a static gadget, the .json of the gadget stored in the database 16 of the server 14 (incidently we notice that the method is "cross-domain", the site of the target web application 18 not being necessarily the same as the one of the server 14 used the extract the gadget's parameters)

At the end of the script execution, the target application 18 will have the following values:

• gadget.base, which contains the base of the site of the static gadget
• gadget.html, which contains the HTML code of the gadget formatted to be injected directly in the web page of the target application (so without and tags)

The application creates a tag, with as source the value gadget.base as first child of the

The objects of the gadget will be fetched with the URL of the origin site and will be displayed correctly.

The application then insert the HTML code of the gadget where it is requires (for example mon_div_gadget.innerHTML=gadget.html)

Therefore the page will still have its own styles applied to its proper elements while the styles of the gadget, included in gadget.html, will apply to the gadget, allowing its perfect reconstitution.

For a dynamic gadget, the reconstitution is made as follow.

The Javascript methods are used on target application side and server side : the application insert a script which will invoke the server 14 asking it to load the URL of the origin site with the user agent of the browser with whom the gadget has been created.

This does allow to get a source page identical to the one used to create the widget, avoiding for example a site adaptation to the device that displays the gadget, like it is the case with some sites who detect this or this type of mobile and send back a specific page different from the one used for the gadget creation.

The server does insert in the loaded page a script that will do the following:

• if the gadget had an id or a name, we get obj via its name or id, if not we scan all the objects of body and we get the most likely according to its position and dimensions (obj)
• we apply the same transformation to conserve the styles of obj than for static gadgets creation (cf ANNEX A mentioned above)
• we attach the tags LINK and STYLE to obj;
• we suppress all the scripts from obj

The target application does insert the gadget in the page inserting a BASE tag with the value returned by the server as the first child of head, using the HTML code returned by the server where it is required (ex: mon_div_gadget.innerHTML=obj.outerHTML).

The advantage to use server side Javascript is that the loading of the page and the gadget reconstruction are much faster than with a mobile device for example, because of the processing capabilities of the server and its high bandwidth internet connections, so with a large optimization compared to the loading of an iframe on the user's device.

We can notice that the wide use of advertising banners whose size vary makes difficult the exact identification of the object location, so the method consisting in retrieving the "most likely object" (according to different criteria, like presence of an image, a word, a monetary symbol, the size, etc) is more reliable than the one consisting for example in scrolling an iframe to the supposed position of the object.

Page 12

The principles of the reconstruction is summarized in ANNEXE C which represents the structure of the target web page before and after the reconstitution of the gadget.

Page 13

ANNEX A : creation of a static gadget

Let obj be the selected object.

We restore the target links of obj if they exist.

1) If initial obj is different from BODY :

We scan all the parents of obj in order to keep the inherited styles.

We set width/height to 100% for them, we apply a transparent background image in order to remove the possible background images of the parents and keep only the background of obj, we position them relatively top 0, margin 0, padding 0

When we reach the body we create a div where the styles of the body are cloned, we set this div to the dimensions width and height of obj.

For the computation of width and height we take into account the positioning of the object with its parent (offsettop and offsetleft). We clone here the styles attached to the body tag only and not the styles applied to body by the CSS properties, because these properties will be present in the final gadget and be applied to it when it will be reconstructed.

We then apply the processes mentioned below {if obj=body}

We reconstitute the obj and parent tree, the parent div of the whole is the div mentioned below, this div becomes obj.

If obj=BODY

We keep obj.

We save the tags LINK and STYLE of BODY

We had the BASE tag in the HEAD (here we are on the source site so the links are pointing to the right place, when we will reconstruct the gadget we will have to give to the base tag the reference to the site so the links are fetching the right site)

We put the LINK and STYLE tags in HEAD.

We add the META tag UTF-8 if not present.

Page 14

We remove all the SCRIPT and NOSCRIPT tags (indeed for the static gadgets they become useless, and annoying in the case of scripts related to ads)

We apply to obj a function that transforms the links with an absolute reference (case of wrong interpretation of the BASE tag in some browsers) and we apply a specific operation to the OBJECT, EMBED tags in order for their code to be correctly retrieved when we will use the outerHTML of obj (to retrieve for example the flashvar which can be specific depending on the browsers)

2) Si obj initial = BODY

We replace in the outerHML of obj BODY...BODY by DIV...DIV which becomes obj, in order to keep the styles of body. This operation is useful since the gadget will be reconstructed in a web page whic has already its own body.

3) In both cases we get as the output:

json: content of HEAD without META, TITLE, BASE + outerHTML of obj

mtchtml: HTML HEAD BODY + outerHTML of obj + BODY HTML

Page 15

ANNEX B: creation of a dynamic gadget

Let obj be the selected object.

We search if obj or its parents that have only one child consecutively have an id or a name.

If yes, we keep the name (and its index in the chain returned by getElementsByTagName) or the id.

We keep the position and the dimensions of the gadget.

We keep the reference to the browser used.

Page 16

ANNEX C: structure of the target web page before and after the reconstruction of the gadget

Before the reconstruction of the gadget:

See the French patent drawing

After the reconstruction of the gadget:

See the French patent drawing

Page 17

Claims

1- A process to display a gadget coming from a source web page from a web site in a target web page including the following steps:

a) individualization of different objects contained in the source web page, each of them being defined by a proper content and proper description parameters describing a structure of the object

b) selection of at least one of the objects in the source page

c) selective extraction, for the selected object, of its description parameters and its content, or of its description parameters alone; and

d) display of the gadget in the target web page, from the description parameters and content, or from the description parameters alone

2- The process of claim 1, where step c) includes the search of the parent objects of the object individualized in step a), and the extraction of the description properties attached to this object and the properties inherited from the parent objects

3- The process of claim 1, where the description parameters describe too the web styles associated to the selected object

4- The process of claim 2 where the description properties describe too the web styles associated to the parents of the selected object

5- The process of claim 1 where:

• the selective extraction in step c) includes the extraction of the HTML code of the object selected at step b, and
• step d) is a step that displays a gadget called static, from the description parameters and the HTML code prevviously extracted at step c)

Page 18

6- The process of claim 1 where:

• the selective extraction in step c) includes the extraction of the description properties alone, including the information containing an hyperlink to the origin site and criteria associated to the selected object, and
• step d) is a step that displays a gadget called "dynamic" from the decription properties with a call to a server via the insertion of a script in the target web page to operate:
• the loading, by the server of the source page from the origin site using the hyperlink
• the insertion on server side of a script of type Javascript in the loaded page which will extract the HTML code of the object as well as the description properties and will send the result to the target web page.

7- The process of claim 6, where step d) includes the search of the parents of the object individualized at step a), and the extraction of the description properties of this object as well as the description properties inherited from its parents

8- The process of claim 7, where the description properties describe also the web styles associated to the parents of the selected object

9- The process of claim 6, where step d) is a step that displays a dynamic gadget from the description properties and the HTML code returned by the server

10- The process of claim 6, where the information extracted at step c) include: the URL of the origin site, id, name, position and dimensions of the selected object in the source page of the origin site, and a reference to the browser used for the steps a)-c)

11- The process of claim 6 where the information give also an identifier of the designated object

Page 19

12- The process of claim 6, where step d) includes the search, among the objects of the web page of the origin site referenced by a hyperlink, of at least one object whose content or structural intrinsic properties match a set of predefined criteria

13- The process of claim 1, where the description properties and the content extracted in step c) are encoded with the UTF-8 international format whatever enconding the source page is using

14- The process of claim 1 where the description properties include the web parameters: BASE, HTML, web styles and size

15- The process of claim 1, where:

• it is foreseen to store the description parameters and the content in a database (16) of the server (14)
• the server (14) is a server distinct from the platform (10) implementing the steps of storage and display of the process; and
• the step of storing the description properties and the content includes the transmission of the description properties and the content to the server via a request of type cross-domain

Page 20

See the French patent

Fig. 1

Fig. 2a

Fig. 2b

The patent vs Web Components - Overview

The W3C Web Components specifications can be found here

This section describes the similitudes between the patent and the Web Components based mainly on the examples given in the patents, the next section will describe in more details the similitudes between the general concepts of the patent and the Web Components.

Custom Elements

The specs states:

"Provide a way for Web developers to build their own, fully-featured DOM elements. Though it was long possible to create DOM elements with any tag names in HTML, these elements weren't very functional. By giving Web developers the means to both inform the parser on how to properly construct an element and to react to lifecycle changes of an element, the specification eliminates the need for DOM-as-a-render-view scaffolding that has to exist today in most web frameworks or libraries. Rationalize the platform. The specification ensures that all of its new features and abilities are in concert with how the relevant bits of the Web platform work today, so that these new features could be used to explain the functionality of existing Web platform features, such as HTML elements."

The patent says:

p2 10 and 15 explain that the current methods for gadgets creation impose to load the full web page or to be restricted to an imposed format or to a specific browser or rendering techno, p2 20 explains that one of the goal of the patent is to solve these problems (similar to "these elements weren't very functional") with an universal solution, which is similar to "build their own, fully featured DOM elements", p2 30 iii) explains that the gadgets are constructed inside a standard web page, which "eliminates the need for DOM-as-a-render-view scaffolding" and associated with p3 15-20 which envisions the display of the gadget inside an application is similar to "is in concert with how the relevant bits of the Web platform work today...such as HTML elements", the reconstruction example p10 shows how to "inform the parser on how to properly construct an element".

The specifications describe:

index.html:
<link rel="import" href="import.html">
...
<me-second></me-second>
...

import.html:
<me-first></me-first>

The patent describes (p9 and 10):

a .html file containing mtchtml (to open the gadget, just call the url of the .html); and
a .json file (Javascript Object Notation) which returns: var gadget = {base: the base of the source site, html: the HTML code}(for the reconstruction in a web application, the .json file will be integrated as a Javascript script and instantiate the gadget gobal variable).

this is similar to import.html

load script gadget.json={html: html of the gadget (so import.html)
including the proper styles of the gadget + base of the gadget} 
and load specific parameters related to the gadget like
height/width, id, name and a screenshot if applicable.

This is similar to <link rel="import" href="import.html">

The global method in the patent explains how to store the specific parameters attached to a gadget (p9), allowing a web application to reconstruct it (p10), this is very exactly what import.html is doing (storage) and Web Components (reconstruction from the storage).

<me-second></me-second> is similar to <div>code du gadget <link><style><div> page 16

and the constructor p10 5-10-15-20 is similar to the Web Components constructor from the input of import.html or gadget.json for the patent, p10 10 mentions that the process is "cross-domain", like the import link is.

and the structure of the page example given in Annex C is very similar to the structure of a web page using custom elements:

<html>
<HEAD>
    <BASE of the gadget> optional
    Styles, scripts, links of the main page
</HEAD>
<BODY>
<DIV>
main page
</DIV>

<DIV>
gadget
<LINK>
<STYLE>
--> isolated gadget with proper styles
</DIV>

</BODY>

Then from the above considerations a "gadget" in the patent === a "custom element" (and not only == despite of the fact that the specifications do describe additional features like lifecycle as well as the patent describes additional features, the final goal is very exactly the same as the patent).

Shadow DOM:

p10 25 of the patent, "Ainsi la page aura pour elle-même toujours ses propres styles....tandis que les styles du gadget...permettant ainsi sa reconstitution parfaite"

This is similar to the Shadow DOM concepts, which isolate the custom element rendering from the main page rendering, and avoid a custom element's styles interfering with the main page and vice versa.

The examples in the patent does mention the BASE tag to achieve this for the links inside the gadget, which could apply to the main page in case of a single gadget, or to the gadget itself only (as stated in p14 5), this is just an example of implementation, the isolation principles are explained all along the patent.

The patent states that the styles of the gadgets can not interfer with the styles of the application it is incorpored into and the constructor script is in charge of this (p10 25), among others.

The patent states clearly that the gadgets are stored with their associated styles and descriptors (and inherited properties from the parents) and reconstructed as such without any possible interference with the styles of the main page or application (please see all the references in next section and Annex A/B for gadget extraction and isolation)

So, all this illustrates the gadgets' rendering isolation, very similar to Shadow DOM custom elements' rendering isolation.

Import:

The import spec states "HTML Imports, or just imports from here on, are HTML documents that are linked as external resources from another HTML document."

This is very exactly what the main claim of the patent is doing (p17,c,d)

As we have seen before, this behavior is illustrated in the patent via the loading of gadget.json and the gadgets' descriptors which will be processed to render the gadget via a script inserting the code of the gadget inside a container in the page, which is similar to an import of import.html processed by the Web Components engine to render the custom element inside the gadget tag container.

The patent vs Web Components - Detailed comparison

The text with a grey background does highlight the similitudes of the Web Components with the patent, while it focuses on comparing the Web Components and the patent, the claims at the end extend the comparison showing that they apply to different implementation of Web Components or widget-like frameworks as shown in the next sections.

Page 1

The invention aims to create mini software applications of type said "gadget" or "widget".

    ie a custom element

More precisely, the "widget" term, which is a concatenation of "windows" and "gadgets", is a generic term to designate a window displayed on a computer or a mobile containing an application. The "gadget" term designates the content of the widget, so the application running inside it.

The widgets allow the dynamic and interactif display of various information in a field (part) of a web page combined (that can interact) with other fields of the same page.

The gadget creation includes essentially two steps:

• extraction, from an already existing web page (hereafter designated as the "source web page" of an "origin site") of some elements of this web page which are integrated inside the gadget,

    Similar to the creation of the custom element import.html
    The origin site is the site hosting import.html

isolating them from the other elements of the web page, and

    Similar to the custom element isolated structure (shadow DOM)

• construction of the gadget from these elements, and insertion of the gadget in a web application, inside a page which will be designated hereafter as the "target page" of a "target application"

    Import import.html in the target page
    Insert the gadget tag <gadget></gadget>
    Process both for construction

Numerous processes have been proposed to create gadgets, among those we can mention the following methods:

...

Page 2

...

The goal of the invention is to solve these problems and to propose an universal solution, usable by anybody without the need of any specific skills, much more reliable than what exist up to now.

More precisely, the goal of the invention is to propose a process allowing:

i) the extraction of web sites pieces from any browser, assuming that is supports features such as Javascript/AJAX (Asynchronous Javascript and XML), which is the case of most of the most widely used browsers.

    the extraction is the import.html itself

ii) their storage, advantageously with an universal format such as international UTF-8; and

   Store the custom element import.html on the server http://web_components_example.com

iii) their reconstruction real-time as gadgets via a web application, as well in UTF-8 format to insure maximum compability.

    Import the utf-8 encoded import.html from the server
    Insert a tag <gadget></gadget>
    Process both for reconstitution

Page 3

The goal of the invention is also to be able to display gadgets created via such a process on any device connected to internet, especially mobile devices.

...

In particular, the goal of the invention is to allow the creation of a gadget that can be integrated directly inside an application, without the need of a browser to render it after it has been created and integrated inside the application.

    A custom element inside any application that can render a web page

For a mobile use, the device just has to receive the gadget and it can be used quite simply, assuming that the mobile has the necessary internet connection to be used with the application.

To achieve this, the invention proposes a process to create such an application of gadget type, defined by the following steps:

a) individualization of different objects contained in the source page, each of them being defined by a proper content and proper description parameters describing a structure of the object

    Source page: similar to import.html on the Web Components server
    taken as a whole as the custom element import.html
    whose content includes the description properties
    and defines a structure of the object <gadget>
    or
    individualization of different gadgets in the page defined by a proper
    content and proper description parameters when for example
    the target web page and the source web page are the same

b) selection of at least one of the object in the source page

    Similar to the selection of import.html
    or
    to the selection of the the gadgets in the page

c) selective extraction, for the selected object, of its description properties and its content

    Similar to the structure and properties of <gadget> in import.html
    or to the structure and properties of the gadgets in the page

d) storage of the description properties and content in a database of a server;

    Storage of import.html on the server
    or
    storage of the page

e) construction of a gadget from the description propperties and content; and

    Import import.html or the page from the server and process it

Note: this section reflects more the version A of the patent and should have been updated to reflect more the final version and the below main claims.

Page 4

f) inclusion of the gadget in a container of type widget inside the web page of the target application

    Add the gadget tag in the page and process it

According to some advantageous subsidiaries methods:

• step c) includes the search of the parent objects of the object individualized at step a), and the extraction of it description properties as well as those inherited from its parents, said description properties being able to describe styles associated to the parents of selected object;

    The isolated styles of a custom element (shadow DOM)

• the description properties describe also the styles associated to the selected object

    Idem

As a first implementation, the selective extraction in step c) includes the extraction of the HTML code of the object selected at step b), and step e) is a phase of construction of a static gadget, from its description parameters and the HTML code previously extracted at step c).

    Import the HTML code from import.html, process it
    and render the gadget tag

As a second implementation, the selective extraction in step c) includes the storage of the information including the hyperlink toward the origin site, and step e) is a phase of construction of a dynamic gadget from the description properties via a call to a server which will insert a script in the target application in order for the server to load the source page of the origin site using the above hyperlink, and the insertion on server side in the loaded page of a script of type "server side javascript" that will reconstruct the gadget extracting the HTML code of the gadget as well as the description properties and will send the result to the target application.

    The script in the target application is similar to the import link processing,
    using the hyperlink as href
    The origin site is the server itself,
    the server just sends the local source page import.html
    The reconstruction script is the embedded Web Components engine
    processing import.html and the gadget tag

According to different subsidiaries characteristics associated to this second implementation:

• step e) includes the research of the parent objects of the object individualized in step a), and the extraction of the description properties of the object as well as those inherited from its parents, said descriptors being able to describe styles associated to the parents of the selected object;

    Styles isolation (shadow DOM)

Page 5

• step e) is a phase of construction of a dynamic gadget from the description properties and the HTML code sent back by the server.

    import.html and gadget tag processing

• the information stored in step c) include : the URL of the origin site, id, name and size of the selected object in the source page of the origin site, and a reference to the browser used to execute steps a)-c);
• the above information give also an identifier of the designated object;
• step e) includes the search among the objects of the web page of the origin site designated by the hyperlink, of at least one object whose content or structural intrinsic characteristics match a set of predined crtiteria.

Advantageously, for one or other of the methods implemented above:

• the files stored at step d) are files encoded in international format UTF-8

    Like import, which processes only utf-8 encoded files

• the description parameters include the parameters of type: BASE, HTML, styles and size;

   Parameters included in import.html

• the server is a distant server, distinct from the platform implementing steps d) and e) of the process, and the step d) of storage of the description properties and the content inside the database

    Storage of import.html in the Web Components server

includes the transmission of these description parameters and the content to the server via a request of type "cross-domain"

We are now going to describe a detailed example of implementation of the invention, which refers to the drawings in the annexes.

Figure 1 schematically describes with functional blocks the different elements involved in the process described by the invention.

Figures 2a and 2b illustrate two ways to isolate on the user's screen the fields (parts) in the origin page that will be extracted to create the widget.

    See the previous section for code comparison

Page 6

We are now going to give a detailed example of the gadget creation process from the invention.

As shown in Figure 1, this process can be implemented by an user (herefafter called "conceptor" to differentiate it from the final user) from a computer 10 connecting to an origin web site 12, to extract from a source page the elements required for the creation of the widget.

The process involves a server 14 which will store the extracted elements in a database 16. The widget created by the conceptor will be integrated in a target web application 18 loaded by a device 20, which can be a mobile device.

    18 is the web application using some custom elements
    20 is the user loading the web application 18
    14 is the server hosting the Web Components modules
    For Web Components 14 and 12 are the same and 10 is the terminal 
    to access this server by the conceptor of the custom element
    16 is where the modules are stored on the server (as files like index.html
    or stored somewhere and served as files)

The gadget creation involves mainly two steps:

• the extraction from the source page of the origin site of the elements required to create the gadget, and

    The extraction is import.html itself

• the construction of the gadget from these extracted elements, and their integration in a target web application

    Import of a custom element, insertion of a gadget tag and processing

Extraction of the gadgets' elements

This step involves the execution of a script, for example a Javascript/AJAX script.

...

The script gives to him two options: creation of a static gadget or a dynamic gadget:

• the static gadget will allow to capture the HTML code of the selected content, which will allow to restitute identically the content: the code of the gadget itself will not change, but the ojects included inside such as images, flash animations, video or other linked resources will continue to update from the sites they belong to;
• the dynamic gadget will allow to capture a content that will be dynamically reconstructed identically from the origin site when it is used.

    Similar to a custom element
    with static or dynamic content

For example if you wish to create a gadget from a site containing a real time map (weather map, alert map, etc):

• if you decide to create a static gadget, the HTML code will contain an image of the map at the time it was created, and when the gadget will be used it will show always the same map;
• if you decide to create a dynamic gadget the content of the map will be updated real time when you use the gadget.

For a video or animation like Flash object, the HTML code of the object will always be dynamically updated according to its origin site, in that case it is recommended to create a static gadget.

Page 9

Some examples of metalanguage algorithms for gadgets creation, static or dynamic, are given in ANNEXES A and B, respectively, at the end of the below description.

The elements that have been extracted by the process are sent to the server 14, via a request using the HTML5 postMessage allowing a "cross domain POST request" encrypted with SSL.

For a static gadget, two files encoded with the UTF8 international format to allow maximum compability are created:

• a .html file containing mtchtml (to open the gadget, just call the url of the .html); and
• a .json file (Javascript Object Notation) which returns: var gadget = {base: the base of the source site, html: the HTML code (note: typo in the French patent)}(for the reconstruction in a web application, the .json file will be integrated as a Javascript script and instantiate the gadget gobal variable).

    Similar to the content of import.html for a custom element

The conceptor access to the server after an authentication phase with his login/password.

The following elements are stored in the database 16 of the server 14:

• the .html file
• the .json file
• the references to the gadget and its dimension width/height; and
• a screenshot of the gadget

    The custom element information import.html stored on
    the Web Components server

The screenshot of the gadget is processed asynchronously by reconstructing the gadget on the server 14 and taking a screenshot of the rendering.

For a dynamic gadget, the process is the same, the stored elements are:

• URL, id, name, position and dimensions of the selected object in the source page, and
• reference of the browser used

    Similar to the URL of a Web Component

Page 10

Reconstruction of the static and dynamic gadgets

The static gadget can be reconstruced by calling directly their URL. Nevertheless the goal of the invention is to allow the reconstruction of gadgets directly in a web application.

To do so, the web application will inject a script whose source is, for a static gadget, the .json of the gadget stored in the database 16 of the server 14 (incidently we notice that the method is "cross-domain", the site of the target web application 18 not being necessarily the same as the one of the server 14 used the extract the gadget's parameters)

    Import processing

At the end of the script execution, the target application 18 will have the following values:

• gadget.base, which contains the base of the site of the static gadget
• gadget.html, which contains the HTML code of the gadget formatted to be injected directly in the web page of the target application (so without and tags)

    Import result
    Similar to the Web Components internal processing

The application creates a tag, with as source the value gadget.base as first child of the

    Links isolation

The objects of the gadget will be fetched with the URL of the origin site and will be displayed correctly.

The application then insert the HTML code of the gadget where it is requires (for example mon_div_gadget.innerHTML=gadget.html)

    Insert a gadget tag and process the custom element
    from import.html

Therefore the page will still have its own styles applied to its proper elements while the styles of the gadget, included in gadget.html, will apply to the gadget, allowing its perfect reconstitution.

    Styles isolation, shadow DOM

For a dynamic gadget, the reconstitution is made as follow.

The Javascript methods are used on target application side and server side : the application insert a script which will invoke the server 14 asking it to load the URL of the origin site with the user agent of the browser with whom the gadget has been created.

    Similar to the import mechanisms,
    the origin site is the Web Components server itself

Page11

This does allow to get a source page identical to the one used to create the widget, avoiding for example a site adaptation to the device that displays the gadget, like it is the case with some sites who detect this or this type of mobile and send back a specific page different from the one used for the gadget creation.

The server does insert in the loaded page a script that will do the following:

• if the gadget had an id or a name, we get obj via its name or id, if not we scan all the objects of body and we get the most likely according to its position and dimensions (obj)
• we apply the same transformation to conserve the styles of obj than for static gadgets creation (cf ANNEX A mentioned above)
• we attach the tags LINK and STYLE to obj;
• we suppress all the scripts from obj

The target application does insert the gadget in the page inserting a BASE tag with the value returned by the server as the first child of head, using the HTML code returned by the server where it is required (ex: mon_div_gadget.innerHTML=obj.outerHTML).

    Insert a <gadget> tag in the page
    and process it using import.html

The advantage to use server side Javascript is that the loading of the page and the gadget reconstruction are much faster than with a mobile device for example, because of the processing capabilities of the server and its high bandwidth internet connections, so with a large optimization compared to the loading of an iframe on the user's device.

We can notice that the wide use of advertising banners whose size vary makes difficult the exact identification of the object location, so the method consisting in retrieving the "most likely object" (according to different criteria, like presence of an image, a word, a monetary symbol, the size, etc) is more reliable than the one consisting for example in scrolling an iframe to the supposed position of the object.

Page 12

The principles of the reconstruction is summarized in ANNEXE C which represents the structure of the target web page before and after the reconstitution of the gadget.

Page 13

ANNEX A : creation of a static gadget

    This annex describes an example how to create a gadget independent
    from the source page of the origin site, and therefore independent
    from the target web page where it will be reconstructed,
    with its own properties and styles including those inherited from the 
    parents.
    This is similar to the properties and styles of the custom element
    defined in import.html and isolated from the target web page per
    the Shadow DOM concepts

    Note: the source web page and the target web page can be the same,
     in that case the process describes how to define the properties and
     structure that can not interfer for the rendering with the rest
     of the page and vice-versa

Let obj be the selected object.

We restore the target links of obj if they exist.

1) If initial obj is different from BODY :

We scan all the parents of obj in order to keep the inherited styles.

We set width/height to 100% for them, we apply a transparent background image in order to remove the possible background images of the parents and keep only the background of obj, we position them relatively top 0, margin 0, padding 0

When we reach the body we create a div where the styles of the body are cloned, we set this div to the dimensions width and height of obj.

For the computation of width and height we take into account the positioning of the object with its parent (offsettop and offsetleft). We clone here the styles attached to the body tag only and not the styles applied to body by the CSS properties, because these properties will be present in the final gadget and be applied to it when it will be reconstructed.

We then apply the processes mentioned below {if obj=body}

We reconstitute the obj and parent tree, the parent div of the whole is the div mentioned below, this div becomes obj.

If obj=BODY

We keep obj.

We save the tags LINK and STYLE of BODY

We had the BASE tag in the HEAD (here we are on the source site so the links are pointing to the right place, when we will reconstruct the gadget we will have to give to the base tag the reference to the site so the links are fetching the right site)

We put the LINK and STYLE tags in HEAD.

We add the META tag UTF-8 if not present.

Page 14

We remove all the SCRIPT and NOSCRIPT tags (indeed for the static gadgets they become useless, and annoying in the case of scripts related to ads)

We apply to obj a function that transforms the links with an absolute reference (case of wrong interpretation of the BASE tag in some browsers) and we apply a specific operation to the OBJECT, EMBED tags in order for their code to be correctly retrieved when we will use the outerHTML of obj (to retrieve for example the flashvar which can be specific depending on the browsers)

    The BASE tag is optional since all the links are absolute now
    The gadget is independent from the main page (Shadow DOM)

2) Si obj initial = BODY

We replace in the outerHML of obj BODY...BODY by DIV...DIV which becomes obj, in order to keep the styles of body. This operation is useful since the gadget will be reconstructed in a web page whic has already its own body.

3) In both cases we get as the output:

json: content of HEAD without META, TITLE, BASE + outerHTML of obj

mtchtml: HTML HEAD BODY + outerHTML of obj + BODY HTML

Page 15

ANNEX B: creation of a dynamic gadget

Let obj be the selected object.

We search if obj or its parents that have only one child consecutively have an id or a name.

If yes, we keep the name (and its index in the chain returned by getElementsByTagName) or the id.

We keep the position and the dimensions of the gadget.

We keep the reference to the browser used.

Page 16

ANNEX C: structure of the target web page before and after the reconstruction of the gadget

Before the reconstruction of the gadget:

See the French patent drawing

After the reconstruction of the gadget:

See the French patent drawing

    See previous section for comparison
    with Web Components

Page 17

Claims

1- A process to display a gadget coming from a source web page from a web site in a target web page including the following steps:

a) individualization of different objects contained in the source web page, each of them being defined by a proper content and proper description parameters describing a structure of the object

    Source page: similar to import.html on the Web Components server
    taken as a whole as the custom element import.html
    whose content includes the description properties
    and defines a structure of the object <gadget>
    or
    individualization of different gadgets in the page defined by a proper
    content and proper description parameters when for example
    the target web page and the source web page are the same

b) selection of at least one of the objects in the source page

    Similar to the selection of import.html
    or
    to the selection of the the gadgets in the page

c) selective extraction, for the selected object, of its description parameters and its content, or of its description parameters alone; and

    Similar to the import of the structure and properties of the gadget in import.html
    or
    to the definition of the structure and properties of each gadget in the page

d) display of the gadget in the target web page, from the description parameters and content, or from the description parameters alone

    If not performed in step c):
        Similar to the import of the structure and properties of the gadget in import.html
        or
        to the definition of the structure and properties of each gadget in the page
    Similar to adding a gadget tag in the page or something equivalent
    and processing the rendering of the gadget

2- The process of claim 1, where step c) includes the search of the parent objects of the object individualized in step a), and the extraction of the description properties attached to this object and the properties inherited from the parent objects

    Properties and styles isolation (shadow DOM) defined in import.html

3- The process of claim 1, where the description parameters describe too the web styles associated to the selected object

    Idem

4- The process of claim 2 where the description properties describe too the web styles associated to the parents of the selected object

    Idem

5- The process of claim 1 where:

• the selective extraction in step c) includes the extraction of the HTML code of the object selected at step b, and
• step d) is a step that displays a gadget called static, from the description parameters and the HTML code prevviously extracted at step c)

    Similar to a <gadget> tag or equivalent and the
    structure/properties defined in import.html or in the page

Page 18

6- The process of claim 1 where:

• the selective extraction in step c) includes the extraction of the description properties alone, including the information containing an hyperlink to the origin site and criteria associated to the selected object, and

    Hyperlink of the custom element import.html

• step d) is a step that displays a gadget called "dynamic" from the decription properties with a call to a server via the insertion of a script in the target web page to operate:

    Import tag with href=hyperlink

• the loading, by the server of the source page from the origin site using the hyperlink

    The origin site is the server itself
    The source page is import.html

• the insertion on server side of a script of type Javascript in the loaded page which will extract the HTML code of the object as well as the description properties and will send the result to the target web page.

    The server sends back import.html
    or
    the page with the gadgets' struture/properties 

7- The process of claim 6, where step d) includes the search of the parents of the object individualized at step a), and the extraction of the description properties of this object as well as the description properties inherited from its parents

    Properties isolation (shadow DOM)

8- The process of claim 7, where the description properties describe also the web styles associated to the parents of the selected object

    Styles isolation (shadow DOM)

9- The process of claim 6, where step d) is a step that displays a dynamic gadget from the description properties and the HTML code returned by the server

    import.html and <gadget> tag processing, or processing of the gadget in the page

10- The process of claim 6, where the information extracted at step c) include: the URL of the origin site, id, name, position and dimensions of the selected object in the source page of the origin site, and a reference to the browser used for the steps a)-c)

    URL of the import tag
    The other parameters are not applicable for Web Components

11- The process of claim 6 where the information give also an identifier of the designated object

Page 19

12- The process of claim 6, where step d) includes the search, among the objects of the web page of the origin site referenced by a hyperlink, of at least one object whose content or structural intrinsic properties match a set of predefined criteria

13- The process of claim 1, where the description properties and the content extracted in step c) are encoded with the UTF-8 international format whatever enconding the source page is using

    Web Components encoding

14- The process of claim 1 where the description properties include the web parameters: BASE, HTML, web styles and size

    Content and properties of a custom element in import.html or of the gagdet in the page

15- The process of claim 1, where:

• it is foreseen to store the description parameters and the content in a database (16) of the server (14)

    Storage of import.html on the Web Components server or storage of the page

• the server (14) is a server distinct from the platform (10) implementing the steps of storage and display of the process; and
• the step of storing the description properties and the content includes the transmission of the description properties and the content to the server via a request of type cross-domain

Page 20

See the French patent

Fig. 1

Fig. 2a

Fig. 2b

The patent vs the traditional approach = the Web Components

As we have seen the process in the patent can create a gadget.html that can be called directly and be rendered as the whole page or inside a frame/iframe.

Frames and iframes are excluded from the patent, since the goal of the patent is to insert HTML gadgets that can interact with the rest of the page (and whose properties can not conflict with the rest of the page), unlike frames and iframes which are isolated objects in the page that can not interact with it.

As stated at the begining of the patent which gives some widget examples using iframes, one of the goal of the patent is to get rid of these iframe based methods.

Up to now, another traditional approach to insert a gadget in a page was typically:

<HTML>
  <HEAD>
    <script type="text/javascript" src="http://google-apis.js"></script>
    <script type="text/javascript" src="http://google-html.js"></script>
    ...
    <script type="text/javascript" src="http://google-jsapi.js"></script>
    <script type="text/javascript" src="http://google-maps.js"></script>
    <script type="text/javascript" src="http://google-chart.js"></script>
  </HEAD>
  <BODY>
  <div id="map"></div>
  <div id="chart"></div>
  <script language="Javascript"> //creation
    var map = new google-map($("map"));
    var chart = new google-chart($("chart"));
  </script>
  <script> //use it
    plenty of javascript code
  </script>
  </BODY>
</HTML>

This can look similar to the code examples in the patent or custom elements' code but is not.

The above example shows a constructor script for each gadget depending on other constructors, while the patent defines a universal constructor for all gadgets, like the Web Components.

"map" and "chart" are not really isolated objects, if for example the chart API comes from another vendor, conflicts are possible between the map gadget and the chart one, the gadgets in the patent have isolated styles, like the custom elements.

This model forces to use global variables for each gadget with possible conflicts, the developers usually don't like to use global variables and the logic would be to have variables wrapped to each gadget, which apparently the Shadow DOM spec is not specifying while its current implementations allow to have both local variables attached to the gadgets and global.

The patent does not really addresses specifically the variables scope's topic but in the examples given for the gadgets construction all the scripts are removed from the gadgets in order to avoid conflicts, avoid outside scripts not inherent to the gadget itself (such as tracking and ads scripts), and for security reasons, to avoid XSS attacks for example.

Another rationale for this was that when the patent was issued it was not trivial to associate scripts to a gadget since the innerHTML method would just ignore them, but the main claims are general and allow any possibility, as shown in the node-dom project used by node-gadgets which computes the scripts and therefore includes the result in the gadgets' properties and structure.

The gadgets of the traditional method are not really "individualized" as described in the patent, you don't really know what is inside and what is their HTML code, therefore it's not easy to interact with them, you have to use the specific constructor API for each.

And using the specific APIs is not simple usually, you have to develop a lot of javascript code as shown above even to perform really simple tasks.

The gadgets in the patent are HTML elements, "individualized", so pre-formatted, like the custom elements, so you don't need a lot of javascript code to use both.

The gadgets in the patent are built with the DOM only, needing a constructor which is an internal engine inside the browser like the Web components but using the DOM only, unlike the traditional way which builds multiple chained frameworks on top of the DOM.

The gadgets in the patent do not render until they are used, like the template tag for the custom elements, unlike the traditional way which computes everything that is in the page, in the examples given in the patent the gadgets' description properties and structure are defined inside the json file sent by the server, or returned as an Array in the node-gadgets project as another example.

As described in the patent one of the goal is to be able to display the gadgets created on any device supporting a web interface, especially mobile with maximum efficiency, which the "individualization" step of the gadgets allows since only what is needed is loaded to reconstruct the gadget, the traditional approach does not allow this, to render the map or the chart you have to load the complete constructor APIs and dependencies even if you are just using 1% of it.

That's why the concepts in the patent does produce a gadget as an isolated HTML piece, like the Web Components, so for devices that have limited processing capabilities, such as mobiles, they don't have to process a lot of frameworks and javascript code to render the gadget, they just have to inject the HTML code via the constructor engine that will just be parsed and rendered by the DOM.

In addition, the Extract Widget Mobile project shows how to transform automatically a web site to a mobile format, basically by selecting inside the page the relevant parts, transforming them into gadgets and retargeting them to the mobile interface, the project itself is not only about responsive design but again all this is very similar to the custom elements responsive design concepts, which has nothing to do with the traditional approach.

Note that the above project uses custom properties attached directly to the HTML tags, such as "ew=1", as shown here, a bit like the "old" way to use HTML, which the custom elements are doing also (HTML <google-map marker="lat,long"></google-map>) instead of defining complex properties attached to some javascript or css constructors.

And the BlimpMe! project shows how to mix the gadgets/custom elements with other elements and how they interact between each others, like with Google map.

Coming back to the traditional method, The patent approach allows to build the required map from the elements required only, which can be performed too by splitting the map into different gadgets or custom elements.

The traditional way usually forces you to define and load the gadgets API and all its dependencies (here google-apis, google-html, google-jsapi, etc) while in the context of the patent, only one call to the server is needed to retrieve the whole structure of the gadget, exactly like the import tag is doing.

Another drawback of the traditional method is that a problem with a script can block the loading of the page, which can not happen with the method defined in the patent and the Web Components.

This section illustrates again the numerous similitudes between the patent and the Web Components, as well as the numerous differences with the traditional approach.

The patent vs Polymer:

A typical Polymer script is:

<html>
<head>

  <title>Paper Calculator</title>

  <script src="../webcomponentsjs/webcomponents.js"></script> -> the constructor script in the patent

  <link rel="import" href="paper-calculator.html"> --> gadget

  <style>

  the styles of the main page

  </style>

</head>
<body>

main page

<gadget 1>

</body>
</html>

A typical patent script example is (after gadget inclusion - Annex C):

<html>
<HEAD>
    <BASE of the gadget> optional
    Styles, scripts, links of the main page
</HEAD>
<BODY>
<DIV>
main page
</DIV>

<DIV>
gadget
<LINK>
<STYLE>
--> isolated gadget with proper styles
</DIV>

</BODY>

To achieve this a constructor script is controlling the main page, loads the gadget (gadget.json, content + descriptors) and insert the gadget in the page (here in a DIV for this example), this is very exactly what are doing webcomponent.js, the import link and the gadget tag.

paper-calculator.html does define the individualized properties and content of the gadget, the constructor script is webcomponent.js, the import is performed by the link tag, the gadget is inserted inside the page via the gadget tag, similar to the patent main claim 1) a to d.

The patent vs X-Tags

X-Tags states "In order to allow for the recognition and parsing of custom HTML tags, X-Tag relies on a variety of events to detect and upgrade elements with user-defined, extended functionality. X-Tag works regardless of whether the element was present in the original source of the document

    Similar to Import

, added by setting innerHTML,

    Similar to p9 and 10 mon_div_gadget.innerHTML=gadget.html

or generated dynamically using document.createElement. Here's an example showing the registration of a custom element, with a description of each of the foundational interfaces the API offers:"

my-template.html:

<template id="my-template">
  <p>Hello there</p>
</template>

Same as above, this describes the individualized properties and content of the gadget stored on a server.

index.html
<!-- Import X-Tag -->
<script src="x-tag.js"></script>

<link rel="import" href="my-template.html" />

xtag.register("my-component",
  prototype object for the component
);

xtag.register('my-element', {
  lifecycle: {
    created: function () {
      this.innerHTML='test');
    }
  }
});

var t = document.getElementById('my-template').content;
document.body.appendChild(t.content.cloneNode());
</script>

<my-component>test1</my-component>
<my-element></my-element>

Same as the Polymer example, the constructor script is x-tag.js, the import tag loads the gadget, the gadget is inserted inside the page via a gadget tag or using another script that will render the gadget in the page using the properties/content of the gadget, this script is part of the global constructor script defined in the patent.

The above example shows that the second constructor script can create a gadget directly in the page, which is equivalent regarding the patent's main claim to have the source web page be the same than the target web page.

All this is similar to the patent main claim 1) a to d.

The patent vs React

React

markdown.js

var MARKDOWN_COMPONENT =("
    var MarkdownEditor = React.createClass({
      getInitialState: function() {
        return {value: 'Type some *markdown* here!'};
      },
      handleChange: function() {
        this.setState({value: React.findDOMNode(this.refs.textarea).value});
      },
      render: function() {
        return (
          <div className="MarkdownEditor">
            <h3>Input</h3>
            <textarea
              onChange={this.handleChange}
              ref="textarea"
              defaultValue={this.state.value} />
            <h3>Output</h3>
            <div
              className="content"
              dangerouslySetInnerHTML={{
                __html: marked(this.state.value, {sanitize: true})
              }}
            />
          </div>
        );
      }
    });

    React.render(<MarkdownEditor />, mountNode);
");

React.render(
  React.createElement(ReactPlayground, {codeText: MARKDOWN_COMPONENT}),
  document.getElementById('markdownExample')
);

Idem again, this describes the individualized properties and content of the gadget stored on a server.

<script type="text/javascript" src="react.js"></script>
<div class="example">
      <h3>A Component Using External Plugins</h3>
      <p>
        React is flexible and provides hooks that allow you to interface with
        other libraries and frameworks. This example uses <strong>marked</strong>, an external
        Markdown library, to convert the textarea&#39;s value in real-time.
      </p>
      <div id="markdownExample"></div>
    </div>
  </div>
  <script type="text/javascript" src="/react/js/examples/markdown.js"></script>
</section>

Idem also, the constructor script is react.js, the import is performed by the script calling markdown.js, the gadget is inserted inside the page via the div of id "markdownExample" and the constructors react.js and markdown.js, regarding markdown.js this is similar in the patent of a HTML content containing scripts evaled in the page completing the main constructor or to the javascript variables returned by the eval of the .json.

All this is similar to the patent main claim 1) a to d.

The patent vs Microsoft univeral Windows app

TODO

The patent vs Delite

Delite on github

<html>
    <head>
        <script src="delite.js"></script>
        <script>
            require.config({
                baseUrl: "../bower_components",
                paths: {
                    "title-package": ".."
                }
            });

                require(["title-package/TitleWidget"], function (TitleWidget) {
                    var anotherTitleWidget = new TitleWidget({value : 'another custom element title'});
                    anotherTitleWidget.placeAt(document.body, 'last');
                });

        </script>
    </head>
    <body>
        <title-widget id="element" value="The Title"></title-widget>
        <button onclick="element.value='New Title'; event.target.disabled=true">click to change title</button>
    </body>
</html>

Idem also, the the individualized description properties and content of the gadget are defined in "title-package/TitleWidget", the constructor script is delite.js, the import is performed by a call to "require", the gadget is inserted inside the page via a gadget tag, the process includes a callback in the require which is a prolongation of the global constructor script.

All this is similar to the patent main claim 1) a to d.

The patent vs AngularJS

AngularJS

index.html

<!DOCTYPE html>
<html ng-app="UIComponents">
<head>
    <title>A Reusable Smart Button Component</title>
    <link href="./lib/bootstrap.min.css" rel="stylesheet">
    <script src="./lib/angular.min.js"></script>
</head>
<body>
    <div class="jumbotron">
        <h1>Smart Buttons!</h1>
        <p><!-- static markup version -->
            <a class="btn btn-default">Dumb Button</a>
        </p>
        <p><!-- dynamic component version-->
            <smart-button></smart-button>
        </p>
    </div>
    <script src="./js/UIComponents.js"></script>
    <script src="./js/SmartButton.js"></script>
</body>
</html>

Idem also, the constructor script is angular-min.js, the import is performed by the script calling SmartButton.js, the gadget is inserted inside the page via the smart-button tag by the constructors angular and SmartButton.

All this is similar to the patent main claim 1) a to d.

The patent vs VanillaJS

VanillaJS

<!-- Importing Web Component's Polyfill -->
 <script src="../bower_components/platform/platform.js"></script>

 <!-- Importing Custom Elements -->
 <link rel="import" href="../src/x-reference.html">

 <x-reference href="./dummy-ext-resource.html?rel=author&" locator="#cite">
      <!-- Fallback -->
      <a target="_blank" href="./dummy-ext-resource.html?rel=author">by locator</a>
 </x-reference>

Idem also, x-reference.html defines the individualized propeties and content of the gadget, the constructor script is platform.js, the import is performed by the import link, the gadget is inserted inside the page via the x-reference tag by the constructor.

All this is similar to the patent main claim 1) a to d.

The patent vs Ember

Ember

<script src="http://builds.emberjs.com/ember-latest.js"></script>

<script type="text/x-handlebars" data-template-name="components/my-name">
   Hi, my name is {{name}}.
</script>
<script type="text/x-handlebars">
   {{my-name name="Toto"}}
</script>

var App = Ember.Application.create();

Idem also, the script with data-template defines the individualized propeties and content of the gadget, the constructor script is platform.js and the second script setting the name, the import of the template is performed by the script tag if not in the page, the gadget is inserted inside the page via the script name.

All this is similar to the patent main claim 1) a to d.

Conclusion

We did not analyze all the components/widget-like frameworks (Aurelia, Bosonic, etc), most probably they all follow the process defined in the patent, like all the projects mentioned above.

We issued the patent in 2010 and we summarize at the begining of the patent the state of the art at this date, to our knowledge nothing related existed before 2012.

We show all along this gist that the Web Components concepts are exactly the concepts describe in the patent without the added value that could bring the additional extraction mechanisms defined in the patent.

Indeed we think that they could be of interest too and could be integrated to the Web Components.

For example to extract a custom element customized by a given web site, like a specific stock price with some added value analysis from the site, or just to extract real time the price of a product, or for the companies (like supermarkets) to automatically compare their prices with the competition, etc

Project references

Our project implementing the patent:

Real-time shop bot

Webble

Extract Widget

BlimpMe!

node-bot

node-gadgets

node-dom

node-googleSearch

Other projects (Desktop Widget factory like)

MyTooCool

MonGadget

Unfortunately we had to stop all of them (including the desktop ones that we were migrating inside browsers following the patent concepts) due to the unwillingness of the major internet companies to provide a free of charge search engine usable from an application, to be precise when Google decided to deprecate its search API.

Since then we are concentrating on other projects mentioned below related to privacy/anonymity/security on the internet, we did not notice all the projects reusing the concepts of the patent which explains the late notice.

Peersm and node-Tor

Torrent-live and torrent-live on github