JP2006067363A - Display data determining apparatus and display data determining method of wap gateway - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system for automatically selecting a provided mode of a function of a mobile terminal of a user or information corresponding to a desire of the user in a WAP gateway for providing menu information of the same contents by means of a plurality of modes, e.g. the FLASH and the XHTML. <P>SOLUTION: A menu request reception means of the user is provided with a means for revising a menu providing request from the user into a menu providing request by means of the FLASH or XHTML form on the basis of specification information of the terminal used by the user and indication data of a menu mode set in advance by the user when the exhibition by the FLASH and the XHTML is available for the menu providing request from the user and the menu request means transfers the revised request to a menu providing means. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

The present invention relates to a WAP gateway that controls access to the Internet from a mobile terminal such as a mobile phone or a PDA (Personal Digital Assistant), and relays services from the Internet. There is no need to be aware of which display format is supported by the terminal that the user is using. The present invention relates to a display data determination device and a display data determination method for a WAP gateway that is selected and displayed.

In order to receive Internet services, such as accessing the Internet from a mobile terminal and acquiring information on the Internet, a WAP gateway is provided between the wireless telephone network and the Internet to relay information or control between the two. Yes. The WAP gateway executes the relay between the radio telephone network and the Internet, and also provides the user with menu data that serves as a portal to the Internet. Users are charged directly on behalf of users, or data such as JAVA applications that can be downloaded by users is stored as a database in the system, and in response to download requests from users, downloads are permitted. There are those with the functions to provide.

There are the following in the literature on WAP gateways.
JP 2002-165276 A

When a user accesses content provided on the Internet, it is very laborious to search for the target content directly from the Internet. Therefore, a WAP gateway that provides access to the Internet by a mobile terminal is provided with a menu providing function that assists users in accessing content. In this technology, content providing servers that provide services such as content on the Internet are classified by, for example, music, video, etc., and a list of providing servers is displayed for each group. The user can access the server by selecting and instructing the desired server from the displayed list of provided servers.

In addition, with the development of information providing technology on the Internet in recent years, various image formats used on homepages have been developed for the purpose of increasing the amount of information to be provided or attracting users' attention. One of them is FLASH technology developed by Macromedia that can display animations. By creating an information provision screen such as a menu screen using the new technology, the amount of information that can be provided on one screen increases, and actions such as user selection become easier.

However, terminals capable of displaying a screen created using a new technology are limited to terminals compatible with the new technology, and cannot be displayed on terminals that do not support the new technology, such as old terminals. As a result, an unsupported terminal cannot request a page created using the new technology, and sending a request results in an error and some kind of response is required. Further, a page including animation data requires a lot of data as compared with a conventional page created by XHTML, for example. For this reason, the number of packets required for the transfer from the server to the user terminal increases, and the time and cost required for the transfer also increase. Therefore, there are users who do not want a menu screen including animation.

In order to solve the above problems, two types of pages that provide menu data, the traditional XHTML page and the FLASH page, are prepared, and the user selects and instructs the desired page. Alternatively, a method of providing a page having a display format desired by the user can be considered. However, in this method, a screen for selecting the page format is provided for each menu, and the selection screen must be transmitted to the user terminal and displayed by the user before displaying the original menu. This will increase the burden on the user.

In the present invention, a page by XHTML and a page by FLASH are created as menu pages for one selection item, both pages are assigned different addresses and stored in a menu server, and the user terminal responds to the one selection item. The page address is transmitted to the menu server as an address common to both types of pages. Further, the relay server that relays the request from the user terminal to the menu server uses the terminal used by the user and the information specifying the menu format set by the user as the XHTML page address. The page is converted to one of FLASH addresses and transmitted to the menu server.

According to the configuration of the present invention, it is not necessary for the user to select a page based on XHTML or a page based on FLASH, and the user only needs to select a single link URL for requesting a menu, A menu page formatted according to the user's specifications is displayed. Therefore, it is not necessary to transfer unnecessary information, and there is no selection error by the user.

FIG. 1-1 is a schematic diagram of a WAP gateway that manages access to the Internet by a mobile terminal to which the present invention is applied. FIG. 1-2 provides a user's mobile phone and free content on the Internet. There is an example of a basic sequence of WAP that establishes a session with a content providing server, acquires free content, and then releases the session.

The outline of each node and server shown in FIG. 1-1 is as follows.
GGSN (2): A gateway between a core network (packet network) to which a user's mobile phone (UE) belongs and an IP network constituting a WAP gateway.
JSR (3): A subscriber authentication mechanism, which checks user access authority for each service.
PCN (4): A server that monitors packets sent by a mobile telephone, describes charging information based on the amount of packets, and outputs a charging record (CDR) for each predetermined period. Subscription based on this CDR Charge the communication fee to the subscriber.
JSP (6): An application gateway that adjusts standard functions and extended functions. Various functions such as a proxy function for converting received requests into an appropriate format and transferring them to the subsequent stage, and a secure access function using SSL Provide functionality.
R2M (7): Manages a subscriber authentication session for checking user access authority for each service. In addition, it manages user information, user setting information, and terminal information necessary for service subscribers to use services such as web and email, and provides such information in response to requests from each server in the WAP gateway. Server.
PTL (8): Collects various statistical information from an external server, and manages the update of the official menu of the WAP gateway, such as sorting the menu based on the statistical information. In response to a request from a mobile terminal, the server retrieves a corresponding menu from the menu database and provides it to the mobile terminal.
WGW (10): A gateway server that mediates a request from a user to a content providing server (CP) when the user of the mobile terminal accesses the web. It has functions such as a billing system (collection agency) that collects user content usage fees on behalf of the content providing server and scheme conversion.
DBS (12): A database synchronizer that synchronizes contents among a plurality of databases.
Wtrans (13): A server that is located between the WGW 10 and the content providing server (CP) on the Internet and performs code conversion and the like.
CP (14): A server that establishes a homepage on the Internet and provides contents to users. Contract with a WAP gateway operator such as a telephone company and register it as a selection item in the official menu of the WAP gateway. When the user selects the selection item from the menu displayed on the display screen of the mobile terminal, the user can access the home page via the WAP gateway and purchase the provided content.

SGSN (30): A gateway between a radio network controller and a core network (Packet network).
SMSC (31): A short message service center and a server for managing simple mail.
DRS (32): A server that locally copies and maintains subscriber information from a server (DIR) that centrally manages information of all subscribers at regular intervals. Subscriber information is provided in response to an inquiry request, and it is possible to continue providing services even in the event of a DIR failure.
PPG (33): A push proxy gateway that is a server that pushes content to a terminal in response to a request from a node that wants to execute a push service.
DRM (34): A copyright management mechanism that supports the three copyright management methods (Forward-lock, Combined delivery, and Separate delivery) defined in the Open Mobile Alliance OMA DRM 1.0. ing.
MMS-R (35): A mail server that receives and transmits multimedia messages, and performs authentication of senders and receivers, storage, retrieval, and distribution of messages in mailboxes.
MACS (36): A midlet (MIDlet) access control server, which manages access and transfer to midlets (simple Java applets for mobile terminals).
Repo-DB (37): A generic term for servers for the purpose of storing and managing data on the Internet.
COP (38): A node (COP: Client OTA Provisioning) that provides information necessary for setting up a mobile terminal, such as network settings, via OTA (Over The Air).

FIG. 1-2 shows a sequence between a user's mobile terminal and a content providing server that provides free content on the Internet, and details thereof are as follows.
(1) Sequence 1-2
Connection request “1) Activate PDP Context Request” for establishing a TCP (Transmission Control Protocol) session when a user agent (UA) such as a WEB browser operating on a mobile terminal (UE) acquires WEB content. To SGSN30. When receiving the “1) Activate PDP Context Request”, the SGSN 30 receives an international identification number (IMSI) assigned to the subscriber of the mobile terminal (UE) and a telephone number (MSISDN) of the mobile terminal (UE). “2) Create PDP Context Request” with Mobile Station ISDN number) attached is generated and sent to GGSN2.

(2) Sequence 3-4
When GGSN 2 receives “2) Create PDP Context Request”, GGSN 2 sends an authentication request “3) RADIUS Access Request” to JSR 3 and returns “4) RADIUS Access Accept” indicating successful authentication from JSR 3. The IP address is issued to the mobile terminal (UE), and a RADIUS accounting request “5) RADIUS Accounting-start Request” is sent to the R2M7. In the RADIUS accounting request “5) RADIUS Accounting-start Request”, the IP address, MSISDN, IMSI, or the like of the issued mobile terminal (UE) is attached.

(3) Sequence 5-7
When R2M7 receives “5) RADIUS Accounting-start Request”, it creates session information and profile information for each user, and caches them in the internal memory together with the IP addresses as keys. This cached information is retained until the corresponding session is released. Also, the R2M7 sends “6) Replication RADIUS Accounting Profile” in order to cause the JSP 6 to replicate this session information. When the JSP 6 receives “6) Replication RADIUS Accounting Profile”, the JSP 6 holds a copy (replica) of the session information therein. Here, the held session information includes the IP address, MSISDN, and IMSI of the mobile terminal (UE). When the JSP 6 holds a copy (replica) of the session information, the JSP 6 sends “7) Replication RADIUS Accounting Profile Response” notifying that the session information has been replicated to the R2M 7.

(4) Sequence 8-10
When R2M7 receives “7) Replication RADIUS Accounting Profile Response”, R2M7 sends “8) RADIUS Accounting-start Response” to notify GGSN 2 that TCP session connection preparation is complete. The GGSN 2 sends “9) Create PDP Context Response” with the IP address assigned to the mobile terminal (UE) attached thereto to the SGSN 30. Next, the SGSN 30 sends “10) Activate PDP Context Response to the mobile terminal (UE), whereby a TCP handshake is performed between the mobile terminal (UE) and the JSP 6 to establish a TCP session. .

(5) Sequence 11
When a TCP session is established between the mobile terminal (UE) and the JSP 6, the mobile terminal (UE) sends an HTTP request “11) HTTP Request” to the JSP 6 in order to acquire content from the content providing server (CP). . When the JSP 6 receives the HTTP request “11) HTTP Request”, the JSP 6 refers to a copy (replica) of the session information held therein, and when the corresponding session information exists and the subscriber information matches. Only the HTTP request “11) HTTP Request” is accepted. In the header of the HTTP request “11) HTTP Request”, the IP address of the mobile terminal (UE) issued from the GGSN 2 and the URI (Request-URI) of the content providing server (CP) that is the destination of the content acquisition , User agent information (UA), and user agent profile information (UA-Profile).

(6) Sequence 12-13
Upon receiving the HTTP request “11) HTTP Request”, the JSP 6 sends out “12) Profile get Request” in order for the mobile terminal (UE) to acquire profile information necessary for content acquisition from the R2M7. R2M7 uses the IP address, user agent information (UA), and user agent profile information (UA-Profile) attached to “12) Profile get Request” to internally cache the mobile terminal (UE). And is notified to JSP 6 by “13) Profile get Response”.

(7) Sequence 14-15
The JSP 6 receives the HTTP request “11 received from the mobile terminal (UE) from the mobile terminal (UE) the parameters that are insufficient based on the terminal information (UE-Profile) included in the profile information of the mobile terminal (UE) notified from the R2M7. Supplementing the extension header of “) HTTP Request”, “14) HTTP Request” is sent to the content providing server (CP) specified by the Request-URI. Here, it is difficult for a WAP-compatible mobile terminal (UE) to send an HTTP request “11) HTTP Request having an extension header for attaching a parameter of terminal information (UE-Profile). However, when the JSP 6 supplements the parameter of the terminal information (UE-Profile) in the extension header of the HTTP request “11) HTTP Request”, the content providing server (CP) makes the mobile terminal (UE) a mobile terminal compatible with WAP. Regardless of whether or not the performance and capability of the mobile terminal (UE) can be known by referring to the parameters of the terminal information (UE-Profile) attached to the extension header of the HTTP request “14) HTTP Request” it can. Then, the content providing server (CP) selects or generates content suitable for the performance and capability of the mobile terminal (UE), and returns the content to the JSP 6 by “15) HTTP Response”.

(8) Sequence 16
The JSP 6 returns the content acquired from the content providing server (CP) by “15) HTTP Response” to the mobile terminal (UE) as an HTTP response “16) HTTP Response”. Here, depending on the content providing server (CP), there is a server that returns the content without referring to the extension header of the HTTP request “14) HTTP Request”. In this case, the content acquired by JSP 6 is not necessarily adapted to the performance and capability of the mobile terminal (UE). In such a case, JSP6 is based on the terminal information (UE-Profile) of the mobile terminal (UE), so that the character conversion and file format of the content are adapted to the performance and capability of the mobile terminal (UE). It performs conversion and returns it to the mobile terminal (UE).

(9) Sequence 17-22
When the mobile terminal (UE) acquires the content by the HTTP response “16) HTTP Response”, the mobile terminal (UE) sends a session release request “17) Deactivate PDP Context Request” to the SGSN in order to terminate communication with the JSP 6. The SGSN 30 sends “18) Delete PDP Context Request” to the GGSN 2, and then the GGSN 2 sends “19) RADIUS Accounting-stop Request” to the R2M 7. Receiving this, the R2M7 discards the corresponding session information held therein, and sends “20) RADIUS Accounting-stop Response” to the GGSN2. The GGSN 2 sends “21) Delete PDP Context Response” to the SGSN 30, and then the SGSN 30 sends “22) Delete PDP Context Response” to the mobile terminal (UE). In this way, the TCP session between the mobile terminal (UE) and the JSP 6 is released and the communication ends.

FIG. 2 shows a procedure in which a user of a mobile terminal acquires content such as a menu related to music from a menu server (PTL8) of the WAP gateway, selects content on a content providing server existing on the Internet with reference to the menu, and purchases the content. And an overview of the control.

(1) The user transmits a display request for a menu related to a specific field, for example, a music sales site, from the mobile terminal (UE) to the WAP gateway (step a).
(2) The GGSN 2 of the WAP gateway, after authenticating the validity of the request from the mobile phone packet network in JSR 3, converts the request into an IP network protocol and transmits it to JSP 6. The PCN 4 monitors packet transmission and reception and records it in the access log statistics 5 as billing information.
(3) The JSP 6 converts the menu request into an appropriate format and sends it to the PTL 8. At this time, the JSP 6 determines whether or not the user is permitted to access the request menu based on the user information recorded in the R2M7. When access is permitted by the JSP 6, the PTL 8 reads the requested menu data from its own database 9, and transmits it to the user terminal (UE) via a route opposite to the route at the time of request (step b).

(4) The user terminal displays the menu transmitted from the JSP 6, and the user selects an option for purchase from the displayed menu item. By the user's selection operation, an access request for the URL of the sales site added to the selected option is transmitted to the WAP gateway (step c).
(5) The above request is sent to Wtrans 13 via GGSN2, JSP6, and WGW10. The Wtrans 13 performs processing such as converting a local IP address in the WAP into a global IP address and sends a request to the Internet.
(6) The access destination content providing server (CP) returns the requested homepage data (step d). This data is transmitted to the user terminal (UE) via a route opposite to the above route and displayed on the display.
(7) The user selects content desired to be purchased based on the data displayed on the user terminal (UE). The user terminal (UE) sends out the URL of the selected content added to the selected content (step e).
(8) The URL request is sent to the WGW 10 via GGSN2 and JSP6. Based on the user information, the WGW 10 determines whether or not the content requested by the user is permitted to be purchased, and transmits a purchase approval / disapproval response to the user terminal (UE) (step f).
(9) When the user receives a reply indicating that the purchase is possible, the user sends a confirmation of purchase intention (step g). Upon receiving the purchase intention from the user, the content providing server (CP) returns information related to the content download (step h).
(
(10) When the JSP 6 receives the download information from the CP 14, the JSP 6 creates correspondence data between the user and the content permitted to purchase, and stores it together with necessary information such as the current time. Next, the JSP 6 relays information related to content download to the user terminal (UE) (step i).

(11) The user starts downloading in accordance with the instruction from the CP 14 displayed on the terminal (step j). The JSP 6 collates the download request from the user terminal (UE) with the corresponding data stored in step i, and determines whether it is a valid download request. When it is determined that the download request is valid, the download request is transferred to the WGW 10 (step k).
(12) The WGW 10 updates and records the billing information of the content corresponding to the download request. Next, the WGW 10 relays the download request to the content providing server (CP) via the Wtrans 13 (step l).
(13) The content providing server (CP) sends the requested content to the user terminal (UE) (step m). The WGW 10 determines the billing information of the content updated in Step l and transfers the content to the user (Step n).
(14) The user terminal determines whether or not the content has been normally received. When the content has been normally received, the user terminal executes a termination process with the GGSN 2 (step o). If the process does not end normally, execute error processing such as retry.

FIG. 3 shows a conceptual diagram of menu selection according to the present invention. In the figure, the relay server JSP 6 determines the menu URL transmitted from the user terminal (UE), and determines whether the URL is a request for a menu having both the FLASH format and the XHTML format. When the request is determined to be a request for a menu having both formats, information on the function of the terminal used by the user and the display format set by the user is read from the profile database 15 managed by the R2M7, and It determines whether the menu format to be sent to the terminal is the FLASH format or the XHTML format. Next, the URL transmitted from the user terminal is changed to a URL designating the menu data in the above-determined format, and transmitted to the menu server PTL8. FIG. 4 shows a process flow of the conceptual diagram shown in FIG. 3, and FIG. 5 shows a process in a flowchart.

As shown in FIG. 4, the profile management server R2M7 holds in the database 15 data relating to the user and data relating to the mobile terminal used by the user. The database 15 includes information on the specifications of the mobile terminal, such as model name data (501) of the mobile terminal used by each user, functions available to each mobile terminal used in the mobile phone network ( 502), setting data (503) arbitrarily set by the user is stored. The telephone specification (502) includes data indicating whether or not the model is compatible with the FLASH format, and the user's setting data (503) agrees to receive the display data in the FLASH format. Data indicating whether or not

In the example shown in FIGS. 4 and 5, the URL for requesting a menu capable of both the FLASH format and the XHTML format is “/ menu”. The JSP 6 to which the request is transmitted from the user's mobile terminal determines what the request is for (S200). The sent HTTP request is “http: // menu”, and the request URL is determined to be a request for the FLASH / XHTML menu. When the request URL is other than “/ menu”, it is a menu with no selection or a request other than a menu, and the request URL is sent to the server for each request.

If it is determined in S200 that the URL is a request for the FLASH / XHTML menu, JSP 6 obtains information on the model of the mobile terminal used by the user who requested the menu from the user terminal data (501) in the profile database 15 of R2M7. Acquire and determine the model of the terminal used by the user (S201). Next, the specification information of the determined model is read from the specification data (502) of the mobile terminal in the profile database 15, and it is determined whether or not the model is compatible with the FLASH format display (S202). XHTML format menus will be sent to models that do not support FLASH format display. In S204, the HTTP request is corrected to the address of the XHTML menu, for example "http: //menu/xhtml/index.xhtml". , To the menu server PTL8 (S204).

If it is determined in S202 that the user's model is compatible with the FLASH format display, in S203, the user displays the terminal device display format from the user setting data (503) in the profile database 15 of R2M7. Read the setting information set for. The user can set in advance whether or not he / she agrees to send and display the data in the FLASH format on his / her terminal, and the consent / disagreement information set by the user is set in the user setting information . When consent is set in the user setting information, data in the FLASH format is transmitted to the user terminal, and a moving image by FLASH is displayed.

If the setting information of the user read in S203 is set to disagree with the data in the FLASH format, the process proceeds to S204, and the same processing is performed as when the user's model does not support the FLASH format display. . If the user's setting information is set to consent to the data in the FLASH format, or if it remains in the initial state, the process proceeds to S205, and the HTTP request is sent to the address of the FLASH menu, for example, "http: // menu / flash" /index.swf "and send it to the menu server PTL8. The menu server PTL8 selects the XHTML menu if the corresponding page data from the address of the HTTP request sent from JSP6, that is, if the sent address is "http: //menu/xhtml/index.xhtml". If "http: //menu/flash/index.swf", the FLASH menu is read and transmitted to the user terminal.

According to the present invention, when there are a plurality of display forms for one menu item, for example, a menu display for displaying animation using FLASH and a menu display centered on characters by XHTML, the user uses it. The menu to be sent to the user can be automatically determined based on the specifications of the terminal to be used and the setting information set in advance by the user. Therefore, when a user requests a menu from the terminal, it is necessary to be aware of what type of menu is supported by the terminal being used, or how the menu of the desired format should be requested. There is no need, and a menu of a desired format can be obtained simply by issuing a single menu request, and there is no need to perform useless selection work or useless communication.
The present invention is not limited to the menu display, and can be generally applied to the case where information is provided to a user terminal and the information is displayed on a display screen. Further, the display form is not limited to the selection of FLASH and XHTML.

Overview of WAP gateway to which the present invention is applied Sequence example of WAP to which the present invention is applied Overview of Internet access by WAP gateway The conceptual diagram of the Example which applied the display data determination of this invention to the menu selection Block diagram of processing of display data determination device Flowchart diagram of display data decision processing

Claims (6)

In a WAP gateway that processes a request for access to the Internet from a mobile terminal, a display form determination device that determines a display form from a display capable of a plurality of display forms for the same display content,
The display form determination device stores a plurality of display form data for the same content display;
Model specification discriminating means for discriminating the specifications of the mobile terminal that requested the display;
Instruction discriminating means for discriminating an instruction relating to a display form of a user who has requested display;
Means for changing a display request from a mobile terminal to a request for requesting data in one of the plurality of display forms, based on outputs of the model specification determining means and the instruction determining means;
A display form determining apparatus comprising: means for outputting display form data corresponding to the changed request to the mobile terminal. The display form determination device according to claim 1,
The display form determining apparatus, wherein the plurality of display forms are FLASH and XHTML. The display form determination device according to claim 1,
The display form determining apparatus, wherein the plurality of display data is menu data. A display mode determination method for determining a display mode of a display requested by a mobile terminal in a WAP gateway that processes an access request from the mobile terminal to the Internet,
A model specification determination step for determining the specification of the terminal that requested the display;
An instruction determination step for determining an instruction of a display form of a user who has requested display;
Based on the determination results of the model specification determination step and the instruction determination step, changing the display request from the mobile terminal to a request for requesting data of one display form among a plurality of display forms;
A method of determining a display form, comprising the step of outputting data of a display form corresponding to the changed request to the mobile terminal. The display form determination method according to claim 4,
The display form determining method, wherein the plurality of display forms are FLASH and XHTML. The display form determination method according to claim 4,
The display form determining method, wherein the plurality of display data is menu data.

Images