TWI469616B

TWI469616B - 資源控制

Info

Publication number: TWI469616B
Application number: TW95144905A
Authority: TW
Inventors: Marko Hietala; Janne Ojanaho
Original assignee: Nokia Corp
Priority date: 2005-12-06
Filing date: 2006-12-04
Publication date: 2015-01-11
Also published as: US20070130336A1; TW200803423A; US7685297B2; WO2007066271A3; WO2007066271A2; EP1958064A2; EP1958064B1

Description

資源控制

本發明係關於一種資源控制之方法，其控制多個客戶對於至少一資源之存取；本發明同時也關於相應之資源控制配設、晶片組、電子裝置、設備及儲存相應軟體碼之軟體程式產品。

多樣之電子裝置提供多種功能，其必須共享相同之資源(例如，單一音訊輸出)。

在行動電話方面，例如，新的功能持續被引介至傳統之電話功能之上。結果，新興之行動電話及其他之行動裝置必須克服複雜之多媒體使用情況及目前消費型態之複雜需求。操控個別功能之各個客戶可能要求，例如，播放及/或記錄、音效、輸入及輸出選路(routing)及音量等等之某些組合，而當其他客戶仍在活動中。

一個豐富之功能組合可能因此造成不可預期之使用事例，其無法簡單地使用基於優先權(priority)之決定來解決問題。個別客戶所提供之優先權值不適用於包含充足之資訊以解決複雜之使用事例，因為相稱之優先權值係因事例而異。然而，若客戶沒有注意到其他任何客戶在裝置中進行之活動，則該客戶自身無法調整使用適當之優先權值。

因此，除了優先權值外，一個或一組額外之值被提出，例如優先喜好(priority preference)值。該優先權值及該一個或一組額外之值可藉使用某些軟體碼或硬編碼而得以評估。

根據“Symbian OS，Beta版本，系列60第3版SDK”，例如，TmdaPriorityPreference iPref是一優先喜好值，其表示之優先特性可包含：無、時間(或速度)、品質或時間與品質兩者。若該值設定為EmdaPriorityPreferenceTime，則音頻資料是屬有時間性的(time－sensitive)。若播放操作無法發生於請求之際，則播放操作失敗，除非將輸出降級，例如允許混合或靜音。若該值設定為EmdaPriorityPreferenceQuality，則音頻資料必須被播放於最佳可能品質(例如，其不可藉靜音或混合來降級)。該播放操作將被延遲直至該聲音裝置可供專屬使用時。若該值設定為EmdaPriorityPreferenceTimeAndQuality，則音頻資料將是有時間性的及高品質要求的。若播放操作無法即刻呈現高品質，則播放操作失敗。

但是，負責管理目前媒體消費使用事例之習用部件之維修及擴充是複雜及困難的。另一方面，電子裝置於操作時所發生之大量狀態是近乎不可能於發展階段來評估。因此，要涵蓋所有之使用事例是困難的。此外，對於資源存取控制之新近修改及變更是困難納入的，因為需要改變軟體碼或甚至硬編碼，並且要了解及預見所有可能狀態下之變更結果，若非不可能，也是很困難的。

因此，解決及管理上述困難之改進技術是必須的。

本發明之目的在於改進不同客戶對相同資源之存取之管理。

本發明提出一種控制多個客戶對至少一個資源存取之方法。該方法包括：當至少一客戶存取至少一資源之事件(event)發生時，從多個可供使用之規則組中選擇至少一規則組；該選擇係依下列至少其中之一來決定：該事件之類型、該至少一客戶之狀態及系統之狀態。該方法進一步包括應用該選擇之至少一規則組產生決定。該方法還包括依據該決定以控制對該至少一資源之存取。

此外，本發明提出一種控制多個客戶對至少一資源存取之資源控制配設。該資源控制配設包括多個規則組。該資源控制配設進一步包括一規則選擇部件，其用於當至少客戶之一存取至少一資源之事件發生時，從多個可供使用之規則組中選擇至少一規則組；該選擇依下列至少其中之一來決定：該事件之類型、該至少一客戶之狀態及系統之狀態。該資源控制配設還包括一控制器，其應用該規則選擇部件所選擇之規則組以得到決定，及依據該決定，控制對該至少一資源之存取。

此外，本發明提出一種由多個客戶對至少一個資源存取之電子裝置，其包括與上述資源控制配設相同之部件。加之，該電子裝置可包含例如所有或部份客戶及/或所有或部份資源。應注意的是，該電子裝置可被設計成所有或部份客戶及/或所有或部份資源是由外部連接至該電子裝置。

此外，本發明提出一種控制多個客戶對至少一個資源存取之晶片組，該晶片組包含至少一個晶片。該至少一個晶片包含與上述資源控制配設相同之部件。

加之，本發明提出一種控制多個客戶對至少一個資源存取之設備。該設備包括一裝置，其用於當至少一個該等客戶存取該至少一資源之事件發生時，從多個可供使用之規則組中選擇至少一規則組；該選擇依下列至少其中之一來決定：該事件之類型、該至少一客戶之狀態及系統之狀態。該設備還包括一裝置，其促成該規則選擇部件所選擇之規則組之應用以得到決定。該設備也包括一裝置，其依據該決定，控制對該至少一資源之存取。

最後，本發明提出一種電腦程式產品，其儲存控制多個客戶對至少一個資源存取之軟體程式碼。當該軟體程式碼由電子裝置之處理單元執行時，可實行上述之方法。該電腦程式產品可以是任何可儲存軟體碼之部件，例如，分開之儲存裝置、可組裝入電子裝置之記憶體、或緩衝該軟體碼執行之處理單元、等等。

本發明著手於考慮將有關客戶對某資源之存取所必須考慮之多個規則劃分成邏輯組。該被劃分之規則形成不同之規則組。因此當一新事件發生時，可能動態地選擇只有適用於目前事件類型、客戶目前狀態及/或目前系統狀態之規則組。明顯地，不同客戶間之潛在衝突祇必須考慮於假若有若干客戶目前是活動或暫停的(例如間歇狀態)。暫停之客戶是必須被考慮的，因為他們可能，例如，仍保留若干記憶空間等等。更進一步應注意的是，其他資訊來源也可用於選擇過程。因此，只有被處理之規則組是實際上可應用於事件。舉例言之，若系統狀態、事件類型及其他客戶之狀態是不受效應約束的，則專門有關於效應之規則組是無關緊要，因此不被使用。應了解的是，該至少一資源可包括可由用戶存取之任何硬體部件及/或軟體部件。更進一步應了解的是，客戶可能是適宜請求存取資源之任何硬體部件及/或軟體部件。

本發明之優點在於降低評估之複雜性。此外可容易地增加新的規則組，並且可容易地以加強版或補充版替代現存的規則組。因此，本發明可管理來自相關使用事例之媒體所產生之複雜性。

新的需求及功能引進新的待解決之衝突類型。例如，新音效之引進需要整體音效之更新權利之控制，其中可能只存在一個事例，但多個客戶可能要使用。新的領域之規則可藉定義相應之規則組而提出，該規則組負責解決在該領域內之所有衝突。該規則組可能是可插入的，若其實行一預先設定之介面且資源控制可經由該介面擷取。

資源之存取可能包含客戶與存取資源間之彼此資訊傳送。該資訊可能是任何交流於客戶與存取資源間之資料。在音訊及視訊之事例中，例如，該資訊可能是往來客戶之視訊或音訊流。以下，任何述及之客戶與資源間之資料串流也可瞭解為包含其他之資訊類型。

在本發明之一實施例中，事件是一相關至少一個客戶存取至少一個資源之請求。該請求可經由一客戶介面或相應之裝置來接收。然後，基於該請求之類型、其他客戶之狀態及/或系統之狀態等之至少其中一，由多個可供使用之規則組中選擇至少一規則組。該選擇之至少一規則組可以應用到該請求以決定該請求可被允許之程度。該決定可例如是允許、修改或拒絕某資源之存取請求。因此，可依據該決定來控制客戶對該至少一資源之存取。

雖然本發明之大部分實施例之事例中，事件是諸如客戶請求，但應注意的是，該等事件並不侷限於客戶請求。舉例言之，該事件可能是任何系統狀態之改變，其對存取可供使用之資源有影響。一使用者可改變系統之狀態，例如，選擇一靜音模式，其要求所有目前存取音頻輸出之客戶之音頻流設定為零音量，等等。

在本發明之一實施例中，各客戶結合一優先權值，而接收自不同客戶之請求則依該等優先權值循序處理。個別請求之處理，特別是該至少一規則組之應用，可能之排程方式是該個別請求可被進一步接收之較高優先權值之客戶請求中斷。該個別請求可能被檢視，例如，於一規則組之各個應用之後，且於下個選擇之規則組被應用到目前之請求之前，是否已有一更高優先權值之客戶請求被接收。此外，只有預設優先權值級別之請求可允許中斷正在進行中具有較低優先權值之處理。

在本發明之一實施例中，客戶類型可被標識及/或分類成群組。兩種資訊皆可做為選擇適當之規則組及/或應用選擇之規則組以產生決定之基礎。該分類可基於，例如，客戶類型或與該客戶有關聯之識別符。分類能促進規則之明確及改進可管理性。分類可被使用到維持做決定所需之解答之程度。應注意的是，當使用客戶之分類，某些極特殊之決定可仍基於確切之客戶類別。某些類別可能只用於被標識為“受信任”(trusted)之客戶(例如，具有受信任領域中之提供者識別符之用戶)。一屬於某系統重要類別之未受信任(untrusted)之客戶則將被強制歸屬至一指定給諸如該類客戶之類別。

在本發明之一實施例中，提交之請求可被儲存在用於支援處理之不同版本中。首先，原始請求可被儲存，其對應接收之請求，結合之前之客戶請求(若存在)。如此可於任何時刻提供有關客戶之理想目標狀態之資訊。其次，工作請求可被儲存，其初始為原始請求，然後在應用至少一規則組後被修改。再者，活動請求可被儲存，其對應最後之工作請求，即最後完成處理循環之結果。該請求版本一方面表示該提交之請求以何種形式被獲准；另一方面，其提供有關客戶狀態之資訊，作為另一客戶之任何請求之處理依據。

依據可供資源之實例，可將許多規則劃分成任何適當之規則組。

一種混合之規則基礎(rulebase)可被提供，其包含一組相關於其他客戶之規則。該規則基礎可限定資源，相關於來自其他客戶之進行中之資料串流，如何使用於一來自於請求客戶之資料串流，且可能地，如何修改進行中之資料串流之操作。一種選路之規則基礎可被提供，其包含一組依優先順序處理輸入及/或輸出之規則。一種效應之規則基礎可被提供，其包含一組限定那些客戶可被允許控制那些資源之規則。一種安全性之規則基礎可被提供，其包含一組相關於存取資源之安全要求之規則。該安全要求可基於，例如，客戶之性能、VIDS(供應商識別符)及/或SIDS(安全識別符)。一種硬體限制之規則基礎可被提供，其包含一組規定目前硬體之種種限制，例如，何種輸入及輸出硬體之組合是可能或不可能的。一種軟體限制之規則基礎可被提供，其包含一組規定目前軟體之種種限制。軟體之限制可例如為排程之限制。一種資源限制之規則基礎可被提供，其包含一組解決資源衝突情況之規則。如此之規則基礎可考慮到可供使用之處理性能，例如，可供使用之MIPS(每秒百萬指令)及可供使用之記憶體，且當衝突情況發生時，負責推論那個資料串流應被要求回收並以何種順序。一種例外之規則基礎可被提供，其包含一組規定一般決定之例外之規則。一進一步之規則基礎可包含一組規定不同客戶之組態之規則，其促進客戶組態之簡易性，等等。

應了解的是，其他種種之規則基礎也可被實行。

資源管理可替代選擇地由操作於更廣泛層面之專屬部件來提供。例如，若在實施例中之資源存取持別是為音頻客戶而控制，則資源管理部件可能也注意到消耗記憶體及處理循環之音頻客戶以外之客戶。該資源管理部件可提供相關於資源之決定，其必須考慮到目前規則處理之結果。例如，其首先考慮到當資源要求回收被作成決定時，已經基於其他規則而決定停止之客戶。

在本發明之一實施例中，至少一組規則可被部分或完全地以組態矩陣(configuration matrix)之形式來實行。該組態矩陣可指定規則組中處理各方面之特定決定給各個可能之請求類型。例如，一混合矩陣可基於進行活動之各個可能類型而決定每個請求類型可被允許之程度。

組態矩陣允許以一特別簡單之方式實行變更。視覺形式強制變更或增加之結果被考慮及限制於所有之情況。一個以規則可被讀取及應用之方式敘述規則之語言可以使用軟體碼來實行。一個軟體碼之組態檔案可由按下單一按鍵而產生自包含組態矩陣之組態文件。應注意的是，組態矩陣需要知道請求之類型以做評估。因此，習用之簡單優先權值非支援該矩陣使用之首要。但是，應注意的是，某些規則是高度地特殊化，致使矩陣無所用處。因此，所有或部分之規則也可能被實行而非使用分開之組態矩陣。

大體上，規則組可被實行以任何適當之格式。其可能例如使用網域特定語言(DSL)、類似矩陣、相依圖、小語言(little language)、組態檔案、等等。另外，其也可以使用資源控制實施語言(resource control implementation language)之編碼或藉定義常態行為來實行。為各組規則選擇最適當之表現方式來敘述需求之行為是有助益的。

在本發明之一實施例中，應用一選擇之規則組包括基於該規則組之各規則採取處理請求之個別決定。然後，在所有決定中具有最大情境特定衝擊之決定將被選擇。如此可能是，但非必然，所有規則中最具約束力的決定。具有最大情境指定衝擊之決定之替代決定可能是資源消耗最少之決定。

至少一規則組之應用之決定可能包括：接受請求、接受具有修改之請求、接收具有另一客戶之修改之請求、或拒絕請求。

如上述，至少一規則組可包括可能影響另一客戶對資源存取之規則。由另一客戶存取資源之結果可能被撤銷，若由請求所產生之資源存取被另外一個新的請求終止。

在本發明之一實施例中，客戶被通知是否請求被接受、修改地接受或拒絕。

在本發明之一實施例中，每一個在應用所選之至少一規則組之前之客戶之狀態將被恢復，若應用該所選之至少一規則組因為某些原因而被放棄於完成之前。

在本發明所提出之資源控制配設或電子裝置之中，客戶介面可促成與客戶之通訊。利用例如裝置狀態資訊及其他領域之特定規則，規則組可以提供特定領域之決策方法來修改請求以符合資源存取控制。該規則組方面可利用不同策略得到決定，例如投票方式。規則選擇元件或規則序列生產部件(rule sequence factory)可檢查接收之請求及產生可供使用之規則組。控制器可選擇性地使用階段處理策略以做為資源存取方法之主管及工作流程之管理員。

此外，資源介面可被提供，其用於將資源控制認可之串流特性傳向該資源。此外，請求佇列(request queue)可提供通訊最佳化及處理優先順序之請求。為管理與接踵而至之請求有關聯的客戶，客戶管理器可被提供予該客戶之相關資訊。加之，客戶管理器可提供方法，以管理支援工作流程之客戶之串流資訊容器。該串流資訊容器可啟動資源控制及規則組以留意該客戶之目標狀態、目前活動狀態及於處理階段由其他規則組所做之修改。該串流資訊容器可用於，例如，儲存如上述定義之原始請求、工作請求及活動請求。任何與資源連接及回覆客戶之有關串流特性之允許及改變之通訊可基於比較該改變於該容器內。

另外，資源控制行動可用於促進由一客戶施加於另一客戶之修改之逆轉。使不同客戶已成為活動之指令可能影響若干規則基礎所做之決定。因此，當若干客戶停止時，該逆轉無法合理地由執行所有客戶與其他所有客戶相左而推論。資源控制行動可用於連結資訊源客戶與目標客戶至任何施加之修改。當該資訊源客戶之狀態發生改變，所有由其施加之動作可因此容易地被偵測、評估及逆轉。

本發明可應用於例如(但非侷限)在音頻輸出之資源之存取控制。

某些可由客戶提出之請求之實例如下：電話警示、文字轉語音(text－to－speech)警示、電路交換(circuit－switched；CS)通話、網際網路語音通訊(Voice over IP；VoIP)通話、即按即說行動電話(Push－to－talk over Cellular；PoC)通話、警示、接收之資訊、電池狀態、記錄、錄音、媒體播放器、行動電視(mobile TV)、調頻(FM)收音機、網路訊息、視訊電話(video call)、視我所視(See What I SEE；SWIS)播放、語音撥號(voice dialing)、高階音調、音量調整、最小音頻、音響試播、低階音調、電話功率、壓鍵(key press)、相機色調、視像、雙音多頻(Dual Tone Multi－Frequency；DTMF)音調、未知播放器、未知記錄器、等等。

某些行動之實例，其由一規則組指定給要求之客戶於一修改請求之範圍內或指定給其他活動之客戶，包括：暫停、暫停及自動重新開始、停止、演出、播放嗶嗶聲(beep)、音量遞增(ramp up)、音量遞減(ramp down)但非完全靜音而繼續播放、音量遞減至完全靜音、強制靜音、降低音量、佇列、等等。佇列必須用於當聲音具有最小持續期間，且所有請求之聲音都必須完整播放而不被中斷於該等請求是快速而連續的時候。從最嚴格至最寬容之規則序列可能是，例如，即刻停止、停止及播放嗶嗶聲(beep)、音量遞減之停止、演出並強制靜音、演出並降低音量、演出並遞減音量、演出並播放嗶嗶聲、演出並遞增音量於播放開始時、演出。

本發明可進一步以電子裝置實行，以促使多個客戶對於至少一資源之存取。可用以實行之實例包括(但非侷限)行動通訊裝置(例如行動電話)、膝上型電腦、個人電腦、等等。

本發明之其他目標及特徵將由以下之陳述及相關圖式而更趨明晰。應了解的是，圖式僅為描述之目的而非設限。圖式非依比例繪製而僅係表達架構及步驟。

圖1係電子裝置1之示意區塊圖，其中依據本發明實施例，控制對資源之存取。

該電子裝置1可例如是具多媒體功能之行動電話。

該電子裝置1包括硬體部件10及要求存取該硬體部件10之多個客戶15。因此，該硬體部件10是被控制存取之資源。該硬體部件10可能包括，例如，音頻輸出單元、震動裝置、記錄裝置、顯示器、效應裝置、記憶體、中央處理單元(CPU)、等等。該等客戶可能包括，例如，電話客戶、電池管理器客戶、FM收音機客戶、相機客戶、警示器客戶、音樂撥放器客戶、媒體播放器客戶、媒體記錄器客戶、等等。

該電子裝置1進一步包括一資源控制配設30。客戶15經由資源控制配設30之客戶介面31而連結資源控制配設30之不同部件，而硬體部件10經由資源控制配設30之硬體介面34而連結資源控制配設30之不同部件。應了解的是，雖然本發明之實施範例處理的是經由硬體介面34對硬體部件10之控制，但一相應之經由軟體介面對軟體部件之控制可藉相同或分開之資源控制配設以相同方式來實行。

該資源控制配設30包括對於各客戶15之客戶資訊部件20，該客戶資訊部件包含：原始請求容器21、工作請求容器22、活動請求容器23及固定資訊儲存部件24。各客戶資訊部件20連結至客戶介面31。該客戶介面31進一步經由請求佇列32連結至控制器33。該控制器33進一步連結至硬體介面34。此外，客戶管理器35連結至客戶介面31、客戶資訊部件20、控制器33及硬體介面34。該控制器33進一步連結至規則序列生產器40及規則基礎部件50。該規則基礎部件50包含多個規則基礎，分別為混合規則基礎51、選路(routing)規則基礎52、效應規則基礎53、安全規則基礎54、及其他之規則基礎55。該規則基礎部件50連結至規則序列生產器40及資源控制行動部件60。該資源控制行動部件60包含促使產生具體資源控制行動之規定，其可能例如是系統中一組具體級別之規定。最後，該資源控制行動部件60連結至客戶資訊部件20。

資源控制配設30負責管理客戶15其中之一之任何硬體存取請求。其組構成根據本發明之資源控制配設之範例。該資源控制配設30之部件31－35、40、50及60可例如以軟體碼(software code；SW)部件之形式來實行，及可由電子裝置1之處理單元執行該軟體碼。部件20－24可儲存於該處理單元之可直接存取之緩衝器或記憶體中。另一替代選擇之方式是該資源控制配設30可能是，例如，實施相同功能之晶片或晶片組。

應注意的是，各客戶資訊部件20之內容可選擇地儲存於某些資料庫中，其經資料庫介面而由客戶15及資源控制配設30存取。

以下陳述將對電子裝置1之部件做更詳細之說明。

當客戶15希望存取硬體部件10時，其可產生由該硬體部件10處理之個別資料串流。例如，音樂播放器客戶15可能產生一可由電子裝置1之喇叭輸出之音頻資料串流。然而應注意的是，客戶也可能希望為接收資料串流而存取硬體部件。此外，客戶要求之硬體存取可能並不需要任一方向之資料串流。舉例言之，全體效應控制可能由某客戶執行，其自身實際上是不需要資料串流。該硬體部件10之存取是基於客戶15之個別請求來管理。一要求關係到客戶之資料串流之特性或狀態之改變，例如，改變音量、應用特效或開始播放。單一之要求可包括不定之資訊量，例如，只是音量改變之資訊或音量、特效及狀態改變之資訊。

為啟動對硬體部件10之存取之管理，客戶串流之特性及狀態必須提供給資源控制配設30。各客戶具有“固定(static)”之特性，其經初始化後不得變更，例如，客戶應用處理識別號。該“固定”之特性儲存於客戶資訊部件20之固定資訊儲存部件24。另外，各客戶也具有“動態(dynamic)”之特性。對於該動態之特性，有三個容器可供使用以促進硬體存取控制，即客戶資訊部件20中之原始請求容器21、工作請求容器22、活動請求容器23。

原始請求容器21包含客戶想要求之串流特性，若請求可被完全同意。單一原始請求是特定客戶之所有要求之組合之一特定串流。若一客戶應用具有多個串流，則一分開之容器組將為各串流產生。新的要求致使在原始請求之請求特性之舊數值被改寫。該原始請求需要作為存取控制之基礎，因為該存取控制應經常注意客戶之理想目標狀態。

工作請求容器22於存取控制開始規則處理之前，將被初始化為原始請求值。因此，該初始之工作請求相同於被儲存之原始請求。在規則處理之期間，該工作請求可依據規則基礎部件50來修改。更確切地說，該規則基礎部件50檢查該該初始之工作請求、實施規則及修改該工作請求。該規則基礎部件50也可修改在對應工作請求容器內之其他客戶之目前工作請求，而非僅是發送正在被處理之請求之客戶之工作請求。舉例言之，一設定之音頻串流類型成為活動的可能致使其他客戶要求之現存音頻串流被停止或成為靜音。

當特定要求之規則處理已完成，在各工作請求容器22之目前工作請求將於關聯之活動請求容器23內被儲存成為新的活動請求。因此，該活動請求容器23包含該串流之目前特性，亦即，經所有適用規則修改後之原始請求。此刻，客戶15也將接收一訊息，其指示先前之活動請求與新的活動請求之差別。換言之，該訊息將指示該客戶有關請求所改變之串流特性及狀態之結果。在規則處理期間，在其他之活動或中止客戶15之活動請求容器23內之資訊可由該規則基礎部件50使用，以推斷正在處理中之請求如何被處置。

因為一客戶之要求之規則處理可能影響其他客戶之要求，所以所有客戶皆需要三個容器21、22、23，而非僅是提出正在受處理之要求之客戶。

客戶介面31使客戶15能夠提出其之請求。該介面31也用於將回答傳回該客戶15，亦即，資訊控制最終所允許之請求之資訊。可能地，該客戶15可被允許經由該客戶介面31存取予其關聯之客戶資訊部件20之內容。

進來之初始請求由客戶介面31傳送至請求佇列32，該請求於該請求佇列中依優先權順序處理。應注意的是，若有必要，某些更先進之機制也可被應用，例如，為防止某些低優先權之客戶必須延長時間等待。該初始請求可能包含：請求之類型、指定給提出請求之客戶15之優先權及客戶15所要求之所有改變之資訊。具有最高優先權之客戶15之請求將首先被處理。請求佇列32本身負責維持該優先權順序及回答適當之請求。請求佇列32也可促使客戶15提出新的請求於先前之請求被處理之前。如此，過時的請求不需被處理。舉例言之，假若客戶15快速地提出連續的請求以改變串流之某些特性，例如音頻串流之輸出音量，只有最近之請求之值必須被考慮，而其他較早之請求則被丟棄。請求佇列32還可促使來自相同客戶15之大量請求之情況得到最佳化。假若客戶15提出不同類型之請求，該等請求可被合併成為單一之操作處理。

客戶管理器35管理客戶串流。該客戶管理器可預處理來自該請求佇列32之客戶請求，並且將該進來之請求與現存之客戶15之請求合併。該客戶管理器亦管理容器21、22及23。此外，該客戶管理器35產生及傳送該請求之回應至客戶15。進一步地，該客戶管理器可反轉變更，若初始之規則處理因故放棄。該客戶管理器提供必要之資料，包括工作請求容器22之內容及其他資訊，例如，固定之客戶資訊(例如，處理識別符)，以供規則基礎部件50使用。該客戶管理器基於可供使用之資訊解決該客戶音頻類型。

控制器33是資源控制配設30之核心部件；其實施資源控制功能之主要邏輯。該控制器接收來自可影響資料串流之次系統之改變之指示。該次系統包括請求佇列32，該請求佇列可通知請求到來之資訊，但該次系統可同時包括其他之次系統，例如，通知有關附件之某些附屬架構。一但接收到改變之指示，控制器33進一步啟動規則處理。其提供階段處理邏輯，其中該規則處理方法是以片段方式執行。如此使得具有較高優先權之客戶之請求可為較低優先權之客戶而放棄處理。該規則處理之後，控制器33經由硬體介面34將目前串流之資訊傳送至硬體部件10，因此，例如音量或串流之選路將實際改變。

當新的請求之規則處理開始時，控制器33要求規則序列生產器40產生一規則序列。該序列產生器40檢查目前之客戶請求、其他客戶之狀態及目前系統狀態，及基於該資訊及客戶類型組成一規則基礎之序列。亦即，僅有實際可應用至該請求類型之規則基礎51－55將被選擇。舉例言之，若系統狀態、請求類型及其他客戶之狀態不是效應制約的，則效應規則基礎將不會包括在該規則序列內。該系統狀態可包括，例如，選擇之活動檔案設定(譬如‘靜音模式’、‘戶外’、等等)，或附件之存在或不存在。

應注意的是，該規則處理也可由其他之事件類型來啟動而非客戶請求，例如，由系統狀態改變，諸如靜態模式之開啟。在此狀態，序列產生器40檢查系統狀態以產生適當之規則序列。此外，在該系統狀態之檢查之期間，該序列產生器40可偵測未處理之系統狀態變更，其也影響被包括在規則序列內之規則基礎之類型。該未處理之系統狀態之類型也可作為參數傳送給序列產生器40。

一但接收來自規則序列生產器40之規則基礎序列，控制器33將使客戶請求受制於該規則基礎序列所標示之各規則基礎51－55。規則基礎部件50選擇與目前處理之要求有關聯之串列狀態及可指定資源控制行動於所有活動及中止之客戶15。該規則基礎部件50使用所有客戶之相關資訊以做決定。在該規則處理期間，請求客戶所請求之變更將對照所有活動及中止之客戶進行評估。各個比較將決定如何處理新要求。當規則處理結束，最嚴格、最具限制性之決定將由規則基礎部件50選出及經由硬體介面34由控制器33來執行。

應注意得是，該等規則基礎之安排及可供該規則基礎使用之資訊可能變動。該規則基礎及實際資源控制部件，例如，可能屬於不同之執行線程(threads)。若該等規則基礎是分散式的，如此可能要求客戶資訊不能由規則基礎直接存取，而是該客戶資訊可能經過濾，使得通過特定之規則基礎之資料量可小量化，亦即，只有該規則基礎真正需要之資料才傳送。從資源管理之觀點，重要資訊之例如為“客戶類型”及“若請求被所有規則處理串列所接受，則被停止之客戶”；後者對於能夠評估請求之新客戶組合之資源消耗是重要的；前者，以資源管理之觀點，對於能夠按優先順序處理客戶是必要的。

若規則處理由其他事件類型而非進來之客戶請求所啟動，則控制器33將命令在目前規則序列之各規則基礎依序實施處理。當處理該類系統狀態改變，規則基礎部件50將擷取所需之客戶資訊及使用問題中最適用於規則基礎之方法得到解答。一種方法可能包含對各個客戶實施改變。舉例言之，若靜音模式啟動，則各個客戶之音量將設定為零。另一種方法可能包含藉分析客戶間之相關特性以推論系統狀態改變之效應。舉例言之，若客戶正在錄製之輸入資源變成無法供應，因為附件被拆卸，該客戶應被停止及通知。又另一種方法可能包含評估系統狀態改變時，彼此將牴觸之客戶。

在規則處理期間，客戶15可能相互指定資源控制行動。該指定由規則基礎部件50實施且該指定將作為該資源控制行動之“來源”客戶與另一個作為該資源控制行動之“目標”客戶相聯結。在此聯結中，客戶之請求目前在處理中之客戶可以作為來源客戶，但同樣可為目標客戶。資源控制行動最通常是以某方法修改目標。舉例言之，資源控制行動可能致使目標之音量設定為零，亦即，強制靜音。當資源控制行動之來源消失，亦即停止，該資源控制行動離開該目標，及可能執行回復(rollback)程序。舉例言之，音量可回復至強制靜音前之狀態。客戶15之固定資訊儲存部件24可能包含一目標陣列，其用於資源控制行動中為目標之客戶，及一來源客戶，其用於資源控制行動中為來源之客戶。如此，當取消條件符合，儲存於來源陣列之客戶之行動可被取消，例如該客戶停止。相同地，所有儲存於目標陣列之客戶之行動可被取消，若該目標客戶停止於符合該取消條件之前。因此，當稍後取消條件符合時，確保不會試圖取消一不存在之客戶。該資源控制行動可修改該目標之工作請求容器22之內容。

因此，資源控制行動促進反轉規則基礎部件50於目標客戶15所造成之修改。資源控制行動將來源與目標聯結，所以稍後來源之改變可即刻對目標作評估。舉例言之，在來源客戶停止後，其資源控制行動被反轉。然後，在目標客戶方面，檢查是否該移除之行動是其之類型之最後一個。由移除資源控制行動所造成之效應只可被反轉於所有相同類型之資源控制行動已經解除。舉例言之，複合之來源客戶可能已施加“強制靜音”之資源控制行動於設定之目標客戶。只移除該等資源控制行動之其中之一是不足以反轉對該目標客戶之強制靜音。所有其他“強制靜音”之資源控制行動也需被移除於恢復音量之前。

此外，定義不同衝擊之修改之資源控制行動也可能須考慮，舉例言之：客戶A施加“強制靜音”於客戶B。然後，一第三客戶C要求“降低音量”於客戶B。該“降低音量”之規則設定音量為1，而“強制靜音”要求音量為0。如此，應該總是遵守對目標客戶之最嚴格資源控制行動而非最新近之資源控制行動。此外，該資源控制行動可確保若客戶A停止，客戶B之音量不會設定回原來之音量而是音量1，只要客戶C仍為活動狀態。

總之，資源控制行動是有助於簿記之目的。尤其重要的是，資源控制行動移除所有客戶15必須對比其他所有客戶15完成所有規則基礎之處理。

為支援個別資源控制行動之產生，資源控制行動部件60包括一級別組。

舉例言之，資源控制行動部件60可包含一總資源控制行動級別CresourceControlAction，其定義被設定之參數及被選擇之功能。該參數可包括，例如，來源客戶、目標客戶及受影響之特性。該功能可包括，例如，調用(invoke)功能，其致使由來源客戶所造成目標客戶之特性改變。該功能可進一步包括，例如，反轉功能，其致使目標客戶之先前特性之設定，當來源客戶加諸之行動停止。該功能可進一步包括，例如，取消功能，其促使行動之取消。舉例言之，若音量遞減行動使得目標客戶之音量程度是緩慢地降低，則音量遞增行動，其音量係逐漸增加，可能被要求於施加該行動之來源客戶停止時。應了解的是，還有其他不同之功能，例如，限定行動之施行於預定之時段之後之功能，譬如5秒之後。

此外，資源控制行動部件60可包括，例如，對每個啟動之資源控制行動之類型之固定資源控制行動級別。該固定資源控制行動級別可能決定於該總資源控制行動級別CresourceControlAction及決定個別資源控制行動之類型之固定特性。舉例言之，可提供級別Cquieten，其決定是否目標客戶應靜音，亦即，目前之音量即刻降至零。另一個實例，可提供級別CrampDown，其可決定是否目標客戶應遞減音量於一預定之時間內至一預定之音量。類似之級別可為所有資源控制行動之支援類型而定義。

圖2之表格表示一簡化之混合規則基礎51之實例。各行標頭表示所有可能進行之活動，而各列則表示所有可能之請求。該等活動及請求包括：電話警示、文字轉語音警示、接收之訊息、錄製、媒體播放器、音樂撥放器、FM收音機、壓鍵、相機鈴聲及視像。對於各個進行活動與請求之組合，左邊方格與右邊方格是關聯的。左邊方格內包含一或多個表示如何處理請求之規則，而右邊方格內包含一或多個表示進行之活動之規則。該等規則包括：動作停止(S)、執行活動(R)、播放警示(B)、音量遞增(U)、音量遞減(D)、降低音量(Q)、及不可能(X)。舉例言之，若媒體播放器是活動的且得到文字轉語音警示之請求，媒體播放器音頻輸出是繼續執行(R)，但媒體播放器音頻輸出在資源控制行動之活動是音量遞減(D)，當執行警示使得文字轉語音警示音頻輸出之音量遞增(U)。此外，未顯示於表格內之進行活動之可能行動組合可例如“SD”，其表示停止但音量遞減以產生一和緩之停止。

在一修改之實施例中，該混合規則基礎甚至考慮到是否請求是來自於相同之客戶。客戶之請求不相對於相同客戶之其他請求做評估。為此目的，各客戶可以處理識別符(process identifier,PID)來辨識。在此修改之實施例中，客戶自身是期望能知道其之資料串流在客戶事例之內容方面應如何運作，然而資源控制知曉及控制該客戶之資料串流在整個裝置之內容方面之運作。

電子裝置1之第一個操作實例之說明是基於圖3之序列示意圖。在初始狀態，當電話來時，電子裝置1之使用者正聽取音樂撥放器客戶提供之音樂，而電話客戶想要求播放鈴聲。

該電話客戶15隨即產生播放許可之相應請求。然後，該該電話客戶15傳送該請求至客戶介面31(步驟101)，其傳遞該請求至請求佇列32(步驟102)。

請求佇列32將新的請求插入處理序列之適當位置。該位置決定於該電話客戶15之優先權。

請求佇列32部件通知控制器33有新的請求，包括該請求客戶15之優先權之指示(步驟103)。

控制器33部件要求該請求佇列32提供受處理之新的請求(步驟104)。譬如一“獲取要求”訊息由控制器33傳送到請求佇列32，每當先前請求已完成，或當新進之請求之優先權命令中止行進中之處理。該請求佇列32提供一具有最高優先權之請求至控制器33，包括該關聯客戶之識別符(步驟105)。

控制器33此刻要求將提交該要求之客戶15之相關資訊提供給客戶管理器35(步驟106)。

客戶管理器35從與該電話客戶15關聯之原始請求容器21中擷取該電話客戶15之先前請求之串流特性，將該先前請求與新請求之特性結合，及儲存該結合之特性於與該電話客戶15關聯之原始請求容器21內。進一步地，客戶管理器35將與該電話客戶15關聯之工作請求容器22初始化，使其具有相同值。此外，客戶管理器35從電子裝置1之所有其他活動或中止之客戶之活動請求容器內擷取目前使用之串流特性；因此，在目前事例中，係至少從與該音樂播放器關聯之活動請求容器內擷取。

客戶管理器提供所有擷取及組合之資訊至控制器33(步驟107)。

控制器33要求規則序列生產器40基於所獲之資訊為新的請求選擇一規則基礎序列(步驟108)。

規則序列生產器40隨即檢查該要求之類型、客戶15之類別、其他客戶之狀態及目前系統之狀態。該規則序列生產器認定沒有特定之系統狀態且客戶15沒有與具有廠商識別符之特定類別有關聯。進一步地，其認定該要求包括一播放請求，亦即播放鈴聲，且存在另一個活動之客戶，亦即音樂播放器客戶。因此，規則序列生產器40決定至少該混合規則基礎51是必須的。此外，其決定選路規則基礎52是必須的(步驟109)。

規則序列生產器40提供決定之規則基礎51、52之序列至控制器33(步驟110)。

控制器33指示該選擇之混合規則基礎51處理客戶資訊(步驟111)。

混合規則基礎51基於客戶管理器35所提供之其他活動或中止之客戶之相關資訊，將該請求與各個其他活動或中止之客戶做比較(步驟112)。該新要求之類型被確認為鈴聲且存在一個活動之音樂播放器客戶。混合規則基礎51規定該音樂播放器不制止鈴聲。然後，與該電話客戶15關聯之工作請求容器22經由客戶管理器35更新，且客戶介面31獲准執行鈴聲。然而，該鈴聲促使該音樂播放器之音量遞減。因此，基於資源控制行動部件60之定義，該混合規則基礎51產生額外一相應之資源控制行動類型；對於該行動，鈴聲關聯的是一來源，而音樂播放器關聯的是一目標(步驟113)。然後，該產生之資源控制行動被儲存於與電話客戶15關聯之客戶資訊部件20之資源陣列內及與音樂播放器客戶關聯之客戶資訊部件之目標陣列內。

一但該資源控制行動產生(步驟115)，該混合規則基礎51通知控制器33有關該該混合規則基礎51已被處理(步驟116)。

同樣地，該控制器33依序處理所選之規則基礎52之剩餘部份，檢查較高之優先權請求及其他高優先權系統狀態改變，其可能需要介於中間之規則處理(步驟117)。

一但所有規則基礎序列之規則基礎已被處理且所有涉及之客戶15之工作要求容器22已相應地更新，則控制器33通知客戶管理器35(步驟118)。該客戶管理器35處理資源控制行動，包括，於提交階段(commit phase)，資源控制行動之行使。因而，在與音樂播放器客戶關聯之工作請求容器內之目標音量被修改。

因此，該客戶管理器35編寫回應(步驟119)及經由客戶介面31將該回應傳送至所有客戶15(步驟120)。更確切地說，其將所有活動及中止之客戶15之工作請求容器22中之串流特性複製至所有活動及中止之客戶15之活動請求容器23中，及通知電話客戶15有關鈴聲請求之准許，以及通知音樂播放器客戶有關其特性所需之改變。

該客戶15經客戶介面31通知資訊之接收及提供該鈴聲之音頻資料至硬體部件10(步驟121)。客戶15之一特定部件負責處理有關該客戶15遵守資源控制決定，亦即，客戶15之行動不會違背決定或未經許可。應注意的是，客戶15之該特定部件(而非客戶管理器35)也可能負責處理更新原始要求容器21，及其可能由活動要求容器23中讀取允許之要求形式，而非由客戶管理器35通知對應之訊息。在此事例中，客戶管理器35可設定客戶15之變數值，例如設定為‘未處理’、‘處理中’或‘已處理’，以通知客戶15有關請求之狀態。

該客戶管理器35此刻可通知控制器33有關該存取控制處理已經完成(步驟122)。該控制器33隨即啟動硬體介面34以使資訊由客戶管理器35經控制器33及硬體介面34串流至硬體部件10(步驟123)。

更明確地，當要求之規則處理完成後，控制器33指示客戶管理器35在位於硬體介面34後面之硬體部件10寫下客戶資訊；該硬體部件10將實際上應用該決定之串流特性。客戶管理器35使用硬體介面34來傳送該資訊至硬體部件10。在此操作中，硬體介面34將該接收之資訊形成“串流”，亦即，將該資訊轉換成二位元序列並傳送出去。

由於該串流(步驟124)，硬體部件10應用該接收自客戶15之資料串流所指示之特性，使鈴聲播放且音樂播放器之音頻輸出之音量將遞減。

最後，控制器33可結束硬體存取控制處理(步驟125)。電子裝置1之第二操作實例之說明是基於圖4之序列示意圖。

初始狀態對應於圖3之處理結果之狀態，亦即，鈴聲告知來電之同時，音樂之音量遞減。圖4之序列所說明之事例是使用者決定拒絕來電以繼續聽音樂。

當相應之使用者輸入，電話客戶15產生一停止請求及傳送該請求至客戶介面31(步驟201)。該客戶介面31將該請求傳送至請求佇列32(步驟202)。該請求佇列32將新的該請求插入處理佇列之適當位置及通知控制器33新的請求之到達(步驟203)。

控制器33要求請求佇列32提出新的請求以供處理(步驟204)，然後該請求佇列32提供具有最高優先權之請求至控制器33，包含相關客戶之識別(步驟205)。控制器33此刻要求客戶管理器35提供有關提交該請求之該客戶15之資訊(步驟206)。該客戶管理器35經客戶介面31與電子裝置1之所有活動及中止之客戶15交換資訊及提供所有擷取及組合之資訊至控制器33(步驟207)。

控制器33要求規則序列生產器40，基於該獲得之資訊，選擇一用於該新的請求之規則基礎序列(步驟208)。

因此，該第二操作實例之步驟201至208之操作係對應於第一操作實例之步驟101至108。

該規則序列生產器40再次檢查該請求之類型、客戶15之類別、其他客戶之狀態及目前系統之狀態。其可決定在此事例中，該請求包括一音頻停止要求，亦即停止鈴聲。其進一步決定，此請求類型不需應用任何規則基礎(步驟209)。因此，規則序列生產器40提供一空的規則基礎序列給控制器33(步驟210)。應注意的是，提供一空的規則基礎序列只是一個舉例。停止請求可能造成其他類型之序列。舉例言之，若該客戶在某紀錄部件中保留某些每秒百萬指令(mips)或記憶，則該等保留必須被釋出。

因此，控制器33可即刻將有關所有選擇之規則基礎已被處理之訊息通知該客戶管理器35(步驟211)。

客戶管理器35注意到該請求是一停止請求，並且決定聯結至客戶15之客戶資訊部件20之來源陣列中之所有資源控制行動以及該電話客戶15已聯結成為來源之所有資源控制行動(步驟212)。

只存在一個該電話客戶15為資源控制行動來源之資源控制行動。該行動之類型是音量遞減，及該資源控制行動之目標是該音樂播放器之客戶。客戶管理器35從與客戶15聯結之客戶資訊部件20之來源陣列中及與該音樂播放器客戶聯結之客戶資訊部件之目標陣列中移除該資源控制行動。此外，其從該音樂播放器客戶聯結之客戶資訊部件之工作請求容器中將該音量遞減之行動移除，及包括一反轉行動，如此音量回復至客戶目標程度(步驟213)。應注意的是，該音樂播放器客戶可能已於此同時提出一音量要求。因此，音量遞增之客戶目標程度是存在於原始要求容器21內，其非必然相同於當行動取消時之該音量遞減。

然後，該客戶管理器35編寫回應(步驟214)及經由客戶介面31將該回應傳送至所有客戶15(步驟215)。更確切地說，其將所有活動及中止之客戶15之工作請求容器22中之串流特性複製至所有活動及中止之客戶15之活動請求容器23中，及通知電話客戶15有關接受之鈴聲停止要求及通知音樂播放器客戶有關其特性所需之改變。

該客戶15經客戶介面31通知該資訊之接收(步驟216)。

該客戶管理器35可隨即通知控制器33有關該存取控制處理已完成(步驟217)。該控制器33此刻要求硬體介面34將資訊由客戶管理器35經控制器33及硬體介面34串流至硬體部件10(步驟18)。由於該串流，鈴聲將停止及音樂播放器之音量將逐漸遞增。

最後，控制器33將結束該存取控制處理。

雖然本發明之基本創新特徵已揭示於上述較可取實施例中，應了解的是，上述之裝置或方法之形式或細節之可由熟悉此技藝之人士進行不同之刪減或替代或改變而不背離本發明之精神。本發明僅受限於後述之申請專利範圍。

1．．．電子裝置

10．．．硬體

20．．．客戶資訊

21．．．原始請求

22．．．工作請求

23．．．活動請求

24．．．固定資訊

30．．．資源控制配設(由處理單元或晶片組執行軟體程式)

31．．．客戶介面

32．．．請求佇列

33．．．控制器

34．．．硬體介面

35．．．客戶管理器

40．．．規則序列生產器

50．．．規則基礎

51．．．混合規則基礎

52．．．選路規則基礎

53．．．效應規則基礎

54．．．安全規則基礎

55．．．其他之規則基礎

60．．．資源控制行動

圖1.依據本發明之實施例之電子裝置之示意區塊圖。

圖2.使用於圖1之裝置之簡化混合式規則基礎之表格。

圖3.圖1電子裝置之第一示範操作實例之流程圖。

圖4.圖1電子裝置之第二示範操作實例之流程圖。