News Column

Patent Issued for Broadcast Receiving Terminal and Program Execution Method for Resource Reservation

June 18, 2014



By a News Reporter-Staff News Editor at Journal of Engineering -- From Alexandria, Virginia, VerticalNews journalists report that a patent by the inventors Hashimoto, Satoshi (Osaka, JP); Suzuki, Takaaki (Osaka, JP), filed on May 28, 2013, was published online on June 3, 2014.

The patent's assignee for patent number 8745632 is Panasonic Corporation (Osaka, JP).

News editors obtained the following quote from the background information supplied by the inventors: "(1) Field of the Invention

"The present invention relates to a broadcast receiving terminal, in particular, to a setup for facilitating viewing video, audio, and data such as a program by receiving a broadcast wave with which contents made up of video, audio, and data such as a program which are mutually synchronized are multiplexed, as well as a setup for overcoming the case where a contention of a resource such as a tuner occurs between the contents.

"(2) Description of the Related Art

"Various contents are included in a broadcast wave sent from a broadcast station. Aside from video and audio used in a normal TV show, there are cases where data is included in the contents. There are several methods for sending the data, which can be roughly divided into a method of sending the data chronologically and a method of repeatedly sending the data per set interval. In the former method of sending the data chronologically, for example, data that continues over the course of time is sent in sequential order. This method is suitable for sending large amounts of data over a long period of time, but there is a drawback in that data that could not be received due to timing of the send cannot be received again. On the other hand, in the later method of repeatedly sending the data at a set interval, the same data is repeatedly sent any number of times during a fixed period. This method has an advantage in that during the period when the same data is being sent, any one of the repeatedly-sent pieces of data can be received, and thus the timing of receiving is not limited. Data broadcast, represented by BML, and file sending through DSMCC data carousel are the examples of this method. It is unknown, particularly in broadcast, when a recipient will select a channel and commence reception. In the method of sending the data chronologically, when the start of reception falls behind the timing of the sending and acquisition of the data fails, the data cannot be re-acquired. Therefore, when sending data such as an application program along with video and audio in the broadcast wave, the method of repeatedly sending the data per set interval is favorable.

"At present, specifications for receiving a broadcast wave that includes video, audio, and an application program and executing the application program in synchronization with video and audio, as in the above method, have been developed and are in operation. It is possible to receive the sent application program, load the application program into a broadcast receiving terminal (hereinafter to be simply referred to as 'terminal' or 'terminal apparatus'), and implement various extra functions by executing the application program, rather than simply viewing the video and audio. This method for sending the application program and importing the application program into the terminal is also called 'downloading'. For example, a specification called Digital Video Broadcasting-Multimedia Home Platform (DVB-MHP) ETSIES201812 v1.1.1 (2003-12) has been developed in Europe, and operations according to this specification have already commenced. In addition, Open Cable Application Platform (OCAP), which provides the same specification in the cable broadcast environment in the United States, is being developed in the United States, and actual operations are set to commence. In these specifications, the application program is written in the Java language. Various Application Programming Interfaces (APIs) for tuning, graphics display, and the like are provided in the terminal, and the Java application program can control those functions by calling the APIs.

"In addition, in North America, the OCAP-DVROC-SP-OCAP-DVR-I01-040524 specification, which is aimed at adding a function for recording and reproducing the contents in the OCAP specification, is being developed. With this specification, the video, audio, and the Java application program synchronized therewith are executed, which are sent as a cable television broadcast, are recorded as contents, and furthermore, are reproduced in the same manner as when the recorded contents are directly reproduced from the broadcast wave. The application program is reproduced in synchronization with the video and audio, in the same manner as direct reproduction from the broadcast wave.

"Moreover, with OCAP-DVR, trick play of the contents is realized by recording broadcast contents to a high-speed random-accessible storage medium, such as a hard disk, a semiconductor memory, and the like. Here, the trick play refers to functions for reproducing the contents at an arbitrary speed, from an arbitrary position, and so on, such as fast-forward, rewind, slow-motion, pause, skip, and the like. With OCAP-DVR, the application program imported into the terminal from the broadcast wave can control the recording and trick play of the contents. In other words, APIs for recording and trick play are provided in the terminal, and the Java application program controls each function by calling those APIs.

"Normally, in order that the application program is executed in synchronization with the video and audio, control information for the synchronization is already multiplexed in the broadcast wave. The application program is sequentially executed according to the synchronization control information and is terminated. Thus, it is possible to execute the application program by switching the program to an appropriate one in accordance with a specific scene of video and audio.

"The OCAP and OCAP-DVR standards provide for the case where a contention between resources such as tuners and AV encoders occurs between the application programs, and defines a framework of invoking a handler previously registered by a privileged application program or a framework that is based on priorities held by the application programs, aiming to overcome such case."

As a supplement to the background information on this patent, VerticalNews correspondents also obtained the inventors' summary information for this patent: "As has been described above, the OCAP and OCAP-DVR standards provide for the case where a contention of a resource such as a tuner and an AV encoder occurs between the application programs, and defines a framework of invoking a handler previously registered by a privileged application program or a framework that is based on priorities held by the application programs, aiming to overcome such case. Even in the case where the contention of a resource occurs, the resources are appropriately assigned to the application programs according to the framework.

"In the case of invoking the handler previously registered by a privileged application program in order to solve a contention of a resource, there is a possibility that the call may be blocked by a wait of user's input or the like. Though being blocked, there normally should be no problems, but in the case where a forced tuning has to be executed for notifying the user of an alert by an Emergency Alert System (EAS), when the call is blocked by the handler, the notification to the user may be delayed.

"In order to solve the above problem, in the case of emergency such that the forced tuning has to be executed in order to inform the user of the EAS alert, the handler that may block shall not be invoked even though the handler is previously registered by the privileged application program.

"The present invention is therefore conceived in view of the above-mentioned problems, and provides a broadcast receiving terminal which can promptly execute forced tuning so as to inform the user of an alert without destroying the conventional framework for solving the problem of resource contention and without unexpected blocking upon invoking a resource contention handler already registered by a privileged Java program, even in the case where forced tuning is caused by EAS.

"In one embodiment of the disclosure, there is a broadcast receiving terminal, comprising: a processor; a program executioner configured to control execution of a program, via the processor, according to a priority level of the program; a resource contention detector configured, in a case where a reservation of a resource is requested according to the execution of the program performed by said program executioner, to detect, via the processor, whether or not a contention of the resource occurs due to a fact that the requested resource has already been reserved by another program executed by said program executioner; a resource reservation program determiner configured, when the contention occurs, via the processor, to: (i) when the program requesting the reservation of the resource is not a program having a highest priority level, call a resource contention handler for resolving the contention in the case where the resource contention handler is registered, and determine to permit a program according to a priority level returned from the resource contention handler, and determine to permit the program to reserve the resource which is under contention, according to the priority level of the program, in the case where the resource contention handler is not registered, and (ii) when the program has the highest priority level, determine to permit the program having the highest priority level to reserve the resource which is under contention without imposing any conditions or any resource contention handler; and a resource reservation program notifier configured to notify of the reservation of the resource to the program which is permitted to reserve the resource, via the processor, based on the determination made by said resource reservation program determiner.

"In another embodiment of the disclosure, there is a program execution method for executing a program in a broadcast receiving terminal, comprising: controlling, via a processor, execution of a program according to a priority level of the program; detecting, via the processor, when a reservation of a resource is requested according to the execution of the program performed by processor, whether or not a contention of the resource occurs due to a fact that the requested resource has already been reserved by another program executed by said processor; determining, via the processor, when the contention occurs, to: (i) when the program requesting the reservation of the resource is not a program having a highest priority level, call a resource contention handler for resolving the contention in the case where the resource contention handler is registered, and determine to permit a program to reserve the resource which is under contention, according to a priority level returned from the resource contention handler, and determine to permit the specified program to reserve the resource which is under contention, according to the priority level of the program in the case where the resource contention handler is not registered, and (ii) when the program has the highest priority level, determine to permit the program having the highest priority level to reserve the resource which is under contention without imposing any conditions or any resource contention handler; and notifying, via the processor, of the reservation of the resource to the program which is permitted to reserve the resource, based on the determination made by said processor.

"In one aspect of the disclosure, the processor includes: a program executioner to perform the controlling; a resource contention detector to perform the detecting; a resource reservation program determiner to perform the determining; and a resource reservation program notifier to perform the notifying.

"Note that the present invention can be realized not only as such broadcast receiving terminal, but also as a method of executing a program in the broadcast receiving terminal, and as a program for the broadcast receiving terminal, and even as a computer-readable storage medium, such as a CD-ROM, in which the program is stored.

"With the broadcast receiving terminal and the program execution method according to the present invention, it is possible to rapidly execute a forced tuning so as to notify the user of an alert, without destroying the conventional framework for solving the problem of resource contention and without unexpected blocking upon invoking a resource contention handler already registered by a privileged Java program even in the case where forced tuning is caused by EAS.

"As further information about technical background to this application, the disclosure of U.S. Provisional Application No. 60/685,378, filed May 31, 2005, including specification, drawings and claims is incorporated herein by reference in its entirety."

For additional information on this patent, see: Hashimoto, Satoshi; Suzuki, Takaaki. Broadcast Receiving Terminal and Program Execution Method for Resource Reservation. U.S. Patent Number 8745632, filed May 28, 2013, and published online on June 3, 2014. Patent URL: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=8745632.PN.&OS=PN/8745632RS=PN/8745632

Keywords for this news article include: Panasonic Corporation.

Our reports deliver fact-based news of research and discoveries from around the world. Copyright 2014, NewsRx LLC


For more stories covering the world of technology, please see HispanicBusiness' Tech Channel



Source: Journal of Engineering


Story Tools






HispanicBusiness.com Facebook Linkedin Twitter RSS Feed Email Alerts & Newsletters