專利名稱：服務器裝置、許可證分發(fā)方法和內(nèi)容接收裝置的制作方法
技術領域：
本發(fā)明涉及通過網(wǎng)絡等提供內(nèi)容并提供對內(nèi)容進行再現(xiàn)所需的許可證的服務器
裝置、許可證分發(fā)方法、以及獲取內(nèi)容和對內(nèi)容進行再現(xiàn)所需的許可證并對內(nèi)容進行再現(xiàn) 的內(nèi)容接收裝置。
背景技術：
IPTV(因特網(wǎng)協(xié)議電視)是利用IP分發(fā)數(shù)字電視廣播的服務或其廣播技術的總 稱。在下文中，將像這樣使用IPTV的廣播內(nèi)容的裝置稱作IPTV客戶端。
—般地，當獲取用于對內(nèi)容進行再現(xiàn)的許可證時，向用戶呈現(xiàn)合同條款、許可證的 使用條件等，并在獲得確認之后將許可證給予用戶。該處理通常由能夠與服務器側進行交 互(向用戶呈現(xiàn)合同條款等及確認購買)的瀏覽器等來進行。對于此時使用的用戶的IPTV 客戶機與服務器(在這種情況下是購買處理服務器)之間的認證，采用SSL(安全套接層)、 TLS(傳輸層安全)等通用認證方式(例如專利文獻l)。在這點上，在服務器側普及了例如 安全加速器(能夠高速地進行標準安全協(xié)議的認證處理的特殊的服務器設備)的服務器組 件。 現(xiàn)有技術文獻
專利文獻1 日本專利申請?zhí)亻_2006-031176號(第0044段)
發(fā)明內(nèi)容
伴隨地，隨著經(jīng)由網(wǎng)絡的內(nèi)容的流通量的增加，近年來已要求實施基于比傳統(tǒng)的 通用認證方式更安全的認證方式的許可證獲取協(xié)議，并且還要求實施對于各個服務提供者 的需求特定的許可證獲取協(xié)議。然而，這種基于許可證獲取協(xié)議、安全且特定的認證方式， 與通用的認證方式相比，處理復雜且運算量大。 為此，在來自大量客戶機的許可證獲取請求集中在短時間中的情況下，例如對實 況廣播節(jié)目的內(nèi)容進行再現(xiàn)的情況下，恐怕服務器裝置的負荷會急劇地增大并且操作會變 得不穩(wěn)定。 考慮到上述狀況，本發(fā)明的目的是提供一種能夠避免來自大量客戶機的許可證獲 取請求集中在緊接著內(nèi)容的廣播開始時刻之后并使許可證分發(fā)處理的操作穩(wěn)定的服務器 裝置、許可證分發(fā)方法和內(nèi)容接收裝置。 為了解決上述問題，根據(jù)本發(fā)明，提供了一種服務器裝置，包括暫時許可證處理 部，暫時許可證處理部根據(jù)來自內(nèi)容接收裝置的、用于對加密的廣播內(nèi)容進行再現(xiàn)的許可 證的獲取請求，在從廣播開始時刻起到預定的設定時刻為止的時間段內(nèi)隨機地設定主許可 證的獲取請求時刻，并將關于該主許可證的獲取請求時刻的信息和包括與廣播內(nèi)容的從廣 播開始時刻起到預定的設定時刻為止的再現(xiàn)相對應的暫時內(nèi)容密鑰的暫時許可證發(fā)送到 內(nèi)容接收裝置；以及主許可證處理部，主許可證處理部根據(jù)在內(nèi)容接收裝置中基于關于獲取請求時刻的信息而執(zhí)行的主許可證的獲取請求，將包括與廣播內(nèi)容的全部再現(xiàn)相對應的 主內(nèi)容密鑰的主許可證發(fā)送到內(nèi)容接收裝置。 在本發(fā)明中，通過隨機地設定主許可證的獲取請求時刻，有可能在服務器裝置中
避免來自大量內(nèi)容接收裝置的許可證獲取請求集中在緊接著內(nèi)容的廣播開始時刻之后。因
此，有可能防止服務器裝置的操作由于其上過度的負荷的集中而變得不穩(wěn)定。 根據(jù)本發(fā)明的服務器裝置可以進一步包括第一認證部，第一認證部當從內(nèi)容接
收裝置接收到許可證的獲取請求時、以第一方式進行用戶認證；以及第二認證部，第二認證
部當從內(nèi)容接收裝置接收到主許可證的獲取請求時、以比第一方式具有更高安全強度的第
二方式進行用戶認證。 在本發(fā)明中，在進行安全的用戶認證的服務器裝置中，可以避免來自大量內(nèi)容接 收裝置的許可證獲取請求集中在緊接著內(nèi)容的廣播開始時刻之后。由此，有可能更可靠地 防止服務器裝置的操作由于其上過度的負荷的集中而變得不穩(wěn)定。 在根據(jù)本發(fā)明的服務器裝置中，暫時許可證處理部當在廣播內(nèi)容的廣播開始時刻 之前預定的時間段或預定的時間段以上接收到來自內(nèi)容接收裝置的許可證的獲取請求的 情況下，可以將表示響應于主許可證的獲取請求可以即時發(fā)送主許可證的信息發(fā)送到內(nèi)容 接收裝置。 另外，暫時許可證處理部當在廣播內(nèi)容的廣播開始時刻之后的預定的設定時間后 接收到來自內(nèi)容接收裝置的許可證的獲取請求的情況下，可以將表示響應于主許可證的獲 取請求可以即時發(fā)送主許可證的信息發(fā)送到內(nèi)容接收裝置。 根據(jù)本發(fā)明的另一方面，提供了一種許可證分發(fā)方法，包括根據(jù)來自內(nèi)容接收裝 置的、用于對加密的廣播內(nèi)容進行再現(xiàn)的許可證的獲取請求，在從廣播開始時刻起到預定 的設定時刻為止的時間段內(nèi)隨機地設定主許可證的獲取請求時刻，并將關于該主許可證的 獲取請求時刻的信息和包括與廣播內(nèi)容的從廣播開始時刻起到預定的設定時刻為止的再 現(xiàn)相對應的暫時內(nèi)容密鑰的暫時許可證發(fā)送到內(nèi)容接收裝置；以及根據(jù)在內(nèi)容接收裝置中 基于關于獲取請求時刻的信息而執(zhí)行的主許可證的獲取請求，將包括與廣播內(nèi)容的全部再 現(xiàn)相對應的主內(nèi)容密鑰的主許可證發(fā)送到內(nèi)容接收裝置。 根據(jù)本發(fā)明的另一方面，提供了一種內(nèi)容接收裝置，包括暫時許可證獲取請求
部，暫時許可證獲取請求部將用于對加密的廣播內(nèi)容進行再現(xiàn)的許可證的獲取請求發(fā)送到
第一服務器裝置，并獲取關于在從廣播開始時刻起到預定的設定時刻為止的時間段內(nèi)隨機
地設定的主許可證的獲取請求時刻的信息、以及包括與廣播內(nèi)容的從廣播開始時刻起到預
定的設定時刻為止的再現(xiàn)相對應的暫時內(nèi)容密鑰的暫時許可證作為來自第一服務器裝置
的響應；主許可證獲取請求部，主許可證獲取請求部基于在第一許可證獲取請求部中獲取
的、關于主許可證的獲取請求時刻的信息將主許可證的獲取請求發(fā)送到第二服務器裝置，
并獲取包括與廣播內(nèi)容的全部再現(xiàn)相對應的主內(nèi)容密鑰的主許可證作為來自第二服務器
裝置的響應；以及解密部，解密部通過使用在暫時許可證獲取請求部中獲取的暫時內(nèi)容密
鑰和在主許可證獲取請求部中獲取的主內(nèi)容密鑰對加密的廣播內(nèi)容進行解密。 根據(jù)本發(fā)明，能夠避免來自大量客戶機的許可證獲取請求集中在緊接著內(nèi)容的廣
播開始時刻之后、并使許可證分發(fā)處理的操作穩(wěn)定。
圖1是示出本發(fā)明的實施例的IPTV系統(tǒng)的結構的圖； 圖2是示出在圖1的IPTV系統(tǒng)中的內(nèi)容再現(xiàn)順序的圖； 圖3是示出內(nèi)容列表的頁面的示例的圖； 圖4是示出用于購買許可證的頁面的示例的圖； 圖5是主許可證獲取請求時序的確定方法的說明圖； 圖6是示出主許可證獲取請求時序的生成程序的流程圖； 圖7是示出基于對許可證獲取請求的頻率的預測的Tp設定方法的流程圖； 圖8是示出對DRMControlMessage的結構進行定義的XML模式(schema)的圖； 圖9是以文本格式示出圖8的XML模式的圖； 圖10是示出基于圖8禾P圖9的XML模式的DRMControlMessage的示例的圖； 圖11是示出計算機硬件的結構示例的方框圖。
具體實施例方式以下，將參照附圖來詳細地說明本發(fā)明的實施例。 圖1是示出本發(fā)明的實施例的IPTV系統(tǒng)100的結構的方框圖。 如圖所示，本實施例的IPTV系統(tǒng)100由作為內(nèi)容接收裝置的IPTV客戶端10、可以
通過流(streaming)、下載等來分發(fā)內(nèi)容并分發(fā)對該內(nèi)容進行再現(xiàn)所需的許可證的IPTV服
務器20以及可以連接以上組件的網(wǎng)絡30構成。 IPTV客戶端10是例如PC (個人計算機)、機頂盒和TV (電視)的終端設備。IPTV 客戶端IO包括用戶接口 11、網(wǎng)頁瀏覽器12、 DRM(數(shù)字版權管理)客戶機13、 IPTV媒體客 戶機14、客戶機數(shù)據(jù)庫15等。 具體地，IPTV服務器20由一個或多個服務器裝置構成。這里，將說明IPTV服務器 20由多個服務器裝置構成的情況。IPTV服務器20包括網(wǎng)頁服務器21、許可證服務器22、 IPTV媒體服務器23、服務器數(shù)據(jù)庫24等。
接下來，將說明IPTV客戶端10的詳細結構。 用戶接口 ll處理對于用戶1的輸入/輸出。例如，用戶接口 ll進行如下處理輸 入來自用戶1的各種命令并將它們提交給網(wǎng)頁瀏覽器12、 DRM客戶機13和IPTV媒體客戶 機14，并將來自網(wǎng)頁瀏覽器12、DRM客戶機13和IPTV媒體客戶機14的各種信息可視化地 呈現(xiàn)給用戶1。 網(wǎng)頁瀏覽器12預先從IPTV服務器20的元數(shù)據(jù)服務器(未示出)獲取內(nèi)容的元 數(shù)據(jù)并將它們存儲在客戶機數(shù)據(jù)庫15中，并基于該元數(shù)據(jù)來顯示內(nèi)容列表。對于該內(nèi)容列 表，用戶可以經(jīng)由用戶接口 11選擇希望再現(xiàn)的內(nèi)容，并使得網(wǎng)頁瀏覽器12發(fā)送對該內(nèi)容進 行再現(xiàn)所需的許可證的獲取請求。 此處，內(nèi)容的元數(shù)據(jù)包括內(nèi)容ID、內(nèi)容名稱、例如作為內(nèi)容的訪問目的地的 URI (統(tǒng)一資源標識)的內(nèi)容訪問信息、訪問作為用于對內(nèi)容進行再現(xiàn)的許可證的分發(fā)源的 許可證服務器22所需的訪問信息、廣播時間(開始時刻和結束時刻)、內(nèi)容的屬性和詳情、 關于是否已購買了用于對該內(nèi)容進行再現(xiàn)的許可證的信息等等。 另外，作為來自網(wǎng)頁服務器21、對暫時許可證獲取請求的響應，網(wǎng)頁瀏覽器12獲取包括其中包括暫時內(nèi)容密鑰Kcp的暫時許可證以及關于主許可證獲取請求時序的信息 的DRMControlMessage,并將DRMControlMessage連同內(nèi)容再現(xiàn)指令一起給予IPTV媒體客 戶機14。此處，暫時許可證是指對從預先設定的廣播開始時刻到預定的設定時刻為止的時 間段的內(nèi)容進行再現(xiàn)所需的許可證。與之相對應，主許可證是指對全部內(nèi)容進行再現(xiàn)所需 的許可證。上述暫時許可證和主許可證將在后面詳細說明。 IPTV媒體客戶機14在接收到來自網(wǎng)頁瀏覽器12的內(nèi)容再現(xiàn)指令后，基于存儲在 客戶機數(shù)據(jù)庫15中的內(nèi)容的元數(shù)據(jù)來訪問對內(nèi)容進行分發(fā)的IPTV媒體服務器23，獲取加 密的內(nèi)容的數(shù)據(jù)，并通過使用DRMControlMessage中所包括的暫時內(nèi)容密鑰Kcp對加密的 內(nèi)容的數(shù)據(jù)進行解密來進行再現(xiàn)處理。而且，IPTV媒體客戶機14當從DRM客戶機13獲取 主許可證時，通過使用主許可證中所包括的主內(nèi)容密鑰Kc對從IPTV媒體服務器23獲取的 內(nèi)容進行解密來進行再現(xiàn)處理。 DRM客戶機13從DRMControlMessage中提取暫時許可證中所包括的暫時內(nèi)容密鑰 Kcp并將其傳遞給IPTV媒體客戶機14，或者基于在DRMControlMessage中描述的關于主許 可證獲取請求時序的信息將主許可證獲取請求發(fā)送到IPTV服務器20的許可證服務器22， 從而獲取包括從許可證服務器22發(fā)送的主內(nèi)容密鑰Kc的主許可證、并將主內(nèi)容密鑰Kc給 予IPTV媒體客戶機14。 客戶機數(shù)據(jù)庫15由例如硬盤驅(qū)動器和半導體存儲器的存儲裝置構成，并存儲從
IPTV服務器20獲取的內(nèi)容元數(shù)據(jù)等。 接下來，將詳細地說明IPTV服務器20的結構。 網(wǎng)頁服務器21響應于來自IPTV客戶端10的網(wǎng)頁瀏覽器12的暫時許可證獲取請 求，進行用戶認證、許可證購買確認等。在用戶認證成功并確認了許可證購買的情況下，網(wǎng) 頁服務器21生成包括其中包括暫時內(nèi)容密鑰Kcp的暫時許可證以及關于主許可證獲取請 求時序的信息的DRMControlMessage,從而對IPTV客戶端10的網(wǎng)頁瀏覽器12進行響應。 DRMControlMessage的生成方法將在后面進行說明。 許可證服務器22響應于來自IPTV客戶端10的DRM客戶機13的主許可證獲取請 求，通過比上述瀏覽器標準認證方式更安全并且處理程序更多且運算量更大的方式進行用 戶認證。在該用戶認證成功的情況下，許可證服務器22檢查存儲在服務器數(shù)據(jù)庫24中的 該用戶的許可證購買歷史，并且在確認已經(jīng)購買了許可證的情況下，許可證服務器22將包 括主內(nèi)容密鑰Kc的主許可證分發(fā)給DRM客戶機13。 IPTV媒體服務器23響應于來自IPTV媒體客戶機14的內(nèi)容請求來分發(fā)加密的內(nèi) 容的數(shù)據(jù)。 接下來，將說明在以下情況下的操作在IPTV系統(tǒng)100中，IPTV客戶端10從IPTV 服務器20獲取內(nèi)容以及用于對該內(nèi)容進行再現(xiàn)的暫時內(nèi)容密鑰Kcp和主密鑰Kc、并使用這 些密鑰對內(nèi)容進行再現(xiàn)。 圖2是示出在IPTV系統(tǒng)100中的內(nèi)容再現(xiàn)順序的圖。 首先，IPTV客戶端10的用戶1經(jīng)由用戶接口 11指令網(wǎng)頁瀏覽器12基于存儲在 客戶機數(shù)據(jù)庫15中的元數(shù)據(jù)來顯示內(nèi)容列表的頁面。根據(jù)該指令，網(wǎng)頁瀏覽器12基于存 儲在客戶機數(shù)據(jù)庫15中的元數(shù)據(jù)來創(chuàng)建內(nèi)容列表的頁面，并經(jīng)由用戶接口 11將其呈現(xiàn)給 用戶1。 7
圖3示出了內(nèi)容列表的頁面的示例。在內(nèi)容列表的頁面中，對于每項內(nèi)容顯示了 內(nèi)容的靜止圖像縮略圖、內(nèi)容名稱、內(nèi)容的屬性(推薦節(jié)目、新年節(jié)目、R等級節(jié)目等)、內(nèi)容 的詳情(體裁、視頻和音頻模式、付費/免費)、表示可以購買用于對內(nèi)容進行再現(xiàn)的許可
證(還未購買許可證)的標記41、表示可以對內(nèi)容進行再現(xiàn)(已購買許可證)的標記42等 等。 此處，表示可以購買許可證(還未購買許可證)的標記41作為點擊按鈕而發(fā)揮功 能。當由用戶1點擊某內(nèi)容的標記41時，例如如圖4所示，顯示這樣的頁面其中布置有關 于許可證的購買協(xié)議條款的說明和用戶l選擇接受/不接受購買的按鈕。另外，當用戶1 在該頁面上點擊接受按鈕時，網(wǎng)頁瀏覽器12從元數(shù)據(jù)中提取與用戶1所選擇的內(nèi)容相對應 的內(nèi)容ID，并將包括該內(nèi)容ID、用戶ID和口令的暫時許可證獲取請求發(fā)送到IPTV服務器 20的網(wǎng)頁服務器21 (步驟S101)。 當接收到從IPTV客戶端10的網(wǎng)頁瀏覽器12發(fā)送來的暫時許可證獲取請求時， IPTV服務器20的網(wǎng)頁服務器21基于暫時許可證獲取請求中包括的用戶ID和口令，由例 如SSL和TLS的瀏覽標準認證協(xié)議進行用戶認證。當網(wǎng)頁服務器21已成功地進行該用戶 認證時，網(wǎng)頁服務器21參照存儲在服務器數(shù)據(jù)庫24中的該用戶的許可證購買歷史來檢查 該用戶是否已購買用于對與內(nèi)容ID相對應的內(nèi)容進行再現(xiàn)的許可證(步驟S102)。本次 在該用戶的許可證購買歷史中沒有表示已購買用于對該內(nèi)容進行再現(xiàn)的許可證的歷史。因 此，IPTV服務器20的網(wǎng)頁服務器21將本次的許可證購買信息存儲在該用戶的許可證購買 歷史中(步驟S103)。 接下來，IPTV服務器20的網(wǎng)頁服務器21生成包括其中包括暫時內(nèi)容密鑰Kcp的 暫時許可證以及關于主許可證獲取請求時序的信息的DRMControlMessage，并將其發(fā)送到 IPTV客戶端10的網(wǎng)頁瀏覽器12(步驟S104)。此處，使用為每項內(nèi)容預先準備的密鑰作為 暫時內(nèi)容密鑰Kcp。關于主許可證獲取請求時序的信息是指用于指定IPTV客戶端10的DRM 客戶機13發(fā)送主許可證獲取請求的時刻的信息。 接下來，將參照圖5說明主許可證獲取請求時序的確定方法的概要。Ts表示內(nèi)容 的廣播開始時刻，Te表示內(nèi)容的廣播結束時刻，Tp表示可以由暫時內(nèi)容密鑰Kcp解密的內(nèi) 容的結束時刻，該結束時刻是對每項內(nèi)容預先確定的時刻。從廣播開始時刻Ts起到Tp為 止的時間段是例如約幾秒鐘或幾分鐘?？梢杂芍鲀?nèi)容密鑰Kc進行解密的時間段是從Ts到 Te的時間段。Tacq是主許可證獲取請求時序的示例。在使得已購買許可證的時刻(已存 儲了許可證購買信息的時刻)Tx是在從廣播開始時刻Ts到Tp的范圍內(nèi)的情況下，IPTV服 務器20的網(wǎng)頁服務器21將從已購買許可證的時刻1 《到Tp的范圍內(nèi)隨機確定的時間設 為主許可證獲取請求時序Tacq。 IPTV服務器20的網(wǎng)頁服務器21利用上述關于主許可證獲取請求時序的信息和暫 時內(nèi)容密鑰Kcp來生成DRMControlMessage,并將其發(fā)送到IPTV客戶端10的網(wǎng)頁瀏覽器 12(步驟S104)。 IPTV客戶端10的網(wǎng)頁瀏覽器12在從IPTV服務器20的網(wǎng)頁服務器21獲取 DRMControlMessage后，將DRMControlMessage連同內(nèi)容再現(xiàn)指令一起給予IPTV媒體客戶 機14(步驟S105)。 IPTV媒體客戶機14在從網(wǎng)頁瀏覽器12接收到DRMControlMessage連同內(nèi)容再現(xiàn)指令后，將DRMControlMessage給予DRM客戶機13并且還請求DRM客戶機13從該 DRMControlMessage中提取暫時內(nèi)容密鑰Kcp (步驟S106)。 DRM客戶機13基于來自IPTV媒體客戶機14的請求，從DRMControlMessage中提 取暫時許可證中包括的暫時內(nèi)容密鑰Kcp，并將其傳遞給IPTV媒體客戶機14(步驟S107)。
IPTV媒體客戶機14在從DRM客戶機13獲取暫時內(nèi)容密鑰Kcp后，基于存儲在客 戶機數(shù)據(jù)庫15中的內(nèi)容元數(shù)據(jù)，通過訪問對內(nèi)容進行分發(fā)的IPTV媒體服務器23來獲取加 密的內(nèi)容的數(shù)據(jù)，并通過使用暫時內(nèi)容密鑰Kcp對加密的內(nèi)容的數(shù)據(jù)進行解密來進行再現(xiàn) 處理(步驟S108和S109)。因此，在IPTV客戶端10中，保證對于至少從廣播開始時刻Ts 到Tp為止的時間段的內(nèi)容的再現(xiàn)。 另一方面，DRM客戶機13基于在DRMControlMessage中描述的關于主許可證獲取 請求時序的信息，將包括內(nèi)容ID、用戶ID和口令等的主許可證獲取請求發(fā)送到IPTV服務器 20的許可證服務器22(步驟SI 10)。具體地，DRM客戶機13在由關于主許可證獲取請求時 序的信息所指示的時刻將主許可證獲取請求發(fā)送到IPTV服務器20的許可證服務器22。
IPTV服務器20的許可證服務器22在從IPTV客戶端10的DRM客戶機13接收到 主許可證獲取請求后，進行比上述瀏覽器標準的認證方式更安全并且處理程序更多且運算 量更大的用戶認證(步驟Sill)。當用戶認證成功時，IPTV服務器20的許可證服務器22 基于主許可證獲取請求中所包括的內(nèi)容ID、用戶ID等，參照服務器數(shù)據(jù)庫24中存儲的該用 戶的許可證購買歷史來檢查是否已購買用于對與該內(nèi)容ID相對應的內(nèi)容進行再現(xiàn)的許可 證(步驟S112)。當確認已購買了許可證時，IPTV服務器20的許可證服務器22將包括主 內(nèi)容密鑰Kc在內(nèi)的主許可證分發(fā)給DRM客戶機13(步驟SI 13)。 DRM客戶機13在從許可證服務器22獲取包括主內(nèi)容密鑰Kc的主許可證后，將該 主內(nèi)容密鑰Kc給予IPTV媒體客戶機14(步驟S114)。 IPTV媒體客戶機14在從DRM客戶機13獲取主內(nèi)容密鑰Kc后，使用該主內(nèi)容密鑰 Kc對從IPTV媒體服務器23獲取的內(nèi)容進行解密并進行再現(xiàn)處理(步驟S115)。這樣，在 IPTV客戶端10中進行再現(xiàn)處理直到內(nèi)容的結束時刻為止。
接下來，將參照圖6說明主許可證獲取請求時序的生成程序。 當已購買了許可證時(將許可證購買信息新存儲在服務器數(shù)據(jù)庫24中時)(步驟 S201) ， IPTV服務器20的網(wǎng)頁服務器21判斷時刻T購買是否比時刻T開始前更早，其中T開始前比 內(nèi)容的廣播開始時刻Ts要早預定的時間段。此處，比廣播開始時刻Ts要早預定時間段的 時刻T^^是可以成為對于廣播開始時刻Ts時間充裕的時刻，從而避免服務器裝置上的負 荷集中，例如是廣播開始時刻Ts —天前的時間。 在該判斷中當IPTV服務器20的網(wǎng)頁服務器21判斷已購買許可證的時刻T,要 早于時刻T^^的情況下，網(wǎng)頁服務器21不是在從時刻Tj;^到Tp的范圍內(nèi)隨機地確定關 于主許可證獲取請求時序Tacq的信息，而是將關于主許可證獲取請求時序Tacq的信息作 為"-l"，生成不包括暫時內(nèi)容密鑰Kcp的DRMControlMessage (步驟S206)，并將其發(fā)送到 IPTV客戶端10的網(wǎng)頁瀏覽器12。 另夕卜，當在步驟S202的判斷中判斷已購買許可證的時刻T，在時刻T^^之后時， IPTV服務器20的網(wǎng)頁服務器21判斷已購買許可證的時刻T購買是否早于Tp(步驟S203)。 在"是"的情況下，IPTV服務器20的網(wǎng)頁服務器21將設定在從已購買許可證的時刻T^^
9到Tp的范圍內(nèi)隨機確定的時間作為關于主許可證獲取請求時序Tacq的信息(步驟S204)。在"否"的情況下，網(wǎng)頁服務器21接著判斷已購買許可證的時刻T，是否在Tp與內(nèi)容的廣播結束時刻Te之間的范圍內(nèi)(步驟S205)。在"是"的情況下，IPTV服務器20的網(wǎng)頁服務器21將關于主許可證獲取請求時序Tacq的信息設為"_1"，生成不包括暫時內(nèi)容密鑰Kcp的DRMControlMessage (步驟S206)，并將其發(fā)送到IPTV客戶端10的網(wǎng)頁瀏覽器12。
當IPTV客戶端10的DRM客戶機13得知在DRMControlMessage中描述的關于主許可證獲取請求時序Tacq的信息為"-l"時，DRM客戶機13立即將包括內(nèi)容ID、用戶ID、 口令等的主許可證獲取請求發(fā)送到IPTV服務器20的許可證服務器22。具體地，當在許可證服務器22上的負荷不集中的時間段中購買許可證時，IPTV客戶端10可以立即將主許可證獲取請求發(fā)送到IPTV服務器20以獲取主許可證。因此，在這種情況下，在IPTV客戶端10中，從內(nèi)容的廣播開始時刻Ts起，可以使用主內(nèi)容密鑰Kc對已從IPTV媒體服務器23獲取的加密的內(nèi)容進行解密，并可以進行再現(xiàn)處理。 伴隨地，已說明過Tp是可以由暫時內(nèi)容密鑰Kcp解密的內(nèi)容的結束時刻，并且是針對每項內(nèi)容預先確定的時刻。當在IPTV服務器20中設定該Tp的情況下，可以基于對于該內(nèi)容的許可證獲取請求頻率的預測來設定Tp。 圖7是示出基于對許可證獲取請求的頻率所做的預測的Tp設定方法的流程圖。在該示例中，根據(jù)內(nèi)容的廣播時間段來設定許可證獲取請求的頻率。具體地，在所謂"黃金時間"即從晚7時至晚9時的時間段中開始廣播的內(nèi)容與其它內(nèi)容之間、改變Tp的計算方法(步驟S301)。對于在黃金時間開始廣播的內(nèi)容，預測會從更多用戶接收到許可證獲取請求，因此將從廣播開始時刻Ts到Tp為止的時間段設定得較長(步驟S301)。反之，對于不在黃金時間開始廣播的內(nèi)容，將從廣播開始時刻Ts到Tp為止的時間段設定得較短(步驟S302)。結果，可以根據(jù)許可證獲取請求的頻率來很好地設定Tp。應該注意，在圖7中，Zlarge大于等于1并且是比Zsmall更大的設定值，而Zsmall大于等于1并且是比Zlarge更小的設定值。 接下來，將說明對DRMControlMessage的結構進行定義的XML模式的示例。
圖8和圖9是示出對DRMControlMessage的結構進行定義的XML模式的圖。在DRMControlMessage 50中，作為MarlinLicenseWithActionTokenType要素51的子要素，可以描述存儲有暫時許可證的MarlinTemporaryLicense要素52和可以存儲主許可證獲取請求時序作為AcquisitionTiming屬性54的值的MarlinActionToken要素53。
圖10是基于DRMControlMessage的XML模式的DRMControlMessage的示例。在本不例中，存儲"aMarlinTemporaryLicense，，的文本串作為MarlinTemporaryLicense要素52。具體地，"aMarlinT卿oraryLicense，，是暫時內(nèi)容密鑰Kcp。在MarlinActionToken要素53中，存儲"2008年6月3日12時"作為主許可證獲取請求時序即AcquisitionTiming屬性54的值。 圖11是示出通過程序執(zhí)行上述一系列處理的計算機硬件的結構示例的方框圖。
在計算機200中，CPU(中央處理單元)201、R0M(只讀存儲器)202和RAM(隨機存取存儲器)203通過總線204相互連接。 另外，輸入/輸出接口 205也連接至總線204。由鍵盤、鼠標、麥克風等構成的輸入部206、由顯示器、揚聲器等構成的輸出部207、由硬盤、非易失性存儲器等構成的存儲部208、由網(wǎng)絡接口等構成的通信部209以及驅(qū)動例如磁盤、光盤、磁光盤或半導體存儲器等可移除介質(zhì)211的驅(qū)動器210連接至輸入/輸出接口 205。 在如上所述構成的計算機200中，例如通過CPU 201經(jīng)由輸入/輸出接口 205和總線204將存儲在存儲部208中的程序加載到RAM 203并執(zhí)行該程序，來執(zhí)行上述一系列處理。 應該注意，計算機200所執(zhí)行的程序可以是按照本說明書說明的次序以時間順序進行處理的程序，或者可以是并行地或在進行調(diào)用時以必要的時序進行處理的程序。
另外，程序可以由一臺計算機進行處理，或者可以由多臺計算機分散處理。而且，程序可以被傳送至遠程計算機而進行處理。 如上所述，根據(jù)本實施例，在IPTV服務器20中，尤其是在進行安全的用戶認證的許可證服務器22中，可以避免來自大量IPTV客戶端10的許可證獲取請求集中在緊接著內(nèi)容的廣播開始時刻之后。因此，可以防止許可證服務器22的操作由于其上過度的負荷的集中而變得不穩(wěn)定。 另外，根據(jù)本實施例，由于在IPTV客戶端10中在正式地獲取許可證(主許可證)
之前從IPTV服務器20分發(fā)暫時內(nèi)容密鑰Kcp，因此保證了在從內(nèi)容的廣播開始時刻Ts到
Tp為止的時間段期間的內(nèi)容再現(xiàn)。此外，在從內(nèi)容的廣播開始時刻Ts到Tp為止的時間段
期間已購買許可證的IPTV客戶端10可以在從已購買許可證的時刻1 《到Tp為止的時間
段期間從IPTV服務器20獲取主許可證，從而可以在Tp后繼續(xù)內(nèi)容的再現(xiàn)。 應該注意，本發(fā)明的實施例不限于以上實施例，在不脫離本發(fā)明的主旨的情況下
可以做出各種修改。附圖標記的說明
10:IPTV客戶端11:用戶接口12:網(wǎng)頁瀏覽器13:DRM客戶機14:IPTV媒體客戶機15:客戶機數(shù)據(jù)庫20:IPTV服務器21:網(wǎng)頁服務器22:許可證服務器23:IPTV媒體服務器24:服務器數(shù)據(jù)庫30:網(wǎng)絡10C1 :IPTV系統(tǒng)
權利要求
一種服務器裝置，包括暫時許可證處理部，所述暫時許可證處理部根據(jù)來自內(nèi)容接收裝置的、用于對加密的廣播內(nèi)容進行再現(xiàn)的許可證的獲取請求，在從廣播開始時刻起到預定的設定時刻為止的時間段內(nèi)隨機地設定主許可證的獲取請求時刻，并將關于所述主許可證的獲取請求時刻的信息和包括與所述廣播內(nèi)容的從所述廣播開始時刻起到所述預定的設定時刻為止的再現(xiàn)相對應的暫時內(nèi)容密鑰的暫時許可證發(fā)送到所述內(nèi)容接收裝置；以及主許可證處理部，所述主許可證處理部根據(jù)在所述內(nèi)容接收裝置中基于關于所述獲取請求時刻的信息而執(zhí)行的所述主許可證的獲取請求，將包括與所述廣播內(nèi)容的全部再現(xiàn)相對應的主內(nèi)容密鑰的所述主許可證發(fā)送到所述內(nèi)容接收裝置。
2. 根據(jù)權利要求1所述的服務器裝置，還包括第一認證部，所述第一認證部當從所述內(nèi)容接收裝置接收到所述許可證的獲取請求 時、以第一方式進行用戶認證；以及第二認證部，所述第二認證部當從所述內(nèi)容接收裝置接收到所述主許可證的獲取請求 時、以比所述第一方式具有更高安全強度的第二方式進行用戶認證。
3. 根據(jù)權利要求2所述的服務器裝置，其中，所述暫時許可證處理部當在所述廣播內(nèi)容的廣播開始時刻之前預定的時間段或 預定的時間段以上接收到來自所述內(nèi)容接收裝置的所述許可證的獲取請求的情況下，將表 示響應于所述主許可證的獲取請求能夠即時發(fā)送所述主許可證的信息發(fā)送到所述內(nèi)容接 收裝置。
4. 根據(jù)權利要求3所述的服務器裝置，其中，所述暫時許可證處理部當在所述廣播內(nèi)容的廣播開始時刻之后的預定的設定時 刻后接收到來自所述內(nèi)容接收裝置的所述許可證的獲取請求的情況下，將表示響應于所述 主許可證的獲取請求能夠即時發(fā)送所述主許可證的信息發(fā)送到所述內(nèi)容接收裝置。
5. —種許可證分發(fā)方法，包括根據(jù)來自內(nèi)容接收裝置的、用于對加密的廣播內(nèi)容進行再現(xiàn)的許可證的獲取請求，在 從廣播開始時刻起到預定的設定時刻為止的時間段內(nèi)隨機地設定主許可證的獲取請求時 刻，并將關于所述主許可證的獲取請求時刻的信息和包括與所述廣播內(nèi)容的從所述廣播開 始時刻起到所述預定的設定時刻為止的再現(xiàn)相對應的暫時內(nèi)容密鑰的暫時許可證發(fā)送到 所述內(nèi)容接收裝置；以及根據(jù)在所述內(nèi)容接收裝置中基于關于所述獲取請求時刻的信息而執(zhí)行的所述主許可 證的獲取請求，將包括與所述廣播內(nèi)容的全部再現(xiàn)相對應的主內(nèi)容密鑰的所述主許可證發(fā) 送到所述內(nèi)容接收裝置。
6. —種內(nèi)容接收裝置，包括暫時許可證獲取請求部，所述暫時許可證獲取請求部將用于對加密的廣播內(nèi)容進行再 現(xiàn)的許可證的獲取請求發(fā)送到第一服務器裝置，并獲取關于在從廣播開始時刻起到預定的 設定時刻為止的時間段內(nèi)隨機地設定的主許可證的獲取請求時刻的信息、以及包括與所述 廣播內(nèi)容的從所述廣播開始時刻起到所述預定的設定時刻為止的再現(xiàn)相對應的暫時內(nèi)容 密鑰的暫時許可證作為來自所述第一服務器裝置的響應；主許可證獲取請求部，所述主許可證獲取請求部基于在所述第一許可證獲取請求部中獲取的、關于所述主許可證的獲取請求時刻的信息將所述主許可證的獲取請求發(fā)送到第二 服務器裝置，并獲取包括與所述廣播內(nèi)容的全部再現(xiàn)相對應的主內(nèi)容密鑰的所述主許可證 作為來自第二服務器裝置的響應；以及解密部，所述解密部通過使用在所述暫時許可證獲取請求部中獲取的暫時內(nèi)容密鑰和 在所述主許可證獲取請求部中獲取的主內(nèi)容密鑰對所述加密的廣播內(nèi)容進行解密。
全文摘要
發(fā)明目的通過避免來自大量客戶機的許可證獲取請求集中在緊接著內(nèi)容的廣播開始時刻之后，使得許可證服務器的操作穩(wěn)定。解決手段IPTV服務器的網(wǎng)頁服務器(21)根據(jù)來自IPTV客戶端(10)的、用于對加密的內(nèi)容進行再現(xiàn)的許可證的獲取請求，在從廣播開始時刻起到預定的設定時刻為止的時間段內(nèi)隨機地設定主許可證的獲取請求時刻，并將關于該主許可證的獲取請求時刻的信息和包括與廣播內(nèi)容的從廣播開始時刻起到預定的設定時刻為止的再現(xiàn)相對應的暫時內(nèi)容密鑰的暫時許可證發(fā)送到IPTV客戶端(10)。許可證服務器(22)根據(jù)在IPTV客戶端(10)中基于關于獲取請求時刻的信息而執(zhí)行的主許可證的獲取請求，來發(fā)送包括與內(nèi)容的全部再現(xiàn)相對應的主內(nèi)容密鑰的主許可證。
文檔編號H04N7/16GK101772960SQ20098010007
公開日2010年7月7日 申請日期2009年6月8日 優(yōu)先權日2008年6月9日
發(fā)明者中島由雅子, 二神基誠, 五十嵐卓也, 山岸靖明, 嶋久登, 川本洋志, 藤澤謙二 申請人:索尼公司