Method and apparatus for executing software applications

ES 2 612 263 T3

DESCRIPTION

Method and apparatus for running software applications

Field of the invention

The present invention relates to a method for running or terminating software applications.

Background

The latest developments in consumer electronics devices, such as, for example, high definition (HD) movie players for removable storage media, provide advanced interactivity capabilities for the user. Techniques for interactive software applications are based on command file execution, for example ECMAscript or on code execution, for example JAVA, which is either interpreted or precompiled to run in a virtual machine (VM) located on the device, Such an application, for example, could be a news ticker that displays a text at the bottom of the image in an overlay while, for example, an HD movie is running and is rendered on the screen. While the HD movie is read from the removable storage medium, the executable ticker application can also be read from the same medium or from the player's local storage. The application data can be stored, for example, in a file, for example a JAR file for Java applications. The data used by the ticker application, however, ie the message to be displayed, can be read, for example, from a server via the Internet.

WO01 / 33847A describes a method for reproducing a stored program that includes one or more interactive applications. When special playback modes are used, signals that affect the life cycle of an application are used to maintain proper application state, and applications that are not configured to operate during special playback modes are terminated. An application can be detected by comparing an application's validity interval with a current replay rate for the program.

Document WO02 / 086746A describes an automatic control of interactivity in sync with TV broadcast programs. A broadcast server controls the execution of interactivity on a broadcast receiver. A scheduling system uses identification of a broadcast schedule to determine if there is an attached interactive application and time information is used to determine whether the interactive application should be started, stopped, suspended, or resumed.

Both WO01 / 33847A and WO02 / 086746A describe applications that are related to a single program.

Compendium of the invention

A question that generally arises with software applications is what is the life cycle of such an application and who can control it. Especially if an application was read from a first removable storage medium and started while the medium was inserted into the player and then the storage medium was ejected and exited from the player, the common consequence for the running application (for example , the news ticker) is either to continue running independent of whatever storage media is inserted into the player or to terminate immediately. In the first case, the application process will generally run until the user terminates it manually, for example by turning off the device. This is uncomfortable for the user, particularly in the case of consumer electronic devices. Furthermore, it is desirable to have software applications that survive (that is, continue to run) also if the storage medium from which they were loaded is removed or otherwise not accessible.

The current invention provides a method of controlling whether a running software application loading from removable storage media and running on a removable storage media player should continue or terminate when removable storage media is ejected. In principle, the software application can also be run on a different connected device if the connection between the player and the other device includes control lines to terminate the application. Furthermore, the method according to the invention is suitable for controlling whether the execution of a software application can continue after another removable storage medium is inserted into the player. In accordance with the present invention, the decision whether or not a running application is terminated after media eject may depend on why the media was evicted and under what conditions the application was allowed to remain alive, ie continue to run.

In particular and assuming that a storage medium can contain a plurality of titles from which the user can select or which can be attached or threaded automatically, these conditions can include terminating an application always after a title change, terminating an application only after user initiated title change, terminate an application after title change when a previous title requested a particular follower title and the next title is not the requested title, terminate an application unconditionally after expulsion from the medium, terminate an application after expulsion from the medium only if the expulsion of the medium was done by a user, for example, pressing an eject button (hardware or software,

ES 2 612 263 T3 i.e. shown on the screen), terminate an application after ejection of the medium and Insertion of other medium and terminate an application after ejection of the medium and insertion of another medium, where the application requested particular half follower and the inserted medium is not actually the requested half follower. In other words, the software applications according to the invention loaded from removable storage media can have a defined lifetime, can request other specific removable media and can continue to run when the requested removable media is inserted or be terminated when other media is inserted. removable, unsolicited.

Furthermore, in one embodiment an application may specify a plurality of removable media that accepts and continues execution when any of the specified media is inserted while terminating when another media is inserted.

According to the invention, a method for executing software applications within a playback device for audio-video data read from a removable storage medium, wherein the playback device comprises a hardware button and / or a software button for ejecting the medium removable storage, comprises the steps of reading from a first removable storage medium data for a software application to be executed (preferably within said reproduction device), the data comprising command file code or executable code defining said application and further comprising an indication defining a termination condition for the application, storing said indication (preferably within the playback device), start the execution of said application (preferably within the playback device), receive a command to eject the first storage medium, detect whether the command received for ejecting was initiated by the software application or by the user using said hardware button and / or software for expulsion, decide, depending on said stored indication and the result of said detection, whether to terminate or continue the software application and based on the decision, terminate or continue the software application. If the application is running on another device connected to the playback device, an additional step performs the sending of a termination signal to the other device in order to terminate the execution process.

In an embodiment of the invention, the method for executing software applications is further specified in that the decision step comprises deciding to continue the execution of the software application, if said indication indicates that the execution of the software application can continue after the expulsion of said first storage medium or if the detection causes that the command for expulsion was initiated by the software application and said indication indicates that the execution of the software application can continue after ejecting said first storage medium if execution was started by the software application; or decide to terminate said software application, if said indication indicates the termination of the software application after ejecting said first storage medium or if said detection causes the eject command to be initiated by the user.

In one embodiment, the method for executing software applications further comprises the steps of receiving from said software application a first identifier, storing the first identifier, detecting before the step of deciding to insert another removable storage medium, reading a second identifier from the second removable storage medium, compare the first identifier and second identifier stored and decide, depending on said stored indication and the result of said detection and the result of said comparison, whether to terminate or continue the software application.

The identifiers that are read from the medium, for example, can be title identifiers or media identifiers, which are the same for several or all copies of a medium. In this way, identifiers that refer to content rather than physical media, that is, several or all copies of, for example, a particular edition of a particular film, have the same identifier. For read-only media, for example, the content provider can assign this identifier.

According to another aspect of the invention, a method for executing or terminating software applications within a playback device for removable storage media comprises the steps of reading a first identifier from a first removable storage medium, reading from the first media data for a software application, start the execution of said application, for example, in a virtual machine (VM), then detect a request for a particular removable storage medium, determine if the request comes from the user or the application and if the request comes from the application then also receive an identifier that identifies a requested removable storage medium, further store the received identifier which identifies the requested removable storage medium, eject the first removable storage medium, wherein the execution of said software application continues, detect the insertion of a second removable storage medium, read an identifier from the second removable storage medium, compare the stored identifier with the identifier read from the second removable storage medium and continue said application software if the identifiers compared match while otherwise terminating said software application.

In the preferred embodiment, the running software application contains an identifier that indicates whether the application is qualified to survive, that is, whether it should be terminated immediately upon ejection of the removable storage medium from which it was read. Such applications are referred to herein as "linked" because they are linked to a particular removable storage medium. Other applications are called "unrelated" herein, because they are not tied to a particular medium and may continue.

ES 2 612 263 T3 being executed after certain conditions after the storage medium from which they were read is ejected. This identifier relative to an application, for example, stored within a list of running processes or VM applications running and checked either while said removable storage medium is being ejected or later while a new storage medium is inserted. removable storage. In the latter case, the identifier of the new medium can be checked before terminating the linked applications, so that it is possible to continue even linked applications if the same medium is inserted again.

The solution given by this invention equally satisfies the content provider and the user of the player. On the one hand, it provides advantages with regard to security that are relevant to content providers who are afraid about the misuse of their multimedia content and, on the other hand, it prevents the user from being bothered by applications that continue to run when the user decides to eject the medium.

An apparatus according to the invention for reproducing multimedia data read from a removable storage medium, comprises a processing unit for executing command file code or executable code, for example Java or ECMAscript code, a hardware and / or software button for ejecting removable storage media, means for reading from a first removable storage medium data for a software application to be executed within said processing unit, the data comprising command file code or executable code defining said application and further comprising an indication defining a termination condition for the application, means for storing said indication, for example a record, means for receiving a command for ejecting the first storage medium, such as the aforementioned hardware and / or software button, means for detecting whether the command for ejecting was initiated by the software application or by the user using said hardware and / or software button for ejection, means of deciding, depending on said stored indication and the result of said detection, whether to terminate or continue the software application, wherein the means for deciding outputs a decision signal and means for terminating or continuing the software application, based on said decision signal.

According to another aspect of the invention, an apparatus for reproducing multimedia data read from a removable storage medium, comprises a processing unit for executing a virtual machine (VM), means for reading an identifier from a first removable storage medium, media to read data from the first removable storage medium for a first software application that is executable on the VM, means for detecting a request to change the removable storage medium, means for determining whether the change request comes from the user or the application, means for receiving an indication of a requested identifier if the request comes from the application, means for storing the requested identifier, means for ejecting the first medium, means for detecting the insertion of a second medium, means for reading a second identifier from the second medium, means for comparing the stored identifier with the second identifier and means for terminating said software application if the compared identifiers do not match and otherwise continuing said software application.

Advantageous embodiments of the invention are described in the dependent claims, the following description and the figures.

Brief description of the drawings

Exemplary embodiments of the invention are described with reference to the accompanying drawings, which show in Fig. 1 the life cycles of different software applications; FIG. 2 an exemplary menu application;

Fig. 3 a flow chart for starting an interactive application;

Fig. 4 a flow chart for terminating an interactive application, wherein the application ejects the media;

Fig. 5 a flow chart for terminating an interactive application, where the user ejects the media;

Fig. 6 a flow chart of the process to be executed before expelling the medium;

Fig. 7 a flow chart of the process to be executed after inserting a medium; and FIG. 8 an application program interface call requesting that a particular storage medium be inserted.

Detailed description of the invention

Although the following examples are based on optical disc players, the invention described herein is also applicable to other high-density storage media and respective players.

ES 2 612 263 T3

Consumer electronics devices, such as HD movie players, often provide the option of running software applications, particularly interactive applications, such as news tickers or games combined with movies. According to the present invention, these applications can be either disc-linked or non-disc-linked and title-linked or non-title-linked. In general, all disc-linked applications will be terminated if the disc is ejected, that is, it comes out of the player.

A non-disk-bound application, however, if started once, is potentially capable of continuing to be run by the virtual machine or interpreter of the environments (i.e., movie players), regardless of whether it is inserted or not. a specific disc. One idea of ​​the invention is for an application to indicate, for example, by means of a mark or indication, whether it is disk-bound or not. This mark indicates whether the application is a disk-bound or a non-disk-bound app. The flag can also be more than a single bit and conditionally indicate how the application should behave when the storage medium is ejected, depending on defined conditions. An Application Program Interface (API) provided within the player firmware serves to extract this information by investigating this flag for each (running) application.

A further advantage of the present invention is that it provides a mechanism that allows, for example, interactive HD movie disc content providers to use multi-disc applications that work safely and seamlessly on different discs. In this way, the invention provides data security against hacking. Furthermore, the invention ensures that the user of the HD movie player is able to terminate such a multi-disc application without interruption if desired. With state-of-the-art players either the content provider would not be able to generate multi-disc applications or the user would not be able to terminate such a multi-disc application. The invention preserves the interest of both parties.

One idea is that when the disc is ejected (or a title is finished playing) the player (that is, the environment) detects who started the ejection. If the eject was requested by an application that has the respective rights, for example, an interactive non-disk-bound application (implemented, for example, as a Java Xlet, where multiple Java applications can be run simultaneously), the eject will not end applications not linked to disk. After inserting another disk (or starting a new title respectively), the conditions for continuing to run non-disk-linked applications are also checked. Such conditions include, for example, that the new title should allow non-disk-bound applications to run. This can be further differentiated by generally allowing non-disk-bound applications or by checking through a security framework whether the interactive application can be identified as authorized or signed, to run with the new disk.

If the user directly requested eviction, all linked interactive applications are terminated as well as all unlinked ones. It is possible to further diversify the termination of the unbound application for this case by asking the user to confirm the termination. This prevents unintended interruptions. Furthermore, it is possible to distinguish between those interactive applications related to the disc that has just been ejected (or title that has just finished) and those interactive applications not linked to the disc that have just been ejected (or title that has just finished). The termination of the first type of applications can generally be decided by the user, as by default, while the termination of the second type can be decided by the user separately for each case.

Interactive applications run on a VM or script interpreter of an advanced interactive movie player can be started by the player or by the user. Fig. 1 shows the life cycles of different software applications, for example in a player while a first Disc-A disc was ejected and currently a second Disc-B disc is inserted. A date indicates where two user-initiated applications begin (ii, iv). Application lifecycles can be disk-linked (i) - (v) or non-disk-linked (vi). Fig. 1 further shows differentiations for such disc-linked interactive applications that are title-linked (i, ii) and such that they are not title-linked (iii, iv, v).

In principle linked to disc and linked to title are very similar from a logical point of view. In a simple case, a movie disc is carrying only one title that comes from a content provider, and the lifecycles of all linked interactive applications end when this title ends or is exited.

In many cases, however, a content provider could put more than one title on a single disc, for example, to provide a few episodes of standard definition (SD) video on a high-capacity disc. To solve the problem of handling interactive applications whose life cycle exceeds a title or a disc or, in other words, survives a service switch, this is very similar. The invention is (in parts) applicable in both cases. This, however, does not include user actions, because when playing multiple titles from a disc, user interaction ejecting a disc and inserting another disc is not necessary and is therefore skipped. Also the examination of a link_mark_to_disk explained below can be skipped in the title changes within a disk as for the cases (iii - v) in Fig. 1. The focus of the explanations is on the non-disk-bound application lifecycles (I saw in Fig. 1) that implicitly cover multiple titles located on a single disk.

ES 2 612 263 T3

The present invention provides a means for the player to distinguish between disc-linked and non-disc-linked Interactive applications, so that the player can determine the proper life cycle for a running application. One idea of ​​the invention is that a mark associated with each (interactive) application describes the intended use, that is, whether the interactive application is a disc-linked (or title) application or a non-disc (or title) linked application. A further idea is the definition of an Application Program Interface (API) that resides in the player firmware and that provides controlled access to the disk-bound_mark information defined for each application. By investigating the disk-linked_mark, the player is able to determine the proper lifecycle, that is, to react correctly to a disk eject request and an interactive application launch request.

A further advantage of the invention is that it provides a mechanism to allow the interactive HD movie disc content provider to use multi-disc applications without interruption and on the other hand to allow the user of a player to terminate such an application without interruption if he wishes.

The following explains what is understood as a seamless multi-disk application. A seamless multi-disc application can be useful for covering large volumes of content, for example television series or movie collections presented via an interactive application. For example, 134 episodes of a soap opera can be stored on twenty-two discs, making a collection and all episodes of all discs use or offer a common interactive application. This framed interactive application is visible to the user as a uniform interface, regardless of whether the collection disc is currently inserted. The non-disc-linked interactive application could also serve to provide disc navigation, i.e. title change through multi-disc applications or to accumulate tentative game results or to store viewing order, etc.

Giving the content provider a tool to establish multi-disk applications could, on the other hand, create disadvantages for the user, who is forced to react to interactive non-disk-linked applications running. When the user, for example, changes the disc in the movie player, pretending to play another movie, then the unlinked application still active could annoy him, for example, asking to insert a special disc or requesting the user to explicitly leave the service. In a more drastic case, it could force the user to turn off the power circuit for termination. Advantageously, the invention preserves the interest of both parties.

As shown in the flowcharts in Fig. 3-5, the player uses a mechanism to distinguish between both types of termination of non-disc-linked interactive applications, since it is the player that verifies who initiates the disc ejection. or change of service.

Fig. 3 shows a flow chart of how an exemplary interactive application is started. Three different sources are incorporated for the interactive application, managing the application that comes from the inserted disk, from the local storage of the player or from the Internet. The first case is the most common situation, because also in multi-disk applications the non-disk-linked interactive application source will normally be placed on all the disks involved. The second case could be, for example, a news ticker. The third case could typically be a studio server for the featured disk provided by the studio.

A security framework serves for consistency in the start of any interactive application, that is, check if the inserted disk allows to start unknown applications or checks if the launch request of the interactive application can be identified as authorized from the disk, for example, by means of a signature verification. The flow chart of Fig. 3 is left at B when an interactive application has been successfully started.

The interactive application life cycle started within the first diagram in Fig. 3 is continued by one of the next two flow diagrams in Fig. 4 and Fig. 5, but always only one of the two. Any end state B in the diagram is followed by either a start state B1 or a start state B2.

The flow chart in Fig. 4 shows the actions in case the request to eject the disk comes from an interactive non-disk-bound application (eg a Java Xlet). Ejecting will not terminate non-disk-bound applications, but rather the player will check, by means of, for example, the security framework and signature verification, if the disk inserted next is the one requested. If the next disk is the requested one, the situation is the same as when the end of Fig. 3 is reached, that is, state B is reached in Fig. 4 and another loop of the flow chart in Fig. 3 or also the flow chart in Fig. 4. Upon inserting another disk, unsolicited (i.e. starting a new service), the user can be informed about his action, i.e. he is told to insert the correct disk or the running multi-disk application will be terminated from another mode. In the event that the user recognizes that he has made a mistake, rejecting a change of service, the disk is ejected again (or the user ejects it) and the request is repeated to insert the correct disk. In case the user requests the change of service, the interactive application is terminated and the final state is reached. The new disk will boot starting with Fig. 3 again.

The flow chart in Fig. 5 shows the actions in case the request to eject the disk comes from the user. The flow chart Fig. 5 a) shows a simple solution terminating all interactive applications

ES 2 612 263 T3 linked and also all unrelated. A more sophisticated solution is represented in the flow chart of Fig. 5 b). It is possible to further diversify the termination of the unbound application by asking the user for confirmation of the termination. This prevents unintended interruptions.

Furthermore, it is possible to distinguish between those interactive applications related to the disc that has just been ejected and those interactive applications not linked to the disc that has just been ejected. The termination of the first type of applications can be decided by the general user while the termination of the second type can be decided by the user separately for each one.

Next, a further embodiment of the invention is described giving a more detailed description of the application framework. The example exploits the disk-linked_mark discussed above within the movie player firmware to ensure that a corresponding interactive application continues to run through a disk change. Also the use of the application signature is explained within the following flow charts depicted in Fig. 6 and Fig. 7.

While Fig. 6 describes what steps are processed from the movie player firmware when the request to eject a disc is directed to it, Fig. 7 covers the steps processed from the firmware each time a disc enters the player. . The described combination of a specific insert and eject stream is necessary to provide multi-disc interactive applications. A solution to the problem of maintaining data integrity is shown for the security of content providers and also for a proper user experience (i.e. the user should have the impression of no interruption, etc.).

The flow chart in Fig. 6 starts each time a disk is requested to eject. This could be requested either by the user when the eject button is pressed (hardware or software) or by an interactive multi-disk application. While the non-disk-bound interactive application is preparing the eject request by writing the media identifier (diskID) of the requested disk (or a plurality of media identifiers from a plurality of acceptable disks) to a special purpose register (diskID register) Upfront, the request to press the user button will enter the flowchart with the diskID record being empty.

Writing the requested disk's media identifier (or a plurality of media identifiers from a plurality of acceptable disks) to the special purpose register does not necessarily need to be done by the non-disk-bound application itself, but can also be done. done by an API, by another service, or by another application that is called or started by the non-disk-bound application.

In this case, the disc can be ejected immediately, but it is also possible to store a command for ejection, as shown in Fig. 8, so that the actual ejection must be confirmed by the user. This has the advantage that the user can change their mind and the applications can continue.

Since running applications are typically cached within the player, they can generally be rated for survivability of a media change. However, since such applications may require reloading a code from the medium from which they were loaded, it may be useful to have the same complete application code stored on all the media that are accepted by an unlinked application, so that it is possible the recharge.

The firmware is analyzing the diskID registration status and when the request comes from a user then it terminates all interactive applications. Another detail not represented has already been explained in Fig. 5 a). After finishing all interactive applications, the movie player physically ejects the disc and the flowchart is at its end.

When the firmware analysis detects a diskID within the diskID record, it begins looping through all running interactive applications, checking for each one whether it is a non-disk-bound application, whether it is signed, and also whether the application is stored. in the cache of the players. Only when all conditions are met does the application continue to run when the disc exits the player.

In all other cases the examined interactive application is destroyed. Checking the signature of an application ensures that no unauthorized application (malicious or pirated application) is able to pass the security framework. Checking if the non-disk-bound application is cached ensures that the application is able to survive when the disk exits the player. If the application were cached, it would probably "die", that is, it would be unable to continue, because the disk from which it was loaded is gone and there is nothing left to reload from.

When the loop through all running applications ends, only the signed and cached non-disk-linked applications are still running and with the physical ejection of the disk the flowchart is at its end.

ES 2 612 263 T3

A further idea of ​​the Invention, which is not represented in the flowcharts, concerns the case of exiting the loop through all running interactive applications. When the loop is exited and all applications have been terminated, then the diskID registry should also be cleaned, in order to avoid a warm start to the next disk. This will further improve the data consistency and robustness of the application.

Fig. 7 depicts the flow chart that the movie player firmware will input each time when a disc is inserted. First it checks if any media identifier (for example, DiscID) is stored in the DiscID register. This indicates that an interactive application asked the user to insert another disk. It is possible, however, that no application continues to run.

If the diskID register is empty, the disk will start in initial mode from the dash. The streak start is called a "cold" start, which kills all running interactive applications and also cleans up the diskID registry. In case a discID is stored in the DiscID registry, a second check will show if the stored discID actually matches that of the inserted disc. If this is not the case, the user can be warned and help will be given in deciding how to proceed.

Either the user intentionally inserted another disk, then all running applications are terminated and a cold start of the disk follows, or the user made a mistake and then gets another chance to insert the correct disk, as shown in the loop to back in the disc insertion flow chart of Fig. 7.

If the diskID of the newly inserted disk matches the diskID stored within the diskID record, the diskID record is cleaned up and a new investigation loop is executed through all running applications. It is checked if the running application is also part of the new title on the new disk and if it has the same signature as the one on the disk.

Both checks improve security and robustness. Only when both checks are passed successfully does the non-disk-bound interactive application remain running. If the application was not listed within the new disc (or title on the new disc), it is destroyed. If the signature of the disk application and the cache application do not match, the disk application restarts for consistency. The loop ends with a hot start of the disk. This means that the non-disc-bound interactive application continues, for example, to control the service for playback.

Another variant not shown in Fig. 7 is for the case where no application at all is running when exiting the application check loop. In this case a cold boot of the disk should also be performed.

An example is shown in Fig. 2. A disc player PL loaded from a first disc D1 having an associated identifier IDdisk_1 from a menu application, which is displayed on a screen SRC. The displayed menu contains a list of options for the user to select, a software eject button SW_EJ_B and a “Cancel” button C_B. The player has a hardware eject button HW_EJ_B. When the user selects a title, for example Part_31, the menu application determines from its internal list that the selected item is on a different disc than the one currently inserted and displays a message to the user to insert the requested disc. Internally, the application stores the identifier for the requested disk diskID_2 in a dedicated register (diskIDregister). For example, the currently inserted disk can now be ejected when the user confirms his selection, for example by selecting his choice Part_31 again, and the user can now eject the current disk with the hardware or software eject button. Since the application has stored an identifier for a next requested disk (diskID_2) in the dedicated registry, the eject is classified as not user-initiated but application-initiated. Therefore, non-disk-bound applications, such as the menu application, can therefore continue to run. If the user changes his mind, he can still press the Cancel button C_B. This can, for example, have the effect that the already open disc tray is closed again and the application reverts to its previous state.

Generally, consumer electronics devices can provide advanced interactivity capabilities for the user, implemented as software applications. The invention provides a method for executing software applications within a playback device for audio-video data, wherein data from a first removable storage medium is read so that a software application is executed within said playback device and the data they comprise an identification that defines a termination condition for the application. Based on said termination condition and depending on how the media containing the application is ejected, the application is terminated or may survive.

Another example of an application is a guide application built to cover multiple discs. Inserting the first disc in the series starts the guide application and the guide application will survive any disc change until a non-series disc enters. This provides the user with a seamless experience. The invention ensures that only authorized applications can automatically survive disk changes, while non-matching interactive applications are terminated.

ES 2 612 263 T3

The invention is applicable to all types of storage media and corresponding players, which are today particularly optical discs such as DVD, HD-DVD or Blu-ray discs and their corresponding players. The invention is particularly useful for players that are capable of running interactive software applications.

Examples of software applications are a news ticker that connects to the Internet or that organizes software in a manner of personal data assistant (PDA) that can be modified depending on the currently inserted disk, for example, a calendar manager that reads data from a local storage such as a hard disk drive (HDD).