專利名稱：：信息通信系統(tǒng)、設(shè)備和方法、以及計算機程序的制作方法
技術(shù)領(lǐng)域：
：本發(fā)明涉及用于在網(wǎng)際協(xié)議(IP)網(wǎng)絡(luò)上傳輸要受版權(quán)保護的信息內(nèi)容的信息通信系統(tǒng)、信息通信設(shè)備和方法、以及用于此的計算機程序。本發(fā)明尤其涉及用于在具有有限數(shù)目的路由器路由段(hops)的IP網(wǎng)絡(luò)上傳輸IP分組的信息通信系統(tǒng)、信息通信設(shè)備和方法、以及用于此的計算機程序。更具體而言，本發(fā)明涉及用于在IP網(wǎng)絡(luò)上的信息設(shè)備之間、執(zhí)行根據(jù)在網(wǎng)際協(xié)議上的數(shù)字傳輸內(nèi)容保護(DTCP-IP)標準的驗證和密鑰交換(AKE)過程的信息通信系統(tǒng)、信息通信設(shè)備和方法、以及用于此的計算機程序。本發(fā)明尤其涉及用于在具有有限數(shù)目路由器路由段的IP網(wǎng)絡(luò)上的設(shè)備之間發(fā)送和接收用于驗證和密鑰交換的AKE命令的信息通信系統(tǒng)、信息通信設(shè)備和方法、以及用于此的計算機程序。
背景技術(shù)：
：近來，已經(jīng)逐漸開始執(zhí)行用于通過網(wǎng)絡(luò)提供諸如視頻和音樂之類的內(nèi)容的內(nèi)容分發(fā)和遞送服務(wù)。這樣的服務(wù)允許通過網(wǎng)絡(luò)在遠程終端之間執(zhí)行內(nèi)容分發(fā)，而不需要移動諸如致密盤(CD)和數(shù)字多用途盤(DVD)之類的介質(zhì)。要在網(wǎng)絡(luò)上處理的內(nèi)容受到版權(quán)法的保護，作為有版權(quán)的作品之一而免受諸如未經(jīng)授權(quán)復(fù)制或者篡改之類的未經(jīng)授權(quán)使用。在日本的版權(quán)法中，根據(jù)第30條，用戶他/她自己為了他/她個人或者家庭使用的目的而對作品進行再現(xiàn)是允許的，但是根據(jù)49(1)條，為了除了個人或者私人使用之外的目的對作品副本的使用將被禁止。因為這樣的內(nèi)容是數(shù)字數(shù)據(jù)，并且易經(jīng)受諸如復(fù)制和篡改之類的未經(jīng)授權(quán)存取和修改，所以不僅從法律角度而且從技術(shù)方案角度來看，都存在防止未經(jīng)授權(quán)使用的需要。因此，已經(jīng)開發(fā)了許多為了版權(quán)保護以防止數(shù)字內(nèi)容的未經(jīng)授權(quán)使用的技術(shù)。例如，作為用于保護數(shù)字傳輸內(nèi)容的工業(yè)標準的數(shù)字傳輸內(nèi)容保護(DTCP)標準定義了用于在版權(quán)受保護的環(huán)境中的內(nèi)容傳輸?shù)臋C制(例如，參見DTCP規(guī)范第1卷修訂版1.4(信息版本)，其可從http://www.dtcp.com獲得)。在DTCP中，規(guī)定了用于在內(nèi)容傳輸?shù)脑O(shè)備之間進行驗證的協(xié)議以及用于傳輸加密內(nèi)容的協(xié)議。概括地說，該規(guī)范定義了遵循DTCP的設(shè)備不應(yīng)該以未加密的形式將諸如MPEG(活動圖像專家組)內(nèi)容之類的任何易于使用的、壓縮的內(nèi)容發(fā)送到設(shè)備外部，應(yīng)該根據(jù)預(yù)定的驗證和密鑰交換(AKE)算法執(zhí)行加密內(nèi)容的解密所必需的密鑰交換，以及應(yīng)該限制通過其使用AKE命令執(zhí)行密鑰交換的設(shè)備的范圍。內(nèi)容供應(yīng)商(或者服務(wù)器(DTCP源))以及內(nèi)容消費者(或者客戶端(DTCP宿))通過發(fā)送和接收AKE命令的驗證過程而共享密鑰。該密鑰用于加密傳輸線來執(zhí)行內(nèi)容傳輸。除非未經(jīng)授權(quán)的客戶端已經(jīng)成功地與服務(wù)器進行了驗證，否則它不能獲得加密密鑰，并且因此不能接收內(nèi)容。此外，通過限制接收和發(fā)送AKE命令的設(shè)備的數(shù)目和范圍，內(nèi)容的使用可以如版權(quán)法所定義那樣，限于個人或者家庭使用。最初，DTCP定義了使用諸如IEEE1394之類的傳輸線的、在家庭網(wǎng)絡(luò)上的數(shù)字內(nèi)容的傳輸。在家庭網(wǎng)絡(luò)上的內(nèi)容傳輸屬于版權(quán)法所定義的個人或者家庭使用。近來，稱作DTCP-IP的復(fù)雜技術(shù)的發(fā)展已經(jīng)在前進，在DTCP-IP中，將基于IEEE-1394的DTCP技術(shù)并入到IP網(wǎng)絡(luò)技術(shù)中。因為大多數(shù)的家庭網(wǎng)絡(luò)經(jīng)由路由器連接到諸如互聯(lián)網(wǎng)之類的外部廣域網(wǎng)，所以DTCP-IP技術(shù)的建立在保護內(nèi)容的同時提供了數(shù)字內(nèi)容在IP網(wǎng)絡(luò)上的靈活和有效使用。雖然DTCP-IP技術(shù)基本上涉及DTCP標準，但是DTCP-IP技術(shù)與原有的基于IEEE-1394DTCP技術(shù)的不同之處在于IP網(wǎng)絡(luò)用作傳輸線，而且加密的內(nèi)容使用HTTP或者RTP協(xié)議傳輸。IP(網(wǎng)際協(xié)議)本身是網(wǎng)絡(luò)層，其中來自諸如TCP(傳輸控制協(xié)議)之類的上部傳輸層的進入數(shù)據(jù)流按照用作預(yù)定單位的分組尺寸被劃分為多個分組，以通過將報頭添加到這些分組中來產(chǎn)生IP分組，并且將該IP分組遞送到指定的IP地址。IP具有路由功能(例如，參見RFC(請求說明)791INTERNETPROTOCOL(網(wǎng)際協(xié)議))。因為諸如個人計算機(PC)之類的各種設(shè)備連接到IP網(wǎng)絡(luò)，所以存在有竊聽或者篡改數(shù)據(jù)的高風(fēng)險。因此，雖然DTCP-IP基本上是其中將DTCP技術(shù)并入到IP網(wǎng)絡(luò)技術(shù)中的類似于DTCP的技術(shù)，但是DTCP-IP還規(guī)定一種用于在保護內(nèi)容的同時在網(wǎng)絡(luò)上傳輸內(nèi)容的方法(例如，參見DTCP規(guī)范第1卷的附錄EMappingDTCPtoIP，修訂版1.1(信息版本)，其可從http://www.dtcp.com/獲得)。將描述根據(jù)DTCP-IP的內(nèi)容傳輸過程。遵循DTCP的設(shè)備被分為兩種類型，即，一種被稱為“DTCP_Source”，而且另一種被稱為“DTCP_Sink”。起服務(wù)器設(shè)備作用的DTCP_Source設(shè)備接收內(nèi)容請求，并且發(fā)送該內(nèi)容。起客戶端設(shè)備作用的DTCP_Sink設(shè)備請求內(nèi)容，接收該內(nèi)容，并且重放或者記錄該內(nèi)容。首先，DTCP_Source設(shè)備和DTCP_Sink設(shè)備建立單個TCP/IP連接，并且相互驗證。這個驗證被稱為“DTCP驗證”或者“AKE(驗證和密鑰交換)”。遵循DTCP的設(shè)備具有由稱作DTLA(數(shù)字傳輸許可管理員)的認證組織嵌入其中的唯一設(shè)備ID和密鑰。在DTCP驗證過程中，在DTCP_Source設(shè)備和DTCP_Sink設(shè)備使用這樣的信息來核實它們是授權(quán)的遵循DTCP的設(shè)備之后，可以在DTCP_Source設(shè)備和DTCP_Sink設(shè)備之間共享由DTCP_Source設(shè)備管理的、用于加密或者解密內(nèi)容的密鑰。在遵循DTCP的設(shè)備之間執(zhí)行基于AKE的驗證處理之后，DTCP_Sink設(shè)備請求在DTCP_Source設(shè)備上的內(nèi)容。DTCP_Source設(shè)備可以經(jīng)由內(nèi)容目錄服務(wù)(CDS)等預(yù)先向DTCP_Sink設(shè)備通知用于存取在DTCP_Source設(shè)備上的內(nèi)容的內(nèi)容位置。DTCP_Sink設(shè)備可以使用諸如HTTP(超文本傳輸協(xié)議)或者RTP(實時協(xié)議)之類的協(xié)議來請求內(nèi)容。當根據(jù)HTTP過程請求內(nèi)容時，DTCP_Source設(shè)備起HTTP服務(wù)器的作用，而且DTCP_Sink設(shè)備起HTTP客戶端的作用，在它們之間啟動內(nèi)容的傳輸。當請求基于RTP的傳輸時，DTCP_Source設(shè)備起RTP發(fā)送器的作用，而且DTCP_Sink設(shè)備起RTP接收器的作用，在它們之間啟動內(nèi)容的傳輸。還可以采用諸如RSTP(實時流傳輸協(xié)議)之類的其它傳輸協(xié)議。當根據(jù)HTTP執(zhí)行內(nèi)容傳輸時，HTTP客戶端創(chuàng)建用于HTTP的TCP/IP連接，其不同于用于DTCP驗證的TCP/IP連接。HTTP客戶端根據(jù)與標準的HTTP過程類似的操作過程，請求在HTTP服務(wù)器上的內(nèi)容。響應(yīng)于該請求，HTTP服務(wù)器返回所請求的內(nèi)容作為HTTP響應(yīng)。作為HTTP響應(yīng)發(fā)送的數(shù)據(jù)是HTTP服務(wù)器(即DTCP_Source設(shè)備)使用通過AKE驗證共享的密鑰將內(nèi)容加密成的數(shù)據(jù)。當接收到加密的數(shù)據(jù)時，客戶端(DTCP_Sink設(shè)備)使用通過上述驗證共享的密鑰來解密數(shù)據(jù)，以重放或者記錄該內(nèi)容。因此，DTCP-IP即使在IP網(wǎng)絡(luò)上也可以提供安全的內(nèi)容傳輸協(xié)議，其通過在遵循DTCP的設(shè)備之間執(zhí)行驗證以便在經(jīng)過DTCP驗證的設(shè)備之間共享密鑰、并且加密和解密傳輸內(nèi)容，而使得能夠保護內(nèi)容免受傳輸線中的竊聽或者篡改。DTCP不僅涉及通過加密內(nèi)容來保持內(nèi)容傳輸線的安全性，而且還涉及將內(nèi)容的使用限制為如版權(quán)法所定義的個人或者家庭使用。初始的DTCP技術(shù)假定諸如基于IEEE-1394的網(wǎng)絡(luò)之類的家庭網(wǎng)絡(luò)，在該情況下，內(nèi)容的使用基本上限于個人或者家庭使用。然而，在其中DTCP技術(shù)并入到IP網(wǎng)絡(luò)技術(shù)中的類似于DTCP技術(shù)的DTCP-IP中，因為設(shè)備可以經(jīng)由路由器連接到諸如互聯(lián)網(wǎng)之類的廣域IP網(wǎng)絡(luò)，所以需要對內(nèi)容傳輸范圍的限制。例如，在IP網(wǎng)絡(luò)中，為了限制IP分組的生存期，在每個IP分組的報頭中定義了稱為生存時間(TTL)的參數(shù)(例如，參見RFC(請求說明)791INTERNETPROTOCOL)。每當轉(zhuǎn)發(fā)IP分組時，IP路由器遞減報頭中的TTL字段值(例如，參見1995年6月的RFC1812-RequirementsforIPVersion4Routers)，以便可以用TTL字段值表示IP分組的生存期或者到期時間(例如，參見PCT日文翻譯專利公開第2003-521138號)。例如，在DTCP-IP中，設(shè)置了TTL字段值“3”，而且對每個IP分組進行有關(guān)TTL字段值是否不超過3的檢查。也就是說，在用戶和對方(在它們之間執(zhí)行AKE命令的發(fā)送和接收，即密鑰交換)之間的路由器路由段數(shù)目被限制為3或者更少(例如，參見DTCP規(guī)范第1卷附錄EMappingDTCPtoIP，修訂版1.1(信息版本)，其可從http://www.dtcp.com/獲得)，由此將內(nèi)容的使用限制為個人或者家庭使用。然而，當DTCP應(yīng)用實現(xiàn)諸如獲得和檢查IP分組的諸如TTL之類的報頭信息之類的處理時，存在一些技術(shù)問題。將描述這些技術(shù)問題。如本
技術(shù)領(lǐng)域：
公知那樣，通信協(xié)議具有諸如TCP和IP之類的協(xié)議棧，而且應(yīng)用層被定義為最高層?，F(xiàn)有的IP協(xié)議層僅僅實現(xiàn)了每當IP分組通過路由器時，將TTL字段值遞減1的功能。換句話說，IP協(xié)議層沒有被這樣配置，使得當接收IP分組時，從IP分組的報頭中提取TTL字段值并且通知高應(yīng)用層。這阻止了DTCP應(yīng)用在接收AKE命令時、檢查IP分組中的TTL字段值是否為3或者更少。雖然現(xiàn)有的IP協(xié)議具有丟棄其TTL字段值由于多個路由器路由段而過期的IP分組的功能，但是不丟棄其TTL字段值超過預(yù)定值的IP分組。如果AKE命令的發(fā)送目的地檢查IP分組的報頭，并且當TTL字段值超過3時丟棄該IP分組，則AKE命令的傳輸源由于TCP/IP典型的重新傳輸控制功能而執(zhí)行耗時的、用于重新傳輸AKE命令的處理。一種用于根據(jù)DTCP-IP規(guī)范、使用TTL字段值限制AKE命令所達到的范圍的操作是修改IP協(xié)議層，其中在每次出現(xiàn)路由段時，該TTL字段值由路由器遞減。然而，在并入獲得和檢查TTL字段值的功能的TCP/IP協(xié)議層中特別(uniquely)開發(fā)全部處理模塊是代價很高的。在大多數(shù)諸如Linux或者Windows(其為微軟公司的注冊商標)之類的當前主流操作系統(tǒng)(OS)中，諸如TCP和IP之類用于通信的協(xié)議棧被安裝在OS中。如果修改IP協(xié)議，則將要修改與OS緊密相關(guān)的源代碼，這導(dǎo)致各種缺點。例如，在諸如Windows之類的還沒有發(fā)布源代碼的OS的情況下，修改本身幾乎是不可能的。在諸如Linux之類的所謂的開放源代碼OS的情況下，因為公眾可得到源代碼，所以個人能夠添加IP協(xié)議層的上述功能。作為回報，個人必須發(fā)布該源代碼，這是因為全部相關(guān)的代碼根據(jù)GPL(通用公共許可協(xié)議)而被許可。也就是說，開放源代碼產(chǎn)品的修改使得開發(fā)者在將來管理產(chǎn)品變得耗時。此外，與OS核心緊密相關(guān)的內(nèi)核源代碼的修改涉及另外的測試處理，這導(dǎo)致成本增加。OS還在其中安裝了網(wǎng)絡(luò)過濾器，作為TCPIP協(xié)議層中的處理模塊的功能。在Linux中，“iptable”是這樣的網(wǎng)絡(luò)過濾器的示例。通過設(shè)置這個標準的網(wǎng)絡(luò)過濾器，可以使用現(xiàn)有的TCP/IP處理模塊來實現(xiàn)獲得和檢查TTL字段值的處理。與網(wǎng)絡(luò)過濾器的使用有關(guān)的問題在于(1)所設(shè)置的網(wǎng)絡(luò)過濾器可以導(dǎo)致阻止其它通信(或者服務(wù))的副作用，以及(2)因為網(wǎng)絡(luò)過濾器是標準的，所以所設(shè)置的網(wǎng)絡(luò)過濾器可以容易地由任何其它用戶或者處理篡改。本領(lǐng)域的技術(shù)人員還可以想到特別開發(fā)與網(wǎng)絡(luò)過濾器相對應(yīng)的處理模塊，并且將該處理模塊用于獲得和檢查TTL字段值。然而，開發(fā)強加了顯著的成本，而且所設(shè)置的網(wǎng)絡(luò)過濾器可以導(dǎo)致阻止其它通信(或者服務(wù))的副作用。
發(fā)明內(nèi)容因此希望提供這樣的信息通信系統(tǒng)、信息通信設(shè)備和方法、以及用于此的計算機程序，其中可以在IP網(wǎng)絡(luò)上恰當?shù)貍鬏斠艿桨鏅?quán)保護的信息內(nèi)容。還希望提供這樣的信息通信系統(tǒng)、信息通信設(shè)備和方法、以及用于此的計算機程序，其中可以在具有有限數(shù)量的路由器路由段的IP網(wǎng)絡(luò)上恰當?shù)貍鬏擨P分組。進一步希望提供這樣的信息通信系統(tǒng)、信息通信設(shè)備和方法、以及用于此的計算機程序，其中可以在具有有限數(shù)量路由器路由段的IP網(wǎng)絡(luò)上，在設(shè)備之間恰當?shù)匕l(fā)送與接收用于驗證和密鑰交換(AKE)的DTCP-IPAKE命令。進一步希望提供這樣的信息通信系統(tǒng)、信息通信設(shè)備和方法、以及用于此的計算機程序，其中可以在監(jiān)控在攜帶用于驗證和密鑰交換的AKE命令的IP分組的報頭中包括的TTL字段值的同時，將在其之間執(zhí)行驗證和密鑰交換的設(shè)備范圍限制為路由器路由段的預(yù)定數(shù)目或者更少。根據(jù)本發(fā)明的第一實施例，提供了一種信息通信系統(tǒng)，其包括在IP網(wǎng)絡(luò)上交換IP分組的信息通信設(shè)備。當執(zhí)行其中路由器路由段的數(shù)目被限制為預(yù)定控制值或者更少的預(yù)定分組交換過程時，每一信息通信設(shè)備監(jiān)控在從預(yù)定分組交換過程開始到緊靠預(yù)定分組交換過程結(jié)束之前的時間段內(nèi)所接收的IP分組報頭中指定的生存時間(TTL)值，以連續(xù)地更新所監(jiān)控TTL值的最大TTL值，并且檢查緊靠預(yù)定分組交換過程結(jié)束之前，最大TTL值是否不超過該控制值。此處使用的術(shù)語“系統(tǒng)”是指多個設(shè)備(或者實現(xiàn)特定功能的功能模塊)的邏輯集合，而與這些設(shè)備或功能模塊是否放在單個外殼中無關(guān)(這同樣適用于以下的描述)。本發(fā)明的實施例提供了一種用于在IP網(wǎng)絡(luò)上傳輸要被版權(quán)保護的信息內(nèi)容的信息通信系統(tǒng)，尤其是這樣的信息通信系統(tǒng)，其中在IP分組的報頭中指定的TTL字段值用于指定路由器路由段的數(shù)目，以將所分發(fā)內(nèi)容的使用限制為個人或者私人使用。更具體而言，當在遵循DTCP-IP的信息通信設(shè)備之間發(fā)送和接收用于驗證和密鑰交換(AKE)的AKE命令時，在監(jiān)控包括在攜帶AKE命令的IP分組的報頭中的TTL字段值的同時，在其之間執(zhí)行驗證和密鑰交換的設(shè)備的范圍被限制為路由器路由段的數(shù)目或者更少。例如，在DTCP-IP中，設(shè)置了TTL字段值“3”，而且對每個IP分組進行有關(guān)TTL字段值是否已經(jīng)過期的檢查。因此，在其之間執(zhí)行AKE命令的發(fā)送和接收(即密鑰交換)的DTCP設(shè)備之間的路由器路由段數(shù)目被限制為3或者更少，以便可以將內(nèi)容的使用限制為個人或者家庭使用?，F(xiàn)有的IP協(xié)議層僅僅實現(xiàn)了每當分組通過路由器時、將TTL字段值遞減1的功能。因此，為了對每個所接收的IP分組進行有關(guān)TTL字段值是否等于或者小于控制值的檢查、并且隨后丟棄其TTL字段值超過控制值的IP分組，每當接收攜帶AKE命令的IP分組時，上層DTCP應(yīng)用獲得TTL字段值，這需要修改該IP協(xié)議層。然而，因為許多OS在其中并入了TCP/IP協(xié)議層，所以這產(chǎn)生了復(fù)雜的問題。首先，在源代碼沒有發(fā)布的OS中，不可能修改IP協(xié)議層。在源代碼已經(jīng)發(fā)布的OS中，雖然有可能修改IP協(xié)議層，但是這樣的OS的源代碼應(yīng)該發(fā)布，這對于將來的管理來說是耗時的。雖然可設(shè)想特別地開發(fā)TCP/IP協(xié)議層，但這代價是很高的。還設(shè)想設(shè)置網(wǎng)絡(luò)過濾器(其是并入OS中的TCP/IP協(xié)議層中的處理模塊的功能)來獲得TTL字段值。然而，還存在阻礙其它通信以及所設(shè)置的網(wǎng)絡(luò)過濾器可能由其它用戶或者處理中斷的副作用的問題。在根據(jù)本發(fā)明實施例的信息通信系統(tǒng)中，每個信息通信設(shè)備監(jiān)控在從預(yù)定分組交換過程開始到緊靠預(yù)定分組交換過程結(jié)束之前的時間段內(nèi)所接收的IP分組的報頭中指定的TTL字段值，以連續(xù)地更新所監(jiān)控TTL字段值中的最大TTL字段值，并且緊靠預(yù)定分組交換過程結(jié)束之前，檢查該最大TTL字段值是否不超過控制值。如下所述，作為最高層的應(yīng)用層使用現(xiàn)有的庫來實現(xiàn)提取分組中的TTL字段值的處理。因此，在根據(jù)本發(fā)明實施例的信息通信系統(tǒng)中，不需要執(zhí)行諸如修改IP協(xié)議層、特別開發(fā)TCP/IP協(xié)議層、以及修改OS之類的操作，以實現(xiàn)在分組交換期間的預(yù)定時間段內(nèi)連續(xù)地監(jiān)控TTL字段值的操作。當從在從預(yù)定分組交換過程開始到緊靠預(yù)定分組交換過程結(jié)束之前的時間周期內(nèi)所監(jiān)控的分組中提取的TTL字段值的最大值等于或者小于控制值時，執(zhí)行預(yù)定分組交換過程的信息通信設(shè)備可以通過執(zhí)行隨后的分組發(fā)送和接收處理，來繼續(xù)預(yù)定分組交換過程，從而完成該預(yù)定分組交換過程，或者當最大值超過控制值時，可以結(jié)束該預(yù)定分組交換過程，而不用執(zhí)行隨后的分組發(fā)送和接收處理，借此可以將在其之間執(zhí)行信息交換過程的通信方的數(shù)目限制為TTL字段值的預(yù)定范圍。當本發(fā)明的實施例應(yīng)用于DTCP-IP驗證時，在其之間執(zhí)行驗證的兩個信息通信設(shè)備都連續(xù)地監(jiān)控在從DTCP-IP驗證開始到緊靠DTCP-IP驗證結(jié)束之前的時間段內(nèi)所接收的用于驗證的控制命令或者AKE命令，以連續(xù)地更新所接收AKE命令的TTL字段值中的最大值，并且在緊靠驗證過程結(jié)束之前檢查該最大值，以便如果該最大值等于或者小于預(yù)定控制值(例如，3)，則通過執(zhí)行密鑰交換完成該驗證過程，或者如果最大值超過預(yù)定控制值，則結(jié)束該驗證過程，而不用執(zhí)行密鑰交換。例如，根據(jù)DTCP-IP將內(nèi)容分發(fā)給起宿設(shè)備作用的信息通信設(shè)備的起源設(shè)備作用的信息通信設(shè)備，緊靠用于發(fā)送和接收AKE命令的TCP連接建立之后，即緊靠響應(yīng)于從宿設(shè)備接收的連接()請求而返回接受()之后，監(jiān)控在TCP連接上發(fā)送與接收的IP分組，以便為每個IP分組獲得TTL字段值，并且連續(xù)地更新所獲得的TTL字段值中的最大值。然后，源設(shè)備在緊靠發(fā)送Exchange_Key子功能命令之前，檢查最大TTL字段值是否等于或者小于控制值。如果最大TTL字段值等于或者小于控制值，則源設(shè)備繼續(xù)發(fā)送Exchange_Key子功能命令。如果最大TTL字段值超過控制值，則源設(shè)備結(jié)束該AKE過程，而沒有發(fā)送Exchange_Key子功能命令。在緊靠建立用于發(fā)送和接收AKE命令的TCP連接之前，即緊靠將連接()請求發(fā)送到源設(shè)備之前，從起源設(shè)備作用的信息通信設(shè)備獲得內(nèi)容的起宿設(shè)備作用的信息通信設(shè)備監(jiān)控在TCP連接上發(fā)送與接收的IP分組，以便為每個IP分組獲得TTL字段值，并且連續(xù)地更新所獲得的TTL字段值中的最大值。然后，宿設(shè)備在緊靠接收Exchange_Key子功能命令之后，檢查最大TTL字段值是否等于或者小于控制值。如果最大TTL字段值等于或者小于控制值，則宿設(shè)備響應(yīng)于Exchange_Key子功能命令而發(fā)送ACCEPTED(接受)響應(yīng)。如果最大TTL字段值超過控制值，則宿設(shè)備立即結(jié)束該AKE過程。如先前所述，當DTCP應(yīng)用實現(xiàn)為每個攜帶AKE命令的IP分組提取TTL字段值以檢查所提取的TTL字段值是否不超過控制值、隨后丟棄TTL字段值超過控制值的IP分組的處理時，必然有困難的操作，諸如特別開發(fā)TCP/IP協(xié)議層或者修改其中合并有這樣的協(xié)議棧的OS。相反，提取各個IP分組中的TTL字段值并且連續(xù)地監(jiān)控所提取的TTL字段值的處理可以通過使用具有監(jiān)控MAC幀的分組捕獲性能(稱為“pcap”，即libpcap)的現(xiàn)有庫而容易地實現(xiàn)。因此，DTCP應(yīng)用可以在從DTCP-IP驗證開始到緊靠DTCP-IP驗證結(jié)束之前的時間段內(nèi)，使用libpcap連續(xù)地監(jiān)控所接收的AKE命令，以便連續(xù)地更新最大TTL字段值。然后，緊靠驗證過程結(jié)束之前檢查最大TTL字段值。如果該最大值等于或者小于預(yù)定控制值(例如，3)，則執(zhí)行密鑰交換以完成該驗證過程。如果該最大值超過控制值，則結(jié)束該驗證過程而不用執(zhí)行最后階段的處理。因此，在不修改IP協(xié)議層的情況下，DTCP應(yīng)用可以將在其間執(zhí)行驗證和密鑰交換的通信方的范圍限制為TTL字段值的預(yù)定范圍。Pcap是允許監(jiān)控MAC幀的分組捕獲功能，并且包括作為Windows中的libpcap的“WinPcap”(例如，參見http://www.winpcap.org/)。根據(jù)本發(fā)明的第二實施例，提供了一種計算機可讀計算機程序，用于在計算機系統(tǒng)上執(zhí)行用于在IP網(wǎng)絡(luò)上與另一信息通信設(shè)備交換IP分組的處理。當執(zhí)行其中路由器路由段的數(shù)目被限制為預(yù)定控制值或者更少的預(yù)定分組交換過程時，該計算機程序?qū)е掠嬎銠C系統(tǒng)執(zhí)行步驟監(jiān)控在從預(yù)定分組交換過程開始到緊靠預(yù)定分組交換過程結(jié)束之前的監(jiān)控時間內(nèi)所接收的IP分組報頭中指定的TTL字段值；在監(jiān)控時間期間連續(xù)更新所監(jiān)控TTL字段值中的最大TTL字段值的同時，存儲該最大TTL字段值；檢查該最大TTL字段值是否沒有超過該控制值；當從預(yù)定分組交換過程開始到緊靠預(yù)定分組交換過程結(jié)束之前的時間段內(nèi)監(jiān)控的分組中提取的TTL字段值的最大TTL字段值等于或者小于控制值時，通過執(zhí)行后續(xù)分組發(fā)送和接收處理，來繼續(xù)預(yù)定的分組交換過程，從而完成該預(yù)定的分組交換過程；以及當從預(yù)定分組交換過程開始到緊靠預(yù)定分組交換過程結(jié)束之前的時間段內(nèi)所監(jiān)控的分組中提取的TTL字段值的最大TTL字段值超過控制值時，結(jié)束該預(yù)定分組交換過程，而沒有執(zhí)行后續(xù)分組發(fā)送和接收處理。根據(jù)本發(fā)明第二實施例的計算機程序是以計算機可讀格式編寫的計算機程序，以便可以在計算機系統(tǒng)上執(zhí)行預(yù)定處理。換句話說，根據(jù)本發(fā)明第二實施例的計算機程序被安裝在計算機系統(tǒng)上，因此在該計算機系統(tǒng)上施加協(xié)作效應(yīng)以充當根據(jù)本發(fā)明第一實施例的信息通信系統(tǒng)中的信息通信設(shè)備。其中啟動多個這樣的信息通信設(shè)備以作為源設(shè)備和宿設(shè)備操作來交換IP分組的系統(tǒng)可以實現(xiàn)與根據(jù)本發(fā)明第一實施例的信息通信系統(tǒng)中的那些優(yōu)點類似的優(yōu)點。根據(jù)本發(fā)明的實施例，因此可以提供其中IP分組可以在具有有限數(shù)目路由器路由段的IP網(wǎng)絡(luò)上恰當傳輸?shù)母呒壭畔⑼ㄐ畔到y(tǒng)、信息通信設(shè)備以及方法、以及用于此的計算機程序。此外，根據(jù)本發(fā)明的實施例，可以提供其中可以在具有有限數(shù)量路由器路由段的IP網(wǎng)絡(luò)上，在設(shè)備之間恰當?shù)匕l(fā)送與接收根據(jù)DTCP-IP的、用于驗證和密鑰交換(AKE)的AKE命令的高級信息通信系統(tǒng)、信息通信設(shè)備和方法、以及用于此的計算機程序。此外，根據(jù)本發(fā)明的實施例，可以提供其中在監(jiān)控包括在攜帶用于驗證和密鑰交換的AKE命令的IP分組報頭中的TTL字段值的同時，可以將在其間執(zhí)行驗證和密鑰交換的設(shè)備范圍限制為路由器路由段的預(yù)定數(shù)目或者更少的高級信息通信系統(tǒng)、信息通信設(shè)備和方法、以及用于此的計算機程序。當本發(fā)明的實施例應(yīng)用于DTCP-IP驗證時，不是為每個AKE命令從報頭中提取TTL字段值以檢查所提取的TTL字段值是否超過預(yù)定控制值并且隨后丟棄TTL字段值超過控制值的AKE命令，而是由在其間執(zhí)行驗證的兩個信息通信設(shè)備執(zhí)行這樣的處理，即連續(xù)地監(jiān)控在從DTCP-IP驗證開始到緊靠DTCP-IP驗證結(jié)束之前的監(jiān)控時間內(nèi)所接收的AKE命令，以連續(xù)地更新所接收AKE命令的TTL字段值的最大值。然后，緊靠驗證過程結(jié)束之前，檢查最大TTL字段值。如果最大值超過預(yù)定值，則結(jié)束該驗證過程而不用執(zhí)行密鑰交換，因此將在其間執(zhí)行密鑰交換的各方的范圍限制為路由器路由段的預(yù)定數(shù)目或者更少。DTCP應(yīng)用可以使用實現(xiàn)了分組捕獲功能的libpcap來獲得TTL字段值。因此，不用解決GPL許可問題的開發(fā)是可能的。因為libpcap根據(jù)伯克利軟件發(fā)行(Berkeleysoftwaredistribution)(BSD)許可而被許可，所以版權(quán)標記的使用對于使用這個庫的二進制的分發(fā)是足夠的。因此，根據(jù)本發(fā)明的實施例，可以通過使用外部庫來實現(xiàn)根據(jù)DTCP-IP的驗證和密鑰交換(AKE)過程中實現(xiàn)的TTL字段值檢查功能。因此，不需要修改諸如與OS密切相關(guān)的內(nèi)核之類的代碼。研制(manufacturing)步驟的數(shù)目比當修改OS代碼時的步驟少很多。此外，因為可以實現(xiàn)與TTL字段值檢查處理相關(guān)的控制而不用與其它用戶或者處理共享，因此沒有由其它用戶未經(jīng)授權(quán)控制的問題等。根據(jù)本發(fā)明的下列實施例以及結(jié)合附圖的更詳細描述，本發(fā)明的其它目的、特征、和優(yōu)點將變得明顯。圖1是示出根據(jù)本發(fā)明實施例的信息通信系統(tǒng)的示例結(jié)構(gòu)的示意圖；圖2是示出作為圖1所示的信息通信系統(tǒng)中的客戶端(也就是，宿設(shè)備)進行操作的信息通信設(shè)備的功能結(jié)構(gòu)的示意圖；圖3是示出作為圖1所示的信息通信系統(tǒng)中的服務(wù)器(也就是，源設(shè)備)進行操作的信息通信設(shè)備的功能結(jié)構(gòu)的示意圖；圖4是示出AKE命令的分組格式的圖示；圖5是示出使用AKE命令進行驗證和密鑰交換的操作序列的圖示；圖6是示出用于在源設(shè)備A和宿設(shè)備B之間執(zhí)行根據(jù)DTCP-IP的驗證和密鑰交換(AKE)過程的示例操作序列的圖示；圖7是示出當檢查到攜帶AKE命令的IP分組的TTL字段值沒有超過3時，源設(shè)備執(zhí)行驗證和密鑰交換(AKE)過程的處理過程的流程圖；圖8是示出當檢查到攜帶AKE命令的IP分組的TTL字段值沒有超過3時，宿設(shè)備執(zhí)行驗證和密鑰交換(AKE)過程的處理過程的流程圖；以及圖9是示出由IPv6定義的報頭結(jié)構(gòu)的圖示。具體實施例方式將參考附圖對本發(fā)明的實施例進行詳細描述。本發(fā)明的實施例涉及用于在IP網(wǎng)絡(luò)上傳輸受版權(quán)保護的信息內(nèi)容的信息通信系統(tǒng)，尤其涉及這樣的信息通信系統(tǒng)，其中在遵循DTCP-IP的信息通信設(shè)備之間發(fā)送與接收用于驗證和密鑰交換(AKE)的AKE命令，而且通過驗證和密鑰交換所共享的密鑰用于安全地傳輸加密內(nèi)容。在遵循DTCP-IP的信息通信設(shè)備之間的驗證和密鑰交換中，控制包括在攜帶AKE命令的IP分組的報頭中的TTL字段值，以便其不超過3，并且將在其之間執(zhí)行驗證和密鑰交換的設(shè)備范圍限制為路由器路由段的預(yù)定數(shù)目或者更少。系統(tǒng)配置圖1示意地說明了根據(jù)本發(fā)明實施例的信息通信系統(tǒng)的示例結(jié)構(gòu)。在起接收內(nèi)容請求并且傳輸內(nèi)容的服務(wù)器作用的源設(shè)備、以及起請求內(nèi)容、接收該內(nèi)容、并且重放或者記錄該內(nèi)容的客戶端作用的宿設(shè)備之間執(zhí)行基于DTCP-IP的內(nèi)容傳輸。在所述示例中，作為遵循DTCP-IP的驗證服務(wù)器的源設(shè)備A、和作為遵循DTCP-IP的驗證客戶端的宿設(shè)備A經(jīng)由路由器A和B在網(wǎng)絡(luò)上連接。作為遵循DTCP-IP的驗證服務(wù)器的源設(shè)備B、和作為遵循DTCP-IP的驗證客戶端的宿設(shè)備B也經(jīng)由路由器A和B以及路由器C在IP網(wǎng)絡(luò)上連接?，F(xiàn)有的IP協(xié)議定義了每當轉(zhuǎn)發(fā)IP分組時，IP路由器應(yīng)該將嵌入到IP報頭中的TTL字段值遞減1，并且應(yīng)該丟棄其TTL字段值已經(jīng)過期的IP分組。也就是說，它定義了每個路由器在對IP分組進行路由選擇時，應(yīng)該將IP分組中的TTL字段值遞減1，以及每個路由器在接收到其TTL字段值為0的IP分組時，應(yīng)該丟棄該IP分組。在圖1所示的示例中，當IP分組從源設(shè)備A發(fā)出到宿設(shè)備A時，IP分組通過路由器A和B，而且由宿設(shè)備A接收其TTL字段值已經(jīng)減少了2的IP分組。例如，如果具有TTL字段值為3的IP分組由源設(shè)備A生成并且被發(fā)出到宿設(shè)備B，則該IP分組通過路由器A和B到達路由器C。然而，因為TTL字段值從1減少到0，所以路由器設(shè)備C丟棄該IP分組。因而，該IP分組沒有到達宿設(shè)備B。如果具有TTL字段值為3的IP分組從宿設(shè)備A發(fā)出到源設(shè)備B，則TTL字段值為1的IP分組到達源設(shè)備B。其TTL字段值為0的IP分組不在網(wǎng)絡(luò)上傳播。在根據(jù)這個實施例的信息通信系統(tǒng)中，源設(shè)備A和B、宿設(shè)備A和B、以及路由器A到C的實體構(gòu)成了DTCP-IPAKE系統(tǒng)。根據(jù)DTCP-IP，其中執(zhí)行用于在加密內(nèi)容的傳輸中使用的密鑰交換(即AKE)的范圍被限制為其中TTL字段值不超過3的范圍，即其中路由器路由段的數(shù)目不超過3的范圍。因此，允許源設(shè)備與宿設(shè)備A和B二者執(zhí)行AKE。源設(shè)備B可以與宿設(shè)備A和B二者執(zhí)行AKE。同時，因為用于交換分組的路由器路由段的數(shù)目超過了3，所以不允許經(jīng)由路由器D連接到網(wǎng)絡(luò)的宿設(shè)備與源設(shè)備執(zhí)行AKE。換句話說，宿設(shè)備C在圖1所示的DTCP-IPAKE系統(tǒng)之外。圖2和3分別示意地說明了作為圖1所示的信息通信系統(tǒng)中的客戶端(即，宿設(shè)備)和服務(wù)器(即，源設(shè)備)進行操作的信息通信設(shè)備的功能結(jié)構(gòu)。宿設(shè)備和源設(shè)備可以在諸如互聯(lián)網(wǎng)之類的TCP/IP網(wǎng)絡(luò)(未示出)上建立連接，并且可以通過使用該連接執(zhí)行驗證過程和內(nèi)容傳輸過程。作為宿設(shè)備或者源設(shè)備進行操作的信息通信設(shè)備可以作為專用硬件設(shè)備而設(shè)計和制造，或者可分別通過在諸如個人計算機之類的通用計算機系統(tǒng)上安裝預(yù)定的客戶端應(yīng)用程序和服務(wù)器應(yīng)用程序、并執(zhí)行這些應(yīng)用程序來實現(xiàn)。圖2所示的宿設(shè)備符合DTCP-IP標準，并且作為DTCP_Sink設(shè)備進行操作。所述客戶端設(shè)備具有包括DTCP-IP驗證塊、DTCP-IP內(nèi)容接收塊、和內(nèi)容重放/記錄塊在內(nèi)的功能塊。DTCP-IP驗證塊對應(yīng)于驗證過程執(zhí)行裝置，并且包括AKE塊、消息摘要生成塊、和內(nèi)容解密塊。AKE塊是用于(在DTCP_Sink端)實現(xiàn)DTCP-IP中的AKE機制的塊。AKE塊還具有用于轉(zhuǎn)發(fā)由下述消息摘要生成塊請求的參數(shù)的功能。消息摘要生成塊是用于根據(jù)指定的算法、在參數(shù)中生成消息摘要的塊?？梢詫㈩A(yù)定算法指定為通過其生成消息摘要的算法。預(yù)定算法可以是與諸如MD5或者SHA-1(SHA-1是MD4的改進變體，類似于MD5；但是，SHA-1生成160位的哈希值并具有比MD序列更高的強度)之類的單向哈希函數(shù)相關(guān)聯(lián)的算法。消息摘要生成塊位于AKE塊附近，以便在由AKE塊所保持的參數(shù)中生成消息摘要，其不應(yīng)該被發(fā)布到DTCP-IP驗證塊的外面。消息摘要生成塊可以向AKE塊提交請求以獲得該參數(shù)，并且可以在所獲得的參數(shù)中或者從外面給出的參數(shù)中產(chǎn)生消息摘要。內(nèi)容解密塊是用于使用借助于AKE交換的密鑰，而對從服務(wù)器接收的加密內(nèi)容數(shù)據(jù)進行解密的塊。該解密的內(nèi)容被轉(zhuǎn)發(fā)到內(nèi)容重放/記錄塊。內(nèi)容重放/記錄塊在重放模式中重放轉(zhuǎn)發(fā)的內(nèi)容，或者在記錄模式中存儲該內(nèi)容。DTCP-IP內(nèi)容接收塊是在執(zhí)行AKE之后執(zhí)行內(nèi)容傳輸過程的處理模塊。DTCP-IP內(nèi)容接收塊包括HTTP客戶端塊，并且起HTTP客戶端的作用，以向HTTP服務(wù)器提交內(nèi)容請求，并且響應(yīng)于該請求從HTTP服務(wù)器接收該內(nèi)容。HTTP客戶端塊被分成HTTP請求管理塊和HTTP響應(yīng)管理塊。HTTP請求管理塊進一步被分為HTTP請求傳輸塊和HTTP請求生成塊。HTTP請求生成塊生成要發(fā)送的內(nèi)容傳輸請求(HTTP請求)。所生成的HTTP請求由HTTP請求傳輸塊發(fā)送到服務(wù)器。HTTP響應(yīng)管理塊被分成HTTP響應(yīng)接收塊和HTTP響應(yīng)解釋塊。由HTTP響應(yīng)接收塊接收從服務(wù)器返回的HTTP響應(yīng)和加密的內(nèi)容。所接收的HTTP響應(yīng)由HTTP響應(yīng)解釋塊檢查。如果檢查出是好的，則將所接收的加密內(nèi)容轉(zhuǎn)發(fā)到內(nèi)容解密塊。如果檢查出是壞的，則執(zhí)行用于提供錯誤響應(yīng)的處理。DTCP-IP驗證塊和DTCP-IP內(nèi)容接收塊建立分離的與服務(wù)器設(shè)備的TCP/IP連接，并且分別執(zhí)行驗證過程和內(nèi)容傳輸過程。圖3所示的源設(shè)備符合DTCP-IP標準，并且作為DTCP_Source設(shè)備進行操作。服務(wù)器設(shè)備被提供有包括DTCP-IP驗證塊、DTCP-IP內(nèi)容傳輸塊、和內(nèi)容管理塊在內(nèi)的功能塊。DTCP-IP驗證塊對應(yīng)于驗證過程執(zhí)行裝置，并且包括AKE塊、消息摘要生成塊、和內(nèi)容加密塊。AKE是用于(在DTCP_Source端)實現(xiàn)DTCP-IP中的AKE機制的塊。如下所述，AKE塊還具有用于轉(zhuǎn)發(fā)由消息摘要生成塊請求的參數(shù)的功能。AKE塊保持與已驗證設(shè)備的數(shù)目對應(yīng)數(shù)目的有關(guān)已驗證DTCP_Sink設(shè)備的信息，并且當請求內(nèi)容時，使用該信息來確定請求的客戶端是否是已驗證的客戶端。消息摘要生成塊是用于根據(jù)指定的算法、生成參數(shù)中的消息摘要的塊。利用其生成消息摘要的算法可以是預(yù)定算法，例如與諸如MD5或者SHA-1(和上述相同)之類的單向哈希函數(shù)相關(guān)聯(lián)的算法。消息摘要生成塊位于AKE塊附近，以便在由AKE塊所保持的參數(shù)中生成消息摘要，其不應(yīng)該被發(fā)布到DTCP-IP驗證塊的外面。消息摘要生成塊可以向AKE塊提交請求以獲得該參數(shù)，并且可以在所獲得的參數(shù)中或者從外面給出的參數(shù)中產(chǎn)生消息摘要。內(nèi)容加密塊是用于響應(yīng)于來自DTCP-IP內(nèi)容傳輸塊的請求、使用借助于AKE交換的密鑰、對從內(nèi)容管理塊檢索的內(nèi)容數(shù)據(jù)進行加密的塊。該加密的內(nèi)容被轉(zhuǎn)發(fā)到DTCP-IP內(nèi)容傳輸塊，以便將該內(nèi)容發(fā)送到客戶端。內(nèi)容管理塊是管理要使用DTCP-IP機制保護的內(nèi)容的塊。響應(yīng)于內(nèi)容加密塊的檢索，內(nèi)容管理塊轉(zhuǎn)發(fā)該內(nèi)容數(shù)據(jù)。DTCP-IP內(nèi)容傳輸塊對應(yīng)于內(nèi)容傳輸過程執(zhí)行裝置。DTCP-IP內(nèi)容傳輸塊包括HTTP服務(wù)器塊，并且起接收來自客戶端的請求并且根據(jù)該請求執(zhí)行處理的HTTP服務(wù)器的作用。HTTP服務(wù)器塊被分成HTTP請求管理塊和HTTP響應(yīng)管理塊。HTTP請求管理塊進一步被分為HTTP請求接收塊和HTTP請求解釋塊。HTTP請求接收塊接收來自客戶端的HTTP請求。所接收的HTTP請求被轉(zhuǎn)發(fā)到HTTP請求解釋塊以便檢查該請求。如果由HTTP請求解釋塊檢查出是好的，則向DTCP-IP驗證塊通知該HTTP請求中的信息。HTTP響應(yīng)管理塊被分成HTTP響應(yīng)生成塊和HTTP響應(yīng)傳輸塊。當HTTP請求解釋塊檢查出是好的時，HTTP響應(yīng)生成塊產(chǎn)生用于返回加密內(nèi)容的HTTP響應(yīng)。如果HTTP請求解釋塊檢查出是壞的，則HTTP響應(yīng)生成塊產(chǎn)生用于返回錯誤的HTTP響應(yīng)。HTTP響應(yīng)傳輸塊將所產(chǎn)生的HTTP響應(yīng)發(fā)送到請求客戶端。如果HTTP請求解釋塊檢查出是好的，則HTTP響應(yīng)傳輸塊還發(fā)送HTTP響應(yīng)報頭，該報頭后面跟隨經(jīng)加密的內(nèi)容。DTCP-IP驗證塊和DTCP-IP內(nèi)容傳輸塊建立與宿設(shè)備的分離的TCP/IP連接，并且分別執(zhí)行驗證過程和內(nèi)容傳輸過程。為DTCP宿設(shè)備和DTCP源設(shè)備提供的DTCP-IP驗證塊中的消息摘要生成塊不是由DTCP-IP本身指定的功能模塊，并且不與本發(fā)明的實質(zhì)直接相關(guān)。例如，轉(zhuǎn)讓給本受讓人的日本專利申請第2004-113459號公開了消息摘要生成塊?；贒TCP-IP的內(nèi)容傳輸為了在源設(shè)備和宿設(shè)備之間執(zhí)行基于DTCP-IP的內(nèi)容傳輸，首先，源設(shè)備和宿設(shè)備建立單個TCP/IP連接，在這之后這些設(shè)備通過發(fā)送和接收AKE命令而相互驗證。AKE過程使得由源設(shè)備管理的、用于加密或者解密內(nèi)容的密鑰在源設(shè)備和宿設(shè)備之間共享。AKE命令基本上被設(shè)計成實現(xiàn)作為IEEE1394標準的上層協(xié)議的AV/C一般規(guī)范的子集。圖4說明了AKE命令的分組格式。如圖4所述，AKE命令包括1個字節(jié)的類型(Type)字段、2個字節(jié)的控制字節(jié)長度(BLC)字段、在BLC字段中指定了字節(jié)長度的控制(Control)字段、以及AKE_Info字段。類型、BLC、和控制字段中的字節(jié)0用于將DTCP映射到IP。類型字段指示用于這個AKE命令的分組是版本1的AKE控制分組。Ctype/響應(yīng)(Ctype/response)是其中描述了這個AKE命令的命令類型或者響應(yīng)代碼的字段，并且具有與DTCP規(guī)范的第8章中引用、且由AV/C數(shù)字接口命令指定的那些相同的值。如果不在IP協(xié)議中使用，則除了控制字段中的第7字節(jié)的最高有效位(MSB)之外，控制字段中的字節(jié)1到7與8.3.1部分所規(guī)定的操作數(shù)字節(jié)0到6相同。AKE命令可以被分為稱作子功能的部分。在AKE命令第六字節(jié)處的“子功能(subfunction)”字段中描述了子功能。AKE_Info字段類似于在8.3.1部分中規(guī)定的數(shù)據(jù)字段。應(yīng)該檢查每個控制命令的AKE_label和源套接字以確保它們來自恰當?shù)目刂破?。圖5示出了使用AKE命令執(zhí)行驗證和密鑰交換的操作序列。在該序列中，“請求”用于控制作為目標的設(shè)備，而且“響應(yīng)”用于標識來自已經(jīng)接收了該“請求”的設(shè)備的響應(yīng)。具有命令類型的AKE命令是AKE命令請求，而且具有響應(yīng)代碼的AKE命令是AKE命令響應(yīng)。在DTCP-IP中，應(yīng)當注意到，EXCHANGE_KEY子功能命令是僅僅從源設(shè)備發(fā)出到宿設(shè)備且不在相反方向發(fā)出的AKE命令。AKE狀態(tài)命令從源設(shè)備(或者宿設(shè)備)發(fā)送到宿設(shè)備(或者源設(shè)備)。響應(yīng)于該AKE狀態(tài)命令，從宿設(shè)備(或者源設(shè)備)返回AKE狀態(tài)響應(yīng)。然后，CHALLENGE(口令)子功能從源設(shè)備(或者宿設(shè)備)發(fā)送到宿設(shè)備(或者源設(shè)備)，而且響應(yīng)于該CHALLENGE子功能從宿設(shè)備(或者源設(shè)備)返回響應(yīng)。隨后，RESPONSE(響應(yīng))子功能從源設(shè)備(或者宿設(shè)備)發(fā)送到宿設(shè)備(或者源設(shè)備)，而且響應(yīng)于該RESPONSE子功能從宿設(shè)備(或者源設(shè)備)返回響應(yīng)。然后，EXCHANGE_KEY子功能從源設(shè)備發(fā)送到宿設(shè)備，并且響應(yīng)于該EXCHANGE_KEY子功能從宿設(shè)備返回響應(yīng)。然后，SRM子功能從源設(shè)備發(fā)送到宿設(shè)備，并且響應(yīng)于該SRM子功能從宿設(shè)備返回響應(yīng)。隨后，CONTENT_KEY_REQ子功能從源設(shè)備發(fā)送到宿設(shè)備，并且響應(yīng)于該CONTENT_KEY_REQ子功能從宿設(shè)備返回響應(yīng)。在DTCP-IP中，雖然沒有定義AKE觸發(fā)方法，但是定義了用于觸發(fā)AKE的信息(在下文中也稱為“AKE觸發(fā)信息”)。以以下這樣的形式定義AKE觸發(fā)信息，該形式包括接受AKE的源設(shè)備的IP地址和端口號組。AKE觸發(fā)信息從源設(shè)備轉(zhuǎn)發(fā)到宿設(shè)備，在那之后，基于該AKE觸發(fā)信息建立從宿設(shè)備到源設(shè)備的TCP連接，由此觸發(fā)AKE。從AKE觸發(fā)信息的特性顯然可知，源設(shè)備通常試圖建立到宿設(shè)備的TCP連接。在以下的描述中，假定源設(shè)備在網(wǎng)絡(luò)上將AKE的觸發(fā)脈沖(trigger)傳遞到宿設(shè)備(實際上，使用通用即插即用(UPnP)CDS傳遞該觸發(fā)脈沖)。還假定在AKE觸發(fā)信息從源設(shè)備傳遞到宿設(shè)備之前，源設(shè)備準備好從宿設(shè)備接受AKE。在遵循DTCP的的設(shè)備之間執(zhí)行AKE過程之后，宿設(shè)備請求源設(shè)備提供內(nèi)容。源設(shè)備可以經(jīng)由CDS等預(yù)先向宿設(shè)備通知用于存取源設(shè)備上的內(nèi)容的內(nèi)容位置。宿設(shè)備可以使用諸如HTTP或者RTP之類的協(xié)議來請求該內(nèi)容。例如，源設(shè)備起HTTP服務(wù)器的作用，且宿設(shè)備起HTTP客戶端的作用，在它們之間啟動內(nèi)容的傳輸。在這種情況下，與用于DTCP驗證的TCP/IP連接分離的、用于HTTP的TCP/IP連接由HTTP客戶端創(chuàng)建。HTTP客戶端根據(jù)與正常的HTTP過程類似的操作過程，請求在HTTP服務(wù)器上的內(nèi)容。響應(yīng)于該請求，HTTP服務(wù)器返回所請求的內(nèi)容作為HTTP響應(yīng)。作為HTTP響應(yīng)傳輸?shù)臄?shù)據(jù)是HTTP服務(wù)器(即源設(shè)備)使用通過AKE驗證共享的密鑰加密內(nèi)容而得到的數(shù)據(jù)。當接收到加密數(shù)據(jù)時，客戶端(即宿設(shè)備)使用通過上述驗證共享的密鑰來解密數(shù)據(jù)以重放或者記錄該內(nèi)容。因此，即使在IP網(wǎng)絡(luò)上，DTCP-IP也可以提供安全的內(nèi)容傳輸協(xié)議，其通過在已驗證的設(shè)備之間共享密鑰、并且加密和解密傳輸內(nèi)容，來使得能夠保護內(nèi)容免受傳輸線中的竊聽或者篡改。通過TTL檢查對內(nèi)容傳輸范圍的限制在IP協(xié)議中，定義了當轉(zhuǎn)發(fā)IP分組時，IP路由器應(yīng)該將嵌入在IP報頭中的TTL字段值遞減1，并且不應(yīng)該在網(wǎng)絡(luò)上傳播(應(yīng)該丟棄)其TTL字段值已經(jīng)過期的IP分組。在DTCP-IP中，還定義了當發(fā)送作為AKE命令的IP分組時，將TTL字段值設(shè)置為3或者更少。還定義了當接收作為AKE命令的IP分組時，如果IP分組的TTL字段值超過3，則丟棄該IP分組。這是因為在其之間執(zhí)行AKE命令的發(fā)送和接收(即密鑰交換)的用戶和對方之間的路由器路由段數(shù)目被限制為3或者更少，以便可以將內(nèi)容的使用基本上限制為個人或者家庭使用。雖然現(xiàn)有的IP協(xié)議具有丟棄其TTL字段值由于多個路由器路由段而過期的IP分組的功能，但是不丟棄其TTL字段值超過預(yù)定值的IP分組。因此，開發(fā)了獨特的TCP/IP協(xié)議或者修改了與安裝了TCP/IP的OS內(nèi)核相對應(yīng)的代碼，以便每當接收攜帶AKE命令的IP分組時，DTCP應(yīng)用程序可以檢查TTL字段值，并且可以丟棄其TTL字段值超過預(yù)定值的IP分組，這是耗時的。在這個實施例中，不是每當接收AKE命令時就檢查TTL字段值以便逐個確定是否要丟棄所接收的分組，相反，遵循DTCP-IP的信息通信設(shè)備監(jiān)控在從AKE過程開始到緊靠其結(jié)束之前的時間段內(nèi)接收的IP分組報頭中寫入的TTL字段值，并且連續(xù)地更新最大TTL字段值。緊靠執(zhí)行密鑰交換之前，檢查最大TTL字段值是否沒有超過3。如果該最大值超過3，則DTCP-IP應(yīng)用程序結(jié)束后續(xù)的密鑰交換處理。例如，DTCP-IP應(yīng)用程序可以使用諸如libpcap之類的庫來監(jiān)控AKE命令，以獲得IP報頭中的TTL字段值。因此，不需要諸如特別開發(fā)TCP/IP協(xié)議層或者修改OS之類的操作。Libpcap是用于Linux的庫，并且例如可參考http://www.tcpdump.org/。圖6說明了用于在源設(shè)備A和宿設(shè)備B之間執(zhí)行根據(jù)DTCP-IP的驗證和密鑰交換(AKE)過程的示例操作序列。在所述示例中，在源設(shè)備A和宿設(shè)備B之間的路由器路由段的數(shù)目被設(shè)置為3或者更少，而且每個設(shè)備發(fā)送其TTL字段值被設(shè)置為3的AKE命令，以便該AKE命令到達另一個設(shè)備而沒有在傳輸中被丟棄，借此可以成功地執(zhí)行該過程。假定源設(shè)備A在網(wǎng)絡(luò)上將AKE的觸發(fā)脈沖傳遞到宿設(shè)備B，而且在將AKE觸發(fā)信息從源設(shè)備A傳遞到宿設(shè)備B之前，源設(shè)備A準備好從宿設(shè)備B接受AKE。源設(shè)備A切換到這樣的模式，其中它可以在AKE觸發(fā)信息中指定的端口號處接收TCP連接建立請求。具體而言，源設(shè)備A創(chuàng)建套接字對象以執(zhí)行bind(綁定)()方法和listen(收聽)()方法，并且切換到其中它等待來自宿設(shè)備B的connect(連接)()請求的模式。隨后，源設(shè)備A將AKE觸發(fā)信息傳遞到宿設(shè)備B。當接收到該AKE觸發(fā)信息時，宿設(shè)備B準備TCP連接的建立，并且激活用于檢查IP分組中的TTL字段值的處理。具體而言，宿設(shè)備B創(chuàng)建套接字對象，并且激活與該套接字相關(guān)聯(lián)的TTL字段值檢查處理。然后，宿設(shè)備B使用在AKE觸發(fā)信息中指定的IP地址和端口號來向源設(shè)備A發(fā)布TCP連接建立請求。具體而言，宿設(shè)備B執(zhí)行connect(連接)()方法。當從宿設(shè)備B接收到TCP連接建立請求時，源設(shè)備A建立TCP連接，并且激活用于檢查IP分組中的TTL字段值的處理，以進入其中源設(shè)備A可以執(zhí)行與宿設(shè)備B的TCP/IP通信的模式。具體而言，源設(shè)備A執(zhí)行accept(接受)()方法來獲得套接字對象，并且激活與該套接字相關(guān)聯(lián)的TTL字段值檢查處理，以進入其中源設(shè)備A可以通過recv()/send()方法向和從宿設(shè)備B發(fā)送與接收字節(jié)數(shù)據(jù)的模式。因此，宿設(shè)備B切換到其中它可以執(zhí)行與源設(shè)備A的TCP/IP通信的模式。具體而言，宿設(shè)備B切換到這樣的模式，其中它可以相對于當源設(shè)備A切換到其中它可以接收TCP連接建立請求的模式時創(chuàng)建的套接字對象、通過recv()/send()方法向和從源設(shè)備A發(fā)送與接收字節(jié)數(shù)據(jù)。對于從這點到緊靠借助于AKE的驗證和密鑰交換過程結(jié)束之前的時間段，源設(shè)備A和宿設(shè)備B發(fā)送與接收由DTCP-IPAKE規(guī)定的AKE命令。直到緊靠AKE結(jié)束之前為止的時間段對應(yīng)于直到源設(shè)備A準備發(fā)送EXCHANGE_KEY子功能命令為止的時間段，并且對應(yīng)于直到宿設(shè)備B接收EXCHANGE_KEY子功能命令為止的時間段。也就是說，每個源設(shè)備A和宿設(shè)備B及時地對所接收的AKE命令執(zhí)行處理，以便從攜帶AKE命令的IP分組的報頭中獲得TTL字段值，并且將所獲得的TTL字段值與存儲在其中的最大TTL字段值(以下簡稱為“所存儲的最大TTL字段值”)進行比較。如果所接收AKE命令的TTL字段值更大，則將所存儲的最大TTL字段值更新為該值。如果所存儲的最大TTL字段值更大，則不進行任何動作。每當接收到AKE命令時，源設(shè)備A和宿設(shè)備B中的每一個都重復(fù)執(zhí)行上述處理。緊靠發(fā)送EXCHANGE_KEY子功能命令之前，源設(shè)備A檢查所存儲的最大TTL字段值是否沒有超過3。如果所存儲的最大TTL字段值超過3，這意指從該連接的另一端的宿設(shè)備接收的至少一些AKE命令的TTL字段值超過3，也就是說，宿設(shè)備位于路由器路由段的數(shù)目超過3的位置處。因此，為了滿足其中TTL字段值被設(shè)置為3或者更少、且丟棄其TTL字段值超過3的IP分組的DTCP-IP規(guī)范，根據(jù)這個實施例，源設(shè)備A不發(fā)送EXCHANGE_KEY子功能命令，并且由于驗證失敗而結(jié)束AKE過程。因此，與宿設(shè)備B的驗證沒有成功地完成，而且不共享用于加密和解密傳輸內(nèi)容的密鑰，由此實現(xiàn)了與當丟棄任何接收的AKE命令時的那些優(yōu)點類似的優(yōu)點。用于向宿設(shè)備B通知驗證失敗的方法包括“斷開建立的TCP連接”的方法以及“將AKE_CANCEL子功能命令傳輸?shù)剿拊O(shè)備B”的方法。被通知的宿設(shè)備B不激活攜帶AKE命令的IP分組的重新傳輸過程。如果所存儲的最大TTL字段值沒有超過3，這意指從該連接的另一端的宿設(shè)備B接收的任何AKE命令的TTL字段值都沒有超過3，也就是說，宿設(shè)備B位于其中路由器路由段的數(shù)目為3或者更少的位置處。在這種情況下，沒有違反其中TTL字段值被設(shè)置為3或者更少的DTCP-IP規(guī)則，而且源設(shè)備A發(fā)送EXCHANGE_KEY子功能命令以繼續(xù)后續(xù)的處理。同樣，緊靠接收了EXCHANGE_KEY子功能命令之后，宿設(shè)備B檢查所存儲的最大TTL字段值是否沒有超過3。如果所存儲的最大TTL字段值超過3，這意指從該連接的另一端的源設(shè)備接收的至少一些AKE命令的TTL字段值超過3，這違反了DTCP-IP規(guī)則。因此，丟棄其TTL字段值超過3的IP分組。在這個實施例中，宿設(shè)備B發(fā)送拒絕(REJECTED)響應(yīng)，并且結(jié)束該AKE過程。做為選擇，宿設(shè)備B可以直接執(zhí)行諸如斷開TCP連接之類的處理，而不用發(fā)送拒絕(REJECTED)響應(yīng)。因此，與源設(shè)備A的驗證沒有成功地完成，而且不共享用于加密和解密傳輸內(nèi)容的密鑰，由此實現(xiàn)了與當丟棄任何接收的AKE命令時的那些優(yōu)點類似的優(yōu)點。如果所存儲的最大TTL字段值沒有超過3，這意指從該連接的另一端的源設(shè)備A接收的任何AKE命令的TTL字段值都沒有超過3，也就是說，源設(shè)備A位于其中路由器路由段的數(shù)目為3或者更少的位置處。在這種情況下，沒有違反其中TTL字段值被設(shè)置為3或者更少的DTCP-IP規(guī)則，而且宿設(shè)備B響應(yīng)于該EXCHANGE_KEY子功能命令發(fā)送接受(ACCEPTED)響應(yīng)，并且繼續(xù)后續(xù)處理。為了在發(fā)送和接收AKE命令的時間段內(nèi)監(jiān)控TTL字段值，不是監(jiān)控IP分組以連續(xù)地獲得TTL字段值、并且僅僅存儲最大TTL字段值，而是可以存儲和檢查在該時間段上接收的所有IP分組的TTL字段值。圖7是示出當檢查到攜帶AKE命令的IP分組的TTL字段值沒有超過3時，由源設(shè)備執(zhí)行驗證和密鑰交換(AKE)過程的處理過程的流程圖。假定在AKE觸發(fā)信息從源設(shè)備傳遞到宿設(shè)備之前，源設(shè)備準備好從宿設(shè)備接受AKE。源設(shè)備A切換到這樣的模式，其中它可以在AKE觸發(fā)信息中指定的端口號處接收TCP連接建立請求(步驟S1)。具體而言，源設(shè)備創(chuàng)建套接字對象以執(zhí)行bind()方法和listen()方法，并且切換到其中它等待來自宿設(shè)備的connect()請求的模式。然后，源設(shè)備使用UPnPCDS等將AKE觸發(fā)信息傳遞到宿設(shè)備(步驟S2)。當從宿設(shè)備接收到TCP連接建立請求時(步驟S3)，源設(shè)備建立TCP連接(步驟S4)。然后，源設(shè)備激活檢查IP分組中的TTL字段值的處理(步驟S5)，并且進入其中它可以執(zhí)行與宿設(shè)備的TCP/IP通信的模式。具體而言，源設(shè)備執(zhí)行accept()方法來獲得套接字對象，并且激活與該套接字相關(guān)聯(lián)的TTL字段值檢查處理，以進入其中它可以通過recv()/send()方法向和從宿設(shè)備發(fā)送與接收字節(jié)數(shù)據(jù)的模式。在這時候，初始值0被代替為所存儲的最大TTL字段值(步驟S6)。因此，宿設(shè)備切換到其中它可以執(zhí)行與源設(shè)備的TCP/IP通信的模式。具體而言，宿設(shè)備切換到這樣的模式，其中它可以相對于當源設(shè)備切換到其中它可以接收TCP連接建立請求的模式時創(chuàng)建的套接字對象、通過recv()/send()方法向和從源設(shè)備發(fā)送與接收字節(jié)數(shù)據(jù)。對于從這點到緊靠借助于AKE的驗證和密鑰交換過程結(jié)束之前的時間段，或者直到源設(shè)備準備好發(fā)送EXCHANGE_KEY子功能命令為止的時間段，源設(shè)備重復(fù)地執(zhí)行步驟S7到S11的處理以發(fā)送與接收由DTCP-IPAKE規(guī)定的AKE命令。也就是說，當接收到AKE命令(步驟S8)時，源設(shè)備及時對該AKE命令執(zhí)行處理(步驟S7)以從攜帶AKE命令的IP分組的報頭中獲得TTL字段值(步驟S9)，并且將所獲得的TTL字段值與存儲在其中的最大TTL字段值進行比較(以下簡稱為“所存儲的最大TTL字段值”)(步驟S10)。如果所接收AKE命令的TTL字段值更大，則將所存儲的最大TTL字段值更新為該值(步驟S11)。每當接收到AKE命令時，源設(shè)備重復(fù)執(zhí)行上述處理。當源設(shè)備準備好傳輸EXCHANGE_KEY子功能命令時，源設(shè)備檢查所存儲的最大TTL字段值是否沒有超過3(步驟S12)。如果所存儲的最大TTL字段值沒有超過3，這意指從該連接的另一端的宿設(shè)備接收的任何AKE命令的TTL字段值都沒有超過3，也就是說，宿設(shè)備B位于其中路由器路由段的數(shù)目為3或者更少的位置處。在這種情況下，沒有違反其中TTL字段值被設(shè)置為3或者更少的DTCP-IP規(guī)則，而且源設(shè)備發(fā)送EXCHANGE_KEY子功能命令(步驟S13)，并且繼續(xù)后續(xù)的DTCP-IPAKE處理(步驟S14)。然后，結(jié)束該處理例程。如果直到源設(shè)備準備好發(fā)送EXCHANGE_KEY子功能命令為止時、在該處理過程中所存儲的最大TTL字段值超過3(步驟S12)，這意指從該連接的另一端處的宿設(shè)備接收的至少一些AKE命令的TTL字段值超過3，這違反了DTCP-IP規(guī)則，并且丟棄其TTL字段值超過3的IP分組。源設(shè)備不發(fā)送EXCHANGE_KEY子功能命令，并且由于驗證失敗而結(jié)束該AKE過程(步驟S15)。具體而言，源設(shè)備斷開建立的TCP連接，或者將AKE_CANCEL子功能命令傳輸?shù)剿拊O(shè)備。然后，結(jié)束該處理例程。因此，與宿設(shè)備的驗證沒有成功地完成，而且不共享用于加密和解密傳輸內(nèi)容的密鑰，由此實現(xiàn)了與當丟棄任何接收的AKE命令時的那些優(yōu)點類似的優(yōu)點。圖8是示出當檢查到攜帶AKE命令的IP分組的TTL字段值沒有超過3時，由宿設(shè)備執(zhí)行驗證和密鑰交換(AKE)過程的處理過程的流程圖。假定在AKE觸發(fā)信息從源設(shè)備傳遞到宿設(shè)備之前，源設(shè)備準備好從宿設(shè)備接受AKE。首先，當使用UPnPCDS等從源設(shè)備接收AKE觸發(fā)信息時(步驟S21)，宿設(shè)備準備TCP連接的建立(步驟S22)。然后，宿設(shè)備激活用于檢查IP分組中的TTL字段值的處理(步驟S23)。具體而言，宿設(shè)備創(chuàng)建套接字對象，并且激活與該套接字相關(guān)聯(lián)的TTL字段值檢查處理。在這時候，初始值0被代替為所存儲的最大TTL字段值(步驟S24)。然后，宿設(shè)備使用在AKE觸發(fā)信息中指定的IP地址和端口號來向源設(shè)備發(fā)布TCP連接建立請求(步驟S25)。具體而言，宿設(shè)備執(zhí)行connect()方法。因此，宿設(shè)備切換到其中它可以執(zhí)行與源設(shè)備的TCP/IP通信的模式。具體而言，宿設(shè)備切換到這樣的模式，其中它可以相對于當源設(shè)備切換到其中它可以接收TCP連接建立請求的模式時創(chuàng)建的套接字對象、通過recv()/send()方法向和從源設(shè)備發(fā)送與接收字節(jié)數(shù)據(jù)。對于從這點到緊靠借助于AKE的驗證和密鑰交換過程結(jié)束之前的時間段、或者直到宿設(shè)備接收了EXCHANGE_KEY子功能命令為止的時間段，宿設(shè)備重復(fù)執(zhí)行步驟S27到S31的處理以發(fā)送與接收由DTCP-IPAKE規(guī)定的AKE命令。也就是說，當接收到AKE命令(步驟S28)時，宿設(shè)備及時對該AKE命令執(zhí)行處理(步驟S27)，以從攜帶AKE命令的IP分組的報頭中獲得TTL字段值(步驟S29)，并且將所獲得的TTL字段值與存儲在其中的最大TTL字段值進行比較(以下簡稱為“所存儲的最大TTL字段值”)(步驟S30)。如果所接收AKE命令的TTL字段值較大，則將所存儲的最大TTL字段值更新為該值(步驟S31)。每當接收到AKE命令時，宿設(shè)備重復(fù)執(zhí)行上述處理。緊靠接收了EXCHANGE_KEY子功能命令之后，宿設(shè)備檢查所存儲的最大TTL字段值是否沒有超過3(步驟S32)。如果所存儲的最大TTL字段值沒有超過3，這意指從該連接的另一端的源設(shè)備接收的任何AKE命令的TTL字段值都沒有超過3，也就是說，源設(shè)備位于其中路由器路由段的數(shù)目為3或者更少的位置處。在這種情況下，沒有違反其中TTL字段值被設(shè)置為3或者更少的DTCP-IP規(guī)則，而且宿設(shè)備響應(yīng)于EXCHANGE_KEY子功能命令而發(fā)送接受(ACCEPTED)響應(yīng)(步驟S33)，并且繼續(xù)后續(xù)DTCP-IPAKE處理(步驟S34)。然后，結(jié)束該處理例程。如果直到宿設(shè)備接收了EXCHANGE_KEY子功能命令為止時、在該處理過程中所存儲的最大TTL字段值超過3(步驟S32)，這意指從該連接的另一端處的源設(shè)備接收的至少一些AKE命令的TTL字段值超過3，這違反了DTCP-IP規(guī)則，并且丟棄其TTL字段值超過3的IP分組。因此，宿設(shè)備結(jié)束該AKE過程(步驟S35)。具體而言，宿設(shè)備執(zhí)行諸如傳輸拒絕(REJECTED)響應(yīng)或者直接斷開TCP連接而沒有傳輸拒絕(REJECTED)響應(yīng)之類的處理。因此，與源設(shè)備的驗證沒有成功地完成，而且不共享用于加密和解密傳輸內(nèi)容的密鑰，由此實現(xiàn)了與當丟棄任何接收的AKE命令時的那些優(yōu)點類似的優(yōu)點。已經(jīng)在特定實施例的上下文中詳細描述了本發(fā)明。然而，應(yīng)當理解，可以由本領(lǐng)域技術(shù)人員對實施例進行修改或者替換，而沒有背離本發(fā)明的范圍。雖然已經(jīng)通過舉例描述了其中在遵循DTCP-IP的信息通信設(shè)備之間發(fā)送和接收用于驗證和密鑰交換(AKE)的AKE命令的實施例，但是本發(fā)明不局限于這個實施例。其中受版權(quán)保護的信息內(nèi)容在IP網(wǎng)絡(luò)上傳輸?shù)娜魏纹渌畔⑼ㄐ畔到y(tǒng)，或者其中通過使用寫入到IP分組的報頭中的TTL字段值來限制路由器路由段的數(shù)目、以將可以在其間傳遞信息的各方的范圍限制為預(yù)定范圍的任何其它信息通信系統(tǒng)，都屬于本發(fā)明的范圍。雖然此處使用了由IPv4規(guī)定的IP報頭中的TTL字段來限制路由器路由段的數(shù)目，但是本發(fā)明不限于此，而且可以使用分組中的描述路由器路由段數(shù)目的其它控制信息。除TTL字段之外，還可以使用由IPv6規(guī)定的IP報頭中的路由段限制(HopLimit)字段值(例如，參見RFC2460，InternetProtocol，版本6(IPv6)規(guī)范)。為了便于參考，圖9中說明了由IPv6規(guī)定的報頭結(jié)構(gòu)。路由段限制字段包含8位無符號整數(shù)，并且每當IP分組在一個節(jié)點處傳輸時遞減1。在這個節(jié)點丟棄其路由段限制值已經(jīng)過期的IP分組。(IPv6的路由段限制字段具有與用于IPv4的TTL字段基本上相同的功能。但是IPv6的路由段限制字段僅僅可以指定可以通過其傳遞在節(jié)點之間傳送的分組的路由段的最大數(shù)目，并且沒有指定時間，IPv4的TTL字段不僅可以指定路由段數(shù)目，而且還可以指定秒數(shù)。)概括而言，已經(jīng)通過示范實施例公開了本發(fā)明，而且不應(yīng)該限制性地解釋此處公開的內(nèi)容。本發(fā)明的范圍應(yīng)該考慮所附權(quán)利要求而確定。本領(lǐng)域技術(shù)人員應(yīng)當理解在所附權(quán)利要求或其等效的范圍之內(nèi)，取決于設(shè)計要求及其他因素，可以出現(xiàn)各種修改、組合、子組合以及改變。權(quán)利要求1.一種信息通信系統(tǒng)，包含信息通信設(shè)備，在IP網(wǎng)絡(luò)上交換IP分組；其中，當執(zhí)行其中路由器路由段的數(shù)目被限制為預(yù)定控制值或者更少的預(yù)定分組交換過程時，每一信息通信設(shè)備監(jiān)控在從該預(yù)定分組交換過程開始到緊靠該預(yù)定分組交換過程結(jié)束之前的時間段內(nèi)接收的IP分組的報頭中指定的生存時間值，以連續(xù)地更新所監(jiān)控的生存時間值的最大生存時間值，并且檢查最大的生存時間值是否沒有超過該控制值。2.如權(quán)利要求1所述的信息通信系統(tǒng)，其中每個信息通信設(shè)備都在緊靠該預(yù)定分組交換過程結(jié)束之前，檢查最大的生存時間值是否沒有超過該控制值；當該最大生存時間值等于或者小于控制值時，每個信息通信設(shè)備執(zhí)行后續(xù)分組發(fā)送和接收處理，以完成該預(yù)定分組交換過程；以及當該最大生存時間值超過控制值時，每個信息通信設(shè)備結(jié)束該預(yù)定分組交換過程，而不用執(zhí)行后續(xù)的分組發(fā)送和接收處理。3.如權(quán)利要求1所述的信息通信系統(tǒng)，其中該預(yù)定分組交換過程包含根據(jù)DTCP-IP的驗證和密鑰交換過程；以及每個信息通信設(shè)備監(jiān)控在攜帶驗證和密鑰交換命令的IP分組的報頭中的生存時間值。4.如權(quán)利要求3所述的信息通信系統(tǒng)，其中該信息通信設(shè)備包括源設(shè)備和宿設(shè)備；當源設(shè)備根據(jù)DTCP-IP將內(nèi)容分發(fā)到宿設(shè)備時，該源設(shè)備從緊靠建立了用于發(fā)送和接收驗證和密鑰交換命令的TCP連接之后，監(jiān)控在該TCP連接上發(fā)送和接收的IP分組，以獲得該IP分組的生存時間值，從而連續(xù)地更新所獲得的生存時間值中的最大生存時間值，并且緊靠發(fā)送Exchange_Key子功能命令之前，檢查該最大生存時間值是否等于或者小于控制值；當該最大生存時間值等于或者小于控制值時，源設(shè)備繼續(xù)發(fā)送該Exchange_Key子功能命令；以及當最大生存時間值超過控制值時，源設(shè)備結(jié)束該驗證和密鑰交換過程，而沒有發(fā)送Exchange_Key子功能命令。5.如權(quán)利要求3所述的信息通信系統(tǒng)，其中該信息通信設(shè)備包括源設(shè)備和宿設(shè)備；當宿設(shè)備根據(jù)DTCP-IP從源設(shè)備獲得內(nèi)容時，宿設(shè)備從緊靠建立了用于發(fā)送和接收驗證和密鑰交換命令的TCP連接之前，監(jiān)控在該TCP連接上發(fā)送和接收的IP分組，以獲得該IP分組的生存時間值，從而連續(xù)地更新所獲得的生存時間值中的最大生存時間值，并且緊靠接收了Exchange_Key子功能命令之后，檢查該最大生存時間值是否等于或者小于控制值；當該最大生存時間值等于或者小于控制值時，宿設(shè)備響應(yīng)于該Exchange_Key子功能命令而繼續(xù)發(fā)送接受響應(yīng)；以及當該最大生存時間值超過控制值時，宿設(shè)備立即結(jié)束該驗證和密鑰交換過程。6.一種在IP網(wǎng)絡(luò)上與第二信息通信設(shè)備交換IP分組的信息通信設(shè)備，該信息通信設(shè)備包含IP報頭監(jiān)控裝置，用于當執(zhí)行其中路由器路由段的數(shù)目限制為預(yù)定控制值或者更少的預(yù)定分組交換過程時，監(jiān)控在從該預(yù)定分組交換過程開始到緊靠該預(yù)定分組交換過程結(jié)束之前的監(jiān)控時間內(nèi)所接收的IP分組的報頭中指定的生存時間值；最大生存時間值存儲裝置，用于在該監(jiān)控時間期間，在連續(xù)更新的同時，存儲所監(jiān)控的生存時間值中的最大生存時間值；以及生存時間值檢查裝置，用于檢查最大生存時間值是否沒有超過該控制值。7.如權(quán)利要求6所述的信息通信設(shè)備，還包含分組交換過程控制裝置，用于當生存時間值檢查裝置確定最大生存時間值等于或者小于控制值時，執(zhí)行后續(xù)的分組發(fā)送和接收處理，以完成預(yù)定分組交換過程，以及當生存時間值檢查裝置確定最大生存時間值超過控制值時，結(jié)束該預(yù)定分組交換過程而不用執(zhí)行后續(xù)分組發(fā)送和接收處理。8.如權(quán)利要求7所述的信息通信設(shè)備，其中該預(yù)定分組交換過程包含根據(jù)DTCP-IP的驗證和密鑰交換過程；以及IP報頭監(jiān)控裝置監(jiān)控在攜帶驗證和密鑰交換命令的IP分組的報頭中的生存時間值。9.如權(quán)利要求8所述的信息通信設(shè)備，其中該信息通信設(shè)備是源設(shè)備，而該第二信息通信設(shè)備是宿設(shè)備；當該信息通信設(shè)備根據(jù)DTCP-IP將內(nèi)容分發(fā)給第二信息通信設(shè)備時，IP報頭監(jiān)控裝置從緊靠用于發(fā)送和接收驗證和密鑰交換命令的TCP連接建立之后，監(jiān)控在該TCP連接上發(fā)送和接收的IP分組，以獲得該IP分組的生存時間值；該最大生存時間值存儲裝置連續(xù)更新所獲得的生存時間值中的最大生存時間值；該生存時間值檢查裝置在緊靠發(fā)送Exchange_Key子功能命令之前，檢查該最大生存時間值是否等于或者小于控制值；以及當該最大生存時間值等于或者小于控制值時，該分組交換過程控制裝置繼續(xù)發(fā)送Exchange_Key子功能命令，并且當該最大生存時間值超過控制值時，結(jié)束該驗證和密鑰交換過程，而沒有發(fā)送Exchange_Key子功能命令。10.如權(quán)利要求8所述的信息通信設(shè)備，其中該信息通信設(shè)備是宿設(shè)備，而該第二信息通信設(shè)備是源設(shè)備；當該信息通信設(shè)備根據(jù)DTCP-IP從第二信息通信設(shè)備獲得內(nèi)容時，該IP報頭監(jiān)控裝置從緊靠用于發(fā)送和接收驗證和密鑰交換命令的TCP連接建立之前開始，監(jiān)控在TCP連接上發(fā)送和接收的IP分組，以獲得該IP分組的生存時間值；該最大生存時間值存儲裝置連續(xù)更新所獲得的生存時間值中的最大生存時間值；該生存時間值檢查裝置在緊靠接收了Exchange_Key子功能命令之后，檢查該最大生存時間值是否等于或者小于控制值；以及當該最大生存時間值等于或者小于控制值時，該分組交換過程控制裝置響應(yīng)于該Exchange_Key子功能命令而發(fā)送接受響應(yīng)，并且當該最大生存時間值超過控制值時，立即結(jié)束該驗證和密鑰交換過程。11.一種用于由信息通信設(shè)備在IP網(wǎng)絡(luò)上與第二信息通信設(shè)備交換IP分組的信息通信方法，該信息通信方法包含步驟當執(zhí)行其中路由器路由段的數(shù)目被限制為預(yù)定控制值或者更少的預(yù)定分組交換過程時，監(jiān)控在從該預(yù)定分組交換過程開始到緊靠該預(yù)定分組交換過程結(jié)束之前的監(jiān)控時間內(nèi)所接收的IP分組的報頭中指定的生存時間值；在該監(jiān)控時間期間，在連續(xù)更新的同時，存儲所監(jiān)控生存時間值中的最大生存時間值；檢查該最大生存時間值是否沒有超過控制值；當從預(yù)定信息交換過程開始到緊靠該預(yù)定信息交換過程結(jié)束之前的時間段內(nèi)所監(jiān)控的分組中提取的生存時間值中的最大生存時間值等于或者小于控制值時，通過執(zhí)行后續(xù)的分組發(fā)送和接收處理來繼續(xù)該預(yù)定分組交換過程，從而完成該預(yù)定分組交換過程；以及當從預(yù)定分組交換過程開始到緊靠預(yù)定分組交換過程結(jié)束之前的時間段內(nèi)所監(jiān)控的分組中提取的生存時間值中的最大生存時間值超過控制值時，結(jié)束該預(yù)定分組交換過程，而不用執(zhí)行后續(xù)分組發(fā)送和接收處理。12.如權(quán)利要求11所述的信息通信方法，其中該信息通信設(shè)備是源設(shè)備，而該第二信息通信設(shè)備是宿設(shè)備；當根據(jù)DTCP-IP將內(nèi)容分發(fā)給第二信息通信設(shè)備時，在監(jiān)控步驟中，從緊靠用于發(fā)送和接收驗證和密鑰交換命令的TCP連接建立之后開始，監(jiān)控在該TCP連接上發(fā)送和接收的IP分組，以獲得這些IP分組的生存時間值；在存儲步驟中，連續(xù)更新所獲得的生存時間值中的最大生存時間值；在檢查步驟中，緊靠發(fā)送Exchange_Key子功能命令之前，檢查該最大生存時間值是否等于或者小于控制值；在繼續(xù)步驟中，當該最大生存時間值等于或者小于控制值時，發(fā)送Exchange_Key子功能命令；以及在結(jié)束步驟中，當該最大生存時間值超過控制值時，結(jié)束預(yù)定分組交換過程，而不用發(fā)送Exchange_Key子功能命令。13.如權(quán)利要求11所述的信息通信方法，其中該信息通信設(shè)備是宿設(shè)備，而該第二信息通信設(shè)備是源設(shè)備；當根據(jù)DTCP-IP從第二信息通信設(shè)備獲得內(nèi)容時，在監(jiān)控步驟中，從緊靠用于發(fā)送和接收驗證和密鑰交換命令的TCP連接建立之前開始，監(jiān)控在該TCP連接上發(fā)送和接收的IP分組，以獲得這些IP分組的生存時間值；在存儲步驟中，連續(xù)更新所獲得的生存時間值中的最大生存時間值；在檢查步驟中，緊靠接收了Exchange_Key子功能命令之后，檢查該最大生存時間值是否等于或者小于控制值；在繼續(xù)步驟中，當該最大生存時間值等于或者小于控制值時，響應(yīng)于該Exchange_Key子功能命令而發(fā)送接受響應(yīng)；以及在結(jié)束步驟中，當該最大生存時間值超過控制值時，立即結(jié)束該預(yù)定分組交換過程。14.一種計算機可讀計算機程序，用于在計算機系統(tǒng)上執(zhí)行用于在IP網(wǎng)絡(luò)上與另一信息通信設(shè)備交換IP分組的處理，該計算機程序?qū)е略撚嬎銠C系統(tǒng)執(zhí)行步驟當執(zhí)行其中路由器路由段的數(shù)目被限制為預(yù)定控制值或者更少的預(yù)定分組交換過程時，監(jiān)控在從該預(yù)定分組交換過程開始到緊靠該預(yù)定分組交換過程結(jié)束之前的監(jiān)控時間內(nèi)所接收的IP分組的報頭中指定的生存時間值；在該監(jiān)控時間期間，在連續(xù)更新的同時，存儲所監(jiān)控生存時間值中的最大生存時間值；檢查該最大生存時間值是否沒有超過控制值；當從預(yù)定信息交換過程開始到緊靠該預(yù)定信息交換過程結(jié)束之前的時間段內(nèi)所監(jiān)控的分組中提取的生存時間值中的最大生存時間值等于或者小于控制值時，通過執(zhí)行后續(xù)的分組發(fā)送和接收處理，來繼續(xù)該預(yù)定分組交換過程，從而完成該預(yù)定分組交換過程；以及當從預(yù)定分組交換過程開始到緊靠預(yù)定分組交換過程結(jié)束之前的時間段內(nèi)所監(jiān)控的分組中提取的生存時間值中的最大生存時間值超過控制值時，結(jié)束該預(yù)定分組交換過程，而不用執(zhí)行后續(xù)分組發(fā)送和接收處理。15.一種在IP網(wǎng)絡(luò)上與第二信息通信設(shè)備交換IP分組的信息通信設(shè)備，該信息通信設(shè)備包含IP報頭監(jiān)控單元，當執(zhí)行其中路由器路由段的數(shù)目被限制為預(yù)定控制值或者更少的預(yù)定分組交換過程時，監(jiān)控在從該預(yù)定分組交換過程開始到緊靠該預(yù)定分組交換過程結(jié)束之前的監(jiān)控時間內(nèi)所接收的IP分組的報頭中指定的生存時間值；最大生存時間值存儲單元，用于在該監(jiān)控時間期間，在連續(xù)更新的同時，存儲所監(jiān)控的生存時間值中的最大生存時間值；以及生存時間值檢查單元，用于檢查最大生存時間值是否沒有超過該控制值。全文摘要在信息通信系統(tǒng)中，信息通信設(shè)備在IP網(wǎng)絡(luò)上交換IP分組。當執(zhí)行其中路由器路由段的數(shù)目被限制為預(yù)定控制值或者更少的預(yù)定分組交換過程時，每個信息通信設(shè)備監(jiān)控在從該預(yù)定分組交換過程開始到緊靠該預(yù)定分組交換過程結(jié)束之前的時間段內(nèi)所接收的IP分組的報頭中指定的生存時間值，以連續(xù)地更新所監(jiān)控的生存時間值中的最大生存時間值，并且檢查該最大生存時間值是否沒有超過該控制值。文檔編號H04L29/06GK1901512SQ20061010801公開日2007年1月24日申請日期2006年7月24日優(yōu)先權(quán)日2005年7月22日發(fā)明者河野真一,森田隆雄,青木幸彥,五味秀穗,油川達昭,泉佑市申請人:索尼株式會社