客戶端裝置、數據通信系統、數據通信方法以及程序與流程

本發明涉及客戶端裝置、數據通信系統、數據通信方法以及程序。

背景技術：

所謂云這種方式的服務的提供正在普及。例如，如下的服務方式已廣為人知：管理一般家庭中的電力的使用狀況等的客戶端裝置經由因特網與服務提供商的服務器以可通信的方式連接，使得能夠根據需要而進行大容量數據的交換。

在這樣的客戶端裝置中，根據低成本化等觀點，搭載非高性能的CPU(Central Processing Unit，中央處理單元)的情形較多。由此，當在與服務器之間進行大容量數據的發送接收的情況下，CPU的處理負荷變大，有可能會導致在客戶端裝置中應執行的主處理的延遲。作為該問題的解決對策，以往一般采用在客戶端裝置與服務器之間進行壓縮過的數據的發送接收的方法。

關于壓縮過的數據的通信，在例如專利文獻1中，公開了如下的壓縮圖像數據傳送裝置：根據通信線路的線路速度和壓縮處理速度(運算能力)，決定要發送的圖像數據的壓縮率。

現有技術文獻

專利文獻

專利文獻1：日本特開2003-244698號公報

技術實現要素：

發明所要解決的技術問題

然而，在如上述那樣地以壓縮過的數據進行通信的情況下，當例如搭載于客戶端裝置的CPU的性能低時，根據上傳數據的大小等，相比于不壓縮而發送的情況，CPU的處理負荷反而變大，可能引起導致主處理的延遲的不便。

本發明是為了解決上述課題而完成的，其目的在于提供一種在數據通信時能夠防止主處理的延遲的客戶端裝置等。

解決技術問題的技術方案

為了達到上述目的，本發明的客戶端裝置具備：

通信接口，用于與服務器進行通信；

是否需要壓縮判別部，判別是否需要壓縮用于上傳到所述服務器的上傳數據；

數據壓縮部，在由所述是否需要壓縮判別部判別為需要壓縮所述上傳數據的情況下，以預先決定的方式壓縮所述上傳數據；以及

數據送出部，在由所述是否需要壓縮判別部判別為無需壓縮所述上傳數據的情況下，將對所述上傳數據附加了標頭的數據送出到所述通信接口，在由所述是否需要壓縮判別部判別為需要壓縮所述上傳數據的情況下，將對由所述數據壓縮部壓縮后的上傳數據附加了儲存有表示是壓縮后的數據的信息的標頭而得的數據送出到所述通信接口。

發明效果

根據本發明，判別是否需要壓縮上傳數據，在判別為需要壓縮的情況下，壓縮上傳數據而發送到服務器，所以能夠在數據通信時防止主處理的延遲。

附圖說明

圖1是示出本發明的實施方式1的數據通信系統的整體結構的圖。

圖2是示出實施方式1的客戶端裝置的結構的框圖。

圖3是示出實施方式1的有無壓縮時間表格的一個例子的圖。

圖4是示出實施方式1的客戶端裝置具備的控制部的功能結構的圖。

圖5是用于說明數據壓縮時的由控制部進行的發送處理的所需時間的圖。

圖6是用于說明數據不壓縮時的由控制部進行的發送處理的所需時間的圖。

圖7是示出實施方式1的數據發送處理的步驟的流程圖。

圖8是示出在實施方式1中對未壓縮的上傳數據附加的標頭的一個例子的圖。

圖9是示出在實施方式1中對壓縮過的上傳數據附加的標頭的一個例子的圖。

圖10是示出在本發明的實施方式2的客戶端裝置具備的數據存儲部中存儲的表格的圖。

圖11是示出實施方式2的有無解壓時間表格的一個例子的圖。

圖12是示出實施方式2的客戶端裝置具備的控制部的功能結構的圖。

圖13是用于說明數據解壓時的由控制部進行的接收處理的所需時間的圖。

圖14是用于說明數據不解壓時的由控制部進行的接收處理的所需時間的圖。

圖15是示出實施方式2的數據發送處理的步驟的流程圖。

圖16是示出在實施方式2中請求壓縮的情況下對上傳數據附加的標頭的一個例子(其1)的圖。

圖17是示出在實施方式2中請求壓縮的情況下對上傳數據附加的標頭的一個例子(其2)的圖。

圖18是示出實施方式2的數據解壓處理的步驟的流程圖。

圖19是示出在實施方式2中對未壓縮的下載數據附加的標頭的一個例子的圖。

圖20是示出在實施方式2中對壓縮過的下載數據附加的標頭的一個例子的圖。

圖21是示出在本發明的實施方式3的客戶端裝置具備的數據存儲部中存儲的表格的圖。

圖22是示出在實施方式3中對壓縮過的上傳數據附加的標頭的一個例子的圖。

圖23是示出在本發明的實施方式4的客戶端裝置具備的數據存儲部中存儲的表格的圖。

圖24是示出在實施方式4中對壓縮過的上傳數據附加的標頭的一個例子的圖。

圖25是示出實施方式5的客戶端裝置具備的控制部的功能結構的圖。

圖26是示出實施方式6的客戶端裝置具備的控制部的功能結構的圖。

(符號說明)

1：客戶端裝置；2：服務器；3：路由器；4：功率傳感器；5：設備；10：廣域通信接口；11：設備通信接口；12：數據存儲部；13：控制部；14：總線；120：有無壓縮時間表格；121：有無解壓時間表格；130：應用處理部；131、131A：是否需要壓縮判別部；132：數據壓縮部；133、133A：數據送出部；134：數據取入部；135：是否需要解壓判別部；136：數據解壓部；137：壓縮時間測量部；138：送出時間測量部；139：解壓時間測量部；140：取入時間測量部。

具體實施方式

以下，參照附圖，對本發明的實施方式詳細地進行說明。

(實施方式1)

圖1是示出本發明的實施方式1的數據通信系統的整體結構的圖。該數據通信系統包括在住宅H內配置的客戶端裝置1和與因特網等廣域網N連接的服務器2。

客戶端裝置1是管理在一般家庭中使用的電力的、被稱為所謂HEMS(Home Energy Management System，家庭能源管理系統)的系統包含的能量管理控制器。客戶端裝置1經由在住宅H內構建的無線網絡(未圖示)，與測量在該家庭(需求處)消耗的電量的功率傳感器4以及多個設備5以可通信的方式連接。各設備5是例如照明器、空調器、電冰箱、IH烹飪加熱器、電飯鍋、微波爐、地暖系統等在住宅H內設置的電氣設備。

客戶端裝置1經由與寬帶對應的路由器3連接到廣域網N，根據需要與服務器2進行數據的交換。在本實施方式中，作為客戶端裝置1與服務器2之間的通信協議，使用TCP/IP(Transmission Control Protocol/Internet Protocol，傳輸控制協議/網際協議)，作為數據通信的協議，使用HTTP(HyperText Transfer Protocol，超文本傳輸協議)。因此，客戶端裝置1具備HTTP客戶端功能，服務器2具備HTTP服務器功能。

客戶端裝置1如圖2所示，具備：廣域通信接口10，用于與服務器2進行通信；設備通信接口11，用于與功率傳感器4以及各設備5進行通信；數據存儲部12，用于保持程序、數據；以及控制部13，對它們進行控制。這些各結構部經由總線14相互連接。

廣域通信接口10與路由器3連接，經由廣域網N與服務器2通信連接。廣域通信接口10將從控制部13供給的數據發送到服務器2。另外，廣域通信接口10將從服務器2接收到的數據供給到控制部13。

設備通信接口11與在住宅H內構建的上述無線網絡連接，在控制部13的控制下，與功率傳感器4以及各設備5進行無線數據通信。

數據存儲部12由例如閃存存儲器等可讀寫的非易失性半導體存儲器等構成。數據存儲部12存儲有無壓縮時間表格120。另外，雖然未圖示，數據存儲部12存儲用于與服務器2進行數據通信的程序、在該程序的執行時使用的數據。進而，數據存儲部12存儲用于監視家庭內的耗電量的程序、用于控制各設備5的工作的程序以及在這些程序的執行時使用的數據。

有無壓縮時間表格120(第1時間表格)是針對每個階段性地預先決定的數據大小，儲存了壓縮時以及不壓縮時的各自的由控制部13進行的發送處理的所需時間的數據表格。圖3示出本實施方式中的有無壓縮時間表格120的一個例子。在圖3的例子中，示出了關于通過控制部13發送數據大小為100[KB]的數據時的所需時間，在壓縮過的情況下為A1[ms]，在不壓縮的情況下為B1[ms]。此外，在本實施方式中，向服務器2上傳的數據(上傳數據)是文本數據，作為數據壓縮方式，使用gzip(GNU ZIP)。

控制部13構成為包括CPU(Central Processing Unit，中央處理單元)、ROM(Read Only Memory，只讀存儲器)、RAM(Random Access Memory，隨機存取存儲器)等(都未圖示)，對客戶端裝置1進行總體控制。如圖4所示，控制部13作為本發明特有的功能，具備應用處理部130、是否需要壓縮判別部131、數據壓縮部132、數據送出部133以及數據取入部134。

應用處理部130生成要向服務器2上傳的數據(上傳數據)。例如，應用處理部130通過匯總預先決定的期間量(例如1個星期)的與該家庭的1天的耗電量的推移有關的數據的歷史而生成上傳數據。另外，應用處理部130進行與從服務器2下載的數據(下載數據)對應的處理。例如，應用處理部130使基于下載數據的信息顯示于未圖示的終端裝置(例如平板型的個人計算機)。

是否需要壓縮判別部131判別是否需要壓縮應用處理部130所生成的上傳數據。是否需要壓縮判別部131根據所生成的上傳數據的大小和有無壓縮時間表格120，判別是否需要壓縮該上傳數據。例如，在該上傳數據的大小是100[KB]的情況下，如果A1<B1，則判別為需要壓縮，在A1≥B1的情況下，判別為無需壓縮。

數據壓縮部132在由是否需要壓縮判別部131判別為需要壓縮的情況下，以預先決定的方式(在本實施方式中為gzip)壓縮應用處理部130所生成的上傳數據。

數據送出部133進行如下處理：生成對未壓縮或者壓縮過的上傳數據附加了標頭的數據(發送數據)，將所生成的發送數據送出到廣域通信接口10。具體而言，數據送出部133進行如下處理：在廣域通信接口10的發送緩沖器中，從發送數據的開頭依次寫入預先決定的大小量的數據。數據送出部133在對壓縮過的上傳數據附加的標頭中，儲存表示是壓縮過的數據的信息(詳情后述)。

在此，對壓縮上傳數據時由控制部13進行的發送處理的所需時間進行說明。在該情況下，如圖5所示，首先，通過數據壓縮部132進行數據壓縮處理，在該數據壓縮處理完成之后，開始由數據送出部133進行的數據送出處理。在數據送出處理中，生成對壓縮過的上傳數據附加了標頭的發送數據。在此，在被附加的標頭中，如上述那樣地儲存有表示是壓縮過的數據的信息。

接下來，從所生成的發送數據的開頭，按照每次幾個字節地讀出發送數據，寫入到廣域通信接口10的發送緩沖器。然后，從發送數據讀出最后的數據，寫入到廣域通信接口10的發送緩沖器，從而由數據送出部133進行的數據送出處理完成。

在本實施方式中，如上述那樣地壓縮上傳數據時的由控制部13進行的發送處理的所需時間成為將由數據壓縮部132進行的數據壓縮處理的所需時間和由數據送出部133進行的數據送出處理的所需時間相加而得到的時間。

接下來，對不壓縮上傳數據時的由控制部13進行的發送處理的所需時間進行說明。在該情況下，如圖6所示，立即開始由數據送出部133進行的數據送出處理。在數據送出處理中，生成對未壓縮的上傳數據附加了標頭的發送數據。在此，在被附加的標頭中當然沒儲存表示是壓縮過的數據的信息。

接下來，如上述那樣地，從所生成的發送數據的開頭按照每次幾個字節地依次讀出發送數據，寫入到廣域通信接口10的發送緩沖器。然后，從發送數據讀出最后的數據，寫入到廣域通信接口10的發送緩沖器，從而由數據送出部133進行的數據送出處理完成。

在本實施方式中，如上述那樣地，不壓縮上傳數據時的由控制部13進行的發送處理的所需時間等于由數據送出部133進行的數據送出處理的所需時間。

返回到圖4，數據取入部134進行如下的處理：從廣域通信接口10取入從服務器2發送并通過廣域通信接口10接收到的數據(接收數據)。更詳細而言，從廣域通信接口10的接收緩沖器按照每次幾個字節地依次取入接收數據。數據取入部134將所取入的接收數據供給到應用處理部130。

圖7是示出由客戶端裝置1的控制部13執行的數據發送處理的步驟的流程圖。每當通過應用處理部130生成上傳數據時，就執行該數據發送處理。

首先，是否需要壓縮判別部131如上述那樣地判別是否需要壓縮所生成的上傳數據(步驟S101)。其結果是，在需要壓縮上傳數據的情況下(步驟S102：“是”)，數據壓縮部132以預先決定的方式(在本實施方式中為gzip)壓縮上傳數據(步驟S103)。另一方面，在無需壓縮上傳數據的情況下(步驟S102：“否”)，數據送出部133通過對上傳數據附加標頭，生成發送數據(步驟S104)。圖8示出該情況下的標頭的一個例子。

在接著步驟S103的步驟S105中，數據送出部133通過對壓縮過的上傳數據附加儲存有表示是壓縮數據的信息的標頭，生成發送數據。圖9示出該情況下的標頭的一個例子。然后，數據送出部133將所生成的發送數據供給到廣域通信接口10(步驟S106)。具體而言，數據送出部133進行如下的處理：在廣域通信接口10的發送緩沖器中，從發送數據的開頭依次寫入預先決定的大小量的數據。

如以上說明的那樣，根據本發明的實施方式1的數據通信系統，客戶端裝置1的控制部13在將上傳數據發送到服務器2時，根據該上傳數據的大小和有無壓縮時間表格120，判別是否需要壓縮該上傳數據。此時，控制部13判別是否需要壓縮該上傳數據，以使由控制部13進行的發送處理的所需時間變得更短。

由此，能夠高精度地縮短由控制部13進行的發送處理的所需時間，能夠減輕控制部13(CPU)的通信時的負荷。因此，即使在搭載于客戶端裝置1的CPU并非高性能的情況下，也能夠防止與電力的管理、各設備5的控制有關的主處理的延遲。

(實施方式2)

接下來，對本發明的實施方式2的數據通信系統進行說明。此外，在以下的說明中，對與上述實施方式共用的構成要素等附加相同的符號并省略其說明。

本實施方式的客戶端裝置1具備的數據存儲部12如圖10所示，除了有無壓縮時間表格120以外，還存儲有無解壓時間表格121。有無解壓時間表格121(第2時間表格)是針對每個階段性地預先決定的數據大小，儲存了解壓時以及不解壓時的各自的由控制部13進行的接收處理的所需時間的數據表格。圖11示出本實施方式中的有無解壓時間表格121的一個例子。在圖11的例子中，示出了關于通過控制部13接收數據大小為100[KB]的數據時的所需時間，在解壓了的情況下為C1[ms]，在不解壓的情況下為D1[ms]。

此外，在圖11的有無解壓時間表格121中，與解壓時的處理時間對應的數據大小(例如與C1[ms]對應的100[KB])不是表示壓縮后的數據大小，而是表示壓縮前的數據大小。

本實施方式的客戶端裝置1具備的控制部13如圖12所示，作為本發明特有的功能，具備應用處理部130、是否需要壓縮判別部131A、數據壓縮部132、數據送出部133A、數據取入部134、是否需要解壓判別部135以及數據解壓部136。

是否需要壓縮判別部131A與實施方式1的是否需要壓縮判別部131同樣地，判別是否需要壓縮應用處理部130所生成的上傳數據。進而，是否需要壓縮判別部131A在上傳數據的內容表示對服務器2的下載的請求的情況下，判別是否需要壓縮響應于該請求而被預定從服務器2下載的下載預定數據。

在該情況下，是否需要壓縮判別部131A根據下載預定數據的大小和有無解壓時間表格121，判別是否需要壓縮該下載預定數據。例如，在該下載預定數據的大小是100[KB]的情況下，如果C1<D1，則判別為需要壓縮，在C1≥D1的情況下，判別為無需壓縮。此外，在本實施方式中，下載預定數據的大小被設為能夠根據所請求的下載數據的類別而判別的大小。或者，也可以是通過應用處理部130來指定所請求的下載數據的大小的方式。

數據送出部133A與實施方式1的數據送出部133同樣地，進行如下的處理：生成對未壓縮或者壓縮過的上傳數據附加了標頭的數據(發送數據)，將所生成的發送數據送出到廣域通信接口10。進而，數據送出部133A在由是否需要壓縮判別部131A判別為需要壓縮下載預定數據的情況下，將請求壓縮下載數據的信息(詳情后述)儲存于發送數據的標頭。

是否需要解壓判別部135在由廣域通信接口10接收到的來自服務器2的數據(接收數據)中包括下載數據的情況下，判別是否需要解壓該下載數據。是否需要解壓判別部135在附加于下載數據的標頭中儲存有表示是壓縮過的數據的信息的情況下，判別為需要解壓該下載數據(即壓縮過的下載數據)。另一方面，當在上述標頭中未儲存表示是壓縮過的數據的信息的情況下，是否需要解壓判別部135判別為無需解壓該下載數據。

數據解壓部136在由是否需要解壓判別部135判別為需要解壓下載數據的情況下，以預先決定的方式(在本實施方式中為與gzip對應的解壓方式)解壓(恢復)下載數據。

在此，對接收到由服務器2壓縮的下載數據的情況下的由控制部13進行的接收處理的所需時間進行說明。在該情況下，如圖13所示，首先，進行通過數據取入部134從廣域通信接口10取入由廣域通信接口10接收到的數據(接收數據)的處理(數據取入處理)。在數據取入處理中，數據取入部134從廣域通信接口10的接收緩沖器按照每次幾個字節地依次取入接收數據。在該數據取入處理完成之后，通過數據解壓部136開始數據解壓處理。

此外，數據解壓部136對從在數據取入處理中所取入的接收數據中去除了標頭的數據(即壓縮過的下載數據)進行解壓。然后，當數據解壓處理完成時，將已解壓的(即恢復了的)下載數據供給到應用處理部130。

在本實施方式中，如上述那樣地接收到壓縮過的下載數據的情況下的由控制部13進行的接收處理的所需時間成為將由數據取入部134進行數據取入處理的所需時間和由數據解壓部136進行數據解壓處理的所需時間相加而得到的時間。

接下來，對接收到未由服務器2壓縮的下載數據的情況下的由控制部13進行的接收處理的所需時間進行說明。在該情況下，如圖14所示，當由用數據取入部134進行的數據取入處理完成時，不進行由數據解壓部136進行的數據解壓處理，將從由數據取入部134所取入的數據中去掉標頭的數據作為下載數據供給到應用處理部130。

在本實施方式中，如上述那樣地接收到未壓縮的下載數據的情況下的由控制部13進行的接收處理的所需時間等于由數據取入部134進行數據取入處理的所需時間。

圖15是示出由本實施方式的客戶端裝置1的控制部13執行的數據發送處理的步驟的流程圖。每當通過應用處理部130生成上傳數據時，就執行該數據發送處理。

首先，是否需要壓縮判別部131判別是否需要壓縮所生成的上傳數據(步驟S201)。其結果是，在需要壓縮上傳數據的情況下(步驟S202：“是”)，數據壓縮部132以預先決定的方式(在本實施方式中為gzip)壓縮上傳數據(步驟S203)。另一方面，在無需壓縮上傳數據的情況下(步驟S202：“否”)，數據送出部133通過對上傳數據附加標頭，生成發送數據(步驟S204)。

在接著步驟S203的步驟S205中，數據送出部133通過對壓縮過的上傳數據附加儲存有表示是壓縮數據的信息的標頭，生成發送數據。

是否需要壓縮判別部131A判別上傳數據的內容是否為表示對服務器2的下載的請求的內容(步驟S206)。在上傳數據的內容不是表示下載的請求的內容的情況下(步驟S206：“否”)，控制部13進入到步驟S210的處理。

另一方面，在上傳數據的內容是表示下載的請求的內容的情況下(步驟S206：“是”)，是否需要壓縮判別部131A如上述那樣地判別是否需要壓縮響應于該請求而被預定從服務器2下載的下載預定數據(步驟S207)。在由是否需要壓縮判別部131A判別為無需壓縮下載預定數據的情況下(步驟S208：“否”)，控制部13進入到步驟S210的處理。

另一方面，在由是否需要壓縮判別部131A判別為需要壓縮下載預定數據的情況下(步驟S208：“是”)，數據送出部133A在步驟S204或者S205中所生成的發送數據的標頭中儲存請求下載數據的壓縮的信息(步驟S209)。圖16以及圖17示出該情況下的標頭的一個例子。圖16示出上傳數據未被壓縮的情況的例子，圖17示出上傳數據被壓縮的情況的例子。

然后，數據送出部133A將所生成的發送數據供給到廣域通信接口10(步驟S210)。

圖18是示出由本實施方式的客戶端裝置1的控制部13執行的數據解壓處理的步驟的流程圖。每當通過數據取入部134完成從廣域通信接口10取入接收數據時，就執行該數據解壓處理。

首先，是否需要解壓判別部135判別在接收數據中是否包括下載數據(步驟S301)。在接收數據中未包括下載數據的情況下(步驟S301：“否”)，數據解壓處理結束。

另一方面，在接收數據中包括下載數據的情況下(步驟S301：“是”)，是否需要解壓判別部135判別是否需要解壓該下載數據(步驟S302)。是否需要解壓判別部135通過在附加于下載數據的標頭中是否儲存有表示是壓縮過的數據的信息(例如表示壓縮方式的信息)，判別是否需要解壓該下載數據。即，如圖19所示，當在標頭中未儲存表示是壓縮過的數據的信息的情況下，是否需要解壓判別部135判別為無需解壓下載數據。另一方面，如圖20所示，當在標頭中儲存有表示是壓縮過的數據的信息的情況下，是否需要解壓判別部135判別為需要解壓下載數據。

在無需解壓下載數據的情況下(步驟S303：“否”)，數據解壓處理結束。另一方面，在需要解壓下載數據的情況下(步驟S303：“是”)，數據解壓部136以預先決定的方式(在本實施方式中為與gzip對應的解壓方式)，解壓下載數據(步驟S304)。在該情況下，將已解壓的(即已恢復的)下載數據供給到應用處理部130。

如以上說明的那樣，根據本發明的實施方式2的數據通信系統，客戶端裝置1具有與實施方式1的客戶端裝置1等同的功能，進而，在對服務器2請求下載數據時，判別是否需要壓縮響應于該請求而被預定從服務器2下載的下載數據(下載預定數據)。此時，客戶端裝置1的控制部13根據下載預定數據的大小和有無解壓時間表格121，判別是否需要壓縮下載預定數據，以使控制部13(CPU)進行的接收處理的所需時間變得更短。

因此，能夠高精度地縮短由控制部13進行的發送處理以及接收處理的所需時間。因此，能夠在控制部13(CPU)中，減輕數據發送時以及數據接收時的負荷。

(實施方式3)

接下來，對本發明的實施方式3的數據通信系統進行說明。此外，在以下的說明中，對與上述實施方式共用的構成要素等附加相同符號并省略其說明。

在實施方式1中，通過數據壓縮部132壓縮上傳數據時的數據壓縮方式是固定的(例如gzip)。然而，在實施方式3中，數據壓縮部132以由是否需要壓縮判別部131從多個不同的壓縮方式中所選定的壓縮方式壓縮上傳數據。

本實施方式的客戶端裝置1具備的控制部13的功能結構與實施方式1的控制部13的功能結構相同(參照圖4)。另外，在本實施方式的客戶端裝置1具備的數據存儲部12中，如圖21所示，存儲了多個不同的壓縮方式的每一個的有無壓縮時間表格120。在本實施方式中，例如，除了與gzip對應的有無壓縮時間表格120(參照圖3)以外，在數據存儲部12中還存儲了與compress、deflate等壓縮方式對應的有無壓縮時間表格120。

是否需要壓縮判別部131與實施方式1同樣地，對于與有無壓縮時間表格120的上傳數據的大小對應的記錄項，比較壓縮時的處理時間和不壓縮時的處理時間。然而，在本實施方式中，是否需要壓縮判別部131針對所有有無壓縮時間表格120進行上述比較。然后，在至少某一個有無壓縮時間表格120中，對于與該上傳數據的大小對應的記錄項，在壓縮時的處理時間<不壓縮時的處理時間成立的情況下，是否需要壓縮判別部131判別為需要壓縮上傳數據。然后，在多個有無壓縮時間表格120中，對于與該上傳數據的大小對應的記錄項，在壓縮時的處理時間<不壓縮時的處理時間成立的情況下，從其中選定壓縮時的處理時間最短的壓縮方式作為本次使用的壓縮方式。

數據壓縮部132按照由是否需要壓縮判別部131所選定的壓縮方式來壓縮上傳數據。數據送出部133在由數據壓縮部132進行了壓縮的情況下，通過對壓縮過的上傳數據附加儲存有表示由是否需要壓縮判別部131所選定的壓縮方式的信息的標頭，生成發送數據。圖22示出該情況下的標頭的一個例子。

如以上說明的那樣，根據本發明的實施方式3的數據通信系統，客戶端裝置1按照從多個壓縮方式適宜地選定的壓縮方式來壓縮上傳數據。因此，進一步縮短由控制部13進行發送處理的所需時間。

(實施方式4)

接下來，對本發明的實施方式4的數據通信系統進行說明。此外，在以下的說明中，對與上述實施方式共用的構成要素等附加相同符號并省略其說明。

在實施方式2中，在從客戶端裝置1對服務器2請求了下載數據的壓縮的情況下，由服務器2壓縮下載數據時的方式是固定的(例如gzip)。然而，在實施方式4中，客戶端裝置1對服務器2指定從多個壓縮方式中選定的壓縮方式。

本實施方式的客戶端裝置1具備的控制部13的功能結構與實施方式2的控制部13的功能結構相同(參照圖12)。另外，在本實施方式的客戶端裝置1具備的數據存儲部12中，如圖23所示，存儲了多個不同的壓縮方式的每一個的有無壓縮時間表格120和多個不同的壓縮方式的每一個的有無解壓時間表格121。與實施方式3同樣地，為了按照從多個壓縮方式中適宜地選定的壓縮方式來壓縮上傳數據，使用多個不同的壓縮方式的每一個的有無壓縮時間表格120。

在本實施方式中，例如，除了與gzip對應的有無解壓時間表格121(參照圖11)以外，在數據存儲部12中還存儲了與compress、deflate等壓縮方式對應的有無解壓時間表格121。

本實施方式的是否需要壓縮判別部131A與實施方式2同樣地，在上傳數據的內容表示對服務器2的下載的請求的情況下，對于與有無解壓時間表格121的下載預定數據的大小對應的記錄項，比較解壓時的處理時間和不解壓時的處理時間。然而，在本實施方式中，是否需要壓縮判別部131A針對所有有無解壓時間表格121進行上述比較。然后，在至少某一個有無解壓時間表格121中，對于與該下載預定數據的大小對應的記錄項，在解壓時的處理時間<不解壓時的處理時間成立的情況下，是否需要壓縮判別部131A判別為需要壓縮下載預定數據。

然后，在多個有無解壓時間表格121中，對于與該下載預定數據的大小對應的記錄項，在解壓時的處理時間<不解壓時的處理時間成立的情況下，從其中選定解壓時的處理時間最短的壓縮方式作為本次使用的壓縮方式。

數據送出部133A在由是否需要壓縮判別部131A判別為需要壓縮下載預定數據的情況下，將表示由是否需要壓縮判別部131A所選定的壓縮方式的信息儲存到發送數據的標頭。圖24示出該情況下的標頭的一個例子。在圖24的例子中，示出了上傳數據被按照deflate壓縮，示出了對服務器2請求按照compress壓縮下載數據。

服務器2在按照由客戶端裝置1指定的壓縮方式壓縮了下載數據的情況下，在對壓縮過的下載數據附加的標頭中儲存表示壓縮方式的信息。

是否需要解壓判別部135在對來自服務器2的下載數據附加的標頭中儲存有表示壓縮方式的信息的情況下，判別為需要解壓下載數據，對數據解壓部136通知該壓縮方式。數據解壓部136按照由是否需要解壓判別部135通知的壓縮方式，解壓下載數據。

如以上說明的那樣，根據本發明的實施方式4的數據通信系統，客戶端裝置1具有與實施方式2以及3的客戶端裝置1等同的功能，進而，能夠對服務器2指定從多個壓縮方式中適宜地選定的壓縮方式。因此，能夠進一步縮短由控制部13進行的發送處理以及接收處理的所需時間。

(實施方式5)

接下來，對本發明的實施方式5的數據通信系統進行說明。此外，在以下的說明中，對與上述實施方式共用的構成要素等附加相同符號并省略其說明。

本實施方式的客戶端裝置1在實際運行模式和試運行模式這2種模式中的任意模式下工作。在實際運行模式下工作時，本實施方式的客戶端裝置1實現與實施方式3的客戶端裝置1等同的功能。

本實施方式的客戶端裝置1的特征在于，在試運行模式下工作時，構建多個不同的壓縮方式的每一個的有無壓縮時間表格120(參照圖21)。以下，對上述特征詳細地進行說明。

本實施方式的客戶端裝置1具備的控制部13如圖25所示，具備應用處理部130、是否需要壓縮判別部131、數據壓縮部132、數據送出部133、數據取入部134、壓縮時間測量部137以及送出時間測量部138。

壓縮時間測量部137以運行模式是試運行模式為條件，測量由數據壓縮部132進行的上傳數據的壓縮處理的開始至完成所需的時間、即數據壓縮部132的處理時間。此外，用戶能夠通過經由例如平板型的個人計算機等終端裝置的操作，將客戶端裝置1的工作切換為試運行模式或者實際運行模式。

送出時間測量部138以運行模式是試運行模式為條件，測量由數據送出部133進行的發送數據的送出處理的開始至完成所需的時間、即數據送出部133的處理時間。

在試運行模式下，用戶能夠經由上述終端裝置指定由應用處理部130生成的上傳數據的類別、有無壓縮、壓縮方式等測試用的各參數。此外，在試運行模式下，是否需要壓縮判別部131不起動。另外，數據壓縮部132在由上述參數指定為有壓縮的情況下，按所指定的壓縮方式壓縮上傳數據。

當由用戶指示了執行測試時，客戶端裝置1進行如下工作：根據如上述那樣地指定的各參數，將由應用處理部130所生成的上傳數據發送到服務器2。控制部13通過上述工作，根據如上述那樣地測量到的數據壓縮部132的處理時間和/或數據送出部133的處理時間、和上傳數據的大小，生成包括數據大小、壓縮時的處理時間以及不壓縮時的處理時間的記錄項。然后，控制部13將所生成的記錄項登記到與指定的壓縮方式對應的有無壓縮時間表格120。

通過變更各參數反復進行上述測試，構建圖21所示的多個不同的壓縮方式的每一個的有無壓縮時間表格120。

如以上說明的那樣，根據本發明的實施方式5的數據通信系統，使用通過使客戶端裝置1實際地工作而得到的數據(數據壓縮部132的處理時間、數據送出部133的處理時間)來構建多個不同的壓縮方式的每一個的有無壓縮時間表格120。因此，由于在實際運行模式下能夠使用這樣構建的有無壓縮時間表格120，所以由是否需要壓縮判別部131進行的是否需要壓縮的判別精度提高，作為結果，能夠進一步縮短由控制部13進行的發送處理的所需時間。

(實施方式6)

接下來，對本發明的實施方式6的數據通信系統進行說明。此外，在以下的說明中，對與上述實施方式共用的構成要素等附加相同符號并省略其說明。

本實施方式的客戶端裝置1與實施方式5的客戶端裝置1同樣地，在實際運行模式和試運行模式這2種模式中的任意模式下工作。在實際運行模式下工作時，本實施方式的客戶端裝置1實現與實施方式4的客戶端裝置1等同的功能。

本實施方式的客戶端裝置1的特征在于，在試運行模式下的工作時，構建圖23所示那樣的、多個不同的壓縮方式的每一個的有無壓縮時間表格120、和多個不同的壓縮方式的每一個的有無解壓時間表格121。以下，對上述特征詳細地進行說明。

本實施方式的客戶端裝置1具備的控制部13如圖26所示，具備應用處理部130、是否需要壓縮判別部131A、數據壓縮部132、數據送出部133A、數據取入部134、是否需要解壓判別部135、數據解壓部136、壓縮時間測量部137、送出時間測量部138、解壓時間測量部139以及取入時間測量部140。

解壓時間測量部139以運行模式是試運行模式為條件，測量由數據解壓部136進行的下載數據的解壓處理的開始至完成所需的時間、即數據解壓部136的處理時間。此外，與實施方式5同樣地，用戶能夠通過經由例如平板型的個人計算機等終端裝置的操作將客戶端裝置1的工作切換為試運行模式或者實際運行模式。

取入時間測量部140以運行模式是試運行模式為條件，測量由數據取入部134進行的接收數據的取入處理的開始至完成所需的時間、即數據取入部134的處理時間。

在試運行模式下，用戶與實施方式5同樣地，能夠經由上述終端裝置指定由應用處理部130生成的上傳數據的大小、有無壓縮、壓縮方式等構建有無壓縮時間表格120的測試用的參數。進而，在本實施方式中，用戶能夠經由上述終端裝置，指定對服務器2請求的下載數據的類別、有無壓縮請求、請求的壓縮方式等構建有無解壓時間表格121的測試用的參數。

此外，在試運行模式下，是否需要壓縮判別部131A不起動。另外，與實施方式5同樣地，數據壓縮部132在由上述參數指定為有壓縮的情況下，按指定的壓縮方式壓縮上傳數據。

當由用戶指示了執行構建有無壓縮時間表格120的測試時，與實施方式5同樣地，控制部13根據測量到的數據壓縮部132的處理時間和/或數據送出部133A的處理時間、和上傳數據的大小，生成包括數據大小、壓縮時的處理時間以及不壓縮時的處理時間的記錄項。然后，控制部13將所生成的記錄項登記到與指定的壓縮方式對應的有無壓縮時間表格120。

通過變更各參數反復進行用于構建有無壓縮時間表格120的上述測試，構建圖23所示的多個不同的壓縮方式的每一個的有無壓縮時間表格120。

另外，當由用戶指示了執行構建有無解壓時間表格121的測試時，客戶端裝置1進行如下的工作：根據指定的各參數，將用于請求下載數據的上傳數據發送到服務器2，和接收響應于上述請求而從服務器2送來的下載數據。

控制部13通過上述工作，根據如上述那樣地測量到的數據取入部134的處理時間和/或數據解壓部136的處理時間、下載數據的有無壓縮、下載數據的壓縮方式以及下載數據(不壓縮時)的大小，生成包括數據大小、解壓時的處理時間以及不解壓時的處理時間的記錄項。然后，控制部13將所生成的記錄項登記到與指定的壓縮方式對應的有無解壓時間表格121。

通過變更各參數反復進行用于構建有無解壓時間表格121的上述測試，構建圖23所示的多個不同的壓縮方式的每一個的有無解壓時間表格121。

如以上說明的那樣，根據本發明的實施方式6的數據通信系統，起到與實施方式5的數據通信系統同樣的效果。進而，根據實施方式6的數據通信系統，使用通過使客戶端裝置1實際地工作而得到的數據(數據取入部134的處理時間、數據解壓部136的處理時間)，構建多個不同的壓縮方式的每一個的有無解壓時間表格121。因此，由于在實際運行模式下能夠使用這樣構建的有無解壓時間表格121，所以由是否需要壓縮判別部131A進行的是否需要壓縮下載預定數據的判別精度提高，作為結果，能夠進一步縮短由控制部13進行的接收處理的所需時間。

此外，本發明不限于上述各實施方式，當然能夠在不脫離本發明的宗旨的范圍內進行各種變更。

例如，當在數據存儲部12存儲有多個不同的壓縮方式的每一個的有無壓縮時間表格120、多個不同的壓縮方式的每一個的有無解壓時間表格121的情況下，由于不壓縮時的處理時間、不解壓時的處理時間不依賴于壓縮方式而由數據大小決定，所以也可以共用地存儲。

另外，在上述各實施方式中，還能夠將由客戶端裝置1執行的程序儲存到CD-ROM(Compact Disc Read Only Memory，只讀存儲型光盤)、DVD(Digital Versatile Disc，數字多功能盤)、MO(Magneto-Optical Disk，磁光盤)、USB存儲器、存儲卡等計算機可讀取的記錄介質而分發。另外，還能夠通過將上述程序安裝到特定或者通用的計算機，而使該計算機作為上述各實施方式中的客戶端裝置1發揮功能。

另外，也可以將上述程序儲存到因特網等通信網絡上的服務器裝置具有的盤裝置等，疊加到例如載波上，下載到計算機等。另外，通過在經由通信網絡轉發程序的同時起動執行程序，也能夠進行上述處理。進而，通過在服務器裝置上執行程序的全部或者一部分，計算機在經由通信網絡發送接收與該處理有關的信息的同時執行程序，也能夠進行上述處理。

此外，在OS(Operating System，操作系統)分擔實現上述功能時或者通過OS和應用的協作實現上述功能時等，也可以僅將OS以外的部分儲存到上述記錄介質而分發，并且，也可以下載到計算機等。

本發明能夠不脫離廣義的精神和范圍而實現各種實施方式以及變形。另外，上述實施方式用于說明本發明，不限定本發明的范圍。即，本發明的范圍并非由實施方式而是由權利要求書示出。另外，在權利要求書內以及與其等同的發明的意義的范圍內實施的各種變形被視為本發明的范圍內。

產業上的可利用性

本發明可適用于客戶端裝置與服務器之間的數據通信技術。