JP2004171281A - Web content conversion and editing system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a Web content conversion and editing system that can absorb constraints on a mobile station. <P>SOLUTION: The Web content conversion and editing system 12 sets, in a definition file, content types and the size of each content type acceptable by a mobile station 10, and compares content acquired from application servers 13a to 13c with the setting information in the definition file. If the acquired content is of an unset content type or of a size larger than the defined size, information to the effect is transmitted to the mobile station 10 in place of the content. <P>COPYRIGHT: (C)2004,JPO

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a web content conversion / editing system for a mobile station in a mobile communication network to acquire content from an application server serving as a content provider located on the web.
[0002]
[Prior art]
In general, analog mobile communication systems of the 1980s (NTT system, Advanced Mobile Phone Service (AMPS), Total Access Communications System (TACS), etc.) are called first generation, and digital mobile communication systems of the 1990s ( PDC (Personal Digital Cellular communication system), GSM (global system for mobile communication), IS-54, IS-95, etc. are called the second generation (hereinafter, referred to as "2G system"). The spread of these mobile communication systems has been remarkable, and in Japan, the number of mobile phones spread has exceeded 60 million. Such mobile phones have become widespread as mobile phones, and sending and receiving Internet mail using the mobile phone as a terminal and acquiring web contents from a server on the Internet have been performed.
[0003]
[Problems to be solved by the invention]
General web browsers introduced in personal computers and the like in offices and homes, and various contents published on websites are designed on the premise that they are displayed on a large display device such as a personal computer. Are provided. On the other hand, the importance of portability in mobile phones limits the message display area on the display and the memory area for storing acquired data. Most mobile phones have a general web browsing function, but do not have all of the rich functions of a web browser installed in a personal computer or the like. Therefore, there is a problem that even when trying to acquire various contents published on the Internet from a mobile phone, the contents may not be completely acquired. In addition, when various contents are acquired, there is a problem in that the contents cannot be displayed or even if displayed, the display becomes abnormal.
[0004]
Therefore, an object of the present invention is to provide a web content conversion / editing system capable of absorbing restrictions in a mobile station.
[0005]
[Means for Solving the Problems]
In order to achieve the above object, a web content conversion and editing system of the present invention is a web content conversion and editing system for performing conversion and editing of a message transmitted and received between a mobile station and a content provider. First control means for processing a request message for requesting the content and transmitting the request message to the content provider; processing a response message obtained from the content provider in response to the request message and transmitting the response message to the mobile station A second control unit, the second control unit comprising: a content type that can be accepted by the mobile station; a content type and a size set in a definition file in which a size for each content type is set; In response to the request message, a copy of the content obtained from the content In contrast to the content type and size, if the content type of the acquired content is not set in the definition file, or if the size is equal to or larger than the size set in the definition file, the Instead of the content, information indicating this is sent to the mobile station.
[0006]
Next, another web content conversion / editing system of the present invention capable of achieving the above object is a web content conversion / editing system for converting and editing a message transmitted / received between a mobile station and a content provider. A first control unit for processing a request message for requesting content from the mobile station and transmitting the request message to the content provider; and processing a response message obtained from the content provider in response to the request message. And a second control means for transmitting to the mobile station, when the first control means receives a request message for specifying and acquiring a part of the content from the mobile station, the first control means, Providing the content by editing the request message into a request message for obtaining all of the content from the content provider; So that send to.
[0007]
Further, in the other web content conversion / editing system of the present invention, the second control means may include, from the content of the response message obtained from the content provider in response to the edited request message, Some of the contents specified in the request message may be sent to the mobile station.
[0008]
Next, still another web content conversion / editing system of the present invention capable of achieving the above object is a web content conversion / editing system for converting and editing a message transmitted / received between a mobile station and a content provider. A first control means for processing a request message for requesting content from the mobile station and transmitting the request message to the content provider; and processing a response message obtained from the content provider in response to the request message. A second control unit for transmitting to the mobile station, wherein the first control unit is uncompressed from the content provider when receiving a request message for requesting compressed content from the mobile station. The content is edited into a request message for acquiring the content and transmitted to the content provider.
[0009]
Further, in still another web content conversion / editing system according to the present invention, the second control means transmits the uncompressed content obtained from the content provider in response to the edited request message to the mobile station. The compression processing may be performed so that the compression type specified by the request message is transmitted to the mobile station.
Still further, in still another web content conversion / editing system of the present invention, in a case where acceptable compression type information is specified in a request message for acquiring content from the mobile station, the second control means includes: A content size set in a definition file in which a content size acceptable by the mobile station is set, and a content size of uncompressed content obtained from the content provider in response to the edited request message When the content size of the obtained content is set to be equal to or larger than the content size set in the definition file, the compression process is performed so that the obtained non-compressed content becomes the specified compression type. May be sent to the mobile station.
[0010]
According to the present invention, when the acquired content type or size is not set, information indicating the fact is transmitted to the mobile station instead of the content. As a result, it is possible to not acquire the content that cannot be acquired due to the restrictions of the mobile station and to inform the user of the content. In this case, since the content that cannot be obtained is not sent to the mobile station, it is possible to prevent a limited use of the radio resources.
Further, when a part of the content is requested from the mobile station, all the contents are acquired from the content provider, and the specified part of the content is sent to the mobile station. As a result, the mobile station can acquire some contents without causing data inconsistency.
[0011]
Further, when a compressed content is requested from a mobile station, uncompressed content is obtained from a content provider, and is compressed and transmitted to a designated compression type. As a result, it is possible to eliminate the necessity of performing a further compression process after decompressing the content obtained from the content provider, and prevent a reduction in processing efficiency. In addition, restrictions on specifications of the mobile station can be absorbed as much as possible, and usability of the mobile station in web communication can be improved.
[0012]
BEST MODE FOR CARRYING OUT THE INVENTION
FIG. 1 shows a schematic configuration of a network including a web content conversion / editing system according to an embodiment of the present invention.
The network shown in FIG. 1 includes a mobile communication network and another network such as the Internet. The mobile communication network is shown as a mobile station (MS) 10 which is a mobile phone, for example, and a wireless communication path 11. I have. Other networks are shown as application servers 13a, 13b, 13c located on the network. The web content conversion / editing system 12 according to the present invention is arranged between a mobile communication network and another network, and is a message transmitted / received between the mobile station 10 and the application servers 13a to 13c as content providers. Conversion editing.
[0013]
The mobile station 10 transmits an HTTP (HyperText Transport Protocol) request (Request) to the application servers 13a to 13c when acquiring content from any of the application servers 13a to 13c. Upon receiving the HTTP request, the application servers 13a to 13c send an HTTP response (Response) having the requested content as an entity body to the mobile station 10. In this case, the web content conversion and editing system 12 according to the present invention, which is arranged between the mobile station 10 and the application servers 13a to 13c, executes the following various processes related to web content conversion and editing described below.
[0014]
One of the web content conversion and editing processes executed by the web content conversion and editing system 12 is a page size check process. This page size check process is a process of checking the byte length of the entity body which is the content in the HTTP response sent from any of the application servers 13a to 13c when the mobile station 10 acquires the content. . By performing the page size check process, it is possible to prevent the mobile station 10 from inadvertently obtaining large content from the application server 13a to 13c on the content providing side, and to effectively use the resources of the wireless communication path 11. Become. The upper limit byte length that is set in advance in the page size check processing is a page size check definition for each content type (text (text), image (image), application (application), etc.) specified in the HTTP / 1.1 response header. It is set in a file.
[0015]
In this page size check definition file, the content type and its size length are indicated with "," between them. To explain an example, “text / x-mml, 1024” means that the upper limit of the byte length of the text file of the x-mml type is less than 1024 bytes. If the byte length is 1024 bytes or more, a check error is transmitted. “Text / *, 0” means that if the content is text-based content other than that defined in the page size check definition file, error transmission is performed as non-permitted content. Further, “image / png.2048” means that the upper limit of the byte length of a PNG (Portable Network Graphics) type image file is less than 2048 bytes, and the byte length of the type is 2048 bytes or more. If so, send a check error. The size length for other content types can be interpreted in the same way as the corresponding definition file in the page size check definition file shown in FIG.
[0016]
In the page size check process in the content conversion / editing process executed by the web content conversion / editing system 12, when content is acquired from any of the application servers 13a to 13c, byte length information of the entity body is obtained. Then, referring to the page size check definition file, the content type and the size length set in the definition file are compared with the content type of the acquired content and the byte length of the entity body. Here, if the content types of the content obtained from any of the application servers 13a to 13c do not match, an error message indicating that the content type is different is transmitted to the mobile station 10 instead of the requested content. Further, when it is determined that the byte length of the entity body is equal to or larger than the set size length, an error message indicating that the size of the content prepared in advance is too large is replaced by the mobile station 10 instead of the requested content. Send to If the content is a program such as CGI (Common Gateway Interface) and the content size is not specified in the HTTP / 1.1 response header, the size of the entity body part is calculated and the byte length is calculated. The calculation is performed, and the page size check processing is performed based on the calculation result.
[0017]
Here, a flowchart of the page size check processing executed by the web content conversion / editing system 12 is shown in FIG.
When the page size check process starts, in step S10, a content type (Content-Type) such as text / HTML is acquired from a response header in the HTTP response acquired for the HTTP request from any of the application servers 13a to 13c. . Next, in step S11, the content type acquired from the response header is compared with the content type set in the page size check definition file to determine whether or not the content types match. Here, if it is determined that they match, the process branches to step S13, and it is determined whether the set value of the size of the content type set in the page size check definition file is "0". Here, if the set value of the size of the content type is determined to be “0”, the content type is not supported, and the process branches to step S20 to display a page indicating “unsupported content” on the mobile station. 10 to display the page on the display unit of the mobile station 10. In this case, the content is not obtained and is not sent to the mobile station 10.
[0018]
If it is determined in step S14 that the set value of the size of the content type is not “0”, the process proceeds to step S14 to determine whether the content size (Content-Length) is set in the response header. Is done. If it is determined that the content size (Content-Length) is set in the response header, the process proceeds to step S15, and the content size (Content-Length) such as “1236” is obtained from the response header. You. If it is determined in step S14 that the content size (Content-Length) is not set in the response header, the flow branches to step S16 to calculate and substitute the size of the entity body portion of the HTTP response. However, in the case of Chunked transfer coding in which the content is divided and transmitted, after combining the divided content, the size of the entity body part is calculated and substituted.
[0019]
When the processing in step S15 or step S16 is completed, it is determined whether the size of the content obtained or calculated in step S17 is equal to or larger than the size of the content type set in the page size check definition file. You. Here, when it is determined that the size of the content type set in the page size check definition file is smaller than that of the content type, it is determined that the size of the content in the HTTP response conforms to the specification of the mobile station 10. Proceeding to step S18, the obtained HTTP response is transmitted to the mobile station 10 without being edited. If it is determined that the size of the content type is equal to or larger than the size of the content type set in the page size check definition file, the process proceeds to step S19, and the size of the content in the HTTP response is too large and deviates from the specification of the mobile station 10. Therefore, a page indicating that the content size is too large is transmitted to the mobile station 10 instead of the content, and the page is displayed on the display unit of the mobile station 10. If it is determined in step S11 that the content type does not match the content type set in the page size check definition file, it means that the condition for restricting the content type has not been set. Proceeding to step S12, the obtained HTTP response is transmitted to the mobile station 10 without being edited.
[0020]
In the above-described page size check processing, when chunked transfer coding for dividing and sending the content is specified, the content is divided and acquired from any of the application servers 13a to 13c to convert and edit the web content. When transmitting to the mobile station 10 by the system 12, the page size check processing is performed on the entire size obtained by combining the divided contents. The contents of the page size check definition file that defines the content type and size can be changed.
[0021]
Next, one of the web content conversion and editing processes executed by the web content conversion and editing system 12 is a range request handling process. The range request is a request for specifying a range in the content and acquiring only the range. By the way, when the content is subjected to the compression processing or the like, the form of the content compression processing may be different with the web content conversion and editing system 12 interposed therebetween. In this case, the mobile station 10 and the application servers 13a to 13c are used. In some cases, the physical entity such as the size of the content is different on the content provider side. Then, when the mobile station 10 requests the partial content by the range request, data inconsistency may occur between the requested partial content and the acquired partial content.
[0022]
Therefore, in order to prevent this, the web content conversion / editing system 12 specifies this range when the header in the HTTP request received from the mobile station 10 includes a range (range request). The header of the range request is deleted, sent to the application servers 13a to 13c, and all contents are received as a response from the application servers 13a to 13c. Then, the web content conversion / editing system 12 sends to the mobile station 10 the partial content in the range specified in the header of the range request in the received content. This can prevent a possibility that data inconsistency occurs between the requested partial content and the acquired partial content. However, if all range requests from the mobile station 10 are rejected, all contents are always transmitted from the application servers 13a to 13c, and communication efficiency is reduced. Therefore, a file type that does not normally cause a data inconsistency between the requested partial content and the acquired partial content is defined as a file that is not subject to range request processing. FIG. 5 shows an example of this Range request non-process definition file. Then, when the extension of the file type of the content requested by the HTTP request matches the defined extension shown in FIG. 5, the range request is transmitted as it is to the application servers 13a to 13c. As a result, a decrease in communication efficiency can be prevented.
[0023]
Here, FIG. 4 shows a flowchart of the Range request handling process.
When the Range request handling process is started, an extension indicating the file type of the content is acquired from the request header of the HTTP request in step S30. Next, it is determined whether or not the extension acquired from the request header in step S31 matches the extension set in the Range request non-process definition file. FIG. 5 shows an example of the definition file not to be processed for the Range request, in which an extension indicating a file type not to be processed for the range request is set. If it is determined in step S31 that the extension acquired from the request header matches the extension set in the definition file not subject to the Range request processing, the file type of the requested content is determined to correspond to the range request. The file type is not processed. Therefore, the request is transmitted from the web content conversion and editing system 12 to the application servers 13a to 13c without editing the request header by branching to step S35. In this case, even if the request is a range request, the HTTP request is transmitted to the application servers 13a to 13c as they are.
[0024]
If it is determined in step S31 that the extension acquired from the request header does not match the extension set in the Range request target non-processing definition file, the file type of the requested content is This is the file type for which range request handling processing is performed. Then, the process proceeds to step S32, and it is determined whether or not the HTTP request is a range request in which a range (Range) is specified in the request header. Here, if the HTTP request is determined to be a range request, the process branches to step S34, where the range (Range) portion is deleted from the request header, and the edited HTTP request is transmitted to the application servers 13a to 13c.
[0025]
As a result, HTTP responses of all contents are transmitted from the application servers 13a to 13c, which are content providers, and the web content conversion / editing system 12 receives all contents as HTTP responses. Then, the web content conversion / editing system 12 sends to the mobile station 10 the partial content in the range specified in the range request of the received entire content. If it is determined in step S32 that the range (Range) is not specified in the request header and the request is not a range request, the flow advances to step S33 to directly send the request header to the application servers 13a to 13c without editing the request header. To send an HTTP request.
[0026]
As described above, a file type that does not delete the range (Range) portion from the request header of the range request is set in the non-range request target definition file, and when a range request of the corresponding file type is received, the range request header is deleted. The data is sent to the application servers 13a to 13c without deleting the range. As a result, a decrease in communication efficiency can be prevented. The file types that are not subjected to the Range request corresponding processing set in the Range request non-processing definition file include the contents on the mobile station 10 side and the contents providing side of the application servers 13a to 13c as shown in FIG. The file type is a jpeg or png file type in which the physical entity such as the size of the file is unlikely to be different.
[0027]
Next, one of the web content conversion / editing processes executed by the web content conversion / editing system 12 is a compression process of the HTTP entity body.
The compression processing of the HTTP entity body is performed to reduce the amount of data transferred between the mobile station 10 and the application servers 13a to 13c that provide the contents, and to effectively use the resources of the wireless communication path 11. The web content conversion / editing system 12 compresses an entity body (content) in response to a request from the mobile station 10 in the HTTP response received from the application server 13a to 13c, and transmits the compressed entity body to the mobile station 10. When the compressed entity body is sent from the application servers 13a to 13c, the compression type may not be accepted in the mobile station 10. Therefore, the entity body compressed in the web content conversion and editing system 12 is decompressed. , The processing efficiency is reduced. To prevent this, the web content conversion / editing system 12 receives an uncompressed entity body from the application server 13a to 13c as an HTTP response. Then, in the web content conversion and editing system 12, the content is converted and edited, and then the compression process is performed.
[0028]
By the way, the mobile station 10 specifies an acceptable compression type by using an Accept-Encoding header in an HTTP request. In this accept encoding header, when the value of the specified compression type is a NULL value (or “identify”), the mobile station 10 does not permit content compression. Further, when any of the compression types is specified, and when the accept encoding header is not specified, the content compression is permitted in the mobile station 10. The conversion and editing system 12 compresses an entity body of a compression type that is accepted by the mobile station 10.
[0029]
In this case, to notify that the content provider does not compress and transmit the content, the web content conversion / editing system 12 accepts the HTTP request from the mobile station 10 by setting a NULL value (or “identify”). -Add an encoding header and send it to the application servers 13a to 13c, which are the content providers. As a result, HTTP responses from the application servers 13a to 13c are not compressed. If the value of the specified compression type is a NULL value (or “identify”) in the accept encoding header of the HTTP request from the mobile station 10, the content compression is not permitted as described above. Therefore, the web content conversion / editing system 12 does not perform content compression. As a compression type performed by the web content conversion / editing system 12, a DEFLATE format or a GZIP format is generally used.
[0030]
Here, FIG. 6 shows a flowchart of HTTP entity body compression processing 1 executed by the web content conversion / editing system 12. In the HTTP entity body compression process 1, the header of the HTTP request from the mobile station 10 is edited.
When the HTTP entity body compression process 1 starts, in step S40, Accept-Encoding specifying the compression type in the request header of the HTTP request from the mobile station 10 is acquired. Next, it is determined whether or not the compression type is specified in the acquired Accept-Encoding. Here, when it is determined that the compression type is not specified in the Accept-Encoding, it means that the content compression is permitted in the mobile station 10, and the process branches to step S44. In step S44, a NULL value (or “identify”) is set in Accept-Encoding in the request header, and the result is transmitted to the application servers 13a to 13c on the content providing side. As a result, HTTP responses from the application servers 13a to 13c are not compressed.
[0031]
If it is determined in Step S41 that the compression type has been specified by Accept-Encoding, the process proceeds to Step S42, and a NULL value (or “identify”) is set in Accept-Encoding in the request header. Is determined. Here, if it is determined that a NULL value (or “identify”) is set in Accept-Encoding, it means that content compression is not permitted in the mobile station 10, and the process branches to step S45. In step S45, the request header Accept-Encoding is transmitted to the application server 13a to 13c, which is the content providing side, without editing. As a result, HTTP responses from the application servers 13a to 13c are not compressed.
[0032]
If it is determined in step S42 that a compression type that is not a NULL value (or “identify”) is set in Accept-Encoding, content compression of the compression type set in the mobile station 10 is permitted. And proceeds to step S43. In step S43, a NULL value (or “identify”) is set in Accept-Encoding in the request header, and the result is transmitted to the application servers 13a to 13c on the content providing side. As a result, HTTP responses from the application servers 13a to 13c are not compressed. In this way, the HTTP response from the application server 13a to 13c, which is the content provider, is uncompressed and is received by the web content conversion / editing system 12. Then, the web content conversion / editing system 12 transmits to the mobile station an HTTP response obtained by compressing the entity body with a compression type corresponding to the specification of Accept-Encoding in the request header of the HTTP request from the mobile station 10.
[0033]
By the way, whether to compress or not may be compressed when the content type and the byte length of the entity body exceed the content type and the size length set in the page size check definition file. In this case, the page size check definition file that defines the content type and size length to be compressed can be changed. Furthermore, the web content conversion / editing system 12 adds a content-encoding (Content-Encoding) header to the HTTP response obtained by compressing the entity body, and specifies the compression type to transmit to the mobile station 10. ing. The value set for the content encoding is, for example, “DEFLATE” or “GZIP”. Since the image file is usually compressed, it is excluded from the content types to be compressed.
[0034]
Here, a flowchart of the HTTP entity body compression processing 2 executed by the web content conversion / editing system 12 is shown in FIG. In this HTTP entity body compression processing 2, compression processing of the entity body of the obtained HTTP response is performed.
When the HTTP entity body compression process 2 starts, in step S50, the content type (Content-Type) is acquired from the response header of the HTTP response from the application server 13a to 13c on the content providing side. Next, in step S51, the content type acquired from the response header is compared with the content type set in the page size check definition file to determine whether or not the content types match. If it is determined that they match, the process branches to step S53, and the content size (Content-Length) such as “1236” is obtained from the response header.
[0035]
Next, it is determined whether or not the size is equal to or larger than the size of the content type set in the page size check definition file. Here, when it is determined that the size of the content type set in the page size check definition file is smaller than that of the content type, it is determined that the size of the content in the HTTP response conforms to the specification of the mobile station 10. Proceeding to step S55, the entity body of the obtained HTTP response is transmitted to the mobile station 10 without being compressed. If it is determined that the size of the content type set in the page size check definition file is equal to or larger than the size of the content type, the process proceeds to step S56 because the content size of the HTTP response is too large than the specification of the mobile station 10. Of the entity body is performed. In this case, the entity body of the HTTP response is compressed in, for example, the DEFLATE format or the GZIP format, the value of the compression type is set to content encoding (Content-Encoding), and transmitted to the mobile station 10. As a result, even when the content size in the HTTP response exceeds the specification of the mobile station 10, the mobile station 10 can acquire the content by clearing the content size condition by compressing.
[0036]
If the request is a range request and the content compression is specified, the web content conversion / editing system 12 edits the request header of the HTTP request requesting all the uncompressed content, and edits the request header at the content provider. The data is transmitted to certain application servers 13a to 13c. Thereby, the HTTP responses from the application servers 13a to 13c are all uncompressed contents. Therefore, the web content conversion / editing system 12 performs a compression process of the specified compression type on the content in the specified range and transmits the content to the mobile station 10.
[0037]
【The invention's effect】
As described above, according to the present invention, when the acquired content type or size is out of the setting, information indicating the fact is transmitted to the mobile station instead of the content. As a result, it is possible to not acquire the content that cannot be acquired due to the restrictions of the mobile station and to inform the user of the content. In this case, since the content that cannot be obtained is not sent to the mobile station, it is possible to prevent a limited use of the radio resources.
Further, when a part of the content is requested from the mobile station, all the contents are acquired from the content provider, and the specified part of the content is sent to the mobile station. As a result, the mobile station can acquire some contents without causing data inconsistency.
[0038]
Further, when a compressed content is requested from a mobile station, an uncompressed content is obtained from a content provider, and is compressed and transmitted to a designated compression type. As a result, it is possible to eliminate the necessity of performing a further compression process after decompressing the content obtained from the content provider, and prevent a reduction in processing efficiency. Further, it is possible to absorb restrictions on the specifications of the mobile station as much as possible, thereby improving usability of the mobile station in web communication.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating a schematic configuration of a network including a web content conversion / editing system according to an embodiment of the present invention.
FIG. 2 is a flowchart of a page size check process executed by the web content conversion / editing system according to the embodiment of the present invention.
FIG. 3 is a page size check definition file set in the web content conversion / editing system according to the embodiment of the present invention.
FIG. 4 is a flowchart of a Range request corresponding process executed by the web content conversion / editing system according to the embodiment of the present invention.
FIG. 5 is a non-Range request-compatible definition file set in the web content conversion / editing system according to the embodiment of the present invention.
FIG. 6 is a flowchart of HTTP entity body compression processing 1 executed by the web content conversion / editing system according to the embodiment of the present invention.
FIG. 7 is a flowchart of HTTP entity body compression processing 2 executed by the web content conversion / editing system according to the embodiment of the present invention.
[Explanation of symbols]
Reference Signs List 10 mobile station, 11 wireless communication channel, 12 web content conversion / editing system, 13a application server

Claims (6)

A web content conversion and editing system for converting and editing a message transmitted and received between a mobile station and a content provider,
First control means for processing a request message for requesting content from the mobile station and transmitting the request message to the content provider;
Second control means for processing a response message obtained from the content provider in response to the request message and transmitting the response message to the mobile station,
The second control means includes a content type that can be accepted by the mobile station, a content type and a size set in a definition file in which a size for each content type is set, and the content corresponding to the request message. Compare the content type and size of the content obtained from the provider, and the content type of the obtained content is not set in the definition file, or the size is equal to or larger than the size set in the definition file If so, the content is sent to the mobile station, instead of the content, to the mobile station. A web content conversion and editing system for converting and editing a message transmitted and received between a mobile station and a content provider,
First control means for processing a request message for requesting content from the mobile station and transmitting the request message to the content provider;
Second control means for processing a response message obtained from the content provider in response to the request message and transmitting the response message to the mobile station,
When the first control means receives a request message for specifying and acquiring a part of content from the mobile station, the first control means transmits the request message from the content provider to all of the content. The web content conversion and editing system is characterized in that it is edited into a request message for acquiring the content and sent to the content provider. The second control unit is configured to, based on the edited request message, a part of the contents in the response message obtained from the content provider specified in the request message from the mobile station, to the mobile station. 3. The web content conversion / editing system according to claim 2, wherein the web content conversion / editing system is sent to a web site. A web content conversion and editing system for converting and editing a message transmitted and received between a mobile station and a content provider,
First control means for processing a request message for requesting content from the mobile station and transmitting the request message to the content provider;
Second control means for processing a response message obtained from the content provider in response to the request message and transmitting the response message to the mobile station,
When the first control means receives a request message for requesting compressed content from the mobile station, the first control means edits the request message to acquire uncompressed content from the content provider and provides the content. A web content conversion and editing system characterized by being transmitted to the original. The second control means performs a compression process on the uncompressed content obtained from the content provider in response to the edited request message so that the content becomes a compression type specified by the request message from the mobile station. The web content conversion and editing system according to claim 4, wherein the content is transmitted to the mobile station. In a case where the acceptable compression type information is specified in the request message for acquiring the content from the mobile station, the second control means determines that the content size acceptable by the mobile station is at least set. The content size set in the file is compared with the content size of the uncompressed content obtained from the content provider in response to the edited request message, and the obtained content size of the content is defined in the definition file. Wherein when the content size is set to be equal to or larger than the content size, the obtained uncompressed content is subjected to a compression process so as to be a specified compression type and sent to the mobile station. 4. The web content conversion and editing system according to 4.

Images