通信中继装置和通信中继方法.pdf

一种通信中继装置和通信中继方法，客户端应用程序经由没有多会话概念的通信线路而通过多会话无混乱地与图像处理装置进行通信。在该通信中继装置中，当确立新的会话时，在禁止基于其他会话以外的会话的通信时等待通信，在没有禁止通信时、或者解除了待机时，在禁止了基于该新的会话以外的会话的通信的状态下，通过该新的会话在客户端应用程序与图像处理装置之间对通信进行中继，当完成中继时禁止基于该新的会话以外的会话的通信。

权利要求书
1.  一种通信中继装置，以能够通过通信线路进行通信的方式与图像处理装置连接，所述通信中继装置具有处理部，
所述处理部执行：
确立处理，当从通过多会话进行通信的客户端应用程序请求会话的确立时，根据该请求在与所述客户端应用程序之间确立新的会话；
判断处理，当通过所述确立处理而确立所述新的会话时，判断是否禁止了基于在与所述客户端应用程序之间确立的其他会话以外的会话的通信；
待机处理，在通过所述判断处理而判断为通信被禁止时，到通信被解禁为止将基于所述新的会话的通信待机；
排他处理，在通过所述判断处理而判断为通信没有被禁止时，或者，在基于所述待机处理的待机被解除时，禁止基于所述新的会话以外的会话的通信；
中继处理，在通过所述排他处理而禁止了基于所述新的会话以外的会话的通信的状态下，通过所述新的会话在所述客户端应用程序与所述图像处理装置之间对通信进行中继；以及
解禁处理，当完成所述中继处理的中继时，解禁基于所述新的会话以外的会话的通信。

2.  根据权利要求1所述的通信中继装置，其特征在于，
所述通信由一个请求和对于该请求的响应构成，
当在所述中继处理中已完成一对所述请求和所述响应的中继时，所述处理部判断为已完成中继。

3.  根据权利要求1所述的通信中继装置，其特征在于，
所述通信线路为通用串行总线。

4.  根据权利要求1所述的通信中继装置，其特征在于，
所述图像处理装置具有Web服务器功能，
所述客户端应用程序为Web浏览器，
所述处理部对在所述Web浏览器与所述Web服务器功能之间收发的通信数据进行中继。

5.  根据权利要求1所述的通信中继装置，其特征在于，
所述通信是用于从所述客户端应用程序设定所述图像处理装置的通信。

6.  根据权利要求1所述的通信中继装置，其特征在于，
所述处理部，当从所述客户端应用程序接收请求时，将该请求发送到所述图像处理装置，所述处理部当从所述图像处理装置接收对于该请求的响应时，将该响应发送到所述客户端应用程序，
所述请求和所述响应分别由多个通信数据构成，
所述处理部执行：
第1分析处理，对从所述客户端应用程序接收到的通信数据进行分析，判断该通信数据是否是表示所述请求的结束的通信数据；以及
第2分析处理，对从所述图像处理装置接收到的通信数据进行分析，判断该通信数据是否是表示所述响应的结束的通信数据，
在所述中继处理中，在通过所述第1分析处理而判断为是表示所述请求的结束的通信数据时，判断为已完成所述请求的接收，在通过所述第2分析处理而判断为是表示所述响应的结束的通信数据时，判断为已完成所述响应的接收。

7.  根据权利要求1所述的通信中继装置，其特征在于，
所述处理部，当从所述客户端应用程序接收请求时将该请求发送到所述图像处理装置，所述处理部当从所述图像处理装置接收对于该请求的响应时将该响应发送到所述客户端应用程序，
所述请求由多个通信数据构成，
所述处理部在所述中继处理中，在从所述客户端应用程序接收到 所述通信数据之后，在第1预定时间以上没有接收下一个所述通信数据时，临时判断为已完成所述请求的接收，
所述处理部在所述中继处理中，在从向所述图像处理装置发送了所述请求开始的第2预定时间以内没有从所述图像处理装置接收所述响应时，判断为没有完成来自所述客户端应用程序的所述请求的接收，从所述客户端应用程序接收剩余的通信数据。

8.  根据权利要求7所述的通信中继装置，其特征在于，
所述处理部在所述中继处理中，向所述图像处理装置询问是否已完成所述响应的发送，在从所述图像处理装置接收到询问结果是已完成时，判断为已完成所述响应的接收。

9.  根据权利要求1所述的通信中继装置，其特征在于，
所述客户端应用程序和所述通信中继装置构成为能够在单一的所述会话中收发多个成对的请求和响应，
所述处理部当已完成基于所述中继处理的一对所述请求和所述响应的中继时，在所述解禁处理中解禁基于所述新的会话以外的会话的通信，
所述处理部在通过所述解禁处理而解禁了基于所述新的会话以外的会话的通信之后，当在第3预定时间以内接收到维持所述新的会话的维持信号时返回到所述判断处理而重复进行处理，另一方面在没有接收到所述维持信号时切断所述新的会话。

10.  根据权利要求1至9中的任意一项所述的通信中继装置，其特征在于，
所述通信中继装置以能够通过多个物理的或逻辑的所述通信线路进行通信的方式与所述图像处理装置连接，
所述处理部在每次从所述客户端应用程序请求会话的确立时，执行选择任意一个所述通信线路的选择处理，
所述处理部在所述排他处理中，禁止使用相同所述通信线路进行 通信的其他会话的通信。

11.  一种通信中继方法，在以能够通过通信线路进行通信的方式与图像处理装置连接的信息处理装置中执行，所述通信中继方法使所述信息处理装置执行：
确立处理，当从通过多会话进行通信的客户端应用程序请求会话的确立时，根据该请求在与所述客户端应用程序之间确立新的会话；
判断处理，当通过所述确立处理而确立所述新的会话时，判断是否禁止了基于在与所述客户端应用程序之间确立的其他会话以外的会话的通信；
待机处理，在通过所述判断处理而判断为通信被禁止时，到通信被解禁为止将基于所述新的会话的通信待机；
排他处理，在通过所述判断处理而判断为通信没有被禁止时，或者，在基于所述待机处理的待机被解除时，禁止基于所述新的会话以外的会话的通信；
中继处理，在通过所述排他处理而禁止了基于所述新的会话以外的会话的通信的状态下，通过所述新的会话在所述客户端应用程序与所述图像处理装置之间对通信进行中继；以及
解禁处理，当完成所述中继处理的中继时，解禁基于所述新的会话以外的会话的通信。

12.  根据权利要求11所述的通信中继方法，其特征在于，
所述通信由一个请求和对于该请求的响应构成，
当在所述中继处理中已完成一对所述请求和所述响应的中继时，判断为已完成中继。

13.  根据权利要求11所述的通信中继方法，其特征在于，
所述通信线路为通用串行总线。

14.  根据权利要求11所述的通信中继方法，其特征在于，
所述图像处理装置具有Web服务器功能，
所述客户端应用程序为Web浏览器，
所述通信中继方法使所述信息处理装置对在所述Web浏览器与所述Web服务器功能之间收发的通信数据进行中继。

15.  根据权利要求11所述的通信中继方法，其特征在于，
所述通信是用于从所述客户端应用程序设定所述图像处理装置的通信。

16.  根据权利要求11所述的通信中继方法，其特征在于，
所述通信中继方法使所述信息处理装置进行如下处理：当从所述客户端应用程序接收请求时，将该请求发送到所述图像处理装置，当从所述图像处理装置接收对于该请求的响应时，将该响应发送到所述客户端应用程序，
所述请求和所述响应分别由多个通信数据构成，
所述通信中继方法使所述信息处理装置执行：
第1分析处理，对从所述客户端应用程序接收到的通信数据进行分析，判断该通信数据是否是表示所述请求的结束的通信数据；以及
第2分析处理，对从所述图像处理装置接收到的通信数据进行分析，判断该通信数据是否是表示所述响应的结束的通信数据，
在所述中继处理中，在通过所述第1分析处理而判断为是表示所述请求的结束的通信数据时，判断为已完成所述请求的接收，在通过所述第2分析处理而判断为是表示所述响应的结束的通信数据时，判断为已完成所述响应的接收。

17.  根据权利要求11所述的通信中继方法，其特征在于，
所述通信中继方法使所述信息处理装置进行如下处理：当从所述客户端应用程序接收请求时将该请求发送到所述图像处理装置，当从所述图像处理装置接收对于该请求的响应时将该响应发送到所述客户端应用程序，
所述请求由多个通信数据构成，
所述通信中继方法在所述中继处理中，在从所述客户端应用程序接收到所述通信数据之后，在第1预定时间以上没有接收下一个所述通信数据时，临时判断为已完成所述请求的接收，
所述通信中继方法在所述中继处理中，在从向所述图像处理装置发送了所述请求开始的第2预定时间以内没有从所述图像处理装置接收所述响应时，判断为没有完成来自所述客户端应用程序的所述请求的接收，从所述客户端应用程序接收剩余的通信数据。

18.  根据权利要求17所述的通信中继方法，其特征在于，
所述通信中继方法在所述中继处理中，向所述图像处理装置询问是否已完成所述响应的发送，在从所述图像处理装置接收到询问结果是已完成时，判断为已完成所述响应的接收。

19.  根据权利要求11所述的通信中继方法，其特征在于，
所述客户端应用程序和所述信息处理装置构成为能够在单一的所述会话中收发多个成对的请求和响应，
所述通信中继方法使所述信息处理装置进行如下所述的处理：
当已完成基于所述中继处理的一对所述请求和所述响应的中继时，在所述解禁处理中解禁基于所述新的会话以外的会话的通信，
在通过所述解禁处理而解禁了基于所述新的会话以外的会话的通信之后，当在第3预定时间以内接收到维持所述新的会话的维持信号时返回到所述判断处理而重复进行处理，另一方面在没有接收到所述维持信号时切断所述新的会话。

20.  根据权利要求11至19中的任意一项所述的通信中继方法，其特征在于，
所述信息处理装置以能够通过多个物理的或逻辑的所述通信线路进行通信的方式与所述图像处理装置连接，
所述通信中继方法使所述信息处理装置在每次从所述客户端应用 程序请求会话的确立时，执行选择任意一个所述通信线路的选择处理，
所述通信中继方法使所述信息处理装置在所述排他处理中，禁止使用相同所述通信线路进行通信的其他会话的通信。

说明书通信中继装置和通信中继方法
技术领域
本发明涉及对通信进行中继的技术。
背景技术
以往，公开有如下所述的技术：在图像处理装置中具有Web服务器功能，在由终端装置执行的Web浏览器上显示图像处理装置的设定画面等（例如参照专利文献1）。
另外，公开有通过互联网连接图像处理装置与终端装置，经由互联网而使图像处理装置对图像进行处理的称为IPP（Internet Printing Protocol：互联网打印协议）的标准。
并且，公开有在图像处理装置与终端装置通过USB（Universal Serial Bus：通用串行总线）而连接的环境中用于进行基于上述IPP的通信的称为IPP over USB的标准的草案。
现有技术文献
专利文献
专利文献1：日本特开2011-257945号公报
但是，一般Web浏览器与Web服务器功能通过多会话而进行通信。因此，在Web浏览器显示图像处理装置的设定画面等的情况下，Web浏览器通过多会话而与Web服务器功能进行通信。
但是，在USB中没有多会话的概念。因此，在终端装置与图像处理装置通过USB而连接的环境中，当Web浏览器与Web服务器功能 通过多会话而进行通信时，有可能如针对某会话的响应被发送到其他会话等那样响应混乱。
发明内容
在本说明书中，公开有客户端应用程序经由没有多会话概念的通信线路而通过多会话无混乱地与图像处理装置进行通信的技术。
通过本说明书而公开的通信中继装置，以能够通过通信线路进行通信的方式与图像处理装置连接，所述通信中继装置具有处理部，所述处理部执行：确立处理，当从通过多会话进行通信的客户端应用程序请求会话的确立时，根据该请求在与所述客户端应用程序之间确立新的会话；判断处理，当通过所述确立处理而确立所述新的会话时，判断是否禁止了基于在与所述客户端应用程序之间确立的其他会话以外的会话的通信；待机处理，在通过所述判断处理而判断为通信被禁止时，到通信被解禁为止将基于所述新的会话的通信待机；排他处理，在通过所述判断处理而判断为通信没有被禁止时，或者，在基于所述待机处理的待机被解除时，禁止基于所述新的会话以外的会话的通信；中继处理，在通过所述排他处理而禁止了基于所述新的会话以外的会话的通信的状态下，通过所述新的会话在所述客户端应用程序与所述图像处理装置之间对通信进行中继；以及解禁处理，当完成所述中继处理的中继时，解禁基于所述新的会话以外的会话的通信。
根据上述通信中继装置，由于在通过某个会话对通信进行中继的期间禁止其他会话的通信，因此能够抑制如针对某会话的响应被发送到其他会话等那样响应混乱的情况。
由此，根据上述通信中继装置，客户端应用程序能够经由没有多会话的概念的通信线路而通过多会话无混乱地与图像处理装置进行通信。
另外，也可以是所述通信由一个请求和对于该请求的响应构成，当在所述中继处理中已完成一对所述请求和所述响应的中继时，所述处理部判断为已完成中继。
根据上述通信中继装置，由于当完成一对所述请求和所述响应的中继时解禁基于其他会话的通信，因此能够缩短其他会话的待机时间。
另外，所述通信线路也可以是通用串行总线。
根据上述通信中继装置，客户端应用程序能够经由通用串行总线而通过多会话无混乱地与图像处理装置进行通信。
另外，也可以是，所述图像处理装置具有Web服务器功能，所述客户端应用程序为Web浏览器，所述处理部对在所述Web浏览器与所述Web服务器功能之间收发的通信数据进行中继。
根据上述通信中继装置，Web浏览器能够经由没有多会话概念的通信线路而通过多会话无混乱地与Web服务器功能进行通信。
另外，也可以是，所述通信是用于从所述客户端应用程序设定所述图像处理装置的通信。
根据上述通信中继装置，在从客户端应用程序设定图像处理装置时，能够通过多会话而无混乱地进行通信。
另外，也可以是，在该通信中继装置中，所述处理部当从所述客户端应用程序接收请求时将该请求发送到所述图像处理装置，所述处理部当从所述图像处理装置接收对于该请求的响应时将该响应发送到所述客户端应用程序，所述请求和所述响应分别由多个通信数据构成，所述处理部执行：第1分析处理，对从所述客户端应用程序接收到的 通信数据进行分析，判断该通信数据是否是表示所述请求的结束的通信数据；以及第2分析处理，对从所述图像处理装置接收到的通信数据进行分析，判断该通信数据是否是表示所述响应的结束的通信数据，在所述中继处理中，在通过所述第1分析处理而判断为是表示所述请求的结束的通信数据时，判断为已完成所述请求的接收，在通过所述第2分析处理而判断为是表示所述响应的结束的通信数据时，判断为已完成所述响应的接收。
根据上述通信中继装置，能够可靠地判断已完成请求和响应的接收。
另外，也可以是，在该通信中继装置中，所述处理部当从所述客户端应用程序接收请求时将该请求发送到所述图像处理装置，所述处理部当从所述图像处理装置接收对于该请求的响应时将该响应发送到所述客户端应用程序，所述请求由多个通信数据构成，所述处理部在所述中继处理中，在从所述客户端应用程序接收到所述通信数据之后，在第1预定时间以上没有接收下一个所述通信数据时，临时判断为已完成所述请求的接收，所述处理部在所述中继处理中，在从向所述图像处理装置发送了所述请求开始的第2预定时间以内没有从所述图像处理装置接收所述响应时，判断为没有完成来自所述客户端应用程序的所述请求的接收，从所述客户端应用程序接收剩余的通信数据。
根据上述通信中继装置，由于在第1预定时间以上没有从客户端应用程序接收通信数据时临时判断为已完成请求的接收，因此不用对通信数据的内容进行分析而能够判断是否已完成请求的接收。
但是，实际上还存在没有完成请求的接收，而出于某种理由仅是发送被延迟的情况。由于在没有完成请求的接收时，图像处理装置不发送响应，因此在没有在第2预定时间以内从图像处理装置接收响应时，可知已完成请求的接收的临时判断是错误的。
根据通信中继装置，由于在临时判断为错误时从客户端程序接收剩余的通信数据，因此能够接收所有的通信数据。
另外，也可以是，所述处理部在所述中继处理中，向所述图像处理装置询问是否已完成所述响应的发送，在从所述图像处理装置接收到询问结果是已完成时，判断为已完成所述响应的接收。
根据上述通信中继装置，不用对通信数据的内容进行分析而能够判断是否已完成通信的中继。
另外，也可以是，所述客户端应用程序和所述通信中继装置构成为能够在单一的所述会话中收发多个成对的请求和响应，所述处理部当已完成基于所述中继处理的一对所述请求和所述响应的中继时，在所述解禁处理中解禁基于所述新的会话以外的会话的通信，所述处理部在通过所述解禁处理而解禁了基于所述新的会话以外的会话的通信之后，当在第3预定时间以内接收到维持所述新的会话的维持信号时返回到所述判断处理而重复进行处理，另一方面在没有接收到所述维持信号时切断所述新的会话。
根据上述通信中继装置，不是对每个请求切断会话，从而能够高效地进行通信。
另外，也可以是，所述通信中继装置以能够通过多个物理的或逻辑的所述通信线路进行通信的方式与所述图像处理装置连接，所述处理部在每次从所述客户端应用程序请求会话的确立时，执行选择任意一个所述通信线路的选择处理，所述处理部在所述排他处理中，禁止使用相同所述通信线路进行通信的其他会话的通信。根据上述通信中继装置，客户端应用程序能够经由没有多会话的概念的多个通信线路而通过多会话无混乱地与图像处理装置进行通信。
通过本说明书而公开的通信中继方法，在以能够通过通信线路进行通信的方式与图像处理装置连接的信息处理装置中执行，所述通信中继方法使所述信息处理装置执行：确立处理，当从通过多会话进行通信的客户端应用程序请求会话的确立时，根据该请求在与所述客户端应用程序之间确立新的会话；判断处理，当通过所述确立处理而确立所述新的会话时，判断是否禁止了基于在与所述客户端应用程序之间确立的其他会话以外的会话的通信；待机处理，在通过所述判断处理而判断为通信被禁止时，到通信被解禁为止将基于所述新的会话的通信待机；排他处理，在通过所述判断处理而判断为通信没有被禁止时，或者，在基于所述待机处理的待机被解除时，禁止基于所述新的会话以外的会话的通信；中继处理，在通过所述排他处理而禁止了基于所述新的会话以外的会话的通信的状态下，通过所述新的会话在所述客户端应用程序与所述图像处理装置之间对通信进行中继；以及解禁处理，当完成所述中继处理的中继时，解禁基于所述新的会话以外的会话的通信。
另外，关于通过本说明书公开的技术，能够通过通信中继装置、通信中继方法、记录了通信中继程序的记录介质等各种方式来实现。
附图说明
图1是简化示出实施方式1的PC的电气结构的框图。
图2是示出PC的程序结构和打印机的功能的框图。
图3是示出打印机的设定画面的一例的示意图。
图4是示出通信中继处理的整个流程的时序图。
图5是通信中继处理的流程图。
图6是通过线程执行的处理的流程图。
图7是线程单位的中继处理的流程图。
图8是实施方式2的线程单位的中继处理的流程图。
图9是实施方式3的通过线程执行的处理的流程图。
图10是通信中继处理的流程图。
图11是实施方式4的通过线程执行的处理的流程图。
图12是基于IPP功能的通信处理的流程图。
图13是示出实施方式5的PC的程序结构和打印机的功能的框图。
具体实施方式
<实施方式1>
通过图1至图7对实施方式1进行说明。
（1）PC的电气结构
首先，参照图1，对实施方式1的作为信息处理装置的个人计算机（记载为PC）1的电气结构进行说明。
PC1具有CPU10、ROM11、RAM12、显示部13、操作部14、存储部15、USB主机接口部（图1中记载为USB主机IF部）16以及网络接口部（图1中记载为网络IF部）17。
CPU10通过执行存储在ROM11或存储部15中的程序而控制PC1的各部分。在ROM11中存储有通过CPU10执行的程序和数据等。RAM12是作为CPU10用于执行各种处理的主存储装置来使用。CPU10是处理部的一例。
显示部13构成为，具有液晶显示器等显示装置、驱动显示装置的显示器驱动电路等。
操作部14由键盘、鼠标以及连接它们的接口等构成。
存储部15是使用硬盘或闪存等非易失性存储器而存储各种程序和数据的装置。在存储部15中存储有操作系统（记载为OS）21、IPP/USB转换程序22、Web浏览器23等。
IPP/USB转换程序22是通信中继程序的一例。另外，Web浏览器23是通过多会话而进行通信的客户端应用程序的一例。
USB主机接口部16构成为具有USB（Universal SerialBus）主机控制器、连接有USB线缆4的插口等，USB主机接口部16以能够通过USB线缆进行通信的方式与打印机2连接。USB是通信线路的一例。
网络接口部17是用于通过LAN（Local Area Network：局域网）或互联网等通信网络5而与PC、便携电话、便携通信终端等外部的通信终端3进行通信的接口。另外，网络接口部17也可以通过有线而与通信网络5连接，也可以通过无线与通信网络5连接。
（2）打印机
图1所示的打印部2是通过电子照相方式或喷墨打印方式等而在打印纸张等片材上打印图像的装置。打印机2构成为USB打印机类设备。打印机2是图像处理装置的一例。
打印机2能够解释多个打印机语言，用户将使用哪个打印机语言预先设定到打印机2。另外，打印机2作为容纳打印图像的片材的片材托盘具有第1托盘和第2托盘。用户将容纳在各托盘中的片材的尺寸预先设定到打印机2。虽然在之后详细说明，但是这些设定能够从PC1通过USB而进行。
（3）PC与打印机之间的通信
PC1在与打印机2之间通过USB而至少进行以下的通信。
·用于设定打印机2的通信
·用于向打印机2发送打印数据的通信
这些通信是根据IPP over USB标准而进行。IPP（Internet Printing  Protocol）是以HTTP（Hyper Text Transfer Protocol：超文本传输协议）为基础的标准，是用于通过互联网或LAN等TCP/IP网络而与打印机2进行通信的标准。
IPP over USB是在通过USB而连接的环境中用于实现基于上述IPP的通信的标准。在IPP over USB中IPP的通信数据存储在USB分组中而收发。
（4）PC的程序结构和打印机的功能
接着，参照图2，对用于通过IPP over USB而进行通信的PC1的程序结构和打印机2的功能进行说明。
首先，对PC1的程序结构进行说明。PC1执行Web浏览器23、后台处理程序24以及IPP/USB转换程序22。
Web浏览器23是作为用户用于进行打印机2的设定的用户接口而使用的程序。作为Web浏览器23，能够使用一般利用的Web浏览器。
在PC1与打印机2通过USB而连接的环境中，Web浏览器23通过HTTP而与IPP/USB转换程序22进行通信。IPP/USB转换程序作为对于本机（localhost）（IP=127.0.0.1）的特定端口（以后记载为使用端口80）的服务器而工作。WEB浏览器23通过对本机的端口80（例：http://127.0.0.1:80）进行访问，从而向IPP/USB转换程序22请求用于显示打印机2的设定画面41（参照图3）的画面数据的发送。
此处，画面数据通过HTML（HyperText Markup Language：超文本标记语言）或XML（Extensible Markup Language：可扩展标记语言）记载。
发送到IPP/USB转换程序22的请求，通过IPP/USB转换程序22， 经由USB而发送到打印机2的IPP功能31。该IPP功能31进行IPP打印、设定画面CGI（Common Gateway Interface：通用网关接口），如果除去通过USB进行数据的输入输出，则与通过网络进行的以往的情况相同。因此，此处省略其详细。
另外，关于Web浏览器23，可以通过PC1而执行，也可以通过以能够进行通信的方式与PC1连接的外部的通信终端3执行。
后台处理程序24是对打印数据进行后台处理的程序。后台处理程序24是作为OS21的一部分来提供。在PC1与打印机2通过USB而连接的环境中，后台处理程序24通过IPP而与IPP/USB转换程序22进行通信，从而向IPP/USB转换程序22发送打印数据。
发送到IPP/USB转换程序22的打印数据，通过IPP/USB转换程序22，经由USB而发送到打印机2的IPP功能31。
IPP/USB转换程序22是在Web浏览器23与IPP功能31之间、以及在后台处理程序24与IPP功能31之间对通信进行中继的程序。IPP/USB转换程序22是通过USB而与IPP功能31通信。关于IPP/USB转换程序22的详细将在后面叙述。
接着，对打印机2的功能进行说明。打印机2具有IPP功能31和打印功能32。
IPP功能31具有用于从Web浏览器23设定打印机2的Web服务器功能、以及将从PC1接收到的打印数据输出到打印功能32的功能。IPP功能31是Web服务器功能的一例。
打印功能32是打印从IPP功能31输出的打印数据的功能。
（5）USB中的接口
接着，对USB中的接口进行说明。在USB中物理性地在一根USB线缆上构成称为接口1以上的逻辑通信线路。
在USB中必须构成用于进行控制转移的称为端点0的特殊的端点。端点0是能够进行双向通信的端点。接口是基于通过端点0从打印机2获取的接口描述符而构成的。各接口通常具有一至多个端点。
在本实施方式的打印机中构成接口1和接口2。而且，这些接口具有导线用端点和光线用端点，通过使用这些而实现双向通信。
并且，用于设定打印机2的通信是使用接口1而进行的，用于向打印机2发送打印数据的通信是通过接口2而进行的。
另外，也可以不构成接口2，用于设定打印机2的通信、和用于向打印机2发送打印数据的通信都使用接口1而进行。
（6）通过USB进行基于多会话的通信时的课题
接着，对通过USB进行基于多会话的通信时的课题进行说明。此处以用于从PC1设定打印机2的通信为例进行说明。
此处首先，参照图3，对打印机2的设定画面41进行说明。在图3所示例子的设定画面41中，能够设定打印机语言41a、设置在第1托盘的纸张尺寸41b、设置在第2托盘的纸张尺寸41c。
另外，如图3所示，在设定画面41上显示图像42、图像43、图像44。此处，将图像42～44分别称为GIF1、GIF2、GIF3。由于这些图像没有包含在画面数据中，因此Web浏览器23在接收到画面数据之后向IPP/USB转换程序22请求这些图像的发送。
即，该设定画面41通过由基于IPP功能31的设定画面CGI制作的HTML或XML数据而构成。
当通过Web浏览器23而访问本机的特定端口80（例:http://127.0.0.1:80）时，Web浏览器23在与IPP/USB转换程序之间构筑用于发出GET命令的会话，该GET命令用于获取该主页面的文件。该GET命令通过IPP/USB转换程序22而经由USB发送到打印机2，并通过IPP功能31的CGI而处理。作为该响应，用于显示设定画面41的HTML/XML数据的主页面通过USB而返回。该数据再次通过IPP/USB转换程序22而作为GET命令的响应返回到浏览器23。
浏览器23对该主页面进行分析，同样请求不足显示页面的部件（GIF1、GIF2、GIF3等）。
此时，由于Web浏览器23能够进行基于多会话的通信，因此对每个不足的部件（GIF1、GIF2、GIF3）确立会话而请求图像的发送。也就是说，首先发送对于GIF1的GET命令，不等待该响应而继续发送对于GIF2、GIF3的GET命令。但是，在USB的接口中没有多会话的概念。另外，IPP功能31未必按照GET命令的顺序返回该请求的部件，该返回的次序是不定的。因此，当多个会话的请求想要通过接口1而进行通信时，有可能引起对于某会话的响应被发送到其他会话等那样的混乱。
具体地讲，在从IPP功能31发送到IPP/USB转换程序22的响应中没有附加有用于识别会话的信息。因此，如果各会话通过接口1而进行通信，则在从IPP功能31接收到响应时，IPP/USB转换程序22不能判断该响应是对于哪个会话的响应。因此，有可能引起对于某会话的响应被发送到其他会话等的混乱。
因此，实施方式1的IPP/USB转换程序22，通过执行排他处理， 从而同时仅通过一个会话而对通信进行中继。
（7）基于IPP/USB转换程序的通信中继处理的整个流程
参照图4，对基于IPP/USB转换程序22的通信中继处理的整个流程进行说明。此处以用于从PC1设定打印机2的通信为例进行说明。如上所述用于设定打印机2的通信是使用接口1而进行。
在之后的说明中，在称为Web浏览器23时是指执行Web浏览器23的CPU10。关于IPP/USB转换程序22也同样。
IPP/USB转换程序22是作为对于http://127.0.0.1:80的TCP服务器程序而常驻。
当从用户输入用于指示设定画面41的显示的地址（http://127.0.0.1:80）时，Web浏览器23在与IPP/USB转换程序22之间确立网络的会话1（S101）。并且，Web浏览器23通过该会话1，将请求画面数据的主页面的发送的GET请求发送到IPP/USB转换程序22（S102）。另外关于此处说明的网络，假设在单一的PC1内进行的虚拟的网络。
当接收对于主页面的GET请求时，IPP/USB转换程序22将该GET请求通过USB而转送到打印机2的IPP功能31（S103）。
当接收GET请求时，IPP功能31将画面数据发送到IPP/USB转换程序22（S104）。
当从IPP功能31接收主页面的数据时，IPP/USB转换程序22经由网络将该画面数据转送到Web浏览器23（S105）。
当接收主页面的数据时，Web浏览器23解释该数据（S106）。在 该主页面上记载有为了显示设定画面41而所需的GIF1、GIF2、GIF3的信息。因此，Web浏览器23为了获取这些GIF1、GIF2、GIF3，在与IPP/USB转换程序22之间确立新的会话而请求图像的发送。
此时，Web浏览器23通过多会话而对GIF1、GIF2、GIF3的各自确立会话而请求图像的发送。因此，在图3所示的设定画面41的情况下，如图4所示，确立用于请求GIF1的发送的会话2（S107）、用于请求GIF2的发送的会话3（S108）以及用于请求GIF3的发送的会话4（S109）这三个会话。此处按照会话2、会话3以及会话4的顺序确立会话。
此时，当确立作为最初的会话的会话2时，IPP/USB转换程序22禁止基于会话2以外的会话的通信。并且，IPP/USB转换程序22通过会话2而在Web浏览器23与IPP功能31之间中继通信（S110～S113）。
并且，当已完成通过会话2的通信的中继时，IPP/USB转换程序22解禁基于会话3的通信。因此会话4成为通信被禁止的状态。
并且，IPP/USB转换程序22通过会话3而在Web浏览器23与IPP功能31之间中继通信（S114～S117），当完成该中继时解禁基于会话4的通信。
并且，IPP/USB转换程序22通过会话4而在Web浏览器23与IPP功能31之间中继通信（S118～S121）。
通过这一系列的处理，设定画面41的主页面和在该主页面中使用的GIF1、GIF2以及GIF3被读入到Web浏览器23，Web浏览器23显示设定画面41。对于该设定画面41的操作，被变更为HTTP协议的GET命令、POST命令等而同样通过IPP/USB转换程序发送到IPP功能31。通过该处理，按照与以往的通过网络而访问IPP的CGI同样的 顺序，通过USB进行打印机2的设定。
（8）基于IPP/USB转换程序的通信中继处理的详细
接着，参照图5，对上述通信中继处理进行具体说明。IPP/USB转换程序22是作为常驻程序而执行，该处理是当向PC1投入电源时作为常驻程序而开始的。
此处，本处理是在Web浏览器23与IPP功能31之间对通信进行中继的处理，在后台处理程序24与IPP功能31之间对通信进行中继的处理是作为与本处理不同的处理而执行的处理。省略关于该不同的处理的说明。
在S201中，IPP/USB转换程序22制作用于执行排他处理的互斥。互斥是用于进行排他处理的机制，是通过程序语言而提供的机制。关于互斥的详细将在后面叙述。
另外，虽然此处以使用互斥而进行排他处理的情况为例进行了说明，但是进行排他处理的方法不限定于此。例如也可以使用信号量而进行，也可以不使用互斥和信号量而通过单独的方法而进行。
在S202中，IPP/USB转换程序22进行套接字的制作和设定，该套接字对确立会话的请求（称为接受请求）进行监视。套接字是指用于通过TCP/IP而进行通信的抽象化的接口。另外，套接字的设定是指：在套接字上设定PC1的IP地址、端口号等，使该套接字的工作模式成为接受请求的监视模式。在本实施方式中，作为IP地址监视127.0.0.1，作为端口监视80。
当用户启动Web浏览器23，作为IP地址设定127.0.0.1、作为端口设定端口80时，Web浏览器23为了与该地址和端口进行通信，尝试连接。该处理成为接受请求。
在S203中，IPP/USB转换程序22到从Web浏览器23接收接受请求为止进行待机，当接收接受请求时前进到S204。
在S204中，IPP/USB转换程序22制作线程。
在S205中，IPP/USB转换程序22判断是否从OS21存在结束请求。IPP/USB转换程序22在存在结束请求时结束本处理，在不存在时返回到S203而重复进行处理。
（9）通过线程执行的处理
接着，参照图6，对通过在S204中制作的线程而执行的处理进行说明。如上所述线程是在每次接收接受请求时制作的。由于任意一个线程所执行的处理相同，因此此处以最初所制作的线程、即第1线程为例进行说明。
在S301中，第1线程执行接受处理。接受处理是在与发送了接受请求的对方、即发送确立会话的请求的对方之间确立新的会话的处理。当确立会话时，制作通过该会话进行通信的新的套接字。另外，在套接字的打开/关闭、接受等的定时，利用使用了USB的端点0的控制转移而将信息送到打印机2，也可以在上述打开、关闭、接受等的定时与打印机2获取同步。S301是在与Web浏览器23之间确立新的会话的确立处理的一例。
在S302中，第1线程执行禁止基于在S301中确立的新的会话以外的会话的通信的排他处理。
具体地讲，第1线程尝试在S201中制作的互斥的获取。在没有通过其他线程而获取互斥时，通过第1线程而获取互斥，之后尝试了互斥的获取的其他线程到通过第1线程而释放互斥为止成为待机状态。 由此，其他线程成为通信被禁止的状态。
另一方面，在通过其他线程而获取互斥时，第1线程到能够获取互斥为止成为待机状态。由此，第1线程成为通信被禁止的状态。并且，当其他线程释放互斥时，在存在比第1线程更早成为待机状态的线程时，通过该更早成为待机状态的线程而获取该互斥，第1线程继续成为待机状态。在没有比第1线程更早成为待机状态的线程时，通过第1线程而获取互斥。
第1线程当获取互斥时前进到S303。
此处，S302是判断处理、待机处理以及排他处理的一例。也就是说，第1线程通过使用互斥的机制而执行判断处理、待机处理以及排他处理。
在S303中，第1线程执行线程单位的中继处理。线程单位的中继处理是通过在S301中确立的新的会话而在Web浏览器23与IPP功能31之间中继通信的处理。关于线程单位的中继处理的详细，将在后面叙述。
在S304中，第1线程执行排他结束处理。具体地讲，第1线程释放互斥。S304是解禁处理的一例。
在S305中，第1线程关闭在S301中制作的会话而结束处理。
（10）线程单位的中继处理
接着，对在S303中执行的线程单位的中继处理进行说明。
此处首先，对从Web浏览器23发送到IPP/USB转换程序22的请求、和从IPP功能31发送到IPP/USB转换程序22的响应进行说明。
从Web浏览器23发送到IPP/USB转换程序22的请求由一个以上的通信数据构成。以下示出请求的一例。此处在各通信数据之前用[]括起来行号而示出。
[第一行]POST/ipp/[功能（function）]HTTP/1.1<CRLF>
[第二行]主机（Host）：本机<CRLF>
[第三行]内容-类型（Content-Type）：请求（application）/ipp<CRLF>
[第四行]传输-编码：分块（Transfer-Encoding：chunked）<CRLF>
[第五行]<CRLF>
在上述例中各行分别表示一个通信数据。另外，从上述例子可知，各通信数据最后以<CRLF>结束。<CRLF>是返回换行代码。
另外，如第五行所示，请求的最后的通信数据仅是<CRLF>。因此，在接收到的通信数据仅是<CRLF>时，能够判断为已完成一个请求的接收。
另外，在PUT命令和POST命令中，通常除了该一系列的请求以外，还发送二进制数据或文本数据。此时，在上述一系列的请求中插入内容-长度（Content-Length）：4554这一行，表示连着所指定的字节数（此时为4554）的附加数据。
另外，在预先不知道所有的附加数据的字节数时，有时表示以传输-编码：分块等形式连着切碎的数据块。此时，示出每个数据块的尺寸。
同样，从IPP功能31发送到IPP/USB转换程序22的一个响应也由一个以上的通信数据构成，最后的通信数据只是<CRLF>。另外，就对于GET命令的响应而言，与上述同样连着二进制数据。由于是在任何情况下都能广泛使用的技术，因此在此处省略该详细。
在S401中，第1线程通过在S301中确立的网络的会话而从Web浏览器23接收通信数据。
在S402中，第1线程将在S401中从Web浏览器23接收到的通信数据通过USB而发送到IPP功能31。
在S403中，第1线程判断是否已完成一个请求的接收。
具体地讲，根据HTTP的协议，对<CRLF>、内容-长度、传输-编码：分块等的出现状况进行分析，判断该数据结束。具体地讲，通过确认<CRLF>的有无、通过内容-长度和传输-编码：分块表示附加数据的尺寸，从而能够判断数据结束。
其结果，在判断为从Web浏览器23通过该会话而发送的所有请求数据和附随的数据向IPP功能31的转送结束时，前进到S404。另一方面，在判断为从Web浏览器23接收到的通信数据还没有结束时，第1线程判断为没有完成一个请求的接收，返回到S401而重复进行处理。S403是第1分析处理的一例。该转送的请求数据和附随的数据，通过IPP功能31的设定画面CGI而解释，IPP功能31制作与此对应的响应数据。例如，对于主页面请求的GET命令的响应，成为包含该主页面的一系列的信息。该数据通过USB而返回到IPP/USB转换程序22。
在S404中，第1线程作为对于发送到IPP功能31的请求的响应，从IPP功能31通过USB而接收通信数据。
在S405中，第1线程将在S404中从打印机2接收的通信数据，通过在S301中确立的会话而发送到Web浏览器23。
在S406中，第1线程判断是否已完成一个响应的接收。
该判断方法按照与S403相同的顺序进行。并且，在判断为已完成响应的接收时，结束该处理。另一方面，在判断为没有完成响应的接收时，返回到S404而重复进行处理。S406是第2分析处理的一例。
另一方面，虽然在第2线程中也与上述同样地进行通信，但是此时在S302中的排他处理中，到进行第一线程的排他结束处理S304为止成为待机状态。
同样，在第3线程中也到进行第2线程和第1线程的排他结束处理S304为止成为待机状态。
因此，中继处理S303保证在所有的线程中不同时进行。
（11）实施方式的效果
根据以上说明的IPP/USB转换程序22，在Web浏览器23经由作为没有多会话概念的通信线路的USB（更具体地讲是接口）通过多会话而与打印机2进行通信时，由于在通过某个会话对通信进行中继的期间禁止基于其他会话的通信，因此能够抑制如针对某会话的响应被发送到其他会话等那样的响应混乱。
由此，根据IPP/USB转换程序22，Web浏览器23能够经由USB而通过多会话无混乱地与打印机2进行通信。
而且，根据IPP/USB转换程序22，由于当一对请求和响应的中继完成时解禁基于其他会话的通信，因此能够缩短其他会话的待机时间。
而且，根据IPP/USB转换程序22，由于对在Web浏览器23与IPP功能31之间收发的通信数据进行中继，因此Web浏览器23能够经由USB而通过多会话无混乱地与IPP功能31进行通信。
而且，根据IPP/USB转换程序22，由于对用于从Web浏览器23设定打印机2的通信进行中继，因此在从Web浏览器23设定打印机2时能够通过多会话无混乱地进行通信。
而且，根据IPP/USB转换程序22，由于对从Web浏览器23接收到的通信数据进行分析，判断为已完成接收，因此能够判断为已完成请求的接收。关于从IPP功能31接收到的响应也同样。
<实施方式2>
接着，通过图8对实施方式2进行说明。
实施方式2是实施方式1的线程单位的中继处理的变形例。在实施方式1的线程单位的中继处理中，通过对通信数据进行分析，判断是否已完成请求的接收以及是否已完成响应的接收。相对于此，在实施方式2的中继处理中，不用对通信数据进行分析而判断是否已完成请求的接收以及已完成响应的接收。
参照图8，对实施方式2的线程单位的中继处理进行说明。
在S501中，第1线程从Web浏览器23接收通信数据。
具体地讲，第1线程询问在S301中制作的套接字中是否存在通信数据。第1线程在存在从Web浏览器23接收到的通信数据时，接收该通信数据而前进到S502。另一方面，在没有从Web浏览器23接收到的通信数据时，第1线程在经过第1预定时间之后超时而前进到S502。
在S502中，第1线程判断在S501中是否超时，在没有超时时前进到S503，在超时时判断为请求的接收结束而前进到S504。
在S503中，第1线程将在S501中从Web浏览器23接收到的通信数据通过USB而转送到IPP功能31。IPP功能31的设定画面CGI对该通信数据进行处理，返回对于对应的命令的响应。
在S504中，第1线程从IPP功能31通过USB而接收通信数据。该通信数据是作为对于通过S501～S503而发送到IPP功能31的请求的响应而接收的。
此处，在第1线程向IPP功能31发送了最后的通信数据时开始的第2预定时间以内，在第1线程没有从IPP功能31接收通信数据时，来自IPP功能31的通信数据的接收超时。
在S505中，第1线程判断来自S504中的IPP功能31的通信数据的接收是否超时。以下对进行该判断的理由进行说明。
如上所述，当第1线程在S502中判断为超时时，判断为已完成来自Web浏览器23的请求的接收。但是，实际上还存在请求的接收没有完成，由于CPU10的负荷高等某种理由而仅通信数据的发送被延迟的情况。
由于在第1线程没有完成来自Web浏览器23的请求的接收时，从第1线程向IPP功能31的请求的发送也没有完成，因此IPP功能31成为等待请求的接收完成的状态。因此，IPP功能31不向第1线程发送响应。
因此，与来自Web浏览器23的请求的接收没有完成无关，当在S502中判断为超时时，在S504中来自IPP功能31的通信数据的接收超时。
因此，通过判断来自IPP功能31的通信数据的接收是否超时，能 够以高精度判断S502中的超时是由来自Web浏览器23的请求的接收完成引起的正常的超时、还是来自Web浏览器23的请求的接收没有完成的异常的超时。
第1线程在来自IPP功能31的通信数据的接收没有超时时前进到S506。另一方面，在来自IPP功能31的通信数据的接收超时时，第1线程判断为S502中的超时为异常的超时，为了从Web浏览器23接收剩余的通信数据而返回到S501。
在S506中，第1线程将从打印机2接收到的通信数据发送到Web浏览器23。
在S507中，第1线程向IPP功能31询问是否已完成响应的发送。该询问是通过使用了端点0的控制转移而进行。
在S508中，第1线程判断对于S507中的询问的来自打印机2的询问结果。第1线程在询问结果（数据结束）是已完成时判断为已完成通信的中继，结束该处理而返回到基于线程的处理。另一方面，在询问结果是没有完成时，第1线程判断为没有完成通信的中继而前进到S509。
在S509中，第1线程从IPP功能31通过USB而接收通信数据。之后再次返回到S506，该通信数据被发送到WEB浏览器23。之后到数据结束为止，即到将来自IPP功能31的响应全部转送到Web浏览器23为止继续进行该循环。
根据以上说明的实施方式2的IPP/USB转换程序22，由于在没有从Web浏览器23接收第1预定时间以上的通信数据时临时判断为已完成来自Web浏览器23的请求的接收，因此不用对通信数据的内容进行分析而能够判断是否已完成请求的接收。
另外，根据IPP/USB转换程序22，在没有在第2预定时间以内从IPP功能31接收通信数据时，由于已完成请求的接收这样的临时判断有误而从Web浏览器23接收剩余的通信数据，因此能够更可靠地从Web浏览器23接收请求。
而且，根据IPP/USB转换程序22，由于向IPP功能31询问是否已完成响应的发送，在接收到询问结果是已完成时判断为已完成通信的中继，因此不用对通信数据的内容进行分析而能够判断是否已完成通信的中继。
<实施方式3>
接着，通过图9对实施方式3进行说明。
上述实施方式1的IPP/USB转换程序22当在一个会话中已完成一对请求和响应的收发时切断会话。相对于此，实施方式3的IPP/USB转换程序22在一个会话中收发多个成对的请求和响应。
图9是示出实施方式3的第1线程的处理的流程的流程图。
由于到S301～S304为止与实施方式1相同，因此省略说明。
在S601中，第1线程判断是否从在S304中结束了排他处理时开始在第3预定时间以内接收到保持-活动（Keep-Alive）信号，在接收到保持-活动信号时返回到S302，在没有接收时前进到S305而关闭会话。
此处，保持-活动信号是为了维持会话而发送的信号。保持-活动信号是由Web浏览器23发送。保持-活动信号是维持信号的一例。
根据以上说明的实施方式3的IPP/USB转换程序22，通过在每次完成一对请求和响应的收发时不切断会话，从而能够高效地进行通信。
<实施方式4>
接着，通过图10至图12对实施方式4进行说明。
实施方式4是实施方式1的变形例。上述实施方式1的IPP/USB转换程序22使用一个接口（具体地讲为接口1）进行用于设定打印机2的通信。
相对于此，实施方式4的IPP/USB转换程序22中，在打印机2与PC1之间构成接口1、接口2以及接口3。接口3也是能够进行双向通信的接口。
并且，IPP/USB转换程序22使用接口1和接口2而进行用于设定上述打印机2的通信。用于向打印机2发送打印数据的通信是使用接口3。
（1）基于IPP/USB转换程序的通信中继处理的详细
首先，参照图10，对实施方式4的通信中继处理进行说明。另外，在图10中将接口记载为IF。
在S701中，IPP/USB转换程序22对每个接口1和接口2制作互斥。
由于S202～S205的处理实际上与实施方式1相同，因此省略说明。
接着，参照图11，对实施方式4的第1线程的处理的流程进行说明。此处，对于与实施方式1实质上相同的处理标注相同标号并省略说明。
在S801中，第1线程选择接口1和接口2中未使用的接口、或者等待少的接口。S801是选择处理的一例。
此处，在任何接口都未使用时，第1线程选择接口1。另外，在任意一个接口都使用时，第1线程选择等待接口被释放的线程的数量最少的接口。另外，在对于任意一个接口等待释放的线程的数量相同时，第1线程选择接口1。
在制作了第1线程的时刻，由于未使用任何接口，因此第1线程选择接口1。
在S802中，第1线程执行在S801中选择的接口1的排他处理。该排他处理是通过获取接口1的互斥而进行。
当执行接口1的排他处理时，接口1成为正在使用的状态。当在该状态下通过第2线程而执行S801时，由于通过第1线程而使用接口1，因此第2线程选择没有使用的接口即接口2。
由于当在该状态下通过第3线程而执行S801时，接口1和接口2都使用，因此第3线程选择接口1。此时，第3线程到接口1被开放为止成为待机状态。
在S803中，第1线程执行使用了接口1的中继处理。
在S804中，第1线程执行接口1的排他结束处理。当执行接口1的排他结束处理时释放接口1的互斥，通过第3线程而获取该互斥。
（2）基于IPP功能的通信处理
接着，参照图12，对实施方式4的基于IPP功能31的通信处理进 行说明。
在S901中，IPP功能31判断在接口1中是否存在通信数据，在存在时前进到S902，在不存在时前进到S904。
在S902中，IPP功能31通过接口1而接收请求。
在S903中，IPP功能31将对于在S902中接收到的请求的响应，通过接口1而发送到IPP/USB转换程序22。
在S904中，IPP功能31判断在接口2中是否存在通信数据，在存在时前进到S905，在不存在时返回到S901。
在S905中，IPP功能31通过接口2而接收请求。
在S906中，IPP功能31将对于在S905中接收到的请求的响应，通过接口2而发送到IPP/USB转换程序22。在已完成响应的发送之后，IPP功能31返回到S901。
（3）实施方式的效果
根据以上说明的实施方式4的IPP/USB转换程序22，Web浏览器23能够经由没有多会话概念的多个接口而通过多会话无混乱地与打印机2进行通信。
<实施方式5>
接着，通过13对实施方式5进行说明。
如图13所示，实施方式5的打印机2不具有IPP功能31。作为其替代，实施方式5的打印机2具有Web服务器功能33。
由于此时Web浏览器23也进行基于多会话的通信，因此响应有可能会混乱。因此，在实施方式5中，通过IPP/USB转换程序22与Web服务器功能33进行通信。但是，由于打印机2不具有IPP功能31，因此IPP/USB转换程序22经由USB而通过HTTP与Web服务器功能33进行通信。
IPP/USB转换程序22将请求存储到USB的分组中而发送到Web服务器功能33，Web服务器功能33将对于该请求的响应存储在USB的分组中而发送到IPP/USB转换程序22。此处，如图13所示，在实施方式5中用于设定打印机2的通信是使用端点0而进行。
另外，由于在实施方式5中打印机2不具有IPP功能31，因此后台处理程序24不通过IPP/USB转换程序22而向打印机2发送打印数据。后台处理程序24与打印机2之间的通信是使用接口1而进行。
根据以上说明的IPP/USB转换程序22，即使在打印机2不具有IPP功能31的情况下，Web浏览器23也能够经由USB而通过多会话无混乱地与打印机2进行通信。
<其他实施方式>
不限定于通过上述记载和附图说明的实施方式，例如如下所述的实施方式也包含在技术范围内。
（1）在上述实施方式中，作为通过多会话进行通信的客户端应用程序以Web浏览器23为例进行了说明。但是，关于客户端应用程序，只要通过多会话而通信，则也可以是其他的应用程序。
（2）在上述实施方式中，作为通信线路以USB为例进行了说明。但是，通信线路不限于USB。例如PC1与打印机2也可以通过作为打印机的通信标准的IEEE1284而进行通信。
（3）在上述实施方式中，以每次请求会话的确立时制作新的线程的情况为例进行了说明。相对于此，也可以不制作线程，在通信中继处理中按照时序执行对于各会话的处理。或者，也可以代替线程而制作进程，通过进程进行由线程所进行的处理。
（4）在实施方式4中，以通过逻辑的多个通信线路连接PC1与打印机2的情况为例进行了说明。相对于此，PC1与打印机2也可以通过物理性的多个通信线路而连接。
（5）在上述实施方式中以在通过多会话进行用于设定打印机2的通信时进行会话的排他控制的情况为例进行了说明。除此以外，也可以在通过多会话进行用于向打印机2发送打印数据的通信时进行会话的排他控制。
（6）在上述实施方式中，作为图像处理装置以打印机2为例进行了说明。相对于此，图像处理装置也可以是具有打印功能、扫描功能、复制功能、传真功能等的所谓复合机。
（7）在上述实施方式中，在开始排他处理之后进行来自Web浏览器23的接收。即，到通过排他处理允许执行为止不进行来自Web浏览器23的请求的接收。但是，排他的开始只要在将来自Web浏览器23的数据发送到打印机（IPP功能31或Web服务器功能33）之前即可，即使在接收了来自Web浏览器23的请求之后也没关系。