ITBO20120053A1 - DECENTRALIZED AND MULTI-LAYERING ARCHITECTURE OF DISTRIBUTION AND DISTRIBUTION OF DIGITAL INTERACTIVE CONTENT INTEGRATED TO TELEVISION DIFFUSION - Google Patents

Description

DESCRIPTION

of industrial invention entitled:

DECENTRALIZED ARCHITECTURE AND MULTIPLATFORM BY

DELIVERY AND DISTRIBUTION OF DIGITAL INTERACTIVE CONTENT

INTEGRATED TO TELEVISION DIFFUSION

Technical reference field

The invention refers to any mode of television broadcasting, such as DVB-T (digital terrestrial), DVB-S (digital satellite), DVB-C (cable) and similar open or proprietary solutions, standard or less.

At the same time it refers to the field of digital interactive platforms (such as the web or a blu-ray player) and, in particular, to the integration of the latter with the aforementioned television broadcasting.

State of the art: MHP and equivalents

Currently the most advanced interactive standard solution used by television broadcasting in Europe is “Multimedia Home Platform”, alias “DVB-MHP”, alias “MHP”. Equivalent solutions are used in the United States, two of which are quite famous are the “EBIF” and “tru2way” standards. We are not aware of any other established alternative technologies to those mentioned. The operating model of EBIF and tru2way follows that of MHP: for simplicity and synthesis, in the rest of the discussion we will refer only to MHP as an emblem of the state of the art.

MHP is an open middleware created as a sub-set of the Java language for the development of interactive applications / services called Xlet which take the form of graphic / textual enrichments of the television image.

MHP can take advantage of Internet connectivity (eg ADSL) to read content from the web. For this purpose it natively provides a special language called DVB-HTML, apparently scarcely used due to the complexity of the related specification. We were unable to identify objective data on how widespread the adoption of DVB-HTML is, our statement comes from a presentation by Prof. Stefano Ciccotti of the La Sapienza University of Rome, available at:

http://www.comunicazione.uniroma1.It/materiali/8.42.58 StC 3Modulo Distribuzione.pdf Also via the Internet, MHP allows the television user who is using an Xlet to forward inputs that affect the operation of the Xlet itself, in a way completely analogous to what happens with a form in a web-application. Without Internet connectivity the device would have no way to send inputs to the broadcaster, since the DVB channel is one-way.

It is our sincere opinion that the MHP tool suffers from some serious limitations deriving from non-optimal architectural choices: the context in which MHP was born and developed intrinsically penalizes it.

It is in fact created as an interactive software component dedicated to devices that by their nature would not be interactive: technically a DVB “receiver” should only receive. To make everything work, DVB receivers have been specialized with components that are atypical for them, designed to create a "return channel" where it was not there, passing through the Internet (eg modem, network card). The resulting hardware platform, so specific and dedicated, reflects these features on the software that drives it: while relying on the consolidated Java technology, in fact, MHP gives life to a development framework and an "ad hoc" execution environment, not used in other contexts, and therefore interesting only for programmers specialized in MHP.

Nevertheless, the platform imposes some stringent constraints in terms of development:

• the programming interface does not admit alternatives, the only language that can be used is a subset of Java called DVB-J (flanked by the specific markup language DVB-HTML)

• the runtime engine is also required (a specialized JVM wired into the device) • for the possible representation of web contents it requires the use of DVB-HTML, whose adoption seems to have never caught on due to the excessive complexity (see above); a possible work-around consists in the use of a browser written in DVB-J language and incorporated in an Xlet, but this involves a greater use of bandwidth (much more substantial Xlet) and the fact that the browser is custom and therefore the web content is generally not optimized to be compatible with it (crossbrowser issues);

• MHP Xlets can only be composed of a few predetermined data types: Java classes, XML files, TXT files, PNG / JPG / GIF images, MP2 audio and MPG video

• the system font supported by default is only one (Tiresias Screenfont)

By virtue of the foregoing, we can already say that this is not a full-featured software environment comparable to the general purpose ones that run on a personal computer, which have a boundless ecosystem of alternative technologies available: inevitably, compared to them, it presents a lower potential.

The specific character of the platform, so peculiar compared to what is already known to the majority of non-MHP developers, and the intrinsic limits described above raise the technological entry barrier, determining a low incentive for the adoption of the technology and consequently lowering its value. technician.

Finally, perhaps the most important consideration: MHP assumes that part of the interactive content is necessarily conveyed within the television data flow, effectively centralizing control over such contents in the hands of the television companies and introducing an additional barrier of entry, this time economic / commercial, for the access of small and medium players in the "interactive TV" market.

The invention

It consists of an innovative architecture for the delivery and distribution of interactive digital content intended for contextual or non-contextual, informative and / or functional integration with television broadcasting.

The existing state-of-the-art architecture identifies the natural placement of interactive contents in the television stream: it primarily integrates upstream of the user device, which is in the possession of the end user. It then envisages that this device, conceived as an ad hoc machine, uses an interactive media (generally the web) to complete the contents broadcast on the television stream and enhance their possibilities of interaction.

Fig. 2 is a schematic description of what has just been said: the blue color indicates the interactive media and the green color indicates the mixed television-interactive flow.

The proposed architecture, on the contrary, takes interactive content out of the traditional television flow. It foresees that the integration takes place, not upstream, but inside the device of use, conceived as a generic computer, e

that the exploited interactive media provides content,

not complementary (to others incorporated in the flow

television), but whole and fully usable.

Fig. 3 is a schematic description of what

just said: the orange color indicates the flow

television without the interactive content to be integrated,

blue and green have the same meaning as

Figure 2.

The specific characteristics of architecture and the way in which

it exceeds the limits of the state of the art (see

previous paragraph) will be illustrated below

through the commentary and the comparison of

images attached to this. We will conclude

with an example of embodiment of the invention

focused on usability in the industrial field.

Conceptual model of the invention: figures and comment

Fig. 4, which we are going to comment on, describes the conceptual model of the invention.

Fig. 4 / A: is the television broadcaster (or company) that broadcasts its one-way audio-video stream. It does not matter what medium the stream is conducted on: it could be DVB broadcasting, or a stream adequately encoded and intended for use via the Internet. What matters is the absence, in the flow, of interactive content intended for integration. It is envisaged that the television broadcaster may optionally make available meta-data relating to its broadcasting activity.

Fig. 4 / B: are the actors interested in the production and / or distribution of interactive contents for television integration. They can, if they believe, make use of the meta-data mentioned in the previous point.

The actors create and make the contents available on the interactive media and at the same time register the requests for integration at a specific service (or more specific services).

Fig. 4 / C: the register of integration requests represents the service through which the actors referred to in point B can indicate which television contents they want to integrate, at what time, with which interactive contents and with which options / methods.

It is plausible that an integration request may contain time indications suitable for achieving synchronization with television broadcasting, for this reason the architecture provides that the register optionally has a reliable time reference available.

The time reference is optional since the time of integration could be defined on the basis of the content of the audio-video stream of the broadcaster (eg: audio or video pattern recognition), eliminating the need for time synchronization.

Fig. 4 / D: is the device that collects the television input and the “interactive” input, still completely separate, integrates them and delivers the result to the television set for viewing the output; at the same time the device collects user input to mediate it towards interactive contents.

As already emerges from the comment just written, the conceptual model wants to abstract the general functioning of architecture, therefore it presupposes that the entities and the relationships that compose it are not understood as necessarily linked in a bijective way to corresponding real entities. For clarity: if "Complete interactive contents" are indicated in a logical block of the diagram, this does not mean that these contents, in practice, must be spatially collected in the same source or in any case must share the same physical medium. Similarly, two logically distinct blocks such as the “Reliable time reference” and the “Integration request register” can very well, in practice, be implemented in the same device and / or by the same service. This also applies to relationships: the arrow in figure 4 / E could suggest that the "Interactive content producers" necessarily created such content and made it available in person, but in practice they could only be investors who have delegated to appropriate professional technicians to create the contents and to communication experts to publish them. As the schematization of every possible implementation of the architecture is not plausible, we believe that the presentation of an abstract model of the same is the only way to describe it in its entirety.

To further clarify the general character of the schematization, we bring two examples that we consider relevant.

1) the first example concerns the case in which the television broadcaster acts as a register of additions.

Let's assume that someone implements the architecture by conveying the information of the "register of integrations" on the television stream: in essence, the interactive content object of the integration remains outside the television media, but the indications on when and how to integrate this content come from broadcaster (transmitted, for example, via MHP).

This scenario could appear not included in the proposed architecture, by virtue of the fact that the television stream is not devoid of extra information, but in reality it is not: the architecture does not place any constraints on how the register of integrations is physically implemented, it is admitted that this role is performed by the issuer itself; moreover, the architecture provides that the television stream does not incorporate the interactive content object of the integration, but this does not exclude that it may contain other types of data in addition to the normal audio-video content.

2) in the second example, analogous to the first, the “broadcasting metadata” are conveyed in the television stream (eg: again MHP).

Let's assume this time that someone implements the architecture by making a time synchronization with the schedules and that these are disseminated via MHP or EPG (“Electronic Program Guide”, old non-interactive protocol).

Also in this case, although additional data to the normal audio-video content travel on the television stream, the implementation falls within the architecture: there are no constraints on how the broadcaster can materially expose meta-data inherent to its broadcasting activity, and even if these are incorporated into the television stream, it remains free from interactive contents intended for integration.

Example of a concrete scenario of the invention

Fig. 5, which we are going to comment on, describes a possible concrete scenario of the invention. Fig. 5 / A: the television broadcaster operates broadcasting with DVB-T technology, this is the Italian case of digital terrestrial.

The transmission does not contain additional data to the audio-video stream, therefore no MHP or similar content.

The broadcaster could optionally publish its updated schedule on the web.

Fig. 5 / B: generic companies interested in integrating their (already existing) web applications

Claims (1)

Claims 1. the architecture allows the interactive TV experience without sending any part of the interactive content within the normal television audio-video stream; 2. the architecture allows interactive TV without imposing the choice of a particular platform for the creation of interactive contents; 3. the architecture makes it possible to integrate pre-existing interactive contents with the television stream without the need to re-implement the contents themselves; 4. the architecture allows interactive TV in a technically independent way from the broadcasting platform of the television companies; 5. the architecture allows interactive TV without imposing the choice of a particular software or hardware platform for the device that realizes the integration of the interactive contents with the television stream; 6. the architecture allows the use of interactive contents for TV conveyed without the need for fragmentation on multiple media or for multiple, complete and fully usable implementations even outside of television integration; 7. the architecture allows the integration of interactive contents also for TV broadcasters without any technical predisposition in this sense.