Patent Application
20080082602
An embodiment of the present invention will be described as an application program similar to a conventional, general Web browser, which operates on an operating system (OS) of a general-purpose computer.
An operating system (OS) and various application programs operate on the computer 10. The OS provides the functions of the various devices in the form of a system call or an API to process execution control (scheduling), short-term storage such as a heap, long-term storage such as a file and a registry, a communication function by TCP/IP, a graphical user interface (GUI) based on a window system and the like. The embodiment of the present invention is not limited to the above configuration, and it may be realized as a computer with a non-graphical user interface or a simple terminal device exclusively used as a browser.
The main functions of the Web browser 100 are an HTTP/HTTPS communication function 100a, an HTML document analysis/management function 100b, a rendering function 100c and a GUI control function 100d. These functions realize communication with a server by the HTTP protocol, interpretation, management and screen display of an HTML document, the main contents of the communication, and interactive operation with a user, in cooperation with a communication API 150 and a GUI API 140 provided by the OS. In most cases, the Web browser 100 can display multiple Web pages at a time with the use of areas called windows or tabs (hereinafter, simply referred to as windows). Furthermore, in general, an HTTP authentication function 100e, a cache function 100f, a script control function 100g, a cookie management function 100h and the like are also provided.
In a short-term storage area 120 such as a heap memory, data which is held only while the Web browser 100 is operating is stored. Such data in the short-term storage area 120 (short-term storage data) includes DOM (document object model) data which is the result of interpretation of an HTML document, HTTP authentication data in which a user ID and a password inputted by a user (or a product generated from inputted data) is held, and volatile cookie data in which cookie information received from a server is held.
In a long-term storage area 130 such as a file and a registry, data is stored which is continuously held even after the Web browser 100 stops operating. Such data in the long-term storage area 130 (long-term storage data) includes cache data and non-volatile cookie data.
The Web browser 200 is provided with a partition table 201, a partitioning setting table 203, a window table 205 and a partitioning management section 210.
The partition table 201 and the partitioning setting table 203 are provided in a long-term storage area 230. The window table 205 is provided in a short-term storage area 220.
The partitioning management section 210 is provided with a request checking section 211, a window selection section 213, a partition creation section 215 and a window creation section 217.
The above-described request determination processing of the present invention is performed by the request checking section 211. Partitioning means is embodied by the window selection section 213, the partition creation section 215 and the window creation section 217. Request editing processing is realized by a request editing section 219.
The Web browser 200 has equivalent processing functions in comparison with the functions and the data structure of the general Web browser 100 shown in
(a) It has multiple partitions.
(b) One partition is associated with each window.
(c) Short-term storage data (DOM data, authentication information, volatile cookies and the like) and long-term storage data (non-volatile cookies, caches and the like) are managed for each partition.
(d) Processing performed within each window is performed with the use of short-term storage data and long-term storage data allocated to a partition corresponding to the window.
(e) When a request transmission event occurs, partition boundary check is performed based on the window where the event has occurred, and a request which crosses between partitions is restricted.
The above characteristic (a) is realized by the partition table 201 of the Web browser 200, the characteristic (b) by the window table 205, the characteristic (c) by the short-term storage area 220 and the long-term storage area 230 each of which is managed being separated to correspond to partitions P0, P1, . . . , and characteristics (d) and (e) by the partitioning management section 210.
Next, the data definition in the Web browser 200 will be described.
In this embodiment, the “partition” is a classification of a Web page based on some condition. The condition of the classification of the partition is basically defined with regard to the characteristic of a request for acquiring the Web page.
P is a set of all partitions p existing on the Web browser 200 at a certain point of time.
P={p1, p2, . . . , pn}
Here, p1, p2, . . . , pn are partition identifiers for uniquely identifying the respective partitions, where n is the number of partitions existing at that point of time, and n=0 is possible. In this case, P is an empty set.
P′ is a set obtained by adding a particular partition identifier p0 to P.
P′={p0}∪P
where p0 is an indication of not being included in any of the partitions. P′ is a set which always changes following P. For example, if an element p is added to the set P, then it is considered that the set P′ has also been automatically added with p.
W is a set of all windows w existing on the Web browser 200 at a certain point of time.
W={w1, w2, . . . , wm}
Here, w1, w2, . . . , wm are window identifiers for uniquely identifying the respective windows, wherein m is the number of windows at that point of time. At the initial state, m=0 is possible. In this case, W is an empty set.
W′ is a set obtained by adding a particular window identifier w0 to W.
W′={w0}∪W
where w0 is an indication of not belonging to any of the windows. For example, it is used when request transmission is requested from a place other than any windows of the Web browser 200, such as the OS or the other applications. W′ is a set which always changes following W. For example, if an element w is added to the set W, then the set W′ has also been automatically added with w.
Each window w is necessarily associated with one partition identifier p. That is, it is assumed that a map f′: W->P′ exits.
Furthermore, a map f′: W′->P′ is defined which has been extended so that w0 can be handled. However, f′(w0)=p0 is always satisfied, and this means that not being any of the windows is treated as not belonging to any of the partitions.
A condition cond(p) for belonging to a partition p is defined in any pεP′. Creation conditions newcond for creating a new partition is also defined.
The set of windows W is to be naturally held by a conventional function of the Web browser 200 and may not be held.
Next, the components of the Web browser 200 will be described.
The partition table 201 is a storage section for storing information indicating the set of partitions P and the conditions cond(p).
Any value can be used as an actual representation of the partition identifier if each partition can be uniquely identified by the value.
The expiration time and date refers to the expiration time and date of the partition. It takes any value among a value concretely specifying the time and date, “volatile (effective only until the Web browser 200 ends processing)” and “n/a (not applicable; without expiration)”.
The storage position in the short-term storage area specifies the position of data (such as a volatile cookie) in the short-term storage area 220, corresponding to the partition. As shown in
The storage position in the long-term storage area specifies the position of data (such as a non-volatile cookie) in the long-term storage area 230, corresponding to the partition. For example, in the disk file system shown in
The condition items in the partition table 201 specify the condition cond(p). In
The condition of URL are constituted by four items of protocol name, hostname, port number and path. Each item is checked against its corresponding portion of a URL. In the respective condition items, the values as shown below is set. The special value “*” means a wild card which indicates that any value is considered to satisfy the condition.
Protocol name: “http”, “https” or “*”;
Hostname: a fully-qualified hostname, a hostname a part of which is replaced with “*”, or “*”;
Port number: an integer between 0 and 65535, “*”, or a special value “default (which means a condition that port number specification must not exist in the URL)”;
Path: an absolute pathname beginning with “/”, a pathname a part of which is replaced with “*”, or “*”.
The item of the trigger cookie in the partition table 201 is for specifying a cookie to be used in partition creation processing by a function of being triggered by a cookie to be described later. For this item, “n/a (which means that this condition is not used)” or a concrete cookie condition described below is stored.
As the cookie condition, a cookie name followed by a list of zero or more options separated by semicolons is described.
The cookie name is any cookie name. The option takes the form of:
domain: If there is an applicable domain for a cookie, the value is taken.
port: If there is an applicable port number for a cookie, the value is taken.
path: If there is an applicable path for a cookie, the value is taken.
secure: If secure is specified for a cookie, “true” is set as the value.
For example, the following are examples of the value for the item of the trigger cookie.
JSESSIONID
ASPSESSIONID; secure=true
PHPSESSID; domain=shop.example.jp; path=/bookstore/
It is assumed that the condition of this item is satisfied when a request is going to transmit a relevant cookie.
For the item of the trigger HTTP authentication in the partition table 201, HTTP authentication specifications to be used in partition creation processing by a function of being triggered by HTTP authentication to be described later is specified. For this item, “n/a (which means that this condition is not used)” or the list separated by semicolons shown below is set.
“Kind of HTTP authentication (“basic” or “digest”); “authentication realm name (any character string surrounded by quotation marks); username (any character string); authentication realm path (absolute path beginning with “/”; optional)”
When the authentication realm path is omitted, the path is considered to be the same as the path item of the URL condition. The value for this item is, for example, a list as shown below.
basic; “Authorized users only”; yamada
digest; “Home directory”; suzuki; /home/suzuki/
It is assumed that the condition of this item is satisfied when a request is going to transmit a relevant HTTP authenticator.
The partitioning management section 210 checks the partition table 201 every time the Web browser 200 is activated and deletes a partition row which satisfies any of the following.
The expiration time and date is “volatile”, or the concretely specified time and date is older than the current time.
A concrete cookie condition is set for the item of the trigger cookie, and the relevant cookie is not stored in the Web browser 200 or the expiration time and date has been exceeded.
The partitioning setting table 203 is a storage section for storing information indicating the creation conditions newcond.
The four functions are a function of being triggered by HTTPS, a function of being triggered by a cookie, a function of being triggered by HTTP authentication, and a function of being triggered by a password field. Each of the items corresponding to these functions takes any of the values “enabled” and “disabled”. Furthermore, minor setting information that is necessary or useful when each function is executed may be also included. In this embodiment, a cookie name pattern related to the function of being triggered by a cookie is set as the minor setting information.
In the partitioning setting table 203 shown in
This specification means the case where the name of a cookie completely corresponds to any of the four specifications within the parentheses which are separated by vertical bar symbols (“|”).
As another specification method, the following is given, for example.
It is when any of the functions of being triggered, of the partition creation section 215 is effective, and a request satisfies the condition for each of the functions that the creation conditions newcond are satisfied under the data set in the partitioning setting table 203.
The window table 205 is a storage section for storing information indicating correspondence relation between the set of windows W and the map f, that is, between each window w and each partition p.
The window identifier is a value which can uniquely identify each window. In general, a value provided by a system (such as a window handle) can be used.
The partition identifier is any of partition identifiers described in the partition table.
It is assumed that multiple windows w1 to w4, . . . are displayed by the Web browser 200 as shown in
As for the window w3, the protocol name is “https”, the access destination hostname is “bank.example.com”, and the condition of the partition p1 is satisfied. Therefore, “p1” is set in the relevant row in the window table 205. As for the window w4, the access destination hostname is “shop.example.jp”, the pathname is “[bookstore/*”, and the condition of the partition p2 is satisfied. Similarly, “p2” is set in the relevant row in the window table 205.
The data in the partition table 201 and the window table 205 is changed in accordance with the result of processing by the partitioning management section 210 as appropriate.
Next, the operation principle of the present invention will be described.
For each window wεW, the Web browser 200 uses the data in the short-term storage area 220 and the long-term storage area 230 assigned to a partition p=f(w) corresponding to the widow w to perform request transmission, interpretation and retention of a response, operation of a script and the like. Therefore, data of the other partitions are not used. For example, even if a cookie to be transmitted to a certain server is stored in a short-term storage area 220 or a long-term storage area 230 assigned to a different partition, the Web browser 200 does not transmit the cookie and transmits only other cookies in the partition assigned to the window w itself. If there is no such cookie, nothing is transmitted.
The partitioning management section 210 is provided with a request checking section 211, a window selection section 213, a partition creation section 215, a window creation section 217 and a request editing section 219.
If a request transmission event is caused by processing, such as clicking a link, pressing a form submit button, and request transmission being requested by an embedded object or JavaScript, within a certain window, the partitioning management section 210 performs partition boundary check processing before transmission of the request.
Here, the request required to be transmitted is denoted by r, and the window where the event has occurred is denoted by wsεW′.
When an event of transmitting the request r from the window w occurs, the request checking section 211 first performs window selection processing (to be described later) and determines a window wd to handle the request r (step S1).
It is checked whether the value of the window wd is a special value (null) (step S2). If the window wd is the special value (null) (step S2: YES), then the processing is ended because the request r should not be transmitted. If the window wd is not the special value (null) (step S2: NO), then the Web browser 200 transmits the request r with the window wd. After that also, the short-term storage data and the long-term storage data assigned to the partition p=f(wd) corresponding to the window wd are used to perform transmission of a request r, interpretation and retention of a response, operation of a script and the like (step S3).
The window selection section 213 first determines the partition ps<-f(ws) of an originating window ws (step S100). Next, it is checked whether a request r satisfies a condition cond(ps) (step S101). If the request r satisfies the condition cond(ps) (step S101: YES), then the request r can be handled within the window ws because the access destination belongs to the same partition as that for the originating window ws. Therefore, ws is substituted for w (step S102), w is outputted (step S103), and the processing is ended.
If the request r does not satisfy the condition cond(ps) (step S101: NO), then it is checked, for each partition pεP, whether the request r satisfies the condition cond(p) to search for such p that the request r satisfies the condition cond(p) (step S104). However, in the case of p=ps, the check has already been performed and can be omitted. If such p that the condition cond(p) is satisfied does not exist, then p0 is substituted for p. Though there is a possibility that there are multiple relevant p's, one p is selected by some method. For example, it is desirable to prevent the conditions from overlapping with one another by determining the order of priority in advance.
Here, the case where the request r does not satisfy the condition cond(ps) means the case where access is attempted by the request r to an access destination belonging to a partition p different from the originating partition ps. The window selection section 213 selects any of the following options by some method (step S105).
Option (A): Refuses the request r.
Option (B): Accepts the request r to the partition p.
Option (C): Accepts the request r to the partition p0 (selectable only when p≠p0 is satisfied).
Option (D): Accepts the request r to a new partition (selectable only when p=p0 is satisfied and r satisfies the newcond).
As the selection method, processing is performed, such as determining an option in accordance with a condition determined in advance, for example, displaying options to a user and determining an inputted option.
If the option (A) is selected (step S106: (A)), then a special value (null) is substituted for w (step S107), w is outputted (step S103), and the processing is ended. Thereby, the request r is discarded.
If the option (B) is selected (step S106: (B)), then it is checked whether such a window wεW as satisfies f′(w)=p exists, where an acceptance partition is denoted by p (step S108). If such a window wεW as satisfies p exists (step S109: YES), then w is outputted (step S103), and the processing is ended. On the other hand, if such a window wεW as satisfies p does not exist (step S109: NO), then a new window w corresponding to the selected partition p is created by window creation processing (step S110), w is outputted (step S103), and the processing is ended. Thereby, the request r is handled in the partition p.
If the option (C) is selected (step S106: (C)), then the processing at and after step S108 is performed after substituting p0 for p (step S111). Thereby, the request r is handled in the partition p0.
If the option (D) is selected (step S106: (D)), then a new partition p is created first by the partition creation processing (step S112). Next, a new window w corresponding to the created partition p is created by the window creation processing (step S110), w is outputted (step S103), and the processing is ended. Thereby, the request r is handled in the new partition
The partition creation section 215 creates a new partition p to which the request r belongs by a predetermined method (step S120). Furthermore, the created partition p is added to a set of partitions P (step S121), and p is outputted (step S122).
Specifically, such a partition pn as has a condition which makes it possible to include the request r is added to the partition table 201, and a corresponding data storage area is prepared in the short-term storage area 220 and the long-term storage area 230. A specific method for setting conditions in the partition table 201 depends on the request r and the creation conditions newcond, that is, the conditions set in the partitioning setting table 203.
When a new window w is created by the Web browser 200 in an existing processing method (step S130), the window creation section 217 adds the created window w to a set of windows W (step S131). Furthermore, in order to associate the window w with the specified partition p, the map f is changed so that f(W)=P is satisfied (step S132), and w is outputted (step S133). Specifically, a new row is added to the window table 205, and w and p are set.
Next, the partition creation processing will be described in more detail.
The partition creation section 215 is provided with the function of being triggered by HTTPS, the function of being triggered by a cookie, the function of being triggered by HTTP authentication and the function of being triggered by a password field, and the partition creation processing is performed by each of the functions as follows.
It is assumed that a new partition identifier is appropriately determined so that it does not correspond to another partition identifier. It is assumed that, as for the storage position in the long-term storage, a relative pathname based on the partition identifier is appropriately determined and, as for the storage position in the short-term area, an offset to the memory area which can be newly used is appropriately determined.
Before actually creating a partition, information about how the partition creation processing is performed may be presented to a user so as to prompt the user to determine whether or not to execute the partition creation processing, whether or not to refuse request transmission and the like.
(1) Partition Creation Processing by the Function of Being Triggered by HTTPS
The partition creation section 215 newly creates a partition by applying the function of being triggered by HTTPS only when the protocol name of the URL of a request r is “https”.
The contents of a created partition will be shown below. This means that, when a request to an HTTPS protocol site is attempted, a partition which can include requests to the site is created.
Expiration time and date: “volatile”
URL protocol condition: “https”
URL hostname condition: the same as the destination hostname of the request r
URL port number condition: the same as the specified destination port number of the request r; and if specification is not given, “default”
URL path condition: “*”, or a prefix portion is automatically copied from the path of the requested URI of the request r and applied (which is to be used is determined by the user's determination or in accordance with presettings)
Trigger cookie condition: “n/a”
Trigger HTTP authentication condition: “n/a”
(2) Partition Creation Processing by the Function of Being Triggered by a Cookie
When the name of any cookie to be transmitted accompanying a request r corresponds to the cookie name pattern in the partitioning setting table 203, the partition creation section 215 applies the function of being triggered by a cookie to newly create a partition. To describe the example of the partitioning setting table 203 shown in
The contents of the created partition will be shown below. This means that, if a request is attempted by attaching a cookie with a specified name, a partition including requests by which the cookie can be transmitted is created.
Expiration time and date: the same as that of the cookie concerned; and if it does not exist, “volatile”
URL protocol condition: “https” if the cookie concerned has the secure attribute; and otherwise, “*”
URL hostname condition: the same as the applicable domain for the cookie concerned; and if it does not exist, the same as the destination hostname of the request r
URL port number condition: the same as the applicable port number for the cookie concerned; if it does not exist, the same as the specified destination port number of the request r; and if it does not exist either, “default”
URL path condition: the same as the applicable path for the cookie concerned; and if it does not exist, “*”
Trigger cookie condition: a list separated with semicolons and constituted by the name of the cookie concerned, applicable domain, applicable port number, applicable path and presence/absence of the secure attribute
Trigger HTTP authentication condition: “n/a”
(3) Partition Creation Processing by the Function of Being Triggered by HTTP Authentication
When an authorization HTTP header field exists in a request r, the partition creation section 215 applies the function of being triggered by HTTP authentication to create a partition.
The contents of the created partition will be shown below. This means that, if request transmission accompanied by authentication information for HTTP authentication is attempted, a partition corresponding to the kind and range of the authentication realm and the user ID is created.
Expiration time and date: “volatile”
URL protocol condition: the same as the protocol name of the request r
URL hostname condition: the same as the destination hostname of the request r
URL port number condition: the same as the destination port number of the request r; and if it does not exist, “default”
URL path condition: the same as the path to the HTTP authentication realm corresponding to the authorization header to be transmitted
Trigger cookie condition: “n/a”
Trigger HTTP authentication condition: a list separated with semicolons and constituted by the kind of HTTP authentication (“basic” or “digest”), realm name, user ID of authentication information and realm pathname which have been obtained from the corresponding HTTP authentication realm and authentication information
(4) Partition Creation Processing by the Function of Being Triggered by a Password Field
When a parameter (of a query or a form) acquired from the password field of an HTML form is included in a request r, the partition creation section 215 applies the function of being triggered by HTTP authentication to newly create a partition. The password field refers to a field (input item) formed by an INPUT tag whose type attribute has a value “password”.
The contents of the created partition will be shown below. This means that, if a request including the value of a password field (in most cases, a password for authentication) is attempted, a partition including requests to the site is created.
Expiration time and date: “volatile”
URL protocol condition: the same as the protocol name of the request r, or “*” (which is to be used is determined by the user's determination or in accordance with presettings)
URL hostname condition: the same as the destination hostname of the request r
URL port number condition: the same as the destination port number of the request r; and if it does not exist, “default”
URL path condition: “*”, or a prefix portion is automatically copied from the path of the requested URI of the request r and applied (which is to be used is determined by the user's determination or in accordance with the presettings)
Trigger cookie condition: “n/a”
Trigger HTTP authentication condition: “n/a”
(5) Partition Creation Processing Triggered by Receiving of a Cookie
The above methods (1) to (4) are for creating a new partition when a request is transmitted. However, the partitioning management section 210 can also create a partition at a different timing.
The partition creation processing triggered by receiving of a cookie is performed only when the partitioning triggered by a cookie in the partitioning setting table 203 in
When receiving a particular response, the partition creation section 215 determines the creation conditions newcond. If creation is necessary, it newly creates a partition based on the create_partition algorithm and describes a method for handling a response in the partition table 201. Information about the created partition is the same as in the case of the partition creation processing by the function of being triggered by a cookie performed when a request is transmitted.
The window creation section 217 creates information for associating the new partition with a window created by the Web browser 200 by the create_window algorithm.
Thereby, when a cookie is issued from a server, isolation by the partition can be performed.
(6) Partition Creation Processing by Receiving of a Cookie and the Use of a Server Specified Attribute
If, in the partition creation processing in (5) described above, issue of a session cookie which means the start of important processing is specified by the server side, the partition creation processing can be performed more certainly.
Accordingly, the partition creation processing by receiving of a cookie and the use of a server specified attribute is performed only when the attribute of session=true is specified for the cookie, in addition to the method of determining the Set-Cookie or Set-Cookie2 header in a response from the server.
Next, request editing processing will be described.
The request editing section 219 of the partitioning management section 210 can arbitrarily change the contents of a request before transmitting the request. The contents of a request may be automatically changed in accordance with predetermined rules or may be edited by interactive operations by a user.
Furthermore, a check field to indicate “not to be transmitted” is provided in the screen 300 as an optional item. When the user puts a checkmark in this check field in the screen 300, the information attached with the checkmark is deleted from the contents of the request to be transmitted, and the request with the edited contents is transmitted.
Refusal of request transmission and selection of a partition to be accepted are performed by the partition boundary check processing. Furthermore, since a parameter of a request which may damage the user is deleted or changed by the request editing processing, it is possible to transmit only a safer request and attempt access.
The operation of the present invention will be described with the use of
It is assumed that the Web browser 200 displays a certain Web page x on a window 400 (partition p0) as shown in
While browsing Web pages on the window 400, a user specifies a different URL (bank) by an input or a bookmark. When request transmission is requested by the specification of the different URL, the partition boundary check processing is performed. If the protocol name of the request which has been requested to be transmitted is “HTTPS”, then a different window 410 is generated based on this request transmission. Furthermore, a partition pl is generated by the partition creation processing triggered by HTTPS, and the window 410 is isolated.
Thereby, the Web page (page of a bank) of the URL (bank) is displayed in the new window 410, and subsequent requests are handled in the window 410 as far as the access destination is the same.
As shown in
Suppose that, while the window 400 and the window 410 are displayed by the Web browser 200, a request to the access destination (bank) of the window 410 is requested by the access destination of the window 400 as the request source. It is determined by the partition boundary check processing that this request transmission is such as goes beyond a partition, and the Web browser 200 can control request transmission which is not desired by the user, by automatically refusing the request transmission or making a notification to the user to confirm whether or not to perform the transmission.
Information of the partition pl corresponding to the window 410 is also isolated from the processing handled by external windows, for example, the window 400.
It is assumed that the user subsequently logs in a community site while browsing Web pages on the window 400. The partition boundary check processing is performed in response to the login request transmission, and a different window 420 is generated. When a response having Set-Cookie is received after the login, a partition p2 is generated by the partition creation processing triggered by receiving of a cookie, and the window 420 is isolated.
Thereby, the Web page (community site) is displayed in the new window 420, and subsequent requests are handled in the window 420 as far as the access destination is the same.
The community site is such a site as the user may visit again. Even after the window 420 is closed, the partition p2 corresponding to the window 420 is held as an effective setting, and information such as cookies is isolated and stored in the long-term storage area 230 corresponding to the partition p2.
Suppose that, after the window 420 is closed, a request to the access destination (community site) of the window 420 is requested by the access destination of the window 400 as the request source. It is determined by the partition boundary check processing that this request transmission is such as goes beyond a partition, and the Web browser 200 controls request transmission which is not desired by the user, by automatically refusing the request transmission or making a notification to the user to confirm whether or not to perform the transmission.
When the user visits and logs in the community site again later, a window 430 is created, the partition p2 is associated therewith, and isolation is similarly performed. The window 430 can use the information isolated as that of the partition p2 the same as before.
In this embodiment, if appropriate information is set in the partition table 201 in advance, the partitioning management section 210 can check a request r and determine a partition in the partition boundary check processing using only the partition table 201 and the window table 205. In this case, the partitioning setting table 203 is not used, and the creation conditions newcond are not specified. Therefore, a new partition is not created.
By providing the partitioning setting table 203 and setting the creation conditions newcond, a partition is automatically created at a suitable timing without a user being required to set information in the partition table 201 in advance, and the convenience is enhanced more.
The present invention has been described with the use of an embodiment thereof. It is natural that various variations of the present invention are possible within the range of the spirit.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2006-264863 | Sep 2006 | JP | national |
