Method and apparatus for executing software applications

[0001] This invention relates to a method of performing or terminating the execution of software applications.

Background [0002] Recent developments in consumer electronics, such as, for example, high definition (HD) movie players for removable storage media, provide the user with the possibility of advanced interactivity. Techniques for interactive software applications are based on the execution of scripts, for example ECMAscript, or code execution, for example JAVA, which is either interpreted or pre-compiled for execution on a virtual machine (VM) placed on the device. For example, such an application may be an information bar that depicts the text superimposed at the bottom of the image, while, for example, an HD movie is executed and depicted on the screen. While an HD movie is read from a removable storage medium, from the same media, or from a local player data medium, the executable file of the information bar application can also be read. These application data can be stored, for example, in an archived file, for example in a JAR file for a Java application. The data used by the information bar application, i.e. the display message, can, however, be read from a server via the Internet, for example.

[0003] WO01 / 33847A discloses the reproduction of programs that include one or more interactive applications. These applications are detected either when they are available or by comparing their validity with the program's playing time. When special playback modes are used, signals are detected that affect the application's lifecycle and, to maintain the proper application status, the signals are generated.

[0004] WO02 / 086746A discloses a synchronous update of dynamic interactive applications, where a server interfaces with broadcast scheduling systems to maintain a suitable interactive application for each broadcast program. This applies to synchronization programs and interactive applications such as television shows and commercials.

Summary of the Invention [0005] A general problem that arises in relation to software applications is what the period of activity of such applications means and who can control it. In particular, if an application has been read from the first removable storage medium and launched when the media has been inserted into the player, then the storage medium has been removed and left the player, usually this will affect the application being executed (e.g., the information bar) such that or it will continue to operate, independent of any data media entered into the player, or it will immediately exit. In the first case, the application process will usually run until the user finishes it manually, for example by turning off the device. It is uncomfortable for the user, especially in the case of consumer electronics devices. In addition, it is desirable to have software applications that will survive (i.e., they will continue to operate) also when the data carrier from which they were loaded will be removed or otherwise inaccessible.

[0006] The present invention provides a method for controlling whether a running software application that has been loaded from a removable storage medium and operating on a media player, should be continued or terminated when the removable storage medium is removed. In principle, this software application can also work on another attached device if the connection between the player and another device contains control lines to complete the application. Furthermore, the method according to the invention is suitable for controlling whether the execution of a software application can be continued after the insertion of another removable storage medium into the player. According to the present invention, the decision whether after the removal of this medium the running application is to be terminated may depend on why the medium was removed,

terminating the execution of the application after removing the medium and inserting another medium and terminating the application after removing the medium and inserting another medium, where the application requires a special next carrier, and the inserted carrier is not really the next carrier required. In other words, the software applications of the invention loaded from a removable storage medium may have a specific period of activity, may require a specific other removable media, and may continue to operate when the required removable media is inserted or terminated when another removable media has been inserted that was not required. and the carrier actually introduced is not a required further carrier. In other words, the software applications of the invention loaded from a removable storage medium may have a specific period of activity, may require a specific other removable media, and may continue to operate when the required removable media is inserted or terminated when another removable media has been inserted that was not required. and the carrier actually introduced is not a required further carrier. In other words, the software applications of the invention loaded from a removable storage medium may have a specific period of activity, may require a specific other removable media, and may continue to operate when the required removable media is inserted or terminated when another removable media has been inserted that was not required.

[0008] Furthermore, in one embodiment, the application may determine a plurality of removable media accepted by it and continue to perform when any of these specific bearers is inserted, and end the execution when another carrier is inserted.

According to the invention, a method of executing software applications by a device for reproducing audio-video data read from a removable storage medium, wherein the reproducing apparatus comprises a hardware button and / or a soft key for removing the removable storage medium, comprises the following steps:

whether to end or continue this software application and, based on this decision, terminate or continue to perform this software application. If the application works on another device connected to the reproducing apparatus, this step then performs sending the termination signal to that other device in order to complete the operation process.

[0010] In one embodiment of the invention, the method of executing a program application is further defined so that the decision step comprises a decision to continue executing the software application if said marking means that execution of the software application may continue after removing the first mentioned data storage medium, or if the detection shows that the delete command has been initiated by the software application and said marking means that the execution of the software application can be continued after the first removable data carrier has been removed, if this deletion was initiated by the software application; or the decision to terminate the said software application,

[0011] In one embodiment, the method of executing a program application further comprises the steps of receiving the first identifier from said software application, saving the first identifier, detecting before inserting another interchangeable data carrier in the decision step, reading the second identifier from the second removable storage medium, comparing the first stored data carrier. an identifier and a second identifier, and deciding, depending on said stored indication, about the result of said detection and the result of said comparison, whether to terminate or continue the software application.

[0012] Identifiers that are read from this medium may be, for example, title identifiers or media identifiers that are the same for a number or all copies of the medium. These identifiers therefore relate to the content rather than the physical medium, i.e. a certain number of copies or all, e.g. a specific release of a particular movie, have the same identifier. The content provider may assign this ID to, for example, read-only media.

[0013] According to another aspect of the invention, the method of performing or terminating the execution of software applications in a reproduction apparatus for removable storage media comprises the following steps:

reading the first identifier from the first removable storage medium, reading the software application from the first data carrier, initiating execution of said application e.g. on a virtual machine (VM), then detecting a request for a specific removable storage medium, determining whether the request comes from the user or the application and if the request originates from the application, then also receiving the identifier identifying the desired removable storage medium, further recording the received identifier identifying the desired removable storage medium, removing the first removable storage medium, where executing said software application is continued, detecting the introduction of the second removable storage medium, reading the identifier from the second removable storage medium,comparing the stored identifier with the read identifier of the second removable storage medium, and continuing said program application if the compared identifiers match each other, and otherwise terminating the said program application.

[0014] In a preferred embodiment, the launched software application includes an identifier indicating whether the application is legitimate to survive, i.e. it must be terminated immediately after the removal of the removable data medium from which it was read. Such applications are referred to herein as "related" because they are associated with specific removable storage media. Other applications are referred to herein as "unrelated", because they are not associated with specific bearers and may continue to operate under specific conditions after the data carrier from which they were read has been removed. The identifier relating to the application is, for example, stored in the list of running processes or running application VM machines and checked either when said removable storage medium is removed or later when a new removable storage medium is inserted. In the latter case, the new media ID can be checked before the end of the associated application, so it is possible to continue even the related application if the same carrier is re-entered.

[0015] The solution offered by this invention equally satisfies both the content provider and the user of the player. On the one hand, it provides security advantages that are relevant to the content provider, fearful of abuse when using their multimedia content, and on the other hand protects the user from irritation caused by applications that continue to work when the user decides to remove the medium.

The device according to the invention for reproducing multimedia data read from removable storage media comprises a processing unit for executing script code or executable code, e.g. Java code or ECMAscript code, a hardware and / or software button for removing this removable storage medium, means for reading data from the first removable data carrier for executing a software application in said processing unit, said data comprising script code or executable code forming said application and further comprising a sign determining a termination of said application, means for storing said indication, example, a register, means for receiving a command to delete a first data carrier, such as a hardware and / or software button mentioned above,means for detecting whether an eject command has been initiated by a software application or by a user using said hardware and / or software delete button, means for deciding, depending on said recorded indication and the result of said detection, whether the software application should end or not continue, where the decision-making means outputs the decision signal and means to terminate the execution or continuation of the software application, based on said decision signal.whether the software application is to end or continue, where the decision-making means output a decision signal and means to terminate the execution or continuation of the software application, based on said decision signal.whether the software application is to end or continue, where the decision-making means output a decision signal and means to terminate the execution or continuation of the software application, based on said decision signal.

[0017] According to another aspect of the invention, a device for reproducing multimedia data read from a removable storage medium comprises a virtual machine processing unit (VM), means for reading an identifier from a first removable data carrier, reading means, from a first removable storage medium. data, data of the first software application executable on the VM machine, means for detecting the change request of the removable data carrier, means for determining whether the request for change comes from the user or from the application, means for receiving the identification of the desired identifier, if the request comes from the application , means for recording the desired identifier, means for removing the first carrier, means for detecting the insertion of the second carrier,means for reading the second identifier from the second bearer, means for comparing the stored identifier with said second identifier and means for terminating the execution of said program application if the compared identifiers do not match each other, or otherwise continue the said software application.

[0018] Preferred embodiments of the invention are disclosed in the dependent claims in the following description and figures.

Brief Description of the Drawings [0019] Exemplary embodiments of the invention are described with reference to the accompanying drawing, which shows in Fig. 1, periods of activity of various software applications;

fig. 2, an exemplary menu application;

Fig. 3, a block diagram of running an interactive application;

4, a block diagram of executing an interactive application, where the application removes the medium;

5 is a flowchart for terminating an interactive application execution where the user deletes the medium;

FIG. 6 is a block diagram of a process to be performed before the carrier is removed; Fig. 7, a block diagram of a process to be performed after inserting the carrier; and FIG. 8, the application interface of the application for calling a specific data carrier request.

Detailed description of the invention [0020] Although the following examples are based on optical disc players, the invention described herein also applies to other high density data carriers and to respective players.

[0021] General electronic devices, such as HD movie players, often provide the ability to run software applications, especially interactive applications such as information bars or games combined with films. According to the present invention, these applications can be either associated with the disc or unrelated to the disc, and associated with the title or unrelated to the title. In general, all disk-related applications are terminated when the disc is removed, ie it leaves the player.

[0022] An application unrelated to the disk, if it has already been started, is potentially capable of proceeding with the execution of a virtual machine (VM) or an environment interpreter (i.e. a movie player), regardless of whether a particular disk is inserted or not. One of the ideas of the invention lies in the fact that the application signals, for example with a tag or sign, whether it is associated with the disc or not. This tag indicates whether the application is associated with the disk or whether the application is unrelated to the disk. The tag can also be more than a single bit and conditionally indicate how the application should behave when the storage medium is removed, depending on the specific conditions. Application programming interface (API), provided in the player's software,

[0023] A further advantage of the present invention lies in the fact that it provides a mechanism that enables, for example, content providers of interactive HD movie disks to use multi-drive applications that work safely and smoothly on different disks. Thus, the invention improves the protection of data against piracy. Furthermore, the invention provides that the user of the HD movie player can, if he wishes, end such a fluid multi-drive application. In the prior art players, neither the content provider would be able to create multi-drive applications nor would the user be able to terminate such multi-drive applications. This invention protects the interests of both parties.

[0024] One idea is that when a disc is deleted (or the title is terminated), the player (i.e., the environment) detects who initiated the deletion. If the removal was requested by an application with appropriate permissions, for example an unbotable interactive application (implemented for example as Java Xlet, where a number of Java applications can be run simultaneously), the removal will not end applications unrelated to the disk. After entering another disk (or starting a new title, respectively), the conditions for continuing the unrelated application running are also checked. Such conditions include, for example, the fact that the new title must enable these unrelated applications to be executed.

[0025] If the request is directly requested by the user, all related and also all unrelated interactive applications are terminated. Further diversification of the end of an unrelated application is possible in this case by asking the user to confirm the end request. This avoids unintentional interruptions. In addition, it is possible to distinguish between interactive applications, just the deleted disk (or the just finished title) and interactive applications, unrelated to the just removed disk (or just finished title). Completion of the first type of application can be, by default, taken by the user as general, while the end of the second type can be taken by the user separately for each case.

[0026] Interactive applications, executed on a VM machine or script interpreter of an advanced interactive movie player, may be run by the player or by the user. Fig. 1 shows the periods of activity of various software applications, for example when the first disc, Disc-A was removed from the player, and the disc Disc-B is now inserted. The arrow indicates the moment when two applications were started by the user (ii, iv). Application activity periods can be associated with disk (i) - (v) or unrelated to disk (vi). Figure 1 further illustrates the distinction of such disk-related interactive applications that are associated with the title (i, ii) and those that are unrelated to the title (iii, iv, v).

[0027] In principle, those associated with the disc and associated with the title are very similar from a logical point of view. In a simple case, the movie disc has only one title from the content provider, and the activity periods of all related interactive applications end when the title ends or is left behind.

[0028] However, in many cases, the content provider may place more than one title on a single disk, for example, to have a high capacity disk, provide some episodes in standard definition (SD) video. Very similar is solving the problem of controlling interactive applications whose activity period exceeds one title or one disk, or in other words that will survive the switching of services. This invention (partly) finds application in both cases. However, this does not apply to the user's actions, because when playing multiple titles from one disk, user interaction that removes the disk and inserts a different disk is not necessary, and thus omitted. Also, the examination of the disc_bound_flag tag explained below may be omitted when the title changes within one disc as in cases (iii - v) in figure 1. These explanations focus on the periods of application activity unrelated to the disk (vi in ​​Figure 1), which implicitly covers numerous titles placed on a single disk.

[0029] The present invention provides the player with means for distinguishing disc-related and disc-unrelated interactive applications, thus the player may determine appropriate periods of active application activity. One of the ideas of the invention lies in the fact that the tag associated with each (interactive) application describes the intended use, i.e. whether this interactive application is an application associated with the disk (or title) or unrelated to the disk (or title). Another idea is to create an application programming interface (API) located in the player's hardware and to provide controlled access to information in the disc_bound_flag tag, set for each application. By testing the disc_bound_flag tag the player can set an appropriate period of activity,

[0030] A further advantage of the invention lies in the fact that it provides a mechanism that allows the content provider to seamlessly use multi-drive applications on interactive HD movie disks and, on the other hand, allows the user of the player to end such a fluid application if he wishes.

[0031] The following explains what is meant as a fluid multi-drive application. A seamless multi-hop application can be useful for delivering a large volume of content, such as a TV series or a collection of videos, presented with the help of one interactive application. For example, 134 soap opera episodes can be stored on the twenty-two discs that make up the collection, and all of these episodes, from all disks, use or offer a shared interactive application. This skeletal interactive application is seen by the user as a unified interface, regardless of which disk from the collection is currently entered. An unrelated disk interactive application can also be used to provide navigation between discs, i.e. change the title in multiple application disks, or to collect intermediate game results,

[0032] Providing the content provider with a multi-drive application tool may in turn create a disadvantage for the user who is forced to respond to unrelated interactive applications running. For example, when a user changes a disk in a movie player in order to play another video, then the still active unrelated application may interfere with it, e.g. by requesting a special disk or directly requesting the user to close the service. In a more dramatic case, to terminate the service, it can force the user to turn off the power. The invention advantageously protects the interests of both parties.

[0033] As illustrated in the block diagrams of figures 3-5, the player uses a mechanism to distinguish between both types of termination of unrelated disk-related interactive applications, because it is a player that checks who initiates disk deletion or service change.

[0034] Fig. 3 shows, in the form of a flowchart, the running of an exemplary interactive application. Three different sources are included to support the interactive application, which come from the entered disk, from the local memory of the player or from the Internet. The first case is the most common situation, because also in multi-drive applications, the source of an unrelated disk interactive application will usually be placed on all involved disks. The second case can be, for example, an information bar. The third case may usually involve a studio server, provided to the recommended drive through this studio.

[0035] The framework security structure is used to ensure consistency at the start of any interactive application, i.e. checks whether the inserted disk allows running unknown applications or checks whether the request to run this interactive application can be recognized as authenticated by the disk, for example by verifying the signature. When the interactive application is successfully launched, the action network of Figure 3 is left in B.

[0036] The period of active application activity running as in the first network of Fig. 3 is continued on one of the two following block diagrams of Fig. 4 and Fig. 5, but always on only one of the two. After any final state B in the action network, either the initial state B1 or the initial state B2 takes place.

The flowchart of Fig. 4 shows the actions in the case where the disk removal request came from an unattended disk-related application (e.g. Java Xlet). This removal does not end applications unrelated to the disk, but the player will check, with the help of, for example, a framework security structure and verification of the signature, whether the disk that was introduced as the next one is the one required. If the next disk is the one required, the situation is the same as after reaching the end in Fig. 3, i.e. the state B in Fig. 4 has been reached and another loop may be followed in the block diagram of Fig. 3, or also the block diagram in Fig. 4 When entering another, not required disk (i.e., starting a new service), the user can be informed about its operation, that is, he is asked to enter the correct disk, or else the multi-drive application will be terminated. In the event that the user has recognized that he has made a mistake, the disk is deleted (or deleted by the user) by rejecting the service change request and the request to enter the correct disk is repeated. In the event that the user requests a service change, the interactive application is terminated and the final state is reached. The new disk will start operating again from Fig. 3. In the event that the user requests a service change, the interactive application is terminated and the final state is reached. The new disk will start operating again from Fig. 3. In the event that the user requests a service change, the interactive application is terminated and the final state is reached. The new disk will start operating again from Fig. 3.

The block diagram of Fig. 5 shows the actions in the case where the disk removal request came from the user. The flowchart of Fig. 5 a) presents a simple solution obtained by terminating the execution of all related, as well as all unrelated, interactive applications. A more advanced solution is depicted in the block diagram of Fig. 5 b). It is possible to further diversify the end of an unrelated application by asking the user to confirm the end request. This avoids unintentional interruptions.

[0039] In addition, it is possible to distinguish between interactive applications for just a deleted disk and interactive applications unrelated to the disk just removed. The end of the first type of application can be taken by the user generally, while the completion of the second type of application can be taken by the user separately for each of them.

[0040] A further embodiment of the invention is described below, which gives a more detailed description of the application framework. This example uses the explained disc_bound_flag tag in the movie player's firmware above to ensure that the corresponding interactive application will remain running when you change the disk. The use of the application signature is also explained in the further operational networks illustrated in Fig. 6 and Fig. 7.

[0041] While FIG. 6 describes what steps are performed based on the player's firmware when a disk removal request is directed to it, FIG. 7 includes steps performed based on the firmware each time the disc is inserted into the player. To provide a multi-disk interactive application, the described combination of a specific network of activities related to the entry and removal is necessary. This presents a solution to the problem of maintaining the integrity of data for the security of content providers, as well as for the purpose of adequate user experience (i.e., the user should have the impression of liquidity and the like).

[0042] The flowchart of Fig. 6 is started each time a disc removal is required. It may be required either by the user when he presses (hardware or software) delete button or through an interactive multi-drive application. While an unbonded disk-related application prepares a removal request by saving it in advance, a special purpose (discIDregister), disc ID (discID) of the requested disk (or multiple media IDs in the case of multiple acceptable disks), requests the user by pressing a button, will initiate a network of activities to clear the discIDregister registry.

[0043] Writing the media identifier of the requested disk (or a plurality of media identifiers of the plurality of acceptable disks) to the special purpose register does not necessarily have to be done by the application itself but with the disc, but it can also be done by the API, another service or other application that has been called or initiated by an application not associated with the disk.

In this case, the disc can be removed immediately, but it is also possible to store the delete command as shown in Fig. 8 so that the actual deletion must be confirmed by the user. This has the advantage that the user can change his mind, and the applications can work further.

0045 [] As running applications are usually cached in the player, they may generally be eligible for a persistent change in the medium. However, since such applications may require re-loading code from the media from which they were loaded, it may be useful that the same full application code is stored on all media that is accepted by the unrelated application so that it can be reloaded.

[0046] The state of the register discIDregister is analyzed by the firmware, and when the user's request arrives, then it ends all interactive applications. Another unmodified detail has already been explained in Fig. 5 a). After completing all interactive applications, the movie player removes the physical drive, and the network of activities reaches its end.

[0047] When the analysis from the firmware detects the discID identifier in the discIDregister register, in the loop through all running interactive applications, the checking for each of them whether it is an application unrelated to the disk, whether it is signed and whether it is a stored application starts in the player's cache. The application remains running when the disc leaves the player only if all conditions are met.

[0048] In all other cases, the examined interactive application is closed. Checking the application signature ensures that no unauthenticated application (malicious or pirated application) can pass through the framework security structure. Checking if an unrelated disk application is cached, ensures that this application can survive when the disk leaves the player. If the application could not be stored in the cache, it could probably "starve", i.e. it could not work any further because the disk from which it was loaded was removed and there is nothing to re-load.

[0049] When the loop is terminated by all running applications, only signed and cached applications that are not associated with the disk and, with the physically removed disk, are still running, thus the action network reaches its end.

[0050] A further idea of ​​the invention, which is not illustrated in action networks, is the case of leaving the loop through all running interactive applications. When this loop is terminated, so all applications are terminated, then also, in order to avoid a warm start of the next disk, the discIDregister should be cleared. It also improves data consistency and application reliability.

[0051] Fig. 7 illustrates a flowchart that the video player firmware introduces each time a disk is inserted. First, check whether any media ID (for example, discID) is stored in the discIDregister registry. This means that an interactive application requires the user to enter another disk. However, it is possible that no application is continuing.

[0052] If the discIDregister register is empty, the disk will be started in a preliminary mode from scratch. Starting from scratch is called a "cold" start that closes all running interactive applications and also clears discIDregister. In the case where the discIDregister is stored in the discID register, the second check will show if the stored discID really matches the entered disk. this is not the case, the user may be warned and may receive help in making a decision regarding further proceedings.

[0053] If the user deliberately inserts a different disk, then all running applications are terminated and a cold disk start occurs, and if the user has made a mistake, then he has a chance to enter the correct disk as depicted in the return loop in the block diagram of the disk insert of FIG. 7.

[0054] If the discID identifier of the newly inserted disk matches the discID identifier stored in the discIDregister register, the discIDregister is cleared, and a new checking loop is executed through all running applications. Checks whether the running application is also part of this new title on the new disk, and whether it has the same signature as the one on the disk.

[0055] Both tests improve safety and reliability. An unrelated disk interactive application is launched only if the results of both tests are successful. If the application is not presented on the new disk (or in the title on the new disk), it is closed. If the application signature from disk and cache does not match, the application from the disk is resumed to maintain consistency. The loop ends with a warm boot disk. This means that an unbinded interactive application continues to work, for example, to control the playback service.

[0056] Another variant, not illustrated in Fig. 7, is the case where no applications are run at the end of the application checking loop. In this case, a cold boot should also be made.

[0057] An example is shown in Fig. 2. The PL player of the disks is loaded from the first disk D1, having the associated discID_1 identifier of the menu application, which is displayed on the SCR screen. This displayed menu contains a list of options to be selected by the user, the SW_EJ_B programmable delete button and the C_B "Cancel" button. The player has a hardware HW_EJ_B delete button. When a user selects a certain title, for example Part_31, the menu application determines from its internal list that the selected object is on a different disk than the one currently entered and displays the message for the user,to enter the required disk. This application stores the ID of the discID_2 required disk internally in a dedicated register (discIDregister). For example, the currently inserted disk can be deleted when the user confirms his selection, for example by re-selecting Part_31, whereby the user can delete the current disk with a hardware or software delete button. Because the application stores the ID of the required next disk (discID_2) in a dedicated registry, the deletion is classified as initiated not by the user but as initiated by the application. Therefore, unrelated applications, like the menu application as such, may still work. If the user changes his intention, he can still press the C_B "Cancel" button. This can, for example, result in

[0058] Generally, consumer electronics devices can provide the user with the capabilities of advanced interactivity, implemented as software applications. The invention provides a method of executing software applications by a device that plays audio-video data, where the program application data to be performed in said reproducing apparatus is read from the first removable data carrier, and this data includes information determining the condition for termination of the application. Based on the said termination condition and depending on how the media containing the application is removed, this application either terminates or can survive.

[0059] Another example of an application is a leading application, built to cover multiple disks with its scope. The introduction of the first disk in this series starts the leading application, but this leading application will survive any changes to the discs until a disc that is not part of the series is entered. This provides the user with a sense of fluidity. This invention ensures that only authenticated applications can automatically survive disk changes while unmatched interactive applications are terminated.

[0060] The invention applies to all types of data carriers and respective players that are now in particular in the form of optical discs, such as DVDs, HD-DVDs or Blu-ray disks and their respective players. The invention is particularly useful in players that are capable of running interactive software applications.

[0061] Examples of software applications are an internet information bar or organizer software similar to a personal data assistant (PDA) that can be modified depending on the currently inserted disk, e.g. a calendar manager that reads data from local storage as a disk drive hard (HDD).