WO2002042918A1 - Procede et terminal d'acquisition de donnees - Google Patents

Procede et terminal d'acquisition de donnees Download PDF

Info

Publication number
WO2002042918A1
WO2002042918A1 PCT/JP2001/010170 JP0110170W WO0242918A1 WO 2002042918 A1 WO2002042918 A1 WO 2002042918A1 JP 0110170 W JP0110170 W JP 0110170W WO 0242918 A1 WO0242918 A1 WO 0242918A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
communication
terminal
receiving
communication method
Prior art date
Application number
PCT/JP2001/010170
Other languages
English (en)
French (fr)
Inventor
Kazuhiro Yamada
Masaaki Yamamoto
Yoshiaki Hiramatsu
Kyoko Inoue
Dai Kamiya
Eriko Ooseki
Motoki Tokuda
Tatsuro Ooi
Yutaka Sumi
Original Assignee
Ntt Docomo, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to BR0107377-0A priority Critical patent/BR0107377A/pt
Priority to PL01356885A priority patent/PL356885A1/xx
Priority to US10/204,363 priority patent/US7174333B2/en
Priority to EP01997742A priority patent/EP1338971B1/en
Priority to DE60126421T priority patent/DE60126421T2/de
Priority to AU2002224062A priority patent/AU2002224062B8/en
Application filed by Ntt Docomo, Inc. filed Critical Ntt Docomo, Inc.
Priority to CA002394294A priority patent/CA2394294C/en
Priority to NZ519408A priority patent/NZ519408A/en
Priority to AU2406202A priority patent/AU2406202A/xx
Publication of WO2002042918A1 publication Critical patent/WO2002042918A1/ja
Priority to NO20023491A priority patent/NO324486B1/no
Priority to HK03108031A priority patent/HK1056024A1/xx

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99931—Database or file accessing
    • Y10S707/99939—Privileged access
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00—Data processing: database and file management or data structures
    • Y10S707/99941—Database schema or data structure
    • Y10S707/99944—Object-oriented database structure
    • Y10S707/99945—Object-oriented database structure processing

Definitions

  • the present invention relates to a data acquisition method for acquiring data via a network, and a terminal for acquiring data using this method.
  • Technology Background With the development of communication networks in recent years, it has been widely practiced to download (download) data via networks such as the Internet.
  • the data obtained via the network such as an in-net is normally stored in a non-volatile memory such as a hard disk at the terminal.
  • the data stored in the non-volatile memory is stored in the CPU (Central Processing Unit) and RAM (Random Access Memory) by turning the terminal off and then on again, or by resetting the terminal. ) Can be used again by reading the data from the non-volatile memory where the data is stored even after the data is initialized.
  • CPU Central Processing Unit
  • RAM Random Access Memory
  • the acquired data is stored in a volatile memory such as a RAM.
  • Data acquired in this way includes, for example, Java Ablet.
  • a Java applet is a type of program (Java application case) created using Java.
  • the Java applet is obtained via a network such as the Internet Network and stored in the terminal's volatile memory.
  • the Java applet acquired by the terminal is executed under the control of a browser and a Java virtual machine that browse the web page described in HTML (Hyper Text Markup Language).
  • HTML Hyper Text Markup Language
  • the Java application is stored in a non-volatile memory after being obtained from a network such as the Internet, and is re-opened from the network such as the Internet even after the terminal is restarted. Some do not need to be acquired.
  • Java applications that are stored in the non-volatile memory of the terminal in advance and do not need to be obtained from the network.
  • the “Java application” in this specification is assumed to be acquired from a network.
  • data acquired from a network such as the Inuichi Net is stored in non-volatile memory or volatile memory
  • data is acquired from the network such as the Inuichi Net on a file-by-file basis. It is usually done.
  • a Java application consisting of one file from a web server using HTTP (HyperText Transfer Protocol)
  • the acquisition of the Java application is performed in one session, that is, the web server. This is achieved by connecting to the Web server, requesting and responding to information, and disconnecting from the Web server.
  • the terminal when the user operates the terminal to instruct acquisition of the Java application, the acquisition of the Java application starts immediately, and until the acquisition of the entire Java application is completed, the Web server and the terminal are used. The connection between is maintained, and the terminal displays, for example, a message indicating that a file is being acquired.
  • the user of the terminal cannot know the attribute information such as the file size of the Java application before starting the acquisition of the Java application. Cannot predict how long it will take to get a JaVa application. For this reason, for example, in the case of a Java application composed of a plurality of files, the time during which the operation of the terminal is restricted by the data acquisition process may be longer than expected by the user. There is. This is particularly important for terminals with extremely limited communication bandwidth and processing capability, such as mobile phones equipped with a browser. Of course, attribute information such as the file name and file size of the Java application case is described on the Web page, and the user of the terminal is notified of the necessary attribute information before acquiring the Java application. However, incorrect attribute information may be notified to the user due to a mistake or malice.
  • An object of the present invention is to provide a data acquisition method and a terminal capable of securing sufficiently high security when acquiring divided data.
  • a terminal capable of communicating via a network receives a first data unit storing data attribute information from the network side, a first receiving step, The terminal determines the data based on a communication method used in the first receiving step and a communication method used when receiving a second data unit storing the substance of the data from the network side.
  • a data acquisition method having a communication step.
  • the terminal uses the communication method used at the time of receiving the first data unit storing the attribute information of the data and the second communication method storing the entity of the data.
  • Whether or not to receive in the second data unit is determined based on the communication method used in the reception in the second data unit. Thereby, for example, when the communication method is inappropriately switched between the reception of the first data unit and the reception of the second data unit, the acquisition of the data can be prohibited. In other words, a sufficiently high level of security (security) can be secured when obtaining the divided data.
  • the present invention provides a method as described above, wherein in the determining step, the security of the communication method used in the second reception unit is lower than the security of the communication method used in the first receiving step. Provides a data acquisition method that makes the data acquisition “no”.
  • a communication method used when receiving the first data unit is a method using encrypted communication, and is used when receiving the second data unit. If the communication method is a method that does not use encrypted communication, a data acquisition method is provided in which the acquisition of the data is set to “NO”.
  • the acquisition of the data Provide a method of obtaining data overnight.
  • the data is a computer program executable on the terminal.
  • the present invention provides the data acquisition method according to any one of the aspects described above, wherein the data acquisition method is a computer program for communicating the data.
  • the present invention also provides the data acquisition method according to any one of the above-described aspects, wherein the terminal is a mobile phone.
  • the present invention provides a first receiving means for receiving, from a network side, a first data unit storing data attribute information; and the first data unit by the first receiving means.
  • Determining means for determining whether to obtain the data based on a communication method used when receiving the data and a communication method used when receiving a second data unit storing the substance of the data from the network side And the judgment result by the judgment means is “OK”
  • FIG. 1 is a diagram showing a basic processing flow when a terminal according to an embodiment of the present invention acquires a Java application.
  • FIG. 2 is a diagram showing a communication pattern of the terminal.
  • FIG. 3 is a diagram showing a display message of the terminal.
  • FIG. 4 is a block diagram showing a configuration of a data distribution system using the terminal.
  • FIG. 5 is a block diagram showing a configuration of a main part of the terminal.
  • FIG. 6 is a conceptual diagram showing the configuration of the processing tables PT1 and PT2 in the terminal.
  • FIG. 7 is a flowchart showing the flow of processing performed by the terminal when acquiring a Java application.
  • BEST MODE FOR CARRYING OUT THE INVENTION will be described with reference to the drawings. It should be noted that the present invention is not limited to the embodiment, and various changes can be made within the scope of the technical idea.
  • FIG. 1 is a diagram showing a flow of a basic process when the terminal according to the present embodiment acquires a Java application.
  • Java application In obtaining and executing Yeon, the processing of the terminal is performed in the order of A, B, C, and D. That is, first, the terminal sends a page acquisition request for acquiring the Java application to the network, and acquires the corresponding page (Step A).
  • Step B when the user of the terminal operates the terminal and inputs an instruction to acquire the Java application described on the page, the terminal sends an acquisition request corresponding to the instruction to the network, and Acquire the ADF of the JaVa application and store it in non-volatile memory.
  • the terminal sends a request to acquire a JAR corresponding to the ADF to the network, acquires the corresponding JAR, and stores the JAR in the nonvolatile memory (Step C).
  • the user of the terminal operates the terminal and instructs the execution of the acquired Java application (the program included in the JAR)
  • the corresponding Java application is executed on the terminal (step D).
  • the basic processing flow is as described above, but conditions are added according to the communication method that reaches each stage. For example, the communication of the same communication method is performed in stages A to C, and the communication of the normal communication method which is not encrypted is performed in stage A. Thereafter, information is encrypted and transmitted and received until stage C.
  • the operation of the terminal differs when communication is performed using the SSL (Secure Sockets Layer) protocol. The operation of the terminal according to such conditions will be described below.
  • FIG. 2 is a diagram showing a communication pattern of the terminal according to the present embodiment. As shown in this figure, communication patterns P1 to P8 are considered as communication patterns of the terminal. Communication patterns; P1 to P8 are all variations of the permutations of the communication methods (normal / SSL) of stages A to C.
  • FIG. 3 is a diagram showing a display message of the terminal according to the present embodiment.
  • the display message at the start of the transition from stage A to stage B and the display message at the start of the transition from stage B to stage C are shown corresponding to communication patterns P1 to P8.
  • the operation of the terminal can be specified from these displayed messages.
  • the connection format when moving from stage A to stage B and the connection format when moving from stage B to stage C are associated with each communication pattern. ⁇ Sage corresponds to the communication pattern and each connection type. However, depending on the connection type In some cases, the displayed message is determined without the presence, and "1" is described in the column for such a connection type.
  • keep-alive which allows multiple data transfers while maintaining the connection
  • non-keep-aHve which disconnects each time one data exchange is completed.
  • the non-keep-alive format is a normal data exchange format in HTTP
  • the keep-alive format is a normal data exchange format in HTTP (HyperText Transfer Protocol Security) that supports SSL.
  • the operation shown in this figure is realized, and since the operation will be described in detail later, an example of the operation will be described here for the purpose of explaining how to read the figure.
  • communication pattern P6 a pattern of SSL in which the communication format in stages A to C is common
  • the message displayed at the beginning of the transition from the B to the stage B is ⁇ Start SSL communication ''
  • the connection type is keep-alive
  • the most characteristic point in this figure is that the transition from stage B to stage C is not permitted for communication patterns P3 and P4.
  • the communication method of stage B is SSL
  • the communication method of stage C is normal. That is, in the present embodiment, an acquisition pattern in which the ADF is acquired by communication using the encrypted communication method and then the JAR is acquired by communication using the normal communication method is not allowed. The reason for this is explained below.
  • the communication method performed by the Java application via the network is as follows. This is the communication method used at the time. For example, if a Java application obtained by SSL communication is executed and the Java application communicates via a network, the communication method is limited to SSL. Because of this assumption, the terminal must download a Java application. If the communication method at the time of obtaining is SSL, the personal information of the terminal user must be transmitted in clear text even when the Java application transmits the personal information of the terminal user using the network. It can be determined that there is no.
  • the Java application when the Java application is acquired from the network using the ADF and the JAR as in the present embodiment, the Java application performs communication using the communication method used when the JAR is acquired.
  • the communication method for obtaining the ADF is SSL and the communication method for obtaining the JAR is normal, as in the communication patterns P3 and P4, the Java application included in the JAR is connected to the network.
  • communication is performed using the normal communication method.
  • the communication method when acquiring the ADF is SSL
  • the communication method when acquiring the JAR will also be SSL. If the communication method when acquiring the ADF and the communication method when acquiring JAR are allowed, there is a risk that the personal information of the terminal user may be transmitted in plain text against the user's will. . In addition, if personal information is transmitted in plain text where it is contrary to the intention of the terminal user, there is a risk that a malicious third party could steal the personal information of the terminal user. In order to avoid such a situation, as shown in FIG. 3, the transition from the stage B to the stage C is not allowed in the communication patterns P3 and P4. In FIG. 2, although the communication schemes of stage B and C are different even in communication patterns P1 and P2, the data transmitted by the JaVa application executed on the terminal In the present embodiment, these communication patterns are allowed because the protection is stronger than intended by the user.
  • FIG. 4 is a block diagram showing a configuration of a data distribution system using the terminal T. As shown in FIG. The overnight distribution system allows the terminal T to use the WWW (World Wide Web).
  • WWW World Wide Web
  • a terminal is a packet communication service of a mobile packet communication network MP.
  • This is a mobile phone that is wirelessly connected to the mobile packet communication network MPN and a mobile telephone network (not shown).
  • the mobile telephone network is a network that provides a general mobile telephone call service, and the terminal T can receive the call service. The detailed functions and configuration of the terminal will be described later.
  • the mobile packet communication network MPN is composed of a plurality of base stations BS, a plurality of bucket subscriber processing devices PS, a gateway server GWS, and a communication line connecting these.
  • the base stations BS are arranged at predetermined intervals that divide the ground in a range of, for example, a radius of 500 m, and perform wireless communication with terminals T located in wireless zones formed by the base stations.
  • the bucket subscriber processing unit PS is a computer system provided in a bucket switching center that accommodates a plurality of base stations BS, and receives a packet exchange request from the terminal T and joins the received packet to another packet. Relay to the destination terminal T via at least one of the user processor PS and the subordinate base station BS.
  • the gateway server GWS is a computer system provided in the mobile packet gateway relay exchange for interconnecting the mobile packet communication network MPN and other networks such as the Internet INET, and converts different communication protocols between networks. .
  • the conversion of the communication protocol referred to here means a mutual conversion between a transmission protocol for a mobile packet communication network that the mobile packet communication network MPN follows and a transmission protocol that the INU-Ichi Net NET follows.
  • the transmission protocol used by the INU INET is based on TCP / IP (Transmission Control 1 Protocol / Internet Protocol) of the network layer and transport layer of the OSI reference model, and is implemented on this TCP / IP.
  • Protocols such as HTTP and HTTPS are included, and the transport protocol that the mobile packet communication network MPN follows is a protocol that simplifies TCP / IP (hereinafter TL) and a protocol equivalent to HT TP (and HTTPS) ( Hereafter, AL) is included. That is, terminal T uses WWW on AL.
  • the gateway server GWS uses the GET method.
  • the HTTP (or HTTPS) message using the GET method is transferred to NET and the response sent from the Internet INET in response to the HTTP (or HTTP S) message using the GET method is sent to the NET.
  • the gateway server GWS uses the HTTP (or HTTPS) using the GET method. The corresponding resource is returned to terminal T in response to the message.
  • the IP server W is a server connected to the Internet INET, and provides various services to clients using the WWW. Specifically, upon receiving an HTTP (or HTTPS) message request using the GET method via the Internet INET, the IP server W includes the request in the HTTP (or HTTPS) message using the GET method. The resource (a work file in this embodiment) specified by the URL is returned.
  • the IP server W distributes the Java application, and all communication between the IP server W and the terminal T is performed by HTTP (and HTTPS) and AL. It is getting to be.
  • both the IP server W and the terminal T support the data exchange format of keep-alive / non-keep-aJive in HTTP (and HTTPS) and SSL in HTTPS.
  • FIG. 5 is a block diagram showing a configuration of a main part of the terminal T.
  • the terminal T is a transmitting / receiving unit (for example, an antenna, a radio unit, a transmitter) for performing radio communication with the base station BS. , A receiver, etc.) 11, a sound generator for sounding (for example, composed of a sound source and a speaker) 12, a keypad for performing input operations such as numeral input and character input, etc. It has an input section 13, a liquid crystal display 14 having a display area of a predetermined size, and a control section 15 for controlling these sections.
  • the control unit 15 is a CPU 151 that performs various controls, a browser executed by the CPU 151, software for realizing a Java virtual machine, software such as a control program for the terminal T, and information necessary for connection with the gateway server GWS. And a ROM (Read Only Memory) 152 storing processing tables PT 1, PT 2, etc., which will be described later, and the received data and user setting contents (for example, whether or not the JAR can be automatically acquired).
  • a flash memory 153 that stores the data so that it can be used again even after it has been activated, and a memory that stores the received data so that it cannot be used again after the terminal is restarted, and the CPU 151 It has a built-in RAM 154 used as memory.
  • the CPU 151 When a power source (not shown) is turned on, the CPU 151 reads and executes the control program stored in the ROM 152, and executes the control program and the flash memory according to the user's instruction input from the input unit 13. 153, RAM 154, each section 11 to # 3, and the liquid crystal display 14 are controlled. Further, the CPU 151 has a function of activating a browser in accordance with a user's instruction input from the input unit 13 and performing communication in accordance with the instruction from the input unit 13 on the browser. Further, the CPU 151 has a function of controlling communication processing based on the processing tables PT1 and PT2 (see FIG. 6) stored in the ROM 152. The specific operation by this function will be described later.
  • the CPU 151 activates the Java virtual machine when executing the Java application stored in the flash memory 153, and executes the Java application on the Java virtual machine. Further, the CPU 151 activates a Java virtual machine and a browser when executing as a Java application (Java creator) stored in the RAM 54, and executes the Java application on these.
  • the terminal T obtains the data overnight by first reading the browser stored in the ROM 152 by the CPU 151 and executing the browser.
  • the home URL stored in the ROM 152 (the resource on the gateway GWS to be accessed first) HTML data from the position), and based on this data, display an interactive screen (page) on the liquid crystal display 15 and the user who visually recognizes this interactive screen It is performed by operating 3.
  • FIG. 7 is a flow chart showing the flow of processing performed by the terminal T when acquiring the Java application.
  • the terminal will be Java.
  • the operation of acquiring an application from the IP server W will be described for each communication pattern. However, in the following description, descriptions overlapping between communication patterns are omitted as much as possible. It is assumed that a browser has already been started on terminal T. Also, as the acquisition form of the Java application to be acquired, there is storage in non-volatile memory / storage in volatile memory, but here, after the acquisition of the Java application, in order to avoid complications, Only an example of storing in a non-volatile memory will be described.
  • the communication method of the communication pattern P1 is usually in stage A and stage B, and SSL in stage C.
  • the terminal T acquires a page for acquiring a desired Java application (hereinafter, a download page) (step S1). Specifically, CPU 151 of terminal T (see FIG. 5) controls transmission / reception unit 11 based on a user's instruction input from input unit 13, and transmission / reception unit 11 performs GET according to the instruction. Send an HTTP message using the method to IP server W (see Fig. 4). In response, the IP server W returns an HTML file of the desired download page. The HTML data is received by the transmission / reception unit 11 and is passed from the transmission / reception unit 11 to the CPU 151. The CPU 151 stores the HTML data in the RAMI 54, and provides a user interface by further interpreting and executing this.
  • a desired Java application hereinafter, a download page
  • the terminal T waits for an instruction input by the user (step S2), and terminates the acquisition processing if the instruction input here is not an instruction to acquire a desired Java application. (Step S3). Specifically, the CPU 151 of the terminal T identifies the user's instruction content based on the instruction input from the input unit 13 and the current user interface, and receives an instruction to acquire another page. Power off when input or not shown When an instruction having contents different from the acquisition of the Java application is input, for example, when the instruction is given, the acquisition processing ends.
  • step S2 Conversely, if the instruction input in step S2 is to request the acquisition of a desired Java application (step S3), the HTML The transition pattern and connection type from A to stage B are specified (step S4), and the processing according to the specified result is performed, and the corresponding ADF is obtained (step S5).
  • the process of acquiring the ADF by normal communication is performed according to the processing table PT1 shown in FIG. At this time, “acquiring” is displayed on the liquid crystal display 14 as a display message.
  • the processing content is determined regardless of the connection type.
  • the user of the terminal does not decide the communication method of stage B.
  • step S4 refer to the URL for acquiring the ADF included in the HTML data acquired in step S1.
  • the head of URL indicates the communication method for accessing the WWW server, and if the URL starts with “ht tp", the communication method indicates HTTP, so "normal” If the URL starts with “ht t ps", the communication method indicates "HTTP S", so it will be "S SL”.
  • step S6 When the acquisition of the ADF is completed, if the automatic acquisition of the JAR is not permitted (step S6), the terminal T queries the user whether to continue acquiring the JAR (step S7). If an instruction to continue acquiring the JAR is input in response to this inquiry (step S8), the process proceeds to step S9. Conversely, when an instruction to suspend acquisition of JAR is input, suspension processing is performed (step S12), and the processing returns to step S1. If the automatic acquisition of the JAR is permitted (step S6), the process immediately proceeds to step S9.
  • the terminal T has a function of setting permission / non-permission of automatic acquisition of JAR.
  • the CPU 151 resets a predetermined bit of the flash memory 153, which is a bit for setting permission / non-permission of automatic acquisition of the JAR, according to the instruction input from the input unit 13. Therefore, by referring to this bit, CPU1 51 can know permission / non-permission of automatic acquisition of JAR. Also, in the interruption process of step S12, the CPU 151 interrupts the process of acquiring the Java application, discards the corresponding ADF stored in the flash memory 153, and effectively uses the storage capacity of the flash memory 153. Like that.
  • step S9 the transition pattern and connection form from stage B to stage C are specified (step S9), and a JAR acquisition process is performed according to the specified result (steps S10, S11).
  • the process is to newly start SSL communication and acquire the JAR according to the processing table PT2.
  • “Start SSL communication (authenticating)” is displayed on the liquid crystal display 14 as a display message.
  • the processing corresponding to the transition pattern P1 in FIG. 3 is performed correctly.
  • the processing content is determined regardless of the connection type.
  • the communication method of the stage C can be determined by referring to the URL for acquiring the JAR included in the ADF file acquired in step S5 in step S9. As in the case of obtaining the ADF, if the URL starts with "ht tp", the communication method is "normal”, and if the URL starts with "ht t ps", the communication method is "SSL". .
  • the communication scheme of the communication pattern P2 is normally in stage B, and is SSL in stages A and C.
  • step S5 the same processing as in the case of the communication pattern P1 is performed.
  • the communication method of stage A is SSL
  • step S1 an HTTP message using the GET method is transmitted to the IP server W.
  • the communication method of stage A is SSL and the communication system of stage B is normal
  • SSL communication is terminated according to the processing table PT1 shown in Fig. 6, and ADF is transmitted by normal communication.
  • the acquisition process is performed.
  • "SSL page ends" is displayed on the liquid crystal display 14 as a display message.
  • step S9 since the communication method of stage B is normal and the communication method of stage C is SSL, the same processing as in the case of communication pattern P1 is performed. Is performed. In this way, the processing corresponding to the communication path P2 in FIG. 3 is performed correctly.
  • the communication method of the communication pattern P3 is usually in stages A and C, and SSL in stage B.
  • steps S1 to S5 the same processing as in the case of the communication pattern P1 is performed.
  • the communication system of stage A is normal and the communication system of stage B is SSL
  • new SSL communication is started according to the processing table PT1 shown in Fig. 6. This is the process for acquiring the ADF.
  • “Start SSL communication (authenticating)” is displayed on the liquid crystal display 14 as a display message. Even if the connection method is keep-alive, it is impossible to change from the normal communication method to the SSL communication method without closing the session. Regardless, SSL communication will start anew.
  • step S9 the transition pattern and connection form from stage B to stage C are specified.
  • the determination result of step S10 is “YE S”, and the processing is performed by interrupting the processing of step S12. Then, the process returns to step S1. That is, the desired Java application is not obtained, and the process corresponding to the communication pattern P3 in FIG. 3 is performed correctly.
  • the communication method of the communication pattern P4 is normally in stage C, and is SSL in stages A and B. '
  • steps S1 to S5 the same processing as in the case of the communication pattern P1 is performed.
  • the communication method of stage A is SSL
  • an HTTP S message using the GET method is transmitted to the IP server W in step S1.
  • the communication method of stages A and B is SSL
  • processing according to the connection format from stage A to stage B is performed. That is, if the connection type is non-keep-alive, the process of starting SSL communication and acquiring ADF is performed, and the connection type is In the case of keep-alive, the process of acquiring the ADF by continuing SSL communication is performed.
  • “Start SSL communication” is displayed on the liquid crystal display 14, and in the latter case, no message is displayed on the liquid crystal display 14. The message is not displayed when the connection type is keep-alive, because a new SSL communication session is not started.
  • the communication method of the communication pattern P5 is normally in stage A, and is SSL in stages B and C.
  • steps S1 to S5 the same processing as in the case of the communication pattern P3 is performed.
  • the connection format from step B to step C is determined based on the processing table PT2 shown in FIG. Is performed.
  • the connection type is non-keep-alive
  • the process of starting SSL communication and acquiring JAR is performed
  • the connection type is keep-alive
  • SSL communication is continued to acquire JAR. Processing is performed. Note that, in the former case, “Starting SSL communication” is displayed on the liquid crystal display 14, and in the latter case, no message is displayed on the liquid crystal display 14. Thus, the processing corresponding to the communication pattern P5 in FIG. 3 is performed correctly.
  • the communication method of the communication path P6 is SSL in stages A, B and C.
  • steps S1 to S5 the same processing as in the case of the communication pattern P4 is performed.
  • step S9 the same processing as in the case of the communication pattern P5 is performed.
  • the processing corresponding to the communication pattern P6 in FIG. 3 is performed correctly.
  • the communication method of communication pattern P7 is composed of stages A, B and C Will be normal.
  • steps S1 to S5 the same processing as in the case of the communication pattern: P1 is performed.
  • steps S1 to S9 the same processing as in the case of the communication pattern: P1 is performed.
  • steps S9 since the communication method of stages B and C is normal, processing for continuing normal communication and acquiring JAR according to the processing table PT2 shown in FIG. 6 is performed. Is performed.
  • "acquiring" is displayed on the liquid crystal display 14 as a display message. In this way, the processing corresponding to the communication pattern P7 in FIG. 3 is performed correctly.
  • the communication method of communication pattern P8 is S S L in stage A and normal in stages B and C.
  • steps S1 to S5 the same processing as in the case of the communication pattern P2 is performed.
  • step S9 the same processing as in the case of the communication pattern P7 is performed.
  • the processing corresponding to the communication pattern P8 in FIG. 3 is performed correctly.
  • the processes corresponding to all the communication patterns shown in FIGS. 2 and 3 are correctly performed, the ADF is acquired by the communication of the encrypted communication method, and the normal It is possible to eliminate the need to acquire Java applications that acquire JAR through communication using the communication method.
  • the Java application transmits the personal information of the terminal user to the terminal. It is possible to prevent transmission in plaintext against the user's will.
  • the terminal is a mobile phone.
  • the data processing capacity of mobile phones is lower than that of notebook computers, and the bandwidth of the communication path is narrower than that of wired communication. It is highly likely that the operation will be restricted.
  • the Java application is divided into an ADF and a JAR so that it can be acquired and a user who refers to the attribute information of the ADF Can determine whether or not to continue acquiring JARs, so such a situation can be reliably avoided.
  • the acquired Java application is stored in the non-volatile memory, and the Java application can be used without acquiring the Java application again even after the terminal is restarted.
  • the Java application is exemplified as the data to be acquired.
  • the present invention is not limited to this, and other programs and data may be acquired.
  • the present invention is applicable when acquiring some data divided into two units from a network.
  • the communication patterns P1 and P2 in FIG. 2 are allowed, but these may be disallowed. That is, an acquisition pattern in which the communication method of stage B and the communication method of stage C do not match may not be allowed.
  • a mobile phone is exemplified as a terminal, but the present invention is not limited to this, and is applicable to a terminal capable of performing communication via a wired or wireless network.
  • the communication patterns P3 and P4 in FIG. 2 are not allowed without exception, but the present invention is not limited to this.
  • the user may be inquired about whether or not to obtain the information. If the user permits, the JAR may be received and stored.
  • the terminal can process HTTP (and HTTP S) and SSL, and the terminal can communicate directly with the IP server. It may be.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Computer And Data Communications (AREA)
  • Credit Cards Or The Like (AREA)
  • Stored Programmes (AREA)
  • Communication Control (AREA)
  • Information Transfer Between Computers (AREA)
  • Traffic Control Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Air Bags (AREA)
  • Heterocyclic Carbon Compounds Containing A Hetero Ring Having Oxygen Or Sulfur (AREA)
  • Electrical Discharge Machining, Electrochemical Machining, And Combined Machining (AREA)
  • Diaphragms For Electromechanical Transducers (AREA)

Description

明 細 書 データ取得方法および端末 技 術 分 野 本発明は、 ネットワークを介してデ一夕を取得するデータ取得方法と、 この方 法を用いてデータを取得する端末とに関する。 技 術 背 近年の通信ネットワークの発達により、 ィン夕一ネット等のネットワークを介 してデ一夕を取得すること （ダウンロード） が広く行われている。 このようにィ ン夕一ネヅト等のネットワークを介して取得したデ一夕は、 通常、 端末において 、 例えばハードディスクなどの不揮発性メモリに格納される。 不揮発性メモリに 格納されたデータは、 端末の電源を一度 OFFにして再度 ONにしたり、 端末の リセットを行うなど端末を再起動させることにより、 CPU (Central Processi ng Unit)および RAM (Random Access Memory) が初期化された後でも、 デ —夕が格納されている不揮発性メモリからデ一夕を読み出すことによって、 再び 利用することができる。
また、 インターネット等のネットワークを介してデ一夕を取得する際に、 取得 したデ一夕を RAM等の揮発性メモリに格納することも行われている。 このよう に取得されるデータとしては、 例えば J a vaアブレットが挙げられる。 J av aァプレットとは、 J a vaをもちいて作成されたプログラム （Javaアプリ ケ一シヨン） の一種である。 J avaァプレットは、 イン夕一ネット等のネヅト ワークを介して取得され、 端末の揮発性メモリに格納される。 端末に取得された J a V aァプレットは、 HTML (Hyper Text Markup Language) により記 述された We bページを閲覧するブラウザおよび J a v a仮想マシンによる制御 の下で実行される。 前述したように端末を再起動させた時には、 RAM等の揮発 性メモリは初期化され、 揮発性メモリに格納されていたデ一夕は消去される。 ィ ン夕一ネット等のネットワークを介して取得したデ一夕を揮発性メモリに格納す る場合には、 端末の再起動後は、 再度インタ一ネット等のネットワークを介して データを取得しない限り再び利用することができない。
なお、 一般に J a V aアプリケーションには、 J a v aァプレットと異なり、 イン夕一ネット等のネットワークから取得後に不揮発性メモリに格納され、 端末 が再起動された後でも、 再度インターネット等などのネットワークから取得する 必要のないものも存在する。 また、 予め端末の不揮発性メモリに格納され、 ネッ トワークからの取得を必要としない J a v aアプリケーションも存在する。 しか し、 本発明はネットワークからのデータ取得を前提としていることから、 本明細 書における 「 J a v aアプリケーション」 は、 ネットワークから取得されるもの とする。
ところで、 イン夕一ネット等のネットワークから取得したデータを不揮発性メ モリ格納するにせよ揮発性メモリに格納するにせよ、 イン夕一ネット等のネット ワークからのデ一夕取得は、 ファイル単位で行われるのが普通である。 例えば、 H T T P (HyperText Transfer Protocol) により W e bサーバから 1つのファ ィルからなる J a V aアプリケーションの取得を行う場合、 J a V aアプリケー シヨンの取得は、 1回のセッション、 すなわち W e bサーバとの接続、 情報の要 求と応答、 W e bサーバとの接続の切断により実現される。 この場合、 利用者が 端末を操作して J a v aアプリケーションの取得を指示すると、 即座に当該 J a v aアプリケーションの取得が開始され、 J a v aアプリケーション全体の取得 が完了するまでの間、 W e bサーバと端末の間の接続は維持され、 端末には、 例 えばファイルを取得中である旨のメヅセージなどが表示される。
このようなデ一夕の取得形態では、 端末の利用者が、 J a v aアプリケ一ショ ンのファイルサイズ等の属性情報を J a v aアプリケーションの取得を開始する 前に知ることができず、 端末の利用者は J a V aアプリケーションを取得するた めに要する時間を予想することができない。 このため、 例えば複数のファイルか らなる J a v aアプリケ一ションの場合には、 データを取得する処理によつて端 末の動作が制限される時間が、 利用者の予想を超えて長時間にわたる虞がある。 このことは特に通信帯域や処理能力が著しく制限された端末、 例えばブラゥザ を搭載した携帯電話機等において極めて重大である。 もちろん、 J a v aアプリ ケーシヨンのファイル名やファイルサイズ等の属性情報を W e bページに記述し 、 端末の利用者に対して当該 J a v aアプリケーションの取得前に必要な属性情 報を通知するようにしてもよいが、 誤記や悪意により、 不正な属性情報が利用者 に通知される虞もある。
そこで、 J a V aアプリケーションを、 属性情報を有する A D F (Applicatio n Descriptor File) とデ一夕の実体を有する J A R (Java ARchive) との 2つ のファイルに分離し、 端末においてはこれらを順に取得することで上述の不都合 を回避することが提案されている。 なお、 J A Rとは一つまたは複数のファイル を一つにまとめた形式のファイルである。 J A Rにより、 単一のセッションにお いて、 複数のファイルまとめてダウンロードすることができ、 複数のファイルが 各々新しいセッションを発生するより、 ある程度のデ一夕の取得時間の短縮が図 られている。 しかしながら、 A D Fと J A Rの 2つのファイルに分割した場合に セキュリティの確保が困難になることについては全く留意されていないのが実情 である。 発明の開示 本発明の目的は、 分割されたデータの取得時に十分に高いセキュリティを確保 することができるデータ取得方法および端末を提供することにある。
上記目的を達成するために、 本発明は、 ネットワークを介して通信可能な端末 が、 データの属性情報を格納した第 1のデ一夕単位を前記ネットワーク側から受 信する第 1受信ステップと、 前記端末が、 前記第 1受信ステップにおいて使用さ れた通信方式と前記ネットワーク側から前記データの実体を格納した第 2のデー 夕単位を受信する時に使用される通信方式とに基づいて前記デ一夕の取得の可否 を判定する判定ステップと、 前記端末が、 前記判定ステップにおける判定結果が 「可」 の場合には前記第 2のデ一夕単位を前記ネットワーク側から受信し、 「否 」 の場合には前記第 2のデータ単位を前記ネットワーク側から受信しない第 2受 信ステップとを有するデータ取得方法を提供する。
このデータ取得方法によれば、 端末において、 データの属性情報を格納した第 1のデータ単位の受信時に使用された通信方式と当該デ一夕の実体を格納した第
2のデ一夕単位の受信時に使用される通信方式とに基づいて第 2のデ一夕単位の 受信の可否が決まる。 これにより、 例えば、 通信方式が第 1のデータ単位の受信 時と第 2のデ一夕単位の受信時とで不適切に切り換わる場合にデ一夕の取得を不 許可とすることができる。 つまり、 分割されたデ一夕の取得時に十分に高い安全 性 （セキュリティ） を確保することができる。
また、 本発明は、 前記判定ステップにおいて、 前記第 2のデ一夕単位の受信時 に使用される通信方式の安全性が前記第 1受信ステップにおいて使用された通信 方式の安全性よりも低い場合には前記データの取得を 「否」 とするデ一夕取得方 法を提供する。
また、 本発明は、 前記判定ステップでは、 前記第 1のデータ単位の受信時に使 用される通信方式が暗号化通信を用いた方式であり、 前記第 2のデータ単位の受 信時に使用される通信方式が暗号化通信を用いない方式である場合には、 前記デ —夕の取得を 「否」 とするデータ取得方法を提供する。
また、 本発明は、 前記判定ステップにおいて、 前記第 1受信ステップにおいて 使用された通信方式と前記第 2のデ一夕単位の受信時に使用される通信方式とが 不一致の場合には前記データの取得を 「否」 とするデ一夕取得方法を提供する。 また、 本発明は、 上述した各態様のいずれかに記載のデ一夕取得方法において 、 前記データを前記端末にて実行可能なコンピュータプログラムとするデ一夕取 得方法を提供する。
また、 本発明は、 上述した各態様のいずれかに記載のデータ取得方法において 、 前記データを通信を行うコンピュータプログラムとするデータ取得方法を提供 する。
また、 本発明は、 上述した各態様のいずれかに記載のデータ取得方法において 、 前記端末は、 携帯電話機であるデータ取得方法を提供する。
また、 本発明は、 データの属性情報を格納した第 1のデ一夕単位をネットヮー ク側から受信する第 1受信手段と、 前記第 1受信手段による前記第 1のデ一夕単 位の受信時に使用された通信方式と前記ネットワーク側から前記データの実体を 格納した第 2のデータ単位を受信する時に使用される通信方式とに基づいて前記 データの取得の可否を判定する判定手段と、 前記判定手段による判定結果が「可
」 の場合には前記ネットワーク側から前記第 2のデータ単位を受信し、 「否 j の 場合には前記ネヅトワーク側から前記第 2のデータ単位を受信しない第 2受信手 段とを具備する端末を提供する。' 図面の簡単な説明 図 1は、 本発明の実施形態に係る端末が J a v aアプリケーションの取得を行 う時の基本的な処理の流れを示す図である。
図 2は、 同端末の通信パターンを示す図である。
図 3は、 同端末の表示メッセージを示す図である。
図 4は、 同端末を用いたデ一夕配信システムの構成を示すブロック図である。 図 5は、 同端末の要部の構成を示すブロック図である。
図 6は、 同端末内の処理テーブル P T 1および P T 2の構成を示す概念図であ る o
図 7は、 J a v aアプリケーションの取得時に同端末が行う処理の流れを示す フローチャートである。 発明を実施するための最良の形態 以下、 図面を参照し本発明の好適な実施形態について説明する。 なお、 本発明 は、 かかる実施形態に限定されず、 その技術思想の範囲内で種々の変更が可能で ある。
[基本思想]
まず、 本実施形態におけるデータ取得方法の基本思想について説明する。 図 1は、 本実施形態に係る端末が J a V aアプリケ一ションの取得を行う時の 基本的な処理の流れを示す図であり。 図 1に示すように、 J a v aアプリケ一シ ヨンの取得および実行において、 端末の処理は、 A、 B、 C, Dの順に行われる 。 すなわち、 まず端末は、 J a v aアプリケーションを取得するためのページの 取得要求をネットワークへ送出し、 該当するページを取得する （段階 A) 。 この 状態において、 端末の利用者が端末を操作して当該ページに記述された J a v a アプリケーションを取得する旨の指示を入力すると、 端末は当該指示に応じた取 得要求をネヅトワークへ送出し、 該当する J a V aアプリケーションの A D Fを 取得して不揮発性メモリに格納する （段階 B ) 。 次に、 端末は、 当該 AD Fに対 応した J ARの取得要求をネヅトワークへ送出し、 該当する J ARを取得して不 揮発性メモリに格納する （段階 C ) 。 次に、 端末の利用者が端末を操作し、 取得 した J a v aアプリケーション （J A Rに内包されているプログラム） の実行を 指示すると、 端末において該当する J a v aアプリケーションが実行される （段 階 D ) 。
基本的な処理の流れは上述の通りであるが、 各段階に至る通信方式に応じて条 件が加わる。 例えば、 段階 Aから Cまで同一の通信方式の通信が行われる場合と 、 段階 Aは暗号化されていない通常の通信方式の通信が行われ、 以後、 段階 Cま では、 情報を暗号化して送受信するプロトコルである S S L (Secure Sockets Layer) による通信が行われる場合とでは、 端末の動作が異なる。 このような条 件に応じた端末の動作について以下に説明する。
図 2は、 本実施形態に係る端末の通信パターンを示す図であり、 この図に示す ように、 端末の通信パターンとしては通信パターン P 1〜P 8が考えられる。 通 信パターン； P 1〜P 8は、 段階 A〜Cの各通信方式 （通常/ S S L ) の順列の全 バリエ一シヨンである。
図 3は、 本実施形態に係る端末の表示メッセージを示す図である。 この図にお いては、 通信パターン P 1〜P 8に対応して、 段階 Aから段階 Bへの遷移開始時 の表示メッセージと、 段階 Bから段階 Cへの遷移開始時の表示メッセージが示さ れており、 これらの表示メッセージから端末の動作を特定することができる。 ま た、 この図には、 各通信パターンに対応して、 段階 Aから段階 Bへ移る際の接続 形式と、 段階 Bから段階 Cへ移る際の接続形式とが対応づけられており、 表示メ ヅセージは、 通信パターンと各接続形式に対応している。 ただし、 接続形式に依 存せずに表示メッセージが決まることもあり、 そのような接続形式の欄には 「一 」 が記載されている。 なお、 接続形式には、 接続を維持したまま複数のデ一夕転 送を行える keep-alive (キープアライブ） 形式と、 一回のデータ交換を終了する たびに接続を解除する非 keep-aHve形式とがある。非 keep-alive形式は HTTPに おける通常のデ一夕交換形式であり、 keep-alive形式は S S Lに対応した HT T P S (HyperText Transfer Protocol Security) において通常のデ一夕交換形式 である。
本実施形態では、 この図に示す動作が実現されており、 その動作については後 に詳述することから、 ここでは、 図の見方を説明する目的で動作に一例を説明す る。 例えば、 通信パターン P 6 (段階 A〜段階 Cにおける通信形式が共通して S SLのパターン) に着目すると、 段階 Aから段階 Bへ遷移する時に、 接続形式が 非 keep-aliveの場合、 段階 Aから段階 Bへの遷移開始時の表示メッセージは 「S SL通信を開始します」 となり、 さらに段階 Bから段階 Cへ遷移する時に、 接続 形式が keep-aliveの場合、 段階 Bから段階 Cへの遷移開始時の表示は行われない 。
この図において最も特徴的な点は、 通信パターン P 3および P 4については、 段階 Bから段階 Cへの遷移を不許可とする点である。 図 2に示されるように、 通 信パターン P 3および P4では、 段階 Bの通信方式が SSLであり、 かつ段階 C の通信方式が通常である。 すなわち、 本実施形態では、 暗号化通信方式の通信に より ADFを取得し、 続いて通常の通信方式の通信により JARを取得するよう な取得パターンを許容していない。 このようにしている理由については、 以下に 説明する。
通常、 ネットワークから取得した J a vaアプリケーションが実行され、 実行 された J a vaアプリケーションがネヅトワーク経由で通信を行う場合、 この J avaアプリケーションがネットワーク経由で行う通信方式は、 端末が Java アプリケーションを取得した時に使用した通信方式となる。 例えば、 S SLの通 信により取得された J a V aアプリケ一ションを実行し、 この J a V aアプリケ ーシヨンがネットワーク経由で通信を行う場合、 その通信方式は SSLに限定さ れる。 このような前提があるため、 端末側では、 J avaアプリケーションを取 得した時の通信方式が SSLであれば、 以後、 当該 J avaアプリケーションが 、 ネットワークを使用して端末利用者の個人情報を送信する場合でも、 端末利用 者の個人情報が平文で送信されることはないと判断できる。
ところで、 本実施形態のように、 ADFおよび JARを使用して J avaアブ リケ一シヨンをネットワークから取得する場合、 当該 J avaアプリケーション は JARの取得時の通信方式で通信を行うことになる。 すなわち、 通信パターン P3および P4のように、 ADF取得時の通信方式が SSLであり、 かつ JAR 取得時の通信方式が通常の場合には、 当該 JARに内包された J avaアプリケ —シヨンは、 ネットワークを使用して通信を行う場合に通常の通信方式で通信を 行うことになる。
しかしながら、 利用者は、 ADF取得時の通信方式が S SLであれば JAR取 得時の通信方式も S S Lであろうと推定しがちである。 このような、 ADF取得 時の通信方式と J AR取得時の通信方式が異なる場合を許容すると、 端末の利用 者の個人情報等が利用者の意に反して平文で送信されてしまう虞がある。 また、 端末の利用者の意に反するところで個人情報が平文で送信されると、 悪意を持つ た第 3者などに端末の利用者の個人情報が盗み見られる虞がある。 このような事 態を回避するために、 図 3に示すように、 通信パターン P 3および P 4において 段階 Bから段階 Cへの遷移が許容されていないのである。 なお、 図 2において、 通信パターン P 1および： P 2でも段階 Bの通信方式と段階 Cの通信方式は異なつ ているが、 端末において実行された J a V aアプリケーションが送信するデ一夕 は利用者が意図しているよりも強力に保護されることになるため、 本実施形態で はこれらの通信パターンを許容している。
[[構成!！
次に、 本実施形態に係る端末 Tを用いたデ一夕配信システムについて説明する 図 4は端末 Tを用いたデータ配信システムの構成を示すプロック図であり、 こ の図に示すように、 本デ一夕配信システムは、 WWW (World Wide Web)の利 用を端末 Tに許容したシステムである。
この図において、 端末 Τは移動パケヅト通信網 MP Νのパケット通信サービス を受ける端末であり、 移動パケット通信網 MP N及び図示せぬ移動電話網に無線 接続される携帯電話機である。 移動電話網は一般的な移動電話の通話サービスを 提供する網であり、 端末 Tは当該通話サービスを受けることができる。.端末丁の 詳細な機能及び構成については後述する。
移動パケット通信網 MPNは、 複数の基地局 B S、 複数のバケツト加入者処理 装置 PS、 ゲートウェイサーバ GWS、 及びこれらを接続する通信回線によって 構成されている。
基地局 B Sは、 地上を例えば半径 500m等の範囲で分割した所定間隔で配置 されており、 各々が形成する無線ゾーンに在圏した端末 Tとの間で無線通信を行 う。
バケツト加入者処理装置 PSは、 複数の基地局 BSを収容するバケツト加入者 交換局に備えられたコンピュータシステムであり、 端末 Tからのパケット交換要 求を受け付けるとともに、 受け付けたパケットを他のパケット加入者処理装置 P S及び配下の基地局 B Sの少なくとも一方を介して宛先の端末 Tへ中継する。 ゲートウェイサーバ GWSは、 移動パケット通信網 MPNとインターネット I NET等の他網とを相互接続するための移動パケット関門中継交換局に備えられ たコンピュータシステムであり、 ネットワーク間で異なる通信プロトコルの変換 を行う。 ここでいう通信プロトコルの変換とは、 具体的には、 移動パケット通信 網 MP Nが従う移動パケット通信網用の伝送プロトコルと、 イン夕一ネット IN ETが従う伝送プロトコルとの相互変換をいう。
なお、 イン夕一ネット I NE Tが従う伝送プロトコルには、 OSI参照モデル のネヅトワーク層及びトランスポート層の T C P/I P (Transmission Contro 1 Protocol/Internet Protocol) と、 この TCP/IP上で実現される HTTPや HTTPS等のプロトコルが含まれており、 移動パケット通信網 MPNが従う伝 送プロトコルには、 TCP/I Pを簡素化したプロトコル （以後、 TL) と HT TP (および HTTPS) に相当するプロトコル （以後、 AL) とが含まれてい る。 すなわち、 端末 Tは AL上で WWWを利用することになる。
また、 ゲートウェイサーバ GWSは、 端末 Tから GETメソッドを用いた HT TP (あるいは HTTPS) メヅセージを受け取ると、 当該 GETメソッドを用 いた HTTP (あるいは HTTP S) メッセージに含まれる URL (Uniform R esource Locator)を調べ、当該 URLがィン夕ーネヅ ト I NE T上の一般的な U RLである場合には、 イン夕一ネヅト I NETへ当該 GETメソヅドを用いた H TTP (あるいは HTTPS) メッセージを転送し、 この GETメソッドを用い た HTTP (あるいは HTTP S) メヅセージに対応してイン夕一ネット INE Tから送信されてきた応答を当該端末 Tへ返送する。 なお、 GETメソッドを用 いた HTTP (あるいは HTTPS) メヅセージに含まれる URLが自身内のリ ソース位置を示すものの場合には、 ゲートウェイサーバ GWSは、 当該 GETメ ソヅ ドを用いた HTTP (あるいは HTTPS) メッセージに対応して該当リソ ースを端末 Tへ返送する。
I Pサーバ Wはイン夕一ネヅト I NETに接続されたサーバであり、 WWWを 利用するクライアントに対して様々なサ一ビスを提供する。 具体的には、 IPサ ーバ Wは、 インターネット INET経由で GETメソッドを用いた HTTP (あ るいは HTTPS) メッセ一ジ要求を受け取ると、 当該 GETメソヅドを用いた HTTP (あるいは HTTPS) メヅセージに含まれる UR Lで特定されるリソ —ス （本実施形態では著作物ファイル） を返送する。 なお、 本実施形態において は、 I Pサーバ Wは J a V aアプリケーションを配信するものであり、 IPサ一 バ Wと端末 Tとの間の全ての通信は HTTP (および HTTPS)および A Lに より行われるようになつている。 また、 I Pサーバ Wおよび端末 Tは共に、 HT TP (および H TTP S)における keep-alive/非 keep-aJiveによるデータ交換形 式と HTTP Sにおける S SLに対応している。
次に、 端末 Tの構成について説明する。 ただし、 ここでは、 本発明に直接的に 関連する要部の構成について説明する。
図 5は端末 Tの要部の構成を示すブロック図であり、 この図に示すように、 端 末 Tは、 基地局 BSとの無線通信を行う送受信部 （例えばアンテナ、 無線部、 送 信機、 受信機等を有する） 11、 発音するための発音部 （例えば音源やスピーカ 等から構成される） 12、 数字入力、 文字入力等の入力操作が行われる、 キ一パ ッド等を備えた入力部 13、 所定サイズの表示領域を有する液晶ディスプレイ 1 4、 これら各部を制御する制御部 15を内蔵している。 制御部 15は各種制御を行う CPU151と、 CPU151に実行されるブラ ゥザ、 J ava仮想マシンを実現するソフトウェア、 端末 Tの制御プログラム等 のソフトウェア、 ゲートゥヱイサーバ GWSとの接続に必要な情報、 および後述 する処理テーブル P T 1 , PT 2等を格納した ROM (Read Only Memory) 1 52と、 受信したデ一夕や利用者の設定内容 （例えば JARの自動取得の可否） 等を端末を再起動させた後でも再度利用することが可能なように格納するフラッ シュメモリ 153と、 受信したデ一夕を端末を再起動させた後では再度利用する ことができないように格納するとともに CPU 151のワークメモリとして使用 される RAM 154とを内蔵している。
CPU 151は、 図示せぬ電源が投入されると、 ROM 152に格納された制 御プログラムを読み出して実行し、 .制御プログラムおよび入力部 13から入力さ れる利用者の指示に従って ROM 152、 フラッシュメモリ 153、 RAM 15 4、 各部 11〜Γ3、 及び液晶ディスプレイ 14を制御する。 また、 CPU 15 1は、 入力部 13から入力される利用者の指示に従って、 ブラウザを起動し、 こ のブラウザ上で入力部 13からの指示に応じた通信を行う機能を有する。 さらに 、 CPU 151は、 ROM 152に格納された処理テーブル PT 1, PT2 (図 6参照） に基づいて通信処理を制御する機能を有する。 この機能による具体的な 動作については後述する。
また、 CPU151は、 フラッシュメモリ 153に格納した Javaアプリケ ーシヨンを実行する際に J ava仮想マシンを起動し、 この J ava仮想マシン 上で当該 J avaアプリケーションを実行する。 さらに、 CPU151は、 RA Ml 54に格納した J avaアプリケーション （J avaアブレツト） として実 行する際に J ava仮想マシンおよびブラウザを起動し、 これらの上で当該 J a vaアプリケーションを実行する。
端末 Tによるデ一夕の取得は、 まず、 CPU151が ROM152に格納され たブラウザを読み出し当該ブラウザを実行することにより、 ： ROM 152に格納 されたホーム URL (最初にアクセスすべきゲートウェイ GWS上のリソース位 置） から HTMLデータを取得し、 このデ一夕に基づいて、 液晶ディスプレイ 1 5に対話画面 （ページ） を表示させ、 この対話画面を視認した利用者が入力部 1 3を操作することで行われる。
[ J a V aアプリケ一ション取得動作]
図 7は J a V aアプリケーションの取得時に端末 Tが行う処理の流れを示すフ ローチャートであり、 以下、 主に図 2、 図 3、 図 6および図 7を参照し、 端末で が J avaアプリケーションを I Pサーバ Wから取得する動作について、 通信パ ターン毎に説明する。 ただし、 以降の説明において、 通信パターン間で重複する 説明は極力省略されている。 なお、 端末 Tにおいては既にブラウザが起動されて いるものとする。 また、 取得対象の J avaアプリケーションの取得形態として は不揮発性メモリに格納/揮発性メモリに格納があるが、 ここでは、 説明が繁雑 になるのを避けるために J a V aアプリケ一ション取得後に不揮発性メモリに格 納する例についてのみ説明する。
( 1) 通信パターン P 1の場合
図 2に示されるように、 通信パターン P 1の通信方式は、 段階 Aおよび段階 B では通常、 段階 Cでは S SLとなる。
まず、 端末 Tは所望の J avaアプリケーションを取得するためのページ （以 後、 ダウンロードページ） を取得する （ステップ S 1 ) 。 具体的には、 端末 Tの CPU 151 (図 5参照） が、 入力部 13から入力された利用者の指示に基づい て送受信部 1 1を制御し、 送受信部 1 1が当該指示に応じた G E Tメソッドを用 いた HTTPメッセージを IPサーバ W (図 4参照） へ送信する。 これに応答し て、 所望のダウンロードページの HTMLデ一夕が I Pサーバ Wから返送される 。 この HTMLデータは送受信部 1 1に受信され、 送受信部 1 1から CPU 15 1へ渡される。 CPU 151は当該 HTMLデータを RAMI 54に格納し、 更 にこれを解釈 ·実行することでユーザインタフヱ一スを提供する。 この結果、 液 晶ディスプレイ 14には当該ユーザィン夕フェースによる画面が表示される。 次に、 端末 Tは、 利用者による指示の入力を待ち （ステップ S 2) 、 ここで入 力された指示が所望の J a V aアプリケ一ションの取得指示でない場合には取得 処理を終了する （ステップ S 3) 。 具体的には、 端末 Tの CPU151は入力部 13から入力された指示と現在のュ一ザィン夕フヱ一スとに基づいて利用者の指 示内容を特定し、 他のページの取得指示が入力された場合や図示せぬ電源の切断 が指示された場合等の、 J a V aアプリケーションの取得とは異なる内容の指示 が入力された場合には取得処理を終了する。
逆に、 ステップ S 2において入力された指示が所望の J a vaアプリケ一ショ ンの取得を求めるものである場合には （ステップ S3)、 ステップ S 1にて取得 した HTMLデ一夕により、 段階 Aから段階 Bへの遷移パターンおよび接続形式 が特定され （ステップ S 4)、 特定した結果に応じた処理が行われるとともに、 該当する ADFが取得される （ステップ S 5) 。 ここでは、 段階 Aおよび Bの通 信方式は通常であることから、 図 6に示す処理テーブル PT 1に従って、 通常通 信をによって ADFを取得する処理が行われる。 この際、 液晶ディスプレイ 14 には表示メヅセージとして 「取得中」 が表示される。 なお、 図 6の処理テーブル PT 1から明らかなように、 このケースでは接続形式に関わらず処理内容が決定 される。 また、 段階 Bの通信方式は端末の利用者が決めるのではなく、 ステップ S 4において、 ステップ S 1にて取得した HTMLデータに内包されている、 A DFを取得するための URLを参照することにより判明する。 具体的には、 UR Lの先頭は WWWサーバへアクセスするための通信方式を示しており、 URLが 「ht tp」 で始まる場合には、 通信方式は HTTPを示しているため 「通常」 となり、 URLが「ht t ps」 で始まる場合には、 通信方式は HTTP Sを示 しているため 「S SL」 となる。
ADFの取得が完了すると、 JARの自動取得が許可されていない場合には （ ステップ S 6)、 端末 Tは継続して JARを取得するか否かを利用者に問い合わ せ （ステップ S 7)、 この問い合わせに応じて JARの取得を継続する旨の指示 が入力されると （ステップ S 8) 、 ステップ S 9の処理へ進む。 逆に JARの取 得を中断する旨の指示が入力されると中断処理が行われ （ステップ S 12)、 処 理はステヅプ S 1に戻る。 また、 JARの自動取得が許可されている場合には （ ステップ S 6) 、 処理は即座にステップ S 9へ進む。
なお、 端末 Tは J A Rの自動取得の許可/不許可を設定する機能を有している 。 CPU 151は入力部 13から入力された指示に応じて、 JARの自動取得の 許可/不許可を設定するビヅトであるフラッシュメモリ 153の所定ビヅトをセ ヅトノリセットする。 したがって、 当該ビットを参照することにより、 CPU1 51は JARの自動取得の許可/不許可を知ることができる。 また、 ステップ S 12の中断処理では、 CPU 151は J a vaアプリケーションを取得する処理 を中断し、 フラッシュメモリ 153に格納された該当する ADFを破棄し、 フラ ヅシュメモリ 153の記憶容量を有効に活用するようにしている。
次に、 段階 Bから段階 Cへの遷移パターンおよび接続形式が特定され （ステツ プ S9)、 特定結果に応じて JARの取得処理が行われる （ステップ S 10, S 11) 。 ここでは、 段階 Bの通信方式は通常であり、 かつ段階 Cの通信方式は S SLであることから、 処理テーブル PT 2に従い、 新規に SSL通信を開始して JARを取得する処理となる。 この際、 液晶ディスプレイ 14には表示メッセ一 ジとして 「SSL通信を開始します （認証中） 」 が表示される。 このように、 図 3の遷移パターン P 1に対応した処理が正しく行われる。 なお、 図 6の処理テ一 ブル P T 2から明らかなように、 このケースでは接続形式に関わらず処理内容が 決定される。 また、 段階 Cの通信方式はステップ S 9において、 ステップ S 5に て取得した ADFファイルに内包されている、 JARを取得するための URLを 参照することにより判明する。 ADFを取得する時と同様に、 URLが「ht t p」 で始まる場合には、 通信方式は 「通常」 となり、 URLが 「ht t ps」 で 始まる場合には、 通信方式は 「SSL」 となる。
(2)通信パターン P 2の場合
図 2に示されるように、 通信パターン P 2の通信方式.は、 段階 Bでは通常、 段 階 Aおよび Cでは S S Lとなる。
まず、 ステップ S 1〜S 5において、 通信パターン P 1の場合と同様の処理が 行われる。 ただし、 段階 Aの通信方式は S S Lであることから、 ステップ S 1で は GE Tメソヅドを用いた HT TP Sメヅセージを I Pサ一バ Wへ送信する。 ま た、 ここでは段階 Aの通信方式は SSLであり、 かつ段階 Bの通信方式は通常で あることから、 図 6に示す処理テーブル PT 1に従い、 SSL通信を終了し、 通 常通信により ADFを取得する処理が行われる。 この際、 液晶ディスプレイ 14 には表示メッセージとして 「S SLページを終了します」 が表示される。
また、 ステップ S 9以降においては、 段階 Bの通信方式は通常であり、 かつ段 階 Cの通信方式は SSLであることから、 通信パターン P 1の場合と同一の処理 が行われる。 このように、 図 3の通信パ夕一ン P 2に対応した処理が正しく行わ れる。
(3)通信パターン P 3の場合
図 2に示されるように、 通信パターン P 3の通信方式は、 段階 Aおよび Cでは 通常、 段階 Bでは SSLとなる。
まず、 ステップ S 1〜S 5において、 通信パターン P 1の場合と同様の処理が 行われる。 ただし、 ここでは、 段階 Aの通信方式は通常であり、 かつ段階 Bの通 信方式は S SLであることから、 図 6に示す処理テ一ブル PT 1に従い、 新規に SSL通信を開始して ADFを取得する処理となる。 この際、 液晶ディスプレイ 14には表示メッセージとして 「SSL通信を開始します （認証中） 」 が表示さ れる。 なお、 たとえ接続方式が keep-aliveであったとしても、 セッションをクロ ーズすることなく通常の通信方式から S S Lの通信方式へ変更することは不可能 であることから、 ここでは、 接続形式に関わらず、 新規に S SL通信を開始する ことになる。
次に、 段階 Bから段階 Cへの遷移パターンおよび接続形式が特定される （ステ ヅプ S9) 。 ここでは、 段階 Bの通信方式は S SLであり、 かつ段階 Cの通信方 式は通常であることから、 ステップ S 10の判断結果が「YE S」 となり、 処理 はステップ S 12の中断処理を経てステップ S 1に戻る。 すなわち、 所望の J a v aアプリケーションは取得されず、 図 3の通信ノ ターン P 3に対応した処理が 正しく行われる。
(4)通信パターン P 4の場合
図 2に示されるように、 通信パターン P 4の通信方式は、 段階 Cでは通常、 段 階 Aおよび Bでは S S Lとなる。 '
まず、 ステップ S 1〜S 5において、 通信パターン P 1の場合と同様の処理が 行われる。 ただし、 段階 Aの通信方式は SSLであることから、 ステップ S 1で は GETメソヅドを用いた HTTP Sメッセージを I Pサーバ Wへ送信する。 ま た、 ここでは、 段階 Aおよび Bの通信方式は S SLであることから、 段階 Aから 段階 Bへの接続形式に従った処理が行われる。 すなわち、 接続形式が非 keep-ali veの場合には S S L通信を開始して AD Fを取得する処理が行われ、 接続形式が keep-aliveの場合には S S L通信を継続して A D Fを取得する処理が行われる。 なお、 前者の場合には、 液晶ディスプレイ 1 4に 「S S L通信を開始します」 が 表示され、 後者の場合には、 液晶ディスプレイ 1 4にメッセージは表示されない 。 接続形式が keep-aliveの場合にメッセージが表示されないのは、 S S L通信の セッションが新たに開始される訳ではない為である。
また、 段階 Bの通信方式は S S Lであり、 かつ段階 Cの通信方式は通常である ことから、 通信パターン P 3の場合と同一の処理が行われる。 このように、 図 3 の通信パ夕ーン P 4に対応した処理が正しく行われる。
( 5 ) 通信パ夕一ン P 5の場合
図 2に示されるように、 通信パターン P 5の通信方式は、 段階 Aでは通常、 段 階 Bおよび Cでは S S Lとなる。
まず、 ステップ S 1〜S 5において、 通信パターン P 3の場合と同一の処理が '行われる。 次に、 ステップ S 9以降の処理においては、 段階 Bおよび Cの通信方 式が S S Lであることから、 図 6に示す処理テーブル P T 2に基づいて、 段階 B から段階 Cへの接続形式に従った処理が行われる。 すなわち、 接続形式が非 keep -aliveの場合には S S L通信を開始して J ARを取得する処理が行われ、 接続形 式が keep-aliveの場合には S S L通信を継続して J A Rを取得する処理が行われ る。 なお、 前者の場合には、 液晶ディスプレイ 1 4に 「S S L通信を開始します 」 が表示され、 後者の場合には、 液晶ディスプレイ 1 4にメッセージは表示され ない。 このように、 図 3の通信パターン P 5に対応した処理が正しく行われる。
( 6 ) 通信パターン P 6の場合
図 2に示されるように、 通信パ夕一ン： P 6の通信方式は、 段階 A、 Bおよび C において S S Lとなる。
まず、 ステップ S 1〜S 5において、 通信パターン P 4の場合と同一の処理が 行われる。 次に、 ステップ S 9以降の処理においては、 通信パターン P 5の場合 と同一の処理が行われる。 このように、 図 3の通信パターン P 6に対応した処理 が正しく行われる。
( 7 ) 通信パターン; P 7の場合
図 2に示されるように、 通信パターン P 7の通信方式は、 段階 A、 Bおよび C において通常となる。
まず、 ステップ S 1〜S 5において、 通信パターン: P 1の場合と同一の処理が 行われる。 次に、 ステップ S 9以降の処理においては、 段階 Bおよび Cの通信方 式が通常であることから、 図 6に示す処理テーブル P T 2に従い、 通常通信を継 続して J ARを取得する処理が行われる。 この際、 液晶ディスプレイ 1 4には表 示メッセージとして 「取得中」 が表示される。 このように、 図 3の通信パターン P 7に対応した処理が正しく行われる。
( 8 ) 通信パターン P 8の場合
図 2に示されるように、 通信パターン P 8の通信方式は、 段階 Aでは S S L、 段階 Bおよび Cでは通常となる。
まず、 ステップ S 1〜S 5において、 通信パターン P 2の場合と同一の処理が 行われる。 次に、 ステップ S 9以降の処理においては、 通信パターン P 7の場合 と同一の処理が行われる。 このように、 図 3の通信パターン P 8に対応した処理 が正しく行われる。
[補足]
以上説明したように、 本実施形態によれば、 図 2および図 3に示す全ての通信 パターンに対応した処理が正しく行われ、 暗号化通信方式の通信により AD Fを 取得し、 続いて通常の通信方式の通信により J ARを取得するような J a v aァ プリケ一シヨンの取得ノ 夕一ンを排除することができる。
したがって、 端末の使用者が、 取得した J a v aアプリケーションを実行し、 実行された J a v aアプリケーションがネットワークを使用して通信を行う場合 、 J a V aアプリケーションが端末の使用者の個人情報等を端末の使用者の意に 反して平文で送信することを防ぐことができる。
また、 上述した実施形態では、 端末を携帯電話機としている点も効果的である 。 携帯電話機のデータ処理能力はノート型のコンピュータ等に比較して低く、 そ の通信路の帯域も有線通信に比較して狭いため、 従来の技術では利用者の想定を 超えた長時間にわたって端末の動作が制限されてしまう事態が発生する可能性が 高い。 しかし、 本実施形態においては、 J a v aアプリケーションを AD Fと J ARとに分割して取得できるようにし、 かつ A D Fの属性情報を参照した利用者 が J A Rの取得を継続するか否かを決定できるようにしたため、 そのような事態 を確実に回避することができる。
なお、 上述した実施形態では、 取得した J a vaアプリケーションを不揮発性 メモリに格納し、 端末を再起動した後でも再度 J a V aアプリケーションを取得 することなく J avaアプリケーション利用可能にする例を示したが、 取得した J avaアプリケーションを揮発性メモリに格納し、 端末を再起動した後は、 再 度 J avaアプリケーションを取得するようにすることも可能である。
また、 上述した実施形態では、 取得するデ一夕として J avaアプリケ一ショ ンを例示したが、 これに限らず、 他のプログラムゃデ一夕であってもよい。 要す るに、 本発明は、 2つの単位に分割された何らかのデータをネットワークから取 得する場合に適用可能である。
また、 上述した実施形態では、 図 2の通信パターン P 1および P2を許容して いるが、 これらを不許可とするようにしてもよい。 すなわち、 段階 Bの通信方式 と段階 Cの通信方式が不一致となる取得パターンを許容しないようにしてもよい 。
また、 上述した実施形態では、 端末として携帯電話機を例示したが、 本発明は これに限定されるものではなく、 有線または無線のネットワークを介して通信を 行うことができる端末に適用可能である。
また、 上述した実施形態では、 図 2の通信パターン P 3および P4を例外なく 許容しないが、 本発明はこれに限定されるものではない。 例えば、 図 2の通信パ ターン P 3および P 4の場合には取得の可否を利用者に問い合わせ、 利用者が許 可した場合には JARを受信 '格納するようにしてもよいし、 J avaアプリケ —シヨンの種類を ADFに包含させ、 図 2の通信パターン P 3および P 4であつ ても対象の J avaアプリケーションが通信を行わない種類のアプリケーション であれば JARを受信 ·格納するようにしてもよい。
また、 上述した実施形態では、 HTTP (および HTTPS) および ALを用 いてデータを転送する例を挙げたが、 本発明においては、 暗号化通信を実現でき る任意の通信プロトコルを採用可能である。 もちろん、 keep-aliveおよび非 keep- aliveに対応した任意の通信プロトコルであってもよいし、これらに対応していな い通信プロトコルであってもよい。
また、 上述した実施形態では、 ゲートゥヱイサーバ GWSにおいて通信プロト コルを変換する例を示したが、 これはあくまで一例である。 例えば、 端末におい て HTTP (および HTTP S) および S SLを処理できるようにし、 端末と I Pサーバとの間で直接的に通信するようにしてもよいし、 複数回の変換を経て通 信するようにしてもよい。

Claims

請 求 の 範 囲
1 . ネットワークを介して通信可能な端末が、データの属性情報を格納した第 1 のデータ単位を前記ネットワーク側から受信する第 1受信ステツプと、
前記端末が、 前記第 1受信ステップにおいて使用された通信方式と前記ネット ワーク側から前記データの実体を格納した第 2のデータ単位を受信する時に使用 される通信方式とに基づいて前記データの取得の可否を判定する判定ステップと 前記端末が、 前記判定ステップにおける判定結果が「可」 の場合には前記第 2 のデ一夕単位を前記ネットワーク側から受信し、 「否」 の場合には前記第 2のデ 一夕単位を前記ネットワーク側から受信しない第 2受信ステツプと
を有することを特徴とするデ一夕取得方法。
2 . 前記判定ステツプでは、前記第 2のデ一夕単位の受信時に使用される通信方 式の安全性が前記第 1受信ステツプにおいて使用された通信方式の安全性よりも 低い場合には前記データの取得を 「否」 とする
ことを特徴とする請求項 1に記載のデータ取得方法。
3 . 前記判定ステツプでは、前記第 1のデータ単位の受信時に使用される通信方 式が暗号化通信を用いた方式であり、 前記第 2のデ一夕単位の受信時に使用され る通信方式が暗号化通信を用いない方式である場合には、 前記データの取得を 「 否」 とする
ことを特徴とする請求項 1に記載のデ一夕取得方法。
4 . 前記判定ステツプでは、前記第 1受信ステヅプにおいて使用された通信方式 と前記第 2のデ一夕単位の受信時に使用される通信方式とが不一致の場合には前 記データの取得を 「否」 とする
ことを特徴とする請求項 1に記載のデ一夕取得方法。
5 . 前記データは前記端末にて実行可能なコンビユー夕プログラムである ことを特徴とする請求項 1に記載のデータ取得方法。
6 . 前記コンビュ一夕プログラムは通信を行うコンピュータプログラムである ことを特徴とする請求項 5に記載のデ一夕取得方法。
7 . 前記端末は携帯電話機である
ことを特徴とする請求項 1に記載のデ一夕取得方法。
8 . デ一夕の属性情報を格納した第 1のデータ単位をネ トヮ一ク側から受信 する第 1受信手段と、
前記第 1受信手段による前記第 1のデータ単位の受信時に使用された通信方式 と前記ネットワーク側から前記デ一夕の実体を格納した第 2のデ一夕単位を受信 する時に使用される通信方式とに基づいて前記デ一夕の取得の可否を判定する判 定手段と、
前記判定手段による判定結果が 「可」 の場合には前記ネットワーク側から前記 第 2のデ一夕単位を受信し、 「否」 の場合には前記ネットワーク側から前記第 2 のデータ単位を受信しない第 2受信手段と
. を具備することを特徴とする端末。
PCT/JP2001/010170 2000-11-24 2001-11-21 Procede et terminal d'acquisition de donnees WO2002042918A1 (fr)

Priority Applications (11)

Application Number Priority Date Filing Date Title
PL01356885A PL356885A1 (en) 2000-11-24 2001-11-21 Data acquiring method and terminal
US10/204,363 US7174333B2 (en) 2000-11-24 2001-11-21 Data obtaining method and terminals
EP01997742A EP1338971B1 (en) 2000-11-24 2001-11-21 Method and terminal for the secure acquisition of applications
DE60126421T DE60126421T2 (de) 2000-11-24 2001-11-21 Verfahren und terminal zum sicheren bezug von programmen
AU2002224062A AU2002224062B8 (en) 2000-11-24 2001-11-21 Data acquiring method and terminal
BR0107377-0A BR0107377A (pt) 2000-11-24 2001-11-21 Aperfeiçoamento introduzido em método para a obtenção de dados e terminais para a obtenção de dados através do dito método
CA002394294A CA2394294C (en) 2000-11-24 2001-11-21 Data obtaining method and terminals
NZ519408A NZ519408A (en) 2000-11-24 2001-11-21 Data obtaining method and terminals when the communication mode is secure or allowable
AU2406202A AU2406202A (en) 2000-11-24 2001-11-21 Data acquiring method and terminal
NO20023491A NO324486B1 (no) 2000-11-24 2002-07-22 Fremgangsmate og terminaler for tilveiebringing av data
HK03108031A HK1056024A1 (en) 2000-11-24 2003-11-06 Method and terminal for the secure acquisition of applications

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2000-358046 2000-11-24
JP2000358046A JP3692290B2 (ja) 2000-11-24 2000-11-24 データ取得方法および端末

Publications (1)

Publication Number Publication Date
WO2002042918A1 true WO2002042918A1 (fr) 2002-05-30

Family

ID=18830014

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2001/010170 WO2002042918A1 (fr) 2000-11-24 2001-11-21 Procede et terminal d'acquisition de donnees

Country Status (17)

Country Link
US (1) US7174333B2 (ja)
EP (1) EP1338971B1 (ja)
JP (1) JP3692290B2 (ja)
KR (1) KR100436687B1 (ja)
CN (1) CN1198432C (ja)
AT (1) ATE353150T1 (ja)
AU (2) AU2002224062B8 (ja)
BR (1) BR0107377A (ja)
CA (1) CA2394294C (ja)
DE (1) DE60126421T2 (ja)
ES (1) ES2280433T3 (ja)
HK (1) HK1056024A1 (ja)
NO (1) NO324486B1 (ja)
NZ (1) NZ519408A (ja)
PL (1) PL356885A1 (ja)
TW (1) TWI222817B (ja)
WO (1) WO2002042918A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8406734B2 (en) * 2003-05-15 2013-03-26 Vodafone Group Plc Resource access control for mobile terminal

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2002351415A1 (en) * 2001-12-28 2003-07-24 Postx Corporation System and method for applet caching
JP4222774B2 (ja) * 2002-05-20 2009-02-12 株式会社エヌ・ティ・ティ・ドコモ 携帯端末およびプログラムの起動方法
JP4323190B2 (ja) * 2003-03-07 2009-09-02 株式会社エヌ・ティ・ティ・ドコモ 通信端末
US7694022B2 (en) * 2004-02-24 2010-04-06 Microsoft Corporation Method and system for filtering communications to prevent exploitation of a software vulnerability
FR2887097A1 (fr) * 2005-06-14 2006-12-15 France Telecom Procede de protection d'un code-source en langage semi-interprete
JP4754922B2 (ja) * 2005-09-30 2011-08-24 富士通株式会社 ワーム感染装置の検出装置
JP4916825B2 (ja) * 2006-09-08 2012-04-18 株式会社エヌ・ティ・ティ・ドコモ 通信端末装置及びそれを用いたデータ取得方法
US8127020B2 (en) * 2008-08-28 2012-02-28 Red Hat, Inc. HTTP standby connection
US8762876B2 (en) * 2012-06-21 2014-06-24 Google Inc. Secure data entry via a virtual keyboard
CN106257879B (zh) * 2015-06-16 2020-02-14 阿里巴巴集团控股有限公司 一种下载应用的方法和装置

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000285048A (ja) * 1999-03-31 2000-10-13 Toshiba Corp 情報ダウンロード機能付きサーバ及び端末並びに記録媒体
JP2000305849A (ja) * 1999-04-21 2000-11-02 Dainippon Printing Co Ltd 送信装置とその方法、受信装置とその方法および通信システム

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06284148A (ja) 1993-03-30 1994-10-07 Hitachi Ltd 動画通信制御方法及び通信制御装置
JPH09102857A (ja) 1995-10-04 1997-04-15 Canon Inc ファクシミリ装置
US6615258B1 (en) * 1997-09-26 2003-09-02 Worldcom, Inc. Integrated customer interface for web based data management
US6810405B1 (en) * 1998-08-18 2004-10-26 Starfish Software, Inc. System and methods for synchronizing data between multiple datasets
US6418472B1 (en) * 1999-01-19 2002-07-09 Intel Corporation System and method for using internet based caller ID for controlling access to an object stored in a computer
US6772159B1 (en) * 2000-02-24 2004-08-03 International Business Machines Corporation System and method for disconnected database access by heterogeneous clients
US6766353B1 (en) * 2000-07-11 2004-07-20 Motorola, Inc. Method for authenticating a JAVA archive (JAR) for portable devices
US6823461B2 (en) * 2002-06-27 2004-11-23 Nokia Corporation Method and system for securely transferring context updates towards a mobile node in a wireless network

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000285048A (ja) * 1999-03-31 2000-10-13 Toshiba Corp 情報ダウンロード機能付きサーバ及び端末並びに記録媒体
JP2000305849A (ja) * 1999-04-21 2000-11-02 Dainippon Printing Co Ltd 送信装置とその方法、受信装置とその方法および通信システム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8406734B2 (en) * 2003-05-15 2013-03-26 Vodafone Group Plc Resource access control for mobile terminal

Also Published As

Publication number Publication date
DE60126421T2 (de) 2007-10-25
US7174333B2 (en) 2007-02-06
PL356885A1 (en) 2004-07-12
BR0107377A (pt) 2002-09-24
NO20023491D0 (no) 2002-07-22
HK1056024A1 (en) 2004-01-30
EP1338971B1 (en) 2007-01-31
EP1338971A4 (en) 2005-09-28
NO20023491L (no) 2002-09-19
JP2002163111A (ja) 2002-06-07
CN1395704A (zh) 2003-02-05
AU2002224062B2 (en) 2005-06-23
CA2394294A1 (en) 2002-05-30
KR100436687B1 (ko) 2004-06-18
NO324486B1 (no) 2007-10-29
CA2394294C (en) 2009-10-13
ES2280433T3 (es) 2007-09-16
EP1338971A1 (en) 2003-08-27
US20030097373A1 (en) 2003-05-22
AU2002224062B8 (en) 2005-07-21
CN1198432C (zh) 2005-04-20
JP3692290B2 (ja) 2005-09-07
KR20020079798A (ko) 2002-10-19
AU2406202A (en) 2002-06-03
TWI222817B (en) 2004-10-21
DE60126421D1 (de) 2007-03-22
ATE353150T1 (de) 2007-02-15
NZ519408A (en) 2004-05-28

Similar Documents

Publication Publication Date Title
US6292833B1 (en) Method and apparatus for providing access control to local services of mobile devices
JP4282237B2 (ja) サーバ・コンピュータへのアクセス方法
US8509754B2 (en) Distributing mobile-device applications
KR100509070B1 (ko) 무선 통신 기기 간 직접 데이터 통신 처리 방법
KR20010024509A (ko) 목적지를 기초로 하여 네트워크 접속을 제어하기 위한방법 및 장치
JP5161244B2 (ja) 通信デバイス間で共通のロケーション関連情報を共有するためのシステム及び方法
US20060224712A1 (en) Device management in a communication system
CA2714627C (en) Method and apparatus for provisioning dual mode wireless client devices in a telecommunications system
US20050108574A1 (en) Method and system for communication between a multi-modal device and a web application
US8312151B2 (en) Communication systems and methods for dynamic and secure simplification of equipment networking
WO2002042918A1 (fr) Procede et terminal d'acquisition de donnees
JP2002082910A (ja) ユーザ認証システム及びユーザ認証方法
JP2000184462A (ja) 移動局からサ―ビス・サ―バへのアクセス方法、並びに、それに対応する移動局における加入者識別モジュ―ル及び端末
JP2004336256A (ja) データ通信システム
US20050181819A1 (en) Communication system, communication terminal device, and information storage module
TWI393406B (zh) Integrating mobile content sharing and delivery system and its method in integrated network environment
JP2010050750A (ja) 通信端末、通信制御方法、通信制御プログラム及び通信システム
EP1533975A2 (en) Method and System for communication between a multi-modal device and a Web Application
JP2017147672A (ja) 通信装置、サーバおよびシステム
JP2001159995A (ja) ファイル転送方法、ファイル受信装置、及びファイル提供装置
JP2003283668A (ja) 携帯情報通信端末装置のサービス設定変更方法、携帯情報通信端末装置のサービス設定自動変更システム、携帯情報通信端末装置、管理サーバネットワークシステム
JP2007288760A (ja) 移動通信端末機
JP2008098833A (ja) サーバ装置
JP2003069729A (ja) 通信方法、情報端末装置、情報管理サーバ装置及びプログラム
JP2005123906A (ja) データリンク起動方法とデータ通信システム

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AU BR CA CN KR NO NZ PL SG US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

WWE Wipo information: entry into national phase

Ref document number: 519408

Country of ref document: NZ

WWE Wipo information: entry into national phase

Ref document number: 2394294

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2001997742

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 1020027009453

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 01804056X

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 10204363

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2002224062

Country of ref document: AU

WWP Wipo information: published in national office

Ref document number: 1020027009453

Country of ref document: KR

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 2001997742

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 1020027009453

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 519408

Country of ref document: NZ

WWG Wipo information: grant in national office

Ref document number: 519408

Country of ref document: NZ

WWG Wipo information: grant in national office

Ref document number: 2002224062

Country of ref document: AU

WWG Wipo information: grant in national office

Ref document number: 2001997742

Country of ref document: EP