TW201331839A - 電視系統及其應用程式管理方法 - Google Patents

Abstract

本發明提供一種設置於電視機中的儲存媒體，其中儲存有一電視軟體系統之程式碼。該電視機具有一處理器用以執行該電視軟體系統之程式碼。該電視軟體系統包含一第一應用程式、一第二應用程式及一程式管理模組。第一應用程式具有一第一函式庫。第二應用程式具有不同於該第一函式庫之一第二函式庫。該程式管理模組分別根據該第一函式庫及該第二函式庫管理該第一應用程式及該第二應用程式。

Description

電視系統及其應用程式管理方法

本發明係與電視系統相關，並且尤其與在電視系統中整合異質作業系統之技術相關。

近年來，隨著科技產品與網際網路的普及，使用者透過網路可獲取之文字、圖片、影片、音樂、遊戲…等資源的種類及數量皆日漸蓬勃豐富。有鑑於此，將網路資源納入家用或商用多媒體系統，以提供使用者更便利的資訊娛樂平台，成為一種願景和趨勢。

一般而言，多媒體系統的主體為電視。因此，如何將透過網際網路取得的資源及應用程式有效整合至電視系統中，是電視系統設計者不可忽視的挑戰。

上述整合的關鍵問題之一是，透過網際網路取得的應用程式未必相容於電視系統本身的作業系統。舉例而言，電視系統本身的作業環境可能為Linux，而透過網際網路取得的應用程式可能係適用於Android作業系統。Linux作業系統和Android作業系統之核心(kernal)相同而函式庫(function library)不同；兩者互為異質作業系統(heterogeneous operating system)。在不修改電視系統之作業環境或應用程式的情況下，該應用程式即無法在該電視系統中執行。

針對上述不相容的問題，目前最普遍的做法是修改電視系統軟體原有之源編碼(source code)，來配合相容於其他作業系統的應用程式。然而，這種做法需要大幅修改電視系統軟體之源編碼，除了耗時耗力之外，難度亦相當高。此外，若欲進一步增加電視系統中可整合的作業系統種類，修改電視系統軟體原有之源編碼的做法幾乎是不可行的。由此可知，若採用舊有方式實現網路電視，其彈性和擴充性皆不理想。

為解決上述問題，本發明提出了一種電視系統，利用一程式管理模組使具有不同函式庫之異質作業系統的應用程式，在無需修改源編碼的情況下，便可於同一顯示頁面上同時顯示與被使用。

根據本發明之一具體實施例為一設置於電視機中的儲存媒體，其中儲存有一電視軟體系統之程式碼。該電視機具有一處理器用以執行該電視軟體系統之程式碼。該電視軟體系統包含一第一應用程式、一第二應用程式及一程式管理模組。第一應用程式具有一第一函式庫。第二應用程式具有不同於該第一函式庫之一第二函式庫。該程式管理模組分別根據該第一函式庫及該第二函式庫管理該第一應用程式及該第二應用程式。

根據本發明之另一具體實施例為一應用程式管理方法，應用於一電視機之一電視軟體系統。該電視軟體系統包含一第一應用程式、一第二應用程式、及一程式管理模組。該應用程式管理方法包含：(a)接收針對一目標應用程式所發出之一呼叫；(b)判斷該目標應用程式是否為該等應用程式中之一焦點應用程式；以及(c)若該目標應用程式非該焦點應用程式，先向該焦點應用程式發出一收回焦點命令，再向該目標應用程式發出一賦予焦點命令。上述步驟(a)、(b)、(c)皆由該程式管理模組所執行。

根據本發明之另一具體實施例亦為應用於一電視機之一電視軟體系統的一種應用程式管理方法。該電視軟體系統包含一第一應用程式、一第二應用程式、及一程式管理模組。該應用程式管理方法包含：接收一使用者指令；由該程式管理模組判斷該使用者指令是否為一快速鍵指令；由該程式管理模組判斷該快速鍵指令是否被禁能；若該使用者指令快速鍵指令被禁能，由該程式管理模組將該使用者指令發送至該些應用程式中之一焦點應用程式；以及若該使用者指令為該快速鍵指令且該快速鍵指令未被禁能，由該程式管理模組將該使用者指令發送至該些應用程式中對應該快速鍵指令之一目標應用程式。

對系統設計者而言，根據本發明之電視系統架構的優點在於，設計者無須大幅修改電視系統之主要作業平台的主要源編碼來配合各種具有不同函式庫的作業系統。此外，透過定義共同的應用程式介面以及管理機制，相容於各種作業系統之應用程式各自原有的源編碼可被直接採用，設計者無須進行耗時耗力的移植(porting)程序。對使用者而言，上述電視系統可廣納並整合多種異質系統提供的應用程式，其擴充性及便利性皆大幅提升。

關於本發明之優點與精神可以藉由以下的發明詳述及所附圖式得到瞭解。

根據本發明之一具體實施例為一電視系統，圖一(A)為其系統架構圖。如圖一(A)所示，電視系統100包含一程式管理模組10、一主作業平台20、一電視訊號播放程式22、一基於網路(web-based)軟體系統之應用程式24、一基於Flash(Flash-based)軟體系統之應用程式26、一本地軟體系統之應用程式28，以及Android作業系統30。於此實施例中，應用程式22~28各自所屬之軟體系統和Android作業系統30各自對應的核心相同而函式庫皆互不相同，因此可被視為互為異質軟體系統。以下說明將以主作業平台20為Linux作業平台的情況為例，但不以此為限。

圖一(B)係繪示電視系統100之一硬體架構範例。中央處理器61係用以執行系統內各種軟體程式。記憶體62係用以暫存資料。解多工器(de-multiplexer)63負責將電視信號拆解為視訊位元流和音訊位元流，並將這兩種位元流分別提供至影像解碼器64和音訊解碼器65。影像解碼器64的輸出信號會被傳送至記憶體62，供縮放器(scaler)66和繪圖引擎(graphic engine)67使用。繪圖引擎67係用以產生螢幕顯示(on-screen display,OSD)畫面或繪製遊戲及各種應用程式的畫面。縮放器66係用以對影像畫面進行縮放，以產生適合面板解析度之輸出影像畫面。音效數位處理器68則是用以接收音訊解碼器65的輸出，進一步產生各種聲音特效，例如環繞立體聲等。儲存裝置69係用以儲存電視系統所需之軟體程式的程式碼。舉例而言，儲存裝置69可為一硬碟或一快閃記憶體，但不以此為限。儲存裝置69亦可被整合於記憶體62中。

實務上，圖一(B)中的影像解碼器64、音訊解碼器65、縮放器66、繪圖引擎67和音效數位處理器68都是圖一(A)中各應用程式可以請求使用的系統資源。

程式管理模組10係用以分別根據各種軟體系統的函式庫來管理電視系統100中的多個異質軟體系統之應用程式。更明確地說，程式管理模組10係用以管理安裝於電視系統100中的應用程式。實務上，電視訊號播放程式22的功能不限於播放電視訊號，亦可被設計為涵蓋處理其他規格之多媒體訊號(例如來自DVD播放器之視訊信號)的功能。舉例而言，基於網路之應用程式24可為一網路廣播播放程式，基於Flash之應用程式26可為一線上觀賞影片程式，而本地應用程式28可為一網路通話程式。

屬於Android作業系統30的應用程式包含至少一應用程式34，亦即一Android應用程式。舉例而言，Android應用程式34可為遊戲、瀏覽器、多媒體播放程式、界面工具集(widget)，或其他各種類型的Android應用程式。於此實施例中，Android作業系統30的框架(framework)中包含能與程式管理模組10溝通之一啟動器(launcher) 32。實務上，啟動器32可為根據Android作業系統30固有的啟動器修改而成，使啟動器32具有與程式管理模組10溝通的功能。

於此實施例中，程式管理模組10直接與應用程式22~28溝通，與Android應用程式34溝通時則是透過啟動器32。如圖一(A)所示，上述溝通(例如傳送/接收請求或命令)係透過內部程序通訊(inter-process communication,IPC)通道40進行，但不以此為限。如圖一(A)所示，應用程式22~28可各自被視為程式管理模組10的直接客戶(client)，透過程式管理模組10提供的應用程式介面(application interface,API) 80與程式管理模組10溝通。另一方面，對Android作業系統30中的Android應用程式34而言，啟動器32可被視為程式管理模組10的直接客戶，負責透過程式管理模組10所提供之應用程式介面80與程式管理模組10溝通。由於啟動器32可提供的溝通轉換功能，無論Android應用程式34的種類為何，其源編碼皆無須為了配合電視系統100中的主作業平台20而修改。另一方面，無論是對應用程式22~28或Android應用程式34，程式管理模組10都可利用相同的管理機制(例如相同的應用程式介面80)控制。

於一實施例中，各種應用程式(例如圖一(A)中的應用程式22~28和Android應用程式34)被安裝至電視系統100後，該等應用程式的相關資料(例如名稱、圖示、所屬軟體系統、執行檔路徑等等)係集中登錄於一應用程式定義檔案中。程式管理模組10可透過該檔案得知目前電視系統100中安裝有哪些應用程式，並可利用該應用程式定義檔案做為管理應用程式的參考依據。

此外，電視系統100中可安裝一個相容於Linux作業平台的目錄程式，用以列舉(例如透過文字或圖片)電視系統100中已安裝的應用程式供使用者參考。舉例而言，該目錄程式被啟動後可以圖形化介面的形式被呈現在電視系統100的螢幕上，顯示所有應用程式的圖示，供使用者利用遙控器或滑鼠等裝置自該介面點選欲開啟或關閉的應用程式。該目錄程式的資料來源亦可為上述應用程式定義檔案。舉例而言，程式管理模組10可被設計為在每次電視系統100開機後，自該應用程式定義檔案讀取現有的應用程式資訊，再將該等資訊提供給目錄程式使用。

如圖一(A)所示，電視系統100包含一使用者介面50。實務上，電視系統100可同時包含多種不同的使用者控制介面，例如射頻/紅外線遙控器、面板按鍵，或者是滑鼠及鍵盤。因此，使用者介面50可為遙控訊號接收器、滑鼠訊號接收器、鍵盤/按鍵訊號接收器，或是整合有上述數種接收功能的介面，但不以此為限。於此實施例中，使用者介面50所接收的使用者指令被預設為將提供至該等應用程式中之一焦點應用程式，通常也就是目前呈現於螢幕畫面最上層的應用程式。

使用者介面50收到使用者指令後，會透過內部程序通訊通道40將該指令傳遞至程式管理模組10，交由程式管理模組10處理。若此使用者指令被判定為對應於應用程式22~28中的一個，程式管理模組10將會直接透過內部程序通訊通道40將指令轉發至該應用程式。相對地，若此使用者指令係對應於Android應用程式34，程式管理模組10係透過內部程序通訊通道40將指令發送至啟動器32，交由啟動器32轉發給Android應用程式34。

如先前所述，程式管理模組10係用以管理應用程式22~28及應用程式34。實務上，此處所謂的管理可包含啟動/終止應用程式、在應用程式間轉移焦點權限，以及統籌各應用程式對系統資源(例如顯示畫面、音效、網路等)的需求及使用權限。也就是說，程式管理模組10係藉由焦點權限及資源權限來管理各應用程式。於實際應用中，各個應用程式可因分別屬於不同的軟體系統而具有其專屬的賦予焦點函式、收回焦點函式、賦予資源函式、收回資源函式及終止函式等等。程式管理模組10可根據各應用程式的函式與該等應用程式溝通。以下配合圖二(A)~圖二(F)介紹利用程式管理模組10協調各應用程式之啟動、終止、焦點切換、資源切換的範例。

參閱圖二(A)。於此範例中，使用者透過目錄程式A選擇開啟目標應用程式B，而目標應用程式B原來即處於開啟狀態(例如正在背景執行中)，但並非焦點應用程式。首先，目錄程式A將呼叫目標應用程式B的請求傳送至程式管理模組10。在將焦點轉移至目標應用程式B前，程式管理模組10會先向原焦點應用程式C發出一收回焦點命令，然後才對目標應用程式B發出賦予焦點命令，使目標應用程式B成為新的焦點應用程式。易言之，在收到針對一目標應用程式所發出的呼叫後，程式管理模組10會先判斷該目標應用程式是否為焦點應用程式。若該目標應用程式非該焦點應用程式，程式管理模組10會先向原來的焦點應用程式發出收回焦點命令，再向被呼叫的目標應用程式發出賦予焦點命令。

請參閱圖二(B)。於此範例中，使用者同樣是透過目錄程式A選擇開啟目標應用程式B，而目標應用程式B原來係處於關閉狀態。因此，在收到目錄程式A將呼叫目標應用程式B的請求後，程式管理模組10首先向原焦點應用程式C發出收回焦點命令，接著啟動目標應用程式B。於此範例中，目標應用程式B被啟動後即傳送一回呼函式清單(callback function list)至程式管理模組10。該回呼函式清單的主要作用在於告知程式管理模組10與目標應用程式B溝通時可使用的函式及應使用的函式格式，同時可藉此告知程式管理模組10其啟動程序已成功。舉例而言，該回呼函式清單可包含賦予焦點函式、收回焦點函式、賦予資源函式、收回資源函式及終止函式等等。在收到該回呼函式清單後，程式管理模組10即可根據其中的賦予焦點函式對目標應用程式B發出賦予焦點命令。

由以上兩個範例可知，在收到呼叫目標應用程式B的請求後，程式管理模組10可先判斷目標應用程式B是否為一執行中應用程式；若否，程式管理模組10將先啟動目標應用程式B。需說明的是，在其他實施例中，程式管理模組10和應用程式間的溝通不一定要利用上述回呼機制。舉例而言，適用於各應用程式的函式格式可預先儲存於程式管理模組10或其周邊檔案中。各種應用程式的運作規則不盡相同，利用回呼機制的好處在於程式管理模組10無須預先記錄電視系統100中所有應用程式的函式及運作規則。

請參閱圖二(C)。於此範例中，原本在背景執行中的應用程式D自己向程式管理模組10發出希望成為焦點應用程式的請求。在這樣的情況下，程式管理模組10可先向原焦點應用程式C發出收回焦點命令，接著再對應用程式D發出賦予焦點命令。舉例而言，原焦點應用程式C可能為電視訊號播放程式22，而應用程式D為一網路通話程式。該網路通話程式可被設計為在收到來電訊息時即要求程式管理模組10，希望成為呈現在畫面最上層的焦點應用程式，以取得使用者注意。

於實際應用中，將焦點由原焦點應用程式C轉移至應用程式D的請求亦可能是由主作業平台20所發出之一強制開啟要求。舉例而言，主作業平台20可能是根據使用者先前預設的條件在特定時間啟動應用程式D，並預設在開啟應用程式D後令其成為焦點應用程式。

請參閱圖二(D)。此範例係用以說明程式管理模組10如何協調各應用程式間的資源切換。舉例而言，所有應用程式可能必須共用電視系統100中的系統資源，例如圖一(B)中的影像解碼器64、音訊解碼器65、縮放器66、繪圖引擎67和音效數位處理器68。程式管理模組10可用以統籌該等應用程式之系統資源需求。當應用程式D向程式管理模組10發出希望取得影音處理資源的請求，程式管理模組10可先向原資源使用中應用程式E發出收回資源命令，接著再對應用程式D發出賦予資源命令。於實際應用中，程式管理模組10可視情況決定應向原資源使用中應用程式E收回全部或部份的資源。若應用程式D要求或必須獨佔該影音處理資源，程式管理模組10將會向原資源使用中應用程式E收回全部的資源。此外，若電視系統100中的聲音處理資源和影像處理資源可獨立運作，則程式管理模組10可將這兩種資源分別分配給不同的應用程式。

請參閱圖二(E)。於此範例中，使用者透過目錄程式A選擇開啟目標應用程式B，而目標應用程式B原來係處於關閉狀態，且程式管理模組10已知目標應用程式B之執行必須取得影音處理資源。在收到目錄程式A將呼叫目標應用程式B的請求後，程式管理模組10首先向原焦點應用程式C發出收回焦點命令，接著向原資源使用中應用程式E發出收回資源命令，然後才啟動目標應用程式B。如圖二(E)所示，在收到目標應用程式B提供的回呼函式清單後，程式管理模組10即可根據其中的賦予焦點函式和賦予資源函式依序對目標應用程式B發出賦予焦點命令和賦予資源命令。實務上，原焦點應用程式C和原資源使用中應用程式E可為同一個應用程式。

請參閱圖二(F)。此範例與圖二(E)所示之範例的主要差別在於，此範例中的目標應用程式B和原資源使用中應用程式E無法並存。因此，在啟動目標應用程式B之前，程式管理模組10先對原資源使用中應用程式E發出一終止命令。易言之，在啟動目標應用程式B前，程式管理模組10可先判斷一現有應用程式是否與目標應用程式B相衝突；若是，程式管理模組10先向該現有應用程式發出終止命令，再啟動目標應用程式B。實務上，目標應用程式B與哪些應用程式相衝突，可記載在目標應用程式B提供給程式管理模組10的回呼函式清單中，或記載於應用程式定義檔案中。

綜合以上範例，電視系統100中一應用程式的狀態可歸納如圖三所示。在被啟動之初或被終止之前，一應用程式皆處於非焦點且無資源的狀態。程式管理模組10可負責啟動或終止應用程式，亦負責管理協調各應用程式間的焦點權限和資源權限切換。如上所述，傳送各種命令或接收來自應用程式的請求時，程式管理模組10係直接與應用程式22~28溝通，並透過啟動器32與應用程式34溝通。舉例而言，當電視訊號播放程式22需要影音處理資源，電視訊號播放程式22係直接向程式管理模組10發出請求。當Android應用程式34需要影音處理資源，則是透過啟動器32向資源管理模組10發出請求。

於實際應用中，除了透過目錄程式A之外，使用者還可利用遙控器或鍵盤上的快速鍵(hotkey)對一目標應用程式發出開啟、關閉或調整其運作參數的指令，而該目標應用程式未必為焦點應用程式。需注意的是，有些應用程式本身為具焦點權限的焦點應用程式時，會將對應於其他應用程式的快速鍵設定為禁能(disabled)。程式管理模組10在轉發使用者介面50所接收的使用者指令時，亦需考量以上狀況。

圖四為程式管理模組10中判斷應將使用者指令發送給哪一個應用程式的流程範例。在收到使用者介面50傳送來的一個使用者指令時，程式管理模組10首先執行步驟S41，判斷該指令是否為對應於一目標應用程式之一快速鍵要求。若步驟S41的判斷結果為是，程式管理模組10將繼續執行步驟S42，判斷該指令是否為一禁能(disable)快速鍵要求(亦即該快速鍵是否被目前的焦點應用程式設定為禁能)。若步驟S42的判斷結果為否，程式管理模組10將執行步驟S44，程式管理模組10將該使用者指令發送至該目標應用程式。相對地，若步驟S41的判斷結果為否，或者步驟S42的判斷結果為是，程式管理模組10將執行步驟S43，將該使用者指令發送至焦點應用程式。

於實際應用中，程式管理模組10可將該使用者指令發送至對應於該目標應用程式或該焦點應用程式之一暫存器。換句話說，可將每一個執行中的應用程式設計為各自對應於一個用以存放使用者指令的暫存器。將使用者指令儲存在客戶端而非程式管理模組10中的優點在於，可避免客戶(亦即應用程式)為了確認是否有新的使用者指令而必須週期性地詢問程式管理模組10，造成系統效能低落。

於本發明之一實施例中，主作業平台20之啟動時間早於Android作業系統30的啟動時間，藉此可達成將Android界面工具集內嵌於電視畫面中的效果。

雖然圖一(A)係繪示作業系統30中只有一個應用程式34的狀況，但在實際應用中，電視系統100中可安裝有多個屬於作業系統30的應用程式。在這樣的情況下，程式管理模組10仍可被設計為將所有屬於作業系統30的應用程式視為單一個客戶，並透過啟動器32與該等應用程式溝通。舉例而言，所有來自屬於作業系統30之應用程式的焦點轉移請求或資源需求，皆可被視為啟動器32的請求；作業系統30可根據啟動器32所收到來自於程式管理模組10的回應，自行於其內部決定應如何賦予焦點或分配資源。

由以上說明可知，程式管理模組10的運作及管理方式適用於電視系統100包含多個異質軟體系統(例如應用程式22~28和Android作業系統30)的情況。各異質軟體系統可直接或運用其啟動器與程式管理模組10溝通。相對地，程式管理模組10可將各個異質軟體系統視為不同但能利用相同的管理機制(例如相同的應用程式介面)控制的客戶。

對系統設計者而言，上述系統架構的優點在於，設計者無須大幅修改電視系統100之主要作業平台20的主要源編碼來配合各種具有不同函式庫的軟體系統。此外，透過定義共同的應用程式介面以及管理機制，相容於各種軟體系統之應用程式各自原有的源編碼可被直接採用，設計者無須進行耗時耗力的移植(porting)程序。對使用者而言，上述電視系統可廣納並整合多種異質系統提供的應用程式，其擴充性及便利性皆大幅提升。

藉由以上較佳具體實施例之詳述，以更加清楚描述本發明之特徵與精神，而並非以上述所揭露的較佳具體實施例來對本發明之範疇加以限制。本發明得由熟習此技藝之人士任施匠思而為諸般修飾，皆不脫如附申請專利範圍所欲保護者。

100．．．電視系統

10．．．程式管理模組

20．．．主作業平台

22．．．電視訊號播放程式

24．．．基於網路之應用程式

26．．．基於Flash之應用程式

28．．．本地應用程式

30．．．作業系統

32．．．啟動器

34．．．應用程式

40．．．內部程序通訊通道

50．．．使用者介面

80．．．應用程式介面

61．．．中央處理器

62．．．記憶體

63．．．解多工器

64．．．影像解碼器

65．．．音訊解碼器

66．．．縮放器

67．．．繪圖引擎

68．．．音效數位處理器

69．．．儲存裝置

A．．．目錄程式

B．．．目標應用程式

C．．．原焦點應用程式

D．．．應用程式

E．．．原資源使用中應用程式

S41~S44．．．流程步驟

圖一(A)為根據本發明之一實施例中的電視系統架構圖。

圖一(B)為根據本發明之一實施例中電視系統的硬體架構圖。

圖二(A)~圖二(F)係繪示利用根據本發明之程式管理模組協調各應用程式啟動、終止、焦點切換、資源切換的範例。

圖三為根據本發明之電視系統中一應用程式的狀態變換範例。

圖四為根據本發明之資源管理模組中判斷應將使用者指令發送給哪一個應用程式的流程範例。

100．．．電視系統

10．．．程式管理模組

20．．．主作業平台

22．．．電視訊號播放程式

24．．．基於網路之應用程式

26．．．基於Flash之應用程式

28．．．本地應用程式

30．．．作業系統

32．．．啟動器

34．．．應用程式

40．．．內部程序通訊通道

50．．．使用者介面

80．．．應用程式介面

Claims (18)

1. 一種儲存媒體，設置於一電視機中，該儲存媒體係儲存有一電視軟體系統之程式碼，該電視機具有一處理器用以執行該電視軟體系統之程式碼，該電視軟體系統包含：一第一應用程式，其具有一第一函式庫；一第二應用程式，其具有不同於該第一函式庫之一第二函式庫；以及一程式管理模組，其分別根據該第一函式庫及該第二函式庫管理該第一應用程式及該第二應用程式。
2. 如申請專利範圍第1項所述之儲存媒體，其中在該程式管理模組啟動該等應用程式中之一目標應用程式後，該目標應用程式傳送一回呼函式清單至該程式管理模組。
3. 如申請專利範圍第2項所述之儲存媒體，其中該回呼函式清單包含該目標應用程式之函式庫之至少一可用函式及至少一函式格式。
4. 如申請專利範圍第3項所述之儲存媒體，其中該可用函式包含一賦予焦點函式、一收回焦點函式、一賦予資源函式、一收回資源函式及一終止函式等函式中之一函式或多個函式。
5. 如申請專利範圍第1項所述之儲存媒體，其中該程式管理模組係透過一相同之應用程式介面與該第一應用程式及該第二應用程式進行溝通。
6. 如申請專利範圍第1項所述之儲存媒體，其中該電視軟體系統進一步包含：一使用者介面，其接收之一使用者指令被預設為將提供至該等應用程式中之一焦點應用程式；其中該程式管理模組負責將該使用者指令提供至該焦點應用程式。
7. 如申請專利範圍第1項所述之儲存媒體，其中該程式管理模組負責管理該等應用程式使用該電視系統之系統資源。
8. 如申請專利範圍第1項所述之儲存媒體，其中該等應用程式之相關資料係登錄於一應用程式定義檔案中，且該程式管理模組係根據該應用程式定義檔案管理該等應用程式。
9. 如申請專利範圍第1項所述之儲存媒體，其中該程式管理模組係藉由一焦點權限及一資源權限來管理該等應用程式。
10. 如申請專利範圍第1項所述之儲存媒體，其中該第一應用程式係屬於一特定軟體系統，該特定軟體系統包含一啟動器，該程式管理模組係透過該啟動器與該第一應用程式溝通，而該程式管理模組係直接與該第二應用程式溝通。
11. 一種應用程式管理方法，應用於一電視機之一電視軟體系統，該電視軟體系統包含一第一應用程式、一第二應用程式、及一程式管理模組，該應用程式管理方法包含：(a)接收針對一目標應用程式所發出之一呼叫；(b)判斷該目標應用程式是否為該等應用程式中之一焦點應用程式；以及(c)若該目標應用程式非該焦點應用程式，先向該焦點應用程式發出一收回焦點命令，再向該目標應用程式發出一賦予焦點命令；其中步驟(a)、(b)、(c)皆由該程式管理模組所執行。
12. 如申請專利範圍第11項所述之應用程式管理方法，其中該第一應用程式具有一第一函式庫，該第二應用程式具有不同於該第一函式庫之一第二函式庫，該程式管理模組係分別根據該第一函式庫及該第二函式庫管理該第一應用程式及該第二應用程式。
13. 如申請專利範圍第11項所述之應用程式管理方法，其中步驟(c)包含：該程式管理模組發出該賦予焦點命令前，先判斷該目標應用程式是否為一執行中應用程式，若否，先啟動該目標應用程式，再對該目標應用程式發出該賦予焦點命令。
14. 如申請專利範圍第11項所述之應用程式管理方法，其中步驟(c)包含：該程式管理模組啟動該目標應用程式前，先判斷一現有應用程式是否與該目標應用程式相衝突，若是，先向該現有應用程式發出一終止命令，再啟動該目標應用程式。
15. 如申請專利範圍第11項所述之應用程式管理方法，其在步驟(a)後進一步包含：由該程式管理模組判斷該目標應用程式是否需要一資源，若是，對該目標應用程式發出一賦予資源命令。
16. 如申請專利範圍第15項所述之應用程式管理方法，其進一步包含：由該程式管理模組判斷該目標應用程式是否須獨佔該資源，若是，先對一資源使用中應用程式發出一收回資源命令，再對該目標應用程式發出該賦予資源命令。
17. 一種應用程式管理方法，應用於一電視機之一電視軟體系統，該電視軟體系統包含一第一應用程式、一第二應用程式、及一程式管理模組，該應用程式管理方法包含：接收一使用者指令；由該程式管理模組判斷該使用者指令是否為一快速鍵指令；由該程式管理模組判斷該快速鍵指令是否被禁能；若該使用者指令快速鍵指令被禁能，由該程式管理模組將該使用者指令發送至該些應用程式中之一焦點應用程式；以及若該使用者指令為該快速鍵指令且該快速鍵指令未被禁能，由該程式管理模組將該使用者指令發送至該些應用程式中對應該快速鍵指令之一目標應用程式。
18. 如申請專利範圍第17項所述之應用程式管理方法，其中該第一應用程式具有一第一函式庫，該第二應用程式具有不同於該第一函式庫之一第二函式庫，該程式管理模組係分別根據該第一函式庫及該第二函式庫管理該第一應用程式及該第二應用程式。