数据获取方法和终端 【技术领域】
本发明涉及通过网络获取数据的数据获取方法，以及用这种方法获取数据的终端。
背景技术
由于通信网络的新近发展，通过诸如因特网的网络获取(下载)数据被广泛采用。通过诸如因特网的网络获取的数据通常被存储到诸如硬盘的固定存储器中。即使在CPU(中央处理单元)和RAM(随机存取存储器)被通过把终端电源关闭一次再打开来重启终端或复位终端而初始化后，存储于固定存储器中的数据也能够通过从存储数据的固定存储器中读出数据而再次被访问。
另外，当通过诸如因特网的网络获取数据时，获取的数据甚至可以被存储于诸如RAM的临时存储器中。一个这样的数据实例是Java applet(java小应用程序)。Java applet是用Java生产的程序(java应用)。Java applet通过诸如因特网的网络获取，并存储于终端的临时存储器中。终端中获取的Java applet通过浏览以HTML(超文本标记语言)写的网页的浏览器和Java虚拟机来使用。如上所述，当终端被重启时，RAM的临时存储器被初始化，而存储于临时存储器中地数据被去除。当通过诸如因特网的网络获取的数据被存储到临时存储器中时，它将不能再被使用，除非在终端被重启以后，数据再次通过诸如因特网的网络被获取才行。
与Java applet不同，有许多Java应用在从诸如因特网的网络上获取后，被存储于固定存储器中，并且甚至在终端被重启后，也不需要再次从诸如因特网的网络上获取。也有存储于终端的固定存储器中的Java应用，它们不需要从网络上获取。然而，为了描述本发明，既然从网络获取数据是预先假定的条件，那么在下文里“Java应用”将指一个从网络上获取的Java应用。
要注意的是，不论从诸如因特网的网络上获取的数据是存储于固定存储器还是存储于临时存储器，它通常都被作为一个文件从诸如因特网的网络上接收。例如，当由单个文件组成的Java应用通过HTTP(超文本传送协议)从万维网服务器上获取时，它按照一个顺序产生，换句话说就是：连接到万维网服务器、请求信息、接收响应并从万维网服务器断开。这种情况下，当用户通过操作终端来请求Java应用时，下载立刻开始，万维网服务器和终端之间的连接一直保持，直到下载完成。在终端上显示一条消息指示文件正在被下载。
在这个获取数据的方法里，在开始下载之前，终端用户不能够知道Java应用的诸如文件尺寸等的属性信息；因此，终端用户不能够预测下载该Java应用所需要的时间量。所以，就有一个问题，当一个Java应用由多个文件组成时，由于比预期的下载时间更长一些，终端的使用就可能会被限制。这是非常严重的，尤其对于诸如蜂窝电话的、其中所安装的浏览器只有有限的通信范围或处理能力的终端。诸如Java应用的文件名和文件尺寸等必要的属性信息当然可以显示在用户终端内的网页上，但所关心的是，由于错误描述或欺诈意图，一些不正确的属性信息可能会被通报给用户。
为了避免上面提到的问题，建议把Java应用分成两个文件，即包含属性信息的ADF(应用描述符文件)和包含数据实体的JAR(Java档案文件)，并按顺序接收这些文件。JAR是一种文件类型，其中一个或多个文件被组织成一个。JAR能够在一个操作中下载多个文件，从而节省了在分开的操作中下载每个文件所需要的时间。然而，当一个文件被分成两个文件ADF和JAR时，确保安全性的问题完全没有考虑。
【发明内容】
本发明的目的是提供一个数据获取的方法和终端，能够在获取被分割的数据时保证足够高的安全性。
为了实现上面提到的目的，本发明提供了一个数据获取的方法，包含可通过网络进行通信的终端中的第一接收步骤，用于从网络侧接收第一数据单元，有关数据的属性信息被存储在其中；终端中的确定步骤，基于在第一接收步骤中使用过的通信模式，以及用于接收存储数据实体的第二数据单元的通信模式，确定数据是否能够被获取；和第二接收步骤，其中当确定步骤中的确定结果是“是”时，第二数据单元被从网络侧接收，而当确定步骤中的确定结果是“否”时，第二数据单元不被从网络侧接收。
通过这种数据获取方法，第二数据单元是否能被接收要通过比较接收第一数据单元时使用的通信模式和接收第二数据单元时使用的通信模式来确定。也就是，当从接收第一数据单元时的时间到接收第二数据单元时的时间中通信模式被不适当地转换时，数据的获得可以被禁止。换句话说，当分割数据被获取时，能保证足够高的安全性。
另外，本发明提供了一个数据获取方法，其中在确定步骤，当接收第二数据单元时使用的通信模式的安全性比第一接收步骤中使用的通信模式的安全性低时，数据获得不被允许。
另外，本发明提供了一个数据获取方法，其中接收第一数据单元时使用的通信模式是使用加密通信的模式，在确定步骤，当接收第二数据单元时使用的通信模式是不使用加密的模式时，数据获得不被允许。
另外，本发明提供了一个数据获取方法，其中在确定步骤，当用于第一接收步骤的通信模式与用于接收第二数据单元的通信模式不一致时，数据获得不被允许。
另外，本发明提供了一个数据获取方法，其中数据是一个可在终端被执行的计算机程序。
另外，在以上描述的任何一个数据获取方法中，本发明提供了一个数据获取方法，其中的计算机程序是一个执行通信的计算机程序。
另外，在以上描述的任何一个数据获取方法中，本发明提供了一个其中终端是一个蜂窝电话的数据获取方法。
另外，本发明在终端中提供了一个第一接收装置，从网络侧接收存储着关于数据的属性信息的第一数据单元；一个确定装置，基于由第一接收装置使用来接收第一数据单元的通信模式，和用于从网络侧接收存储着数据实体的第二数据单元的通信模式，来确定数据的获取是否可行；以及一个第二接收装置，当确定装置的确定结果是“是”时，从网络侧接收第二数据单元，而当确定装置的确定结果是“否”时，不从网络侧接收第二数据单元。
【附图说明】
图1是在本发明的实施方案中，示出在终端中获取Java应用的基本过程的图示；
图2是示出此终端的通信模型的图示；
图3是示出终端中所显示的消息的图示；
图4是示出使用此终端的数据传递系统的配置框图；
图5是示出此终端的关键单元的配置的框图；
图6是示出终端内的过程表PT1和PT2的配置的概念性图示；
图7是示出在获得Java应用期间，由此终端实现的处理的流程图。
【具体实施方式】
在下文中，本发明的优选实施方案将通过参考附图来解释。本发明不局限于以下的实施方案，在不背离发明精神和范围的前提下，可以有各种变化。
[基本思想]
首先，先解释本发明的数据获取方法的基本思想。
图1示出了当本实施方案中的终端获取一个Java应用时的基本过程。如图1所示，在Java应用的获取和执行过程中，终端中的过程按A、B、C、D的顺序进行。换句话说，终端首先向网络发出一个对页面的获取请求以获得Java应用，然后访问相应的页面(步骤A)。在此状态，终端用户接着通过操作终端来输入命令，以获取此页面中描述的Java应用，终端发出获取请求来响应这条命令，获取相应Java应用的ADF并把它存储在固定存储器里(步骤B)。接着终端向网络发出对应于此ADF的JAR的获取请求，获得该相应的JAR并把它存储在固定存储器中(步骤C)。接着当终端用户操作终端命令执行获取的Java应用(包含在JAR中的程序)时，相应的Java应用在终端中被执行(步骤D)。
基本过程正如上所述，但是根据达到每一步所使用的通信模式，环境会发生改变。例如，在步骤A到C使用同一种通信模式的操作，不同于在步骤A中使用的、其中没有加密的普通通信模式中的操作，但其后，直到步骤C都一直使用通过加密来发送和接收信息的协议SSL(安全套接字协议)的通信。对应这种条件的终端的操作如下。
图2示出了本实施方案的终端的通信模型的图示，如图所示，通信模型P1到P8是终端的可能通信模型。通信模型P1到P8都是步骤A到C的各个通信模式(普通/SSL)的顺序的可能的变化。
图3是示出本实施方案的终端上所显示的消息的图示。在这个图示中，对应于通信模型P1到P8的、在从步骤A到步骤B的转移开始时的显示消息，以及从步骤B到步骤C的转移开始时的显示消息都被指示，从而使终端的操作能够从这些显示消息中被识别出来。另外，在这个图示中，从步骤A转移到步骤B时所使用的连接模式，和从步骤B转移到步骤C时所使用的连接模式对应于每个通信模型，并且显示的消息对应于通信模型和每个连接模式。然而，在某些情况下，显示的消息不依赖连接模式来确定，在这样一个连接模式的列中，指示以“-”。连接模式的类型是保活模式，则其中多个数据可通过维持连接来转发，以及是非使活着模式，则其中只要一个数据交换终止，连接就被取消。非保活模式是HTTP的普通数据交换模式，而保活模式是对应于SSL的HTTPS(超文本传输协议安全)的普通数据交换模式。
在本实施方案中，如图示3所示的操作被实现。这些操作将在后面作详细描述。现在将通过解释一个操作的实例来解释该图。例如，根据通信模型P6(其中从步骤A到C的所有通信模式都是SSL的通信模型)，当连接模式是非保活时，从步骤A到步骤B转移的同时，在步骤A转移到步骤B的开始时的显示消息是“SSL通信开始”。另外，当在连接模式是保活时从步骤B开始转换到步骤C中，在开始处没有显示。
这个图示中最与众不同的点是，在通信模型P3和P4中，从步骤B转移到步骤C是不被允许的。如图2所示，在通信模型P3和P4中，在步骤B的通信模式是SSL，而在步骤C的通信模式是普通。换句话说，在本实施方案中，先通过使用加密通信模式的通信来获取ADF，而随后通过使用普通通信模式的通信来获取JAR的获取模型是不被允许的。之所以这样的原因在后面解释。
当从网络上获取的Java应用被执行，并且被执行的Java应用通过网络进行通信时，此Java应用通过网络进行通信时所使用的模式通常是终端获取Java应用时使用的通信模式。例如，当由SSL通信获取的Java应用被执行，并且这个Java应用通过网络进行通信时，那个通信模式将被限制为SSL。因此，在终端侧，只要当Java应用被获取时的通信模式是SSL，就可以确定关于终端用户的个人信息将不会被用明语传送，甚至当其后这个Java应用使用网络传送关于终端用户的个人信息时也一样。
需要注意的是，正如在本实施方案中，当通过使用ADF和JAR从网络上获取Java应用时，此Java应用以与JAR被获取时相同的通信模式进行通信。换句话说，正如在通信模型P3和P4中能够看到的，当在ADF的获得期间通信模式为SSL，而在JAR的获得期间通信模式为普通时，包含在此JAR中的Java应用在使用网络进行通信时，将以普通通信模式进行通信。
然而，如果获取ADF的通信模式是SSL，用户会倾向于假定获取JAR的通信模式是SSL。如果允许获取ADF的通信模式和获取JAR的通信模式不一样，将会有使关于终端用户的个人信息被以明语传送的危险，这违背了用户的意愿。另外，一旦违背终端用户意愿，使个人信息以明语传送，则将会有被带有欺诈意图等的第三人秘密获得访问关于终端用户的个人信息的危险。为了避免这些问题，如图3所示，在通信模型P3和P4中，从步骤B转移到步骤C不被允许。在图2中，步骤B的通信模式和步骤C的通信模式即使在通信模型P1和P2中也不一样，但在本实施方案中，这些通信模型是被允许的，因为由在终端执行的Java应用所传送的数据比用户可能要求的安全多了。
[配置]
其次，将解释通过使用本实施方案中的终端T的数据传递系统。
图4是示出使用此终端T的数据传递系统的配置框图，如此图所示，这个数据传递系统是允许终端T利用WWW(万维网)的系统。
在此图示中，终端T是一个终端，这里是一个蜂窝电话，用于接收移动分组通信网MPN的分组通信业务，它被远程连至移动分组通信网MPN和移动电话网(没有示出)。移动电话网是为标准移动电话提供呼叫业务的网络，终端T能够接收这项呼叫业务。终端T的具体功能和配置将在后面描述。
移动分组通信网MPN由多个基站BS，多个分组用户处理装置PS，网关服务器GWS和连接这些的通信线路组成。
基站BS被以例如恒定间隔放置，并且每个基站覆盖半径为500米的一个区域，并在它的无线电范围内与终端T进行无线通信。
分组用户处理装置PS是计算机系统，被安装在分组用户交换站内，服务于多个基站BS，并且它从终端T接收分组交换请求，并通过其它分组用户处理装置PS和基站BS把接收到的分组中继给被定址的终端T。
网关服务器GWS是被安装在移动分组网关内的计算机系统，它中继交换站来互连不同的网络，诸如移动分组通信网MPN和因特网INET，并且进行网络间不同通信协议的交换。通信协议的交换在这种情况下具体地是移动分组通信网MPN遵守的、用于移动分组通信网的传输协议与因特网INET遵守的传输协议的相互交换。
因特网INET遵守的传输协议包含OSI参考模型的网络层和传输层的TCP/IP(传输控制协议/互联网协议)，以及在此TCP/IP上实现的HTTP，HTTPS协议等。移动分组通信网MPN所遵守的协议包含其中TCP/IP被简化了的协议(下文称其为TL)，以及与HTTP和HTTPS相当的协议(下文称其为AL)。换句话说，终端T在AL上使用WWW。
另外，当网关服务器GWS使用GET方法从终端T接收HTTP(或HTTPS)消息时，它对包含于使用此GET方法的HTTP(或HTTPS)中的URL(统一资源定位符)进行检查。如果此URL是因特网INET上的一般URL，则使用此GET方法的HTTP(或HTTPS)被转发给因特网INET，并且从因特网INET传送过来、对应于使用此GET方法的HTTP(或HTTPS)消息的响应被发回给终端T。如果包含在使用GET方法的HTTP(或HTTPS)中的URL是一个指示它自己的资源位置的URL，那么网关服务器GWS把与使用此GET方法的HTTP(或HTTPS)消息相关的资源发回给终端T。
IP服务器W是与因特网INET相连并为使用WWW的客户提供各种业务的服务器。特别地，当IP服务器W通过因特网INET接收到一个对使用GET方法的HTTP(或HTTPS)消息的请求时，它就发回资源(在本实施方案中是工作文件)，该资源被包含在使用此GET方法的HTTP(或HTTPS)消息中的URL所标识。在本实施方案中，IP服务器W的目的是传送Java应用，而IP服务器W和终端T之间的通信都由HTTP(和HTTPS)及AL完成。另外，IP服务器W和终端T都支持HTTP(和HTTPS)及HTTPS的SSL的保活/非保活的数据交换模式。
其次，终端T的配置将被解释。然而，在这部分，直接与本发明相关的关键单元的配置将被解释。
图5是示出终端T的关键单元的配置的框图，如此框图所示，终端T具有内置的发送-接收单元11(例如，安装有一个天线、一个无线电单元，一个发射机，一个接收机等等)来与基站BS进行无线电通信，声音产生单元12(例如，由一个声音源，一个扬声器等等组成)来产生声音，输入单元13，通过所安装的键盘可进行诸如数字输入和字母输入的输入操作，包含特定尺寸的显示范围的液晶显示器14，以及控制各个单元的控制单元15。
控制单元15具有内置的进行每项控制操作的CPU151、由CPU151执行的浏览器、实现Java虚拟机的软件、诸如终端T的控制程序的软件、连接到网关服务器GWS的必要信息、后面要描述的过程表PT1、存储PT2等的ROM(只读存储器)152、瞬时存储器153，接收到的数据，用户的设置内容(例如，JAR的自动获得能力)等等被存储在其中，以允许即使当终端重启后它们也能再次被使用，以及还具有RAM154，它被存储来当终端重启后，禁止再次使用接收到的数据，并且它被用作CPU151的工作存储器。
当电源开关(没有示出)打开时，CPU151读出并执行存储在ROM152中的控制程序，然后按照用户从控制程序和输入单元13输入的命令，对ROM152、闪存153、RAM154、单元11到13中的每一个以及液晶显示器14进行控制。另外，按照从输入单元13输入的命令，CPU151激活浏览器，并能够按照来自输入单元13的命令，在此浏览器上进行通信。而且，CPU151能够基于存储在ROM152中的过程表PT1和PT2(参考图6)来控制通信过程。此功能的特殊操作将在后面描述。
另外，当CPU151执行存储在闪存153中的Java应用时，它激活Java虚拟机并在Java虚拟机上执行此Java应用。而且，当CPU151访问存储在RAM154中的Java应用(Java applet)时，它激活Java虚拟机和浏览器，并在Java虚拟机和浏览器上执行此Java应用。
通过CPU151从存储在ROM152的原籍URL(它应该先访问的网关GWS上的资源位置)上获取HTML数据，其中CPU151访问存储在ROM152中的浏览器并执行该浏览器，首先被进行终端T的数据获取。然后，基于此数据，液晶显示器15提示对话屏幕的显示，当用户在此对话屏幕显示后操作输入单元13时，数据被获取。
[Java应用获取操作]
图7是示出在获得Java应用期间，由此终端T实现的处理流的流程图，在下文中，通过主要参考图2、图3、图6和图7，根据每个通信模型，解释终端T从IP服务器W获取Java应用的操作。然而，在下面的解释中，重叠的操作会尽可能被省略。在终端T中，假设浏览器已经被激活。另外，至于作为获得目标的Java应用的获得实施方案，它既可以被存储在固定存储器中，也可在临时存储器中，但为了避免使解释变复杂，只对Java应用获得后被存储在固定存储器中的情况作解释。
(1)通信模型P1的情况
如图2所示，通信模型P1的通信模式在步骤A和步骤B中是普通模式，而在步骤C中是SSL。
首先，终端T获取页面(下文中，称其为下载页面)来获取作为其目标的Java应用(步骤S1)。特别地，终端T的CPU151(参见图5)基于用户从输入单元13输入的命令来控制发送-接收单元11，并通过发送-接收单元11符合此命令的GET方法把发送IP服务器W HTTP消息(参见图4)。作为响应，作为目标的下载页面的HTML数据被从IP服务器W发回。此HTML数据被发送-接收单元11接收并从发送-接收单元11转移到CPU151。CPU151把此HTML数据存储在RAM154中，并通过进一步解释和执行此数据来提供用户接口。结果，通过此用户接口的显示出现在液晶显示器14上。
接着终端T等待用户的命令输入(步骤S2)，并且如果所输入的命令不是获取目标Java应用的命令(步骤S3)，则获取过程结束。特别地，基于从输入单元13输入的命令和当前用户接口，终端T的CPU151识别用户的命令内容，并且如果不同于获取Java应用的内容的命令，诸如获取不同页面的命令被输入，或电源开关(没有示出)被关闭，那么获得过程结束。
另一方面，如果在步骤S2输入的命令是获取目标Java应用(步骤S3)的请求，那么通过在步骤S1获取的HTML数据，从步骤A到步骤B的转移模型和连接模式被识别(步骤S4)。接着，对应于被识别结果的过程被执行，以及作为目标的ADF被获取(步骤S5)。在这种情况下，步骤A和步骤B的通信模式都是普通的；因此符合图6所示的过程表PT1，通过普通通信获取ADF的过程被进行。在此过程期间，“正在获取”被显示在液晶显示器14上。如图6的过程表PT1所示，在此过程中，不论什么连接模式是什么，处理内容都被确定。另外，步骤B的通信模式没有被用户确定，但在步骤S4，通过参照URL，它被显示出来，该URL包含在为获取ADF而在步骤S1中获取的HTML数据中。特别地，URL的开始显示了接入WWW服务器的通信模式，当URL以“http”开始时，由于HTTP被显示，所以通信模式将是“普通”。如果URL以“https”开始，则由于HTTPS被显示，通信模式将是“SSL”。
当ADF的获得被完成时，而且如果JAR的自动获得不被允许(步骤S6)，终端T接着问用户JAR是否要被获取(步骤S7)。当继续获得JAR的命令被作为对此请求的响应输入时(步骤S8)，接着开始步骤S9的过程。然而，当中断获得JAR的命令被输入时，中断过程被执行(步骤S12)，同时过程返回到步骤S1。另外，如果JAR的自动获得被允许(步骤S6)，过程就立刻开始步骤S9。
终端T配有设置允许/不允许JAR的自动获得的功能。CPU151设置/重置闪存153的指定比特，它是响应从输入单元13输入的命令，用于设置允许/不允许JAR的自动获得的比特。因此，通过参照此比特，CPU151可以为JAR的自动获得标识允许/不允许设置。另外，在步骤S12的中断过程中，CPU151中断获取Java应用的过程，丢弃作为目标且存储在闪存153ADF，从而最大利用闪存153的存储量。
其次，从步骤B到步骤C的转移模型和连接模式被识别，而JAR的获得过程基于该识别结果(步骤S10，S11)而进行。在此情况下，步骤B的通信模式是普通的，步骤C的通信模式是SSL；因而，如过程表PT2所示，此过程将是一个通过新开始的SSL通信而获取JAR的过程。在此过程期间，“SSL通信开始(正在被鉴权)”作为显示消息被显示在液晶显示器14上。因而，在图3中，对应转移模型P1的过程被正确地执行。如图6中的过程表PT2所示，在此情况下，不论是什么连接模式，过程内容都被确定。另外，通过参照URL(它包含在为获取JAR而在步骤S5获取的ADF文件中)，步骤C的通信模式将在步骤S9被显示出来。当ADF被获取时，如果URL以“http”开始，则通信模式将是“普通的”。如果URL以“https”开始，则通信模式将是“SSL”。
(2)通信模型P2的情况
如图2所示，通信模型P2的通信模式在步骤B是普通的，而在步骤A和C是SSL。
首先，在步骤1到5，执行与通信模型P1相同的过程。然而，由于在步骤A的通信模式是SSL，GET方法的HTTPS在步骤S1被传送给IP服务器W。另外，在此过程中，步骤A中的通信模式是SSL，而步骤B中的通信模式是普通的；因而，如图6中的过程表PT1所示，SSL通信将被停止，而进行以普通通信获取ADF的过程。在此过程期间，“SSL页面终止”作为显示消息被显示在液晶显示器14中。
另外在步骤S9之后，步骤B中的通信模式是普通，步骤C中的通信模式是SSL；因此，与通信模型P1相同的过程被进行。因而，图3中对应通信模型P2的过程被适当地执行。
(3)通信模型P3的情况
如图2所示，通信模型P3的通信模式在步骤A和C中是普通，在步骤B中是SSL。
首先，在步骤S1到S5中，与通信模型P1相同的过程被进行。然而，在此过程期间，步骤A的通信模式是普通的，而步骤B的通信模式是SSL；因而，如图6中的过程表PT1所示，该过程将是通过新启动的SSL通信而获取ADF的一个过程。在此过程期间，“SSL通信开始(正在被鉴权)”作为显示消息被显示在液晶显示器14上。即使连接模式是保活的，SSL通信也会不管连接模式如何而在此过程中新地启动，因为从普通通信模式切换到SSL通信模式而不中止该过程是不可能的，。
其次，从步骤B到步骤C的转移模型和连接模式被识别(步骤S9)。在此过程期间，步骤B中的通信模式是SSL，步骤C中的通信模式是普通的；因而，步骤10中所确定的结果将是“是”，通过步骤S12中的中断过程，该过程返回步骤S1。换句话说，目标Java应用不被获取，并且图3中对应于通信模型P3的过程被适当地执行。
(4)通信模型P4的情况
如图2所示，通信模型P4的通信模式在步骤C是普通的，而在步骤A和B是SSL。
首先，在步骤S1到S5，与通信模型P1相同的过程被进行。然而，由于在步骤A的通信模式是SSL，所以GET方法的HTTPS消息在步骤S1被传送给IP服务器W。另外，在此过程中，步骤A和B中的通信模式是SSL；因而，符合步骤A到步骤B的连接模式的过程被进行。换句话说，如果连接模式是非保活，则通过启动SSL通信获取ADF的过程被执行。如果连接模式是保活，则通过继续SSL通信获取ADF的过程被执行。在前一种情况中，“SSL通信开始”被显示在液晶显示器14上，而在后一种情况中，没有消息被显示在液晶显示器14上。当连接模式是保活时，没有消息显示，原因是SSL通信的新过程没有开始。
另外，步骤B的通信模式是SSL，而步骤C的通信模式是普通，因此，与通信模型P3相同的过程被进行。因而，图3中对应于通信模型P4的过程被适当地执行。
(5)通信模型P5的情况
如图2所示，在步骤A中，通信模型P5的通信模式是普通的，而在步骤B和C中是SSL。
首先，在步骤S1到S5中，与通信模型P3相同的过程被进行。接着，在步骤S9之后的过程中，由于在步骤B和C中的通信模式是SSL，所以基于图6中的过程表PT2所示的过程，符合从步骤B到步骤C的连接模式的过程被进行。换句话说，当连接模式是非保活时，通过启动SSL通信来执行获取ADF的过程，而当连接模式是保活时，通过继续SSL通信来执行获取JAR的过程。在前一种情况中，“SSL通信开始”被显示在液晶显示器14上，而在后一种情况中，没有消息被显示在液晶显示器14上。因而，图3中对应于通信模型P5的过程被适当地执行。
(6)通信模型P6的情况
如图2所示，通信模型P6的通信模式在步骤A，B和C都是SSL。
首先，在步骤S1到S5，与通信模型P4相同的过程被进行。接着在步骤S9之后的过程中，与通信模型P5相同的过程被进行。因而，图3中对应于通信模型P6的过程被适当地执行。
(7)通信模型P7的情况
如图2所示，通信模型P7的通信模式在步骤A，B和C都是普通的。
首先，在步骤S1到S5，与通信模型P1相同的过程被进行。接着，由于步骤B和C的通信模式是普通，所以在步骤S9和其后的过程中，根据图6中所示的过程表PT2，通过继续普通通信来获取JAR的过程被进行。在此过程期间，“正在被获取”作为显示消息被显示在液晶显示器14上。因而，图3中对应于通信模型P7的过程被适当地执行。
(8)通信模型P8的情况
如图2所示，通信模型P8的通信模式在步骤A是SSL，而在步骤B和C是普通的。
首先，在步骤S1到S5，与通信模型P2相同的过程被进行。接着在步骤S9和其后的过程中，与P7相同的通信模型被进行。因而，图3中对应于通信模型P8的过程被适当地执行。
【补充】
如上面所解释的，根据本实施方案，对应于图2和图3中所示的每个通信模型的过程都被完全实施，而且通过以加密通信模式中的通信获取ADF。于是，通过在普通通信模型中的通信获取JAR来得到Java应用的模型可以被去除了。
因此，当终端用户执行获取的Java应用，而获取的Java应用通过使用网络进行通信时，可以防止违背终端用户的意愿，由Java应用以明语传送个人信息的情况。
另外，正如以上提到的实施方案，蜂窝电话被实现为终端。蜂窝电话的数据处理能力较诸如笔记本电脑等的终端要低一些，同时通信路径的带宽较电缆通信要窄一些；因此，对于终端操作被限制的时间段比用户预期要长的可能性在现有技术中更高一些。然而在本实施方案中，允许通过将Java应用分成ADF和JAR来获取它，以及允许用户参照ADF上的属性信息来确定是否获取JAR，使得这样的限制被避免。
在以上提到的实施方案中，通过把获取的Java应用存储进固定存储器中，使得即使终端重启之后，也允许使用Java应用而不重新获取Java应用的实例被示出；然而，通过把获取的Java应用存储进临时存储器，使得在终端开启后再次获取Java应用也是可行的。
另外，在以上提到的实施方案中，Java应用只是能被获取的数据的一个实例，除此之外其它程序或数据也能被获取。换句话说，当一类可分成两个单元的数据被从因特网获取时，本发明就能够被应用。
另外，在以上提到的实施方案中，图2中的通信模型P1和P2是被允许的，但这些可以被禁止。换句话说，禁止一个其中步骤B的通信系统和步骤C的通信系统不一致的获取模型是可能的。
另外，在以上提到的实施方案中，蜂窝电话是终端的一个实例，但在本发明中，其它能够以电缆或在空中通过网络进行通信的终端也能够被使用。
另外，在以上提到的实施方案中，图2中的通信模型P3和P4毫无例外地是不被允许的，但这种限制对本发明不适用。例如，当图2中的通信模型是P3和P4时，通过询问用户获得是否可能，使得当用户同意时，JAR可以被接收并存储。否则，通过允许一类Java应用被存储在ADF中，在Java应用是一类不进行通信的应用的情况下，即使图2中的通信模型是P3和P4，JAR也可以被接收并存储。
另外，在以上提到的实施方案中，通过使用HTTP(和HTTPS)及AL转发数据的实例被示出，但在本发明中，任何能够实现加密通信的协议都能够被采用。它当然可以是任何对应于保活和非保活的通信协议。它也可以是不与这些对应的通信协议。
另外，在以上提到的实施方案中，在网关服务器GWS处转换通信协议的实例被示出，但这仅是一个实例。例如，通过允许HTTP(和HTTPS)及SSL在终端被处理，通信可以在终端和IP服务器之间直接被完成，或经过多次变换后被完成。