專利名稱：數(shù)據(jù)獲取方法和終端的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通過網(wǎng)絡(luò)獲取數(shù)據(jù)的數(shù)據(jù)獲取方法，以及用這種方法獲取數(shù)據(jù)的終端。
背景技術(shù)：
由于通信網(wǎng)絡(luò)的新近發(fā)展，通過諸如因特網(wǎng)的網(wǎng)絡(luò)獲取(下載)數(shù)據(jù)被廣泛采用。通過諸如因特網(wǎng)的網(wǎng)絡(luò)獲取的數(shù)據(jù)通常被存儲到諸如硬盤的固定存儲器中。即使在CPU(中央處理單元)和RAM(隨機(jī)存取存儲器)被通過把終端電源關(guān)閉一次再打開來重啟終端或復(fù)位終端而初始化后，存儲于固定存儲器中的數(shù)據(jù)也能夠通過從存儲數(shù)據(jù)的固定存儲器中讀出數(shù)據(jù)而再次被訪問。
另外，當(dāng)通過諸如因特網(wǎng)的網(wǎng)絡(luò)獲取數(shù)據(jù)時，獲取的數(shù)據(jù)甚至可以被存儲于諸如RAM的臨時存儲器中。一個這樣的數(shù)據(jù)實(shí)例是Java applet(java小應(yīng)用程序)。Java applet是用Java生產(chǎn)的程序(java應(yīng)用)。Java applet通過諸如因特網(wǎng)的網(wǎng)絡(luò)獲取，并存儲于終端的臨時存儲器中。終端中獲取的Java applet通過瀏覽以HTML(超文本標(biāo)記語言)寫的網(wǎng)頁的瀏覽器和Java虛擬機(jī)來使用。如上所述，當(dāng)終端被重啟時，RAM的臨時存儲器被初始化，而存儲于臨時存儲器中的數(shù)據(jù)被去除。當(dāng)通過諸如因特網(wǎng)的網(wǎng)絡(luò)獲取的數(shù)據(jù)被存儲到臨時存儲器中時，它將不能再被使用，除非在終端被重啟以后，數(shù)據(jù)再次通過諸如因特網(wǎng)的網(wǎng)絡(luò)被獲取才行。
與Java applet不同，有許多Java應(yīng)用在從諸如因特網(wǎng)的網(wǎng)絡(luò)上獲取后，被存儲于固定存儲器中，并且甚至在終端被重啟后，也不需要再次從諸如因特網(wǎng)的網(wǎng)絡(luò)上獲取。也有存儲于終端的固定存儲器中的Java應(yīng)用，它們不需要從網(wǎng)絡(luò)上獲取。然而，為了描述本發(fā)明，既然從網(wǎng)絡(luò)獲取數(shù)據(jù)是預(yù)先假定的條件，那么在下文里“Java應(yīng)用”將指一個從網(wǎng)絡(luò)上獲取的Java應(yīng)用。
要注意的是，不論從諸如因特網(wǎng)的網(wǎng)絡(luò)上獲取的數(shù)據(jù)是存儲于固定存儲器還是存儲于臨時存儲器，它通常都被作為一個文件從諸如因特網(wǎng)的網(wǎng)絡(luò)上接收。例如，當(dāng)由單個文件組成的Java應(yīng)用通過HTTP(超文本傳送協(xié)議)從萬維網(wǎng)服務(wù)器上獲取時，它按照一個順序產(chǎn)生，換句話說就是連接到萬維網(wǎng)服務(wù)器、請求信息、接收響應(yīng)并從萬維網(wǎng)服務(wù)器斷開。這種情況下，當(dāng)用戶通過操作終端來請求Java應(yīng)用時，下載立刻開始，萬維網(wǎng)服務(wù)器和終端之間的連接一直保持，直到下載完成。在終端上顯示一條消息指示文件正在被下載。
在這個獲取數(shù)據(jù)的方法里，在開始下載之前，終端用戶不能夠知道Java應(yīng)用的諸如文件尺寸等的屬性信息；因此，終端用戶不能夠預(yù)測下載該Java應(yīng)用所需要的時間量。所以，就有一個問題，當(dāng)一個Java應(yīng)用由多個文件組成時，由于比預(yù)期的下載時間更長一些，終端的使用就可能會被限制。這是非常嚴(yán)重的，尤其對于諸如蜂窩電話的、其中所安裝的瀏覽器只有有限的通信范圍或處理能力的終端。諸如Java應(yīng)用的文件名和文件尺寸等必要的屬性信息當(dāng)然可以顯示在用戶終端內(nèi)的網(wǎng)頁上，但所關(guān)心的是，由于錯誤描述或欺詐意圖，一些不正確的屬性信息可能會被通報給用戶。
為了避免上面提到的問題，建議把Java應(yīng)用分成兩個文件，即包含屬性信息的ADF(應(yīng)用描述符文件)和包含數(shù)據(jù)實(shí)體的JAR(Java檔案文件)，并按順序接收這些文件。JAR是一種文件類型，其中一個或多個文件被組織成一個。JAR能夠在一個操作中下載多個文件，從而節(jié)省了在分開的操作中下載每個文件所需要的時間。然而，當(dāng)一個文件被分成兩個文件ADF和JAR時，確保安全性的問題完全沒有考慮。

發(fā)明內(nèi)容
本發(fā)明的目的是提供一個數(shù)據(jù)獲取的方法和終端，能夠在獲取被分割的數(shù)據(jù)時保證足夠高的安全性。
為了實(shí)現(xiàn)上面提到的目的，本發(fā)明提供了一個數(shù)據(jù)獲取的方法，包含可通過網(wǎng)絡(luò)進(jìn)行通信的終端中的第一接收步驟，用于從網(wǎng)絡(luò)側(cè)接收第一數(shù)據(jù)單元，有關(guān)數(shù)據(jù)的屬性信息被存儲在其中；終端中的確定步驟，基于在第一接收步驟中使用過的通信模式，以及用于接收存儲數(shù)據(jù)實(shí)體的第二數(shù)據(jù)單元的通信模式，確定數(shù)據(jù)是否能夠被獲?。缓偷诙邮詹襟E，其中當(dāng)確定步驟中的確定結(jié)果是“是”時，第二數(shù)據(jù)單元被從網(wǎng)絡(luò)側(cè)接收，而當(dāng)確定步驟中的確定結(jié)果是“否”時，第二數(shù)據(jù)單元不被從網(wǎng)絡(luò)側(cè)接收。
通過這種數(shù)據(jù)獲取方法，第二數(shù)據(jù)單元是否能被接收要通過比較接收第一數(shù)據(jù)單元時使用的通信模式和接收第二數(shù)據(jù)單元時使用的通信模式來確定。也就是，當(dāng)從接收第一數(shù)據(jù)單元時的時間到接收第二數(shù)據(jù)單元時的時間中通信模式被不適當(dāng)?shù)剞D(zhuǎn)換時，數(shù)據(jù)的獲得可以被禁止。換句話說，當(dāng)分割數(shù)據(jù)被獲取時，能保證足夠高的安全性。
另外，本發(fā)明提供了一個數(shù)據(jù)獲取方法，其中在確定步驟，當(dāng)接收第二數(shù)據(jù)單元時使用的通信模式的安全性比第一接收步驟中使用的通信模式的安全性低時，數(shù)據(jù)獲得不被允許。
另外，本發(fā)明提供了一個數(shù)據(jù)獲取方法，其中接收第一數(shù)據(jù)單元時使用的通信模式是使用加密通信的模式，在確定步驟，當(dāng)接收第二數(shù)據(jù)單元時使用的通信模式是不使用加密的模式時，數(shù)據(jù)獲得不被允許。
另外，本發(fā)明提供了一個數(shù)據(jù)獲取方法，其中在確定步驟，當(dāng)用于第一接收步驟的通信模式與用于接收第二數(shù)據(jù)單元的通信模式不一致時，數(shù)據(jù)獲得不被允許。
另外，本發(fā)明提供了一個數(shù)據(jù)獲取方法，其中數(shù)據(jù)是一個可在終端被執(zhí)行的計算機(jī)程序。
另外，在以上描述的任何一個數(shù)據(jù)獲取方法中，本發(fā)明提供了一個數(shù)據(jù)獲取方法，其中的計算機(jī)程序是一個執(zhí)行通信的計算機(jī)程序。
另外，在以上描述的任何一個數(shù)據(jù)獲取方法中，本發(fā)明提供了一個其中終端是一個蜂窩電話的數(shù)據(jù)獲取方法。
另外，本發(fā)明在終端中提供了一個第一接收裝置，從網(wǎng)絡(luò)側(cè)接收存儲著關(guān)于數(shù)據(jù)的屬性信息的第一數(shù)據(jù)單元；一個確定裝置，基于由第一接收裝置使用來接收第一數(shù)據(jù)單元的通信模式，和用于從網(wǎng)絡(luò)側(cè)接收存儲著數(shù)據(jù)實(shí)體的第二數(shù)據(jù)單元的通信模式，來確定數(shù)據(jù)的獲取是否可行；以及一個第二接收裝置，當(dāng)確定裝置的確定結(jié)果是“是”時，從網(wǎng)絡(luò)側(cè)接收第二數(shù)據(jù)單元，而當(dāng)確定裝置的確定結(jié)果是“否”時，不從網(wǎng)絡(luò)側(cè)接收第二數(shù)據(jù)單元。


圖1是在本發(fā)明的實(shí)施方案中，示出在終端中獲取Java應(yīng)用的基本過程的圖示；圖2是示出此終端的通信模型的圖示；圖3是示出終端中所顯示的消息的圖示；圖4是示出使用此終端的數(shù)據(jù)傳遞系統(tǒng)的配置框圖；
圖5是示出此終端的關(guān)鍵單元的配置的框圖；圖6是示出終端內(nèi)的過程表PT1和PT2的配置的概念性圖示；圖7是示出在獲得Java應(yīng)用期間，由此終端實(shí)現(xiàn)的處理的流程圖。
具體實(shí)施例方式
在下文中，本發(fā)明的優(yōu)選實(shí)施方案將通過參考附圖來解釋。本發(fā)明不局限于以下的實(shí)施方案，在不背離發(fā)明精神和范圍的前提下，可以有各種變化。
首先，先解釋本發(fā)明的數(shù)據(jù)獲取方法的基本思想。
圖1示出了當(dāng)本實(shí)施方案中的終端獲取一個Java應(yīng)用時的基本過程。如圖1所示，在Java應(yīng)用的獲取和執(zhí)行過程中，終端中的過程按A、B、C、D的順序進(jìn)行。換句話說，終端首先向網(wǎng)絡(luò)發(fā)出一個對頁面的獲取請求以獲得Java應(yīng)用，然后訪問相應(yīng)的頁面(步驟A)。在此狀態(tài)，終端用戶接著通過操作終端來輸入命令，以獲取此頁面中描述的Java應(yīng)用，終端發(fā)出獲取請求來響應(yīng)這條命令，獲取相應(yīng)Java應(yīng)用的ADF并把它存儲在固定存儲器里(步驟B)。接著終端向網(wǎng)絡(luò)發(fā)出對應(yīng)于此ADF的JAR的獲取請求，獲得該相應(yīng)的JAR并把它存儲在固定存儲器中(步驟C)。接著當(dāng)終端用戶操作終端命令執(zhí)行獲取的Java應(yīng)用(包含在JAR中的程序)時，相應(yīng)的Java應(yīng)用在終端中被執(zhí)行(步驟D)。
基本過程正如上所述，但是根據(jù)達(dá)到每一步所使用的通信模式，環(huán)境會發(fā)生改變。例如，在步驟A到C使用同一種通信模式的操作，不同于在步驟A中使用的、其中沒有加密的普通通信模式中的操作，但其后，直到步驟C都一直使用通過加密來發(fā)送和接收信息的協(xié)議SSL(安全套接字協(xié)議)的通信。對應(yīng)這種條件的終端的操作如下。
圖2示出了本實(shí)施方案的終端的通信模型的圖示，如圖所示，通信模型P1到P8是終端的可能通信模型。通信模型P1到P8都是步驟A到C的各個通信模式(普通/SSL)的順序的可能的變化。
圖3是示出本實(shí)施方案的終端上所顯示的消息的圖示。在這個圖示中，對應(yīng)于通信模型P1到P8的、在從步驟A到步驟B的轉(zhuǎn)移開始時的顯示消息，以及從步驟B到步驟C的轉(zhuǎn)移開始時的顯示消息都被指示，從而使終端的操作能夠從這些顯示消息中被識別出來。另外，在這個圖示中，從步驟A轉(zhuǎn)移到步驟B時所使用的連接模式，和從步驟B轉(zhuǎn)移到步驟C時所使用的連接模式對應(yīng)于每個通信模型，并且顯示的消息對應(yīng)于通信模型和每個連接模式。然而，在某些情況下，顯示的消息不依賴連接模式來確定，在這樣一個連接模式的列中，指示以“-”。連接模式的類型是?；钅Ｊ?，則其中多個數(shù)據(jù)可通過維持連接來轉(zhuǎn)發(fā)，以及是非使活著模式，則其中只要一個數(shù)據(jù)交換終止，連接就被取消。非保活模式是HTTP的普通數(shù)據(jù)交換模式，而?；钅Ｊ绞菍?yīng)于SSL的HTTPS(超文本傳輸協(xié)議安全)的普通數(shù)據(jù)交換模式。
在本實(shí)施方案中，如圖示3所示的操作被實(shí)現(xiàn)。這些操作將在后面作詳細(xì)描述?，F(xiàn)在將通過解釋一個操作的實(shí)例來解釋該圖。例如，根據(jù)通信模型P6(其中從步驟A到C的所有通信模式都是SSL的通信模型)，當(dāng)連接模式是非?；顣r，從步驟A到步驟B轉(zhuǎn)移的同時，在步驟A轉(zhuǎn)移到步驟B的開始時的顯示消息是“SSL通信開始”。另外，當(dāng)在連接模式是?；顣r從步驟B開始轉(zhuǎn)換到步驟C中，在開始處沒有顯示。
這個圖示中最與眾不同的點(diǎn)是，在通信模型P3和P4中，從步驟B轉(zhuǎn)移到步驟C是不被允許的。如圖2所示，在通信模型P3和P4中，在步驟B的通信模式是SSL，而在步驟C的通信模式是普通。換句話說，在本實(shí)施方案中，先通過使用加密通信模式的通信來獲取ADF，而隨后通過使用普通通信模式的通信來獲取JAR的獲取模型是不被允許的。之所以這樣的原因在后面解釋。
當(dāng)從網(wǎng)絡(luò)上獲取的Java應(yīng)用被執(zhí)行，并且被執(zhí)行的Java應(yīng)用通過網(wǎng)絡(luò)進(jìn)行通信時，此Java應(yīng)用通過網(wǎng)絡(luò)進(jìn)行通信時所使用的模式通常是終端獲取Java應(yīng)用時使用的通信模式。例如，當(dāng)由SSL通信獲取的Java應(yīng)用被執(zhí)行，并且這個Java應(yīng)用通過網(wǎng)絡(luò)進(jìn)行通信時，那個通信模式將被限制為SSL。因此，在終端側(cè)，只要當(dāng)Java應(yīng)用被獲取時的通信模式是SSL，就可以確定關(guān)于終端用戶的個人信息將不會被用明語傳送，甚至當(dāng)其后這個Java應(yīng)用使用網(wǎng)絡(luò)傳送關(guān)于終端用戶的個人信息時也一樣。
需要注意的是，正如在本實(shí)施方案中，當(dāng)通過使用ADF和JAR從網(wǎng)絡(luò)上獲取Java應(yīng)用時，此Java應(yīng)用以與JAR被獲取時相同的通信模式進(jìn)行通信。換句話說，正如在通信模型P3和P4中能夠看到的，當(dāng)在ADF的獲得期間通信模式為SSL，而在JAR的獲得期間通信模式為普通時，包含在此JAR中的Java應(yīng)用在使用網(wǎng)絡(luò)進(jìn)行通信時，將以普通通信模式進(jìn)行通信。
然而，如果獲取ADF的通信模式是SSL，用戶會傾向于假定獲取JAR的通信模式是SSL。如果允許獲取ADF的通信模式和獲取JAR的通信模式不一樣，將會有使關(guān)于終端用戶的個人信息被以明語傳送的危險，這違背了用戶的意愿。另外，一旦違背終端用戶意愿，使個人信息以明語傳送，則將會有被帶有欺詐意圖等的第三人秘密獲得訪問關(guān)于終端用戶的個人信息的危險。為了避免這些問題，如圖3所示，在通信模型P3和P4中，從步驟B轉(zhuǎn)移到步驟C不被允許。在圖2中，步驟B的通信模式和步驟C的通信模式即使在通信模型P1和P2中也不一樣，但在本實(shí)施方案中，這些通信模型是被允許的，因?yàn)橛稍诮K端執(zhí)行的Java應(yīng)用所傳送的數(shù)據(jù)比用戶可能要求的安全多了。
其次，將解釋通過使用本實(shí)施方案中的終端T的數(shù)據(jù)傳遞系統(tǒng)。
圖4是示出使用此終端T的數(shù)據(jù)傳遞系統(tǒng)的配置框圖，如此圖所示，這個數(shù)據(jù)傳遞系統(tǒng)是允許終端T利用WWW(萬維網(wǎng))的系統(tǒng)。
在此圖示中，終端T是一個終端，這里是一個蜂窩電話，用于接收移動分組通信網(wǎng)MPN的分組通信業(yè)務(wù)，它被遠(yuǎn)程連至移動分組通信網(wǎng)MPN和移動電話網(wǎng)(沒有示出)。移動電話網(wǎng)是為標(biāo)準(zhǔn)移動電話提供呼叫業(yè)務(wù)的網(wǎng)絡(luò)，終端T能夠接收這項(xiàng)呼叫業(yè)務(wù)。終端T的具體功能和配置將在后面描述。
移動分組通信網(wǎng)MPN由多個基站BS，多個分組用戶處理裝置PS，網(wǎng)關(guān)服務(wù)器GWS和連接這些的通信線路組成。
基站BS被以例如恒定間隔放置，并且每個基站覆蓋半徑為500米的一個區(qū)域，并在它的無線電范圍內(nèi)與終端T進(jìn)行無線通信。
分組用戶處理裝置PS是計算機(jī)系統(tǒng)，被安裝在分組用戶交換站內(nèi)，服務(wù)于多個基站BS，并且它從終端T接收分組交換請求，并通過其它分組用戶處理裝置PS和基站BS把接收到的分組中繼給被定址的終端T。
網(wǎng)關(guān)服務(wù)器GWS是被安裝在移動分組網(wǎng)關(guān)內(nèi)的計算機(jī)系統(tǒng)，它中繼交換站來互連不同的網(wǎng)絡(luò)，諸如移動分組通信網(wǎng)MPN和因特網(wǎng)INET，并且進(jìn)行網(wǎng)絡(luò)間不同通信協(xié)議的交換。通信協(xié)議的交換在這種情況下具體地是移動分組通信網(wǎng)MPN遵守的、用于移動分組通信網(wǎng)的傳輸協(xié)議與因特網(wǎng)INET遵守的傳輸協(xié)議的相互交換。
因特網(wǎng)INET遵守的傳輸協(xié)議包含OSI參考模型的網(wǎng)絡(luò)層和傳輸層的TCP/IP(傳輸控制協(xié)議/互聯(lián)網(wǎng)協(xié)議)，以及在此TCP/IP上實(shí)現(xiàn)的HTTP，HTTPS協(xié)議等。移動分組通信網(wǎng)MPN所遵守的協(xié)議包含其中TCP/IP被簡化了的協(xié)議(下文稱其為TL)，以及與HTTP和HTTPS相當(dāng)?shù)膮f(xié)議(下文稱其為AL)。換句話說，終端T在AL上使用WWW。
另外，當(dāng)網(wǎng)關(guān)服務(wù)器GWS使用GET方法從終端T接收HTTP(或HTTPS)消息時，它對包含于使用此GET方法的HTTP(或HTTPS)中的URL(統(tǒng)一資源定位符)進(jìn)行檢查。如果此URL是因特網(wǎng)INET上的一般URL，則使用此GET方法的HTTP(或HTTPS)被轉(zhuǎn)發(fā)給因特網(wǎng)INET，并且從因特網(wǎng)INET傳送過來、對應(yīng)于使用此GET方法的HTTP(或HTTPS)消息的響應(yīng)被發(fā)回給終端T。如果包含在使用GET方法的HTTP(或HTTPS)中的URL是一個指示它自己的資源位置的URL，那么網(wǎng)關(guān)服務(wù)器GWS把與使用此GET方法的HTTP(或HTTPS)消息相關(guān)的資源發(fā)回給終端T。
IP服務(wù)器W是與因特網(wǎng)INET相連并為使用WWW的客戶提供各種業(yè)務(wù)的服務(wù)器。特別地，當(dāng)IP服務(wù)器W通過因特網(wǎng)INET接收到一個對使用GET方法的HTTP(或HTTPS)消息的請求時，它就發(fā)回資源(在本實(shí)施方案中是工作文件)，該資源被包含在使用此GET方法的HTTP(或HTTPS)消息中的URL所標(biāo)識。在本實(shí)施方案中，IP服務(wù)器W的目的是傳送Java應(yīng)用，而IP服務(wù)器W和終端T之間的通信都由HTTP(和HTTPS)及AL完成。另外，IP服務(wù)器W和終端T都支持HTTP(和HTTPS)及HTTPS的SSL的?；?非?；畹臄?shù)據(jù)交換模式。
其次，終端T的配置將被解釋。然而，在這部分，直接與本發(fā)明相關(guān)的關(guān)鍵單元的配置將被解釋。
圖5是示出終端T的關(guān)鍵單元的配置的框圖，如此框圖所示，終端T具有內(nèi)置的發(fā)送-接收單元11(例如，安裝有一個天線、一個無線電單元，一個發(fā)射機(jī)，一個接收機(jī)等等)來與基站BS進(jìn)行無線電通信，聲音產(chǎn)生單元12(例如，由一個聲音源，一個揚(yáng)聲器等等組成)來產(chǎn)生聲音，輸入單元13，通過所安裝的鍵盤可進(jìn)行諸如數(shù)字輸入和字母輸入的輸入操作，包含特定尺寸的顯示范圍的液晶顯示器14，以及控制各個單元的控制單元15。
控制單元15具有內(nèi)置的進(jìn)行每項(xiàng)控制操作的CPU151、由CPU151執(zhí)行的瀏覽器、實(shí)現(xiàn)Java虛擬機(jī)的軟件、諸如終端T的控制程序的軟件、連接到網(wǎng)關(guān)服務(wù)器GWS的必要信息、后面要描述的過程表PT1、存儲PT2等的ROM(只讀存儲器)152、瞬時存儲器153，接收到的數(shù)據(jù)，用戶的設(shè)置內(nèi)容(例如，JAR的自動獲得能力)等等被存儲在其中，以允許即使當(dāng)終端重啟后它們也能再次被使用，以及還具有RAM154，它被存儲來當(dāng)終端重啟后，禁止再次使用接收到的數(shù)據(jù)，并且它被用作CPU151的工作存儲器。
當(dāng)電源開關(guān)(沒有示出)打開時，CPU151讀出并執(zhí)行存儲在ROM152中的控制程序，然后按照用戶從控制程序和輸入單元13輸入的命令，對ROM152、閃存153、RAM154、單元11到13中的每一個以及液晶顯示器14進(jìn)行控制。另外，按照從輸入單元13輸入的命令，CPU151激活瀏覽器，并能夠按照來自輸入單元13的命令，在此瀏覽器上進(jìn)行通信。而且，CPU151能夠基于存儲在ROM152中的過程表PT1和PT2(參考圖6)來控制通信過程。此功能的特殊操作將在后面描述。
另外，當(dāng)CPU151執(zhí)行存儲在閃存153中的Java應(yīng)用時，它激活Java虛擬機(jī)并在Java虛擬機(jī)上執(zhí)行此Java應(yīng)用。而且，當(dāng)CPU151訪問存儲在RAM154中的Java應(yīng)用(Java applet)時，它激活Java虛擬機(jī)和瀏覽器，并在Java虛擬機(jī)和瀏覽器上執(zhí)行此Java應(yīng)用。
通過CPU151從存儲在ROM152的原籍URL(它應(yīng)該先訪問的網(wǎng)關(guān)GWS上的資源位置)上獲取HTML數(shù)據(jù)，其中CPU151訪問存儲在ROM152中的瀏覽器并執(zhí)行該瀏覽器，首先被進(jìn)行終端T的數(shù)據(jù)獲取。然后，基于此數(shù)據(jù)，液晶顯示器15提示對話屏幕的顯示，當(dāng)用戶在此對話屏幕顯示后操作輸入單元13時，數(shù)據(jù)被獲取。
圖7是示出在獲得Java應(yīng)用期間，由此終端T實(shí)現(xiàn)的處理流的流程圖，在下文中，通過主要參考圖2、圖3、圖6和圖7，根據(jù)每個通信模型，解釋終端T從IP服務(wù)器W獲取Java應(yīng)用的操作。然而，在下面的解釋中，重疊的操作會盡可能被省略。在終端T中，假設(shè)瀏覽器已經(jīng)被激活。另外，至于作為獲得目標(biāo)的Java應(yīng)用的獲得實(shí)施方案，它既可以被存儲在固定存儲器中，也可在臨時存儲器中，但為了避免使解釋變復(fù)雜，只對Java應(yīng)用獲得后被存儲在固定存儲器中的情況作解釋。
(1)通信模型P1的情況如圖2所示，通信模型P1的通信模式在步驟A和步驟B中是普通模式，而在步驟C中是SSL。
首先，終端T獲取頁面(下文中，稱其為下載頁面)來獲取作為其目標(biāo)的Java應(yīng)用(步驟S1)。特別地，終端T的CPU151(參見圖5)基于用戶從輸入單元13輸入的命令來控制發(fā)送-接收單元11，并通過發(fā)送-接收單元11符合此命令的GET方法把發(fā)送IP服務(wù)器W HTTP消息(參見圖4)。作為響應(yīng)，作為目標(biāo)的下載頁面的HTML數(shù)據(jù)被從IP服務(wù)器W發(fā)回。此HTML數(shù)據(jù)被發(fā)送-接收單元11接收并從發(fā)送-接收單元11轉(zhuǎn)移到CPU151。CPU151把此HTML數(shù)據(jù)存儲在RAM154中，并通過進(jìn)一步解釋和執(zhí)行此數(shù)據(jù)來提供用戶接口。結(jié)果，通過此用戶接口的顯示出現(xiàn)在液晶顯示器14上。
接著終端T等待用戶的命令輸入(步驟S2)，并且如果所輸入的命令不是獲取目標(biāo)Java應(yīng)用的命令(步驟S3)，則獲取過程結(jié)束。特別地，基于從輸入單元13輸入的命令和當(dāng)前用戶接口，終端T的CPU151識別用戶的命令內(nèi)容，并且如果不同于獲取Java應(yīng)用的內(nèi)容的命令，諸如獲取不同頁面的命令被輸入，或電源開關(guān)(沒有示出)被關(guān)閉，那么獲得過程結(jié)束。
另一方面，如果在步驟S2輸入的命令是獲取目標(biāo)Java應(yīng)用(步驟S3)的請求，那么通過在步驟S1獲取的HTML數(shù)據(jù)，從步驟A到步驟B的轉(zhuǎn)移模型和連接模式被識別(步驟S4)。接著，對應(yīng)于被識別結(jié)果的過程被執(zhí)行，以及作為目標(biāo)的ADF被獲取(步驟S5)。在這種情況下，步驟A和步驟B的通信模式都是普通的；因此符合圖6所示的過程表PT1，通過普通通信獲取ADF的過程被進(jìn)行。在此過程期間，“正在獲取”被顯示在液晶顯示器14上。如圖6的過程表PT1所示，在此過程中，不論什么連接模式是什么，處理內(nèi)容都被確定。另外，步驟B的通信模式?jīng)]有被用戶確定，但在步驟S4，通過參照URL，它被顯示出來，該URL包含在為獲取ADF而在步驟S1中獲取的HTML數(shù)據(jù)中。特別地，URL的開始顯示了接入WWW服務(wù)器的通信模式，當(dāng)URL以“http”開始時，由于HTTP被顯示，所以通信模式將是“普通”。如果URL以“https”開始，則由于HTTPS被顯示，通信模式將是“SSL”。
當(dāng)ADF的獲得被完成時，而且如果JAR的自動獲得不被允許(步驟S6)，終端T接著問用戶JAR是否要被獲取(步驟S7)。當(dāng)繼續(xù)獲得JAR的命令被作為對此請求的響應(yīng)輸入時(步驟S8)，接著開始步驟S9的過程。然而，當(dāng)中斷獲得JAR的命令被輸入時，中斷過程被執(zhí)行(步驟S12)，同時過程返回到步驟S1。另外，如果JAR的自動獲得被允許(步驟S6)，過程就立刻開始步驟S9。
終端T配有設(shè)置允許/不允許JAR的自動獲得的功能。CPU151設(shè)置/重置閃存153的指定比特，它是響應(yīng)從輸入單元13輸入的命令，用于設(shè)置允許/不允許JAR的自動獲得的比特。因此，通過參照此比特，CPU151可以為JAR的自動獲得標(biāo)識允許/不允許設(shè)置。另外，在步驟S12的中斷過程中，CPU151中斷獲取Java應(yīng)用的過程，丟棄作為目標(biāo)且存儲在閃存153ADF，從而最大利用閃存153的存儲量。
其次，從步驟B到步驟C的轉(zhuǎn)移模型和連接模式被識別，而JAR的獲得過程基于該識別結(jié)果(步驟S10，S11)而進(jìn)行。在此情況下，步驟B的通信模式是普通的，步驟C的通信模式是SSL；因而，如過程表PT2所示，此過程將是一個通過新開始的SSL通信而獲取JAR的過程。在此過程期間，“SSL通信開始(正在被鑒權(quán))”作為顯示消息被顯示在液晶顯示器14上。因而，在圖3中，對應(yīng)轉(zhuǎn)移模型P1的過程被正確地執(zhí)行。如圖6中的過程表PT2所示，在此情況下，不論是什么連接模式，過程內(nèi)容都被確定。另外，通過參照URL(它包含在為獲取JAR而在步驟S5獲取的ADF文件中)，步驟C的通信模式將在步驟S9被顯示出來。當(dāng)ADF被獲取時，如果URL以“http”開始，則通信模式將是“普通的”。如果URL以“https”開始，則通信模式將是“SSL”。
(2)通信模型P2的情況如圖2所示，通信模型P2的通信模式在步驟B是普通的，而在步驟A和C是SSL。
首先，在步驟1到5，執(zhí)行與通信模型P1相同的過程。然而，由于在步驟A的通信模式是SSL，GET方法的HTTPS在步驟S1被傳送給IP服務(wù)器W。另外，在此過程中，步驟A中的通信模式是SSL，而步驟B中的通信模式是普通的；因而，如圖6中的過程表PT1所示，SSL通信將被停止，而進(jìn)行以普通通信獲取ADF的過程。在此過程期間，“SSL頁面終止”作為顯示消息被顯示在液晶顯示器14中。
另外在步驟S9之后，步驟B中的通信模式是普通，步驟C中的通信模式是SSL；因此，與通信模型P1相同的過程被進(jìn)行。因而，圖3中對應(yīng)通信模型P2的過程被適當(dāng)?shù)貓?zhí)行。
(3)通信模型P3的情況如圖2所示，通信模型P3的通信模式在步驟A和C中是普通，在步驟B中是SSL。
首先，在步驟S1到S5中，與通信模型P1相同的過程被進(jìn)行。然而，在此過程期間，步驟A的通信模式是普通的，而步驟B的通信模式是SSL；因而，如圖6中的過程表PT1所示，該過程將是通過新啟動的SSL通信而獲取ADF的一個過程。在此過程期間，“SSL通信開始(正在被鑒權(quán))”作為顯示消息被顯示在液晶顯示器14上。即使連接模式是?；畹?，SSL通信也會不管連接模式如何而在此過程中新地啟動，因?yàn)閺钠胀ㄍㄐ拍Ｊ角袚Q到SSL通信模式而不中止該過程是不可能的，。
其次，從步驟B到步驟C的轉(zhuǎn)移模型和連接模式被識別(步驟S9)。在此過程期間，步驟B中的通信模式是SSL，步驟C中的通信模式是普通的；因而，步驟10中所確定的結(jié)果將是“是”，通過步驟S12中的中斷過程，該過程返回步驟S1。換句話說，目標(biāo)Java應(yīng)用不被獲取，并且圖3中對應(yīng)于通信模型P3的過程被適當(dāng)?shù)貓?zhí)行。
(4)通信模型P4的情況如圖2所示，通信模型P4的通信模式在步驟C是普通的，而在步驟A和B是SSL。
首先，在步驟S1到S5，與通信模型P1相同的過程被進(jìn)行。然而，由于在步驟A的通信模式是SSL，所以GET方法的HTTPS消息在步驟S1被傳送給IP服務(wù)器W。另外，在此過程中，步驟A和B中的通信模式是SSL；因而，符合步驟A到步驟B的連接模式的過程被進(jìn)行。換句話說，如果連接模式是非保活，則通過啟動SSL通信獲取ADF的過程被執(zhí)行。如果連接模式是保活，則通過繼續(xù)SSL通信獲取ADF的過程被執(zhí)行。在前一種情況中，“SSL通信開始”被顯示在液晶顯示器14上，而在后一種情況中，沒有消息被顯示在液晶顯示器14上。當(dāng)連接模式是?；顣r，沒有消息顯示，原因是SSL通信的新過程沒有開始。
另外，步驟B的通信模式是SSL，而步驟C的通信模式是普通，因此，與通信模型P3相同的過程被進(jìn)行。因而，圖3中對應(yīng)于通信模型P4的過程被適當(dāng)?shù)貓?zhí)行。
(5)通信模型P5的情況如圖2所示，在步驟A中，通信模型P5的通信模式是普通的，而在步驟B和C中是SSL。
首先，在步驟S1到S5中，與通信模型P3相同的過程被進(jìn)行。接著，在步驟S9之后的過程中，由于在步驟B和C中的通信模式是SSL，所以基于圖6中的過程表PT2所示的過程，符合從步驟B到步驟C的連接模式的過程被進(jìn)行。換句話說，當(dāng)連接模式是非?；顣r，通過啟動SSL通信來執(zhí)行獲取ADF的過程，而當(dāng)連接模式是保活時，通過繼續(xù)SSL通信來執(zhí)行獲取JAR的過程。在前一種情況中，“SSL通信開始”被顯示在液晶顯示器14上，而在后一種情況中，沒有消息被顯示在液晶顯示器14上。因而，圖3中對應(yīng)于通信模型P5的過程被適當(dāng)?shù)貓?zhí)行。
(6)通信模型P6的情況如圖2所示，通信模型P6的通信模式在步驟A，B和C都是SSL。
首先，在步驟S1到S5，與通信模型P4相同的過程被進(jìn)行。接著在步驟S9之后的過程中，與通信模型P5相同的過程被進(jìn)行。因而，圖3中對應(yīng)于通信模型P6的過程被適當(dāng)?shù)貓?zhí)行。
(7)通信模型P7的情況如圖2所示，通信模型P7的通信模式在步驟A，B和C都是普通的。
首先，在步驟S1到S5，與通信模型P1相同的過程被進(jìn)行。接著，由于步驟B和C的通信模式是普通，所以在步驟S9和其后的過程中，根據(jù)圖6中所示的過程表PT2，通過繼續(xù)普通通信來獲取JAR的過程被進(jìn)行。在此過程期間，“正在被獲取”作為顯示消息被顯示在液晶顯示器14上。因而，圖3中對應(yīng)于通信模型P7的過程被適當(dāng)?shù)貓?zhí)行。
(8)通信模型P8的情況如圖2所示，通信模型P8的通信模式在步驟A是SSL，而在步驟B和C是普通的。
首先，在步驟S1到S5，與通信模型P2相同的過程被進(jìn)行。接著在步驟S9和其后的過程中，與P7相同的通信模型被進(jìn)行。因而，圖3中對應(yīng)于通信模型P8的過程被適當(dāng)?shù)貓?zhí)行。
補(bǔ)充如上面所解釋的，根據(jù)本實(shí)施方案，對應(yīng)于圖2和圖3中所示的每個通信模型的過程都被完全實(shí)施，而且通過以加密通信模式中的通信獲取ADF。于是，通過在普通通信模型中的通信獲取JAR來得到Java應(yīng)用的模型可以被去除了。
因此，當(dāng)終端用戶執(zhí)行獲取的Java應(yīng)用，而獲取的Java應(yīng)用通過使用網(wǎng)絡(luò)進(jìn)行通信時，可以防止違背終端用戶的意愿，由Java應(yīng)用以明語傳送個人信息的情況。
另外，正如以上提到的實(shí)施方案，蜂窩電話被實(shí)現(xiàn)為終端。蜂窩電話的數(shù)據(jù)處理能力較諸如筆記本電腦等的終端要低一些，同時通信路徑的帶寬較電纜通信要窄一些；因此，對于終端操作被限制的時間段比用戶預(yù)期要長的可能性在現(xiàn)有技術(shù)中更高一些。然而在本實(shí)施方案中，允許通過將Java應(yīng)用分成ADF和JAR來獲取它，以及允許用戶參照ADF上的屬性信息來確定是否獲取JAR，使得這樣的限制被避免。
在以上提到的實(shí)施方案中，通過把獲取的Java應(yīng)用存儲進(jìn)固定存儲器中，使得即使終端重啟之后，也允許使用Java應(yīng)用而不重新獲取Java應(yīng)用的實(shí)例被示出；然而，通過把獲取的Java應(yīng)用存儲進(jìn)臨時存儲器，使得在終端開啟后再次獲取Java應(yīng)用也是可行的。
另外，在以上提到的實(shí)施方案中，Java應(yīng)用只是能被獲取的數(shù)據(jù)的一個實(shí)例，除此之外其它程序或數(shù)據(jù)也能被獲取。換句話說，當(dāng)一類可分成兩個單元的數(shù)據(jù)被從因特網(wǎng)獲取時，本發(fā)明就能夠被應(yīng)用。
另外，在以上提到的實(shí)施方案中，圖2中的通信模型P1和P2是被允許的，但這些可以被禁止。換句話說，禁止一個其中步驟B的通信系統(tǒng)和步驟C的通信系統(tǒng)不一致的獲取模型是可能的。
另外，在以上提到的實(shí)施方案中，蜂窩電話是終端的一個實(shí)例，但在本發(fā)明中，其它能夠以電纜或在空中通過網(wǎng)絡(luò)進(jìn)行通信的終端也能夠被使用。
另外，在以上提到的實(shí)施方案中，圖2中的通信模型P3和P4毫無例外地是不被允許的，但這種限制對本發(fā)明不適用。例如，當(dāng)圖2中的通信模型是P3和P4時，通過詢問用戶獲得是否可能，使得當(dāng)用戶同意時，JAR可以被接收并存儲。否則，通過允許一類Java應(yīng)用被存儲在ADF中，在Java應(yīng)用是一類不進(jìn)行通信的應(yīng)用的情況下，即使圖2中的通信模型是P3和P4，JAR也可以被接收并存儲。
另外，在以上提到的實(shí)施方案中，通過使用HTTP(和HTTPS)及AL轉(zhuǎn)發(fā)數(shù)據(jù)的實(shí)例被示出，但在本發(fā)明中，任何能夠?qū)崿F(xiàn)加密通信的協(xié)議都能夠被采用。它當(dāng)然可以是任何對應(yīng)于?；詈头潜；畹耐ㄐ艆f(xié)議。它也可以是不與這些對應(yīng)的通信協(xié)議。
另外，在以上提到的實(shí)施方案中，在網(wǎng)關(guān)服務(wù)器GWS處轉(zhuǎn)換通信協(xié)議的實(shí)例被示出，但這僅是一個實(shí)例。例如，通過允許HTTP(和HTTPS)及SSL在終端被處理，通信可以在終端和IP服務(wù)器之間直接被完成，或經(jīng)過多次變換后被完成。
權(quán)利要求
1.一種數(shù)據(jù)獲取方法包含終端中的第一接收步驟，可通過網(wǎng)絡(luò)進(jìn)行通信，來經(jīng)過所述網(wǎng)絡(luò)接收第一數(shù)據(jù)單元，關(guān)于數(shù)據(jù)的屬性信息被存儲在其中；所述終端中的確定步驟，基于在所述第一接收步驟中使用過的通信模式，以及用于接收存儲所述數(shù)據(jù)實(shí)體的第二數(shù)據(jù)單元的通信模式，來確定所述數(shù)據(jù)是否能夠被獲取；第二接收步驟，其中當(dāng)確定步驟中的確定結(jié)果是“是”時，所述第二數(shù)據(jù)單元被從網(wǎng)絡(luò)側(cè)接收，當(dāng)確定結(jié)果是“否”時，所述第二數(shù)據(jù)單元不被從網(wǎng)絡(luò)側(cè)接收。
2.根據(jù)權(quán)利要求1的數(shù)據(jù)獲取方法，其中在確定步驟中，當(dāng)接收第二數(shù)據(jù)單元使用的通信模式的安全性比第一接收步驟中使用的通信模式的安全性低時，所述數(shù)據(jù)獲取被確定為“否”。
3.根據(jù)權(quán)利要求1的數(shù)據(jù)獲取方法，其中用于接收第一數(shù)據(jù)單元的通信模式是使用加密通信的模式，并且在確定步驟中，當(dāng)用于接收第二數(shù)據(jù)單元的通信模式是不使用加密的模式時，所述數(shù)據(jù)獲取被確定為“否”。
4.根據(jù)權(quán)利要求1的數(shù)據(jù)獲取方法，其中在確定步驟中，當(dāng)用于第一接收步驟中的通信模式與用于接收第二數(shù)據(jù)單元的通信模式不一致時，所述數(shù)據(jù)獲取被確定為“否”。
5.根據(jù)權(quán)利要求1的數(shù)據(jù)獲取方法，其中所述數(shù)據(jù)是可以在所述終端上執(zhí)行的計算機(jī)程序。
6.根據(jù)權(quán)利要求5的數(shù)據(jù)獲取方法，其中所述計算機(jī)程序是執(zhí)行通信的計算機(jī)程序。
7.根據(jù)權(quán)利要求1的數(shù)據(jù)獲取方法，其中該終端是一個蜂窩電話。
8.一種終端包含一個第一接收裝置，用于從網(wǎng)絡(luò)側(cè)接收存儲著關(guān)于數(shù)據(jù)的屬性信息的第一數(shù)據(jù)單元；一個確定裝置，基于由所述第一接收裝置使用來接收第一數(shù)據(jù)單元的通信模式，和用于從網(wǎng)絡(luò)側(cè)接收存儲著所述數(shù)據(jù)實(shí)體的第二數(shù)據(jù)單元的通信模式，來確定所述數(shù)據(jù)獲得是否可行；一個第二接收裝置，當(dāng)所述確定裝置的確定結(jié)果是“是”時，它從網(wǎng)絡(luò)側(cè)接收第二數(shù)據(jù)單元，而當(dāng)確定結(jié)果是“否”時，它不從網(wǎng)絡(luò)側(cè)接收所述第二數(shù)據(jù)單元。
全文摘要
在一個能夠通過網(wǎng)絡(luò)通信的終端里，接收存儲數(shù)據(jù)屬性信息的ADF以判斷它，并以接收ADF時使用的通信系統(tǒng)(普通/SSL)和接收存儲著數(shù)據(jù)實(shí)體的JAR時要使用的通信系統(tǒng)為基礎(chǔ)，判斷它是否有一個被允許的通信模型。JAR在允許的通信模型的情況下被接收，而在不允許的通信模型的情況下不被接收，因?yàn)樵撃Ｐ蜁＜鞍踩：喍灾?，?shù)據(jù)只能在允許的通信模型的情況下被獲得。
文檔編號G06F13/00GK1395704SQ01804056
公開日2003年2月5日 申請日期2001年11月21日 優(yōu)先權(quán)日2000年11月24日
發(fā)明者山田和宏, 山本正明, 平松孝朗, 井上恭子, 神谷大, 大關(guān)江利子, 德田元紀(jì), 大井達(dá)郎, 鷲見豐 申請人:株式會社Ntt都科摩