CN104220996A - 通信系统、客户端终端以及服务器装置 - Google Patents

Abstract

具备批量要求处理装置(33)，如果与由GUI处理装置(32)所发行的执行要求对应的应答存储在应答存储装置(31)中，则输出指示将该应答输出到GUI处理装置(32)的意思的输出指令，另一方面，如果与该执行要求对应的应答未存储在应答存储装置(31)中，则进行存在接着该执行要求而发行的可能性的要求的预测，对要求模式管理装置(34)指示生成包含该执行要求和预测要求的要求模式，生成包括由要求模式管理装置(34)所生成的要求模式的批量要求。

Description

通信系统、客户端终端以及服务器装置

技术领域

本发明涉及发行服务的执行要求的客户端终端、将与执行要求对应的服务的处理结果回送到客户端终端的服务器装置、和由客户端终端以及服务器装置构成的通信系统。

背景技术

在嵌入设备上使具有GUI(Graphical User Interface，图形用户界面)的应用(Application)进行动作的情况下，以往将规定应用的举动的服务逻辑和GUI安装到同一嵌入设备、并使该服务逻辑和GUI进行协作动作的方式是主流。

但是，在以PC(Personal Computer，个人计算机)为中心的环境中，利用以因特网为代表的网络技术，并将服务逻辑和GUI安装到网络上的不同节点的服务器/客户端方式成为主流。

具体而言，考虑如下情形：将服务逻辑安装到服务器装置(节点)，将GUI安装到客户端终端(节点)，客户端终端经由网络来访问服务器装置，从而实现协作动作，其结果，构成1个应用。

近年来，通过无线网络技术的普及，即使是嵌入设备，可始终连接到网络的环境逐渐完善。另外，嵌入设备的处理性能逐渐提高。

因此，在嵌入设备上实现服务器/客户端方式的应用成为现实。

但是，以往通过同一节点内的进程间通信，服务逻辑和GUI协作动作，但需要变更为网络间通信中的协作，所以其协作处理成为瓶颈。因此，需要削减与协作处理有关的网络通信的次数等对策。

在以下的专利文献1中，公开了如下通信系统：按照在客户端终端中显示的GUI的画面单位，客户端终端预测该画面上的利用者的操作，在实际进行该操作之前，预先执行在该操作中所需的协作处理，从而在操作发生时不发生通信处理。

但是，在该通信系统中，仅在刚刚显示了GUI的画面之后预测利用者的操作，画面必须伴随利用者的操作而转移，无法进行再次的预测。

因此，在使同一画面长时间显示那样的应用中，无法充分地削减与协作处理有关的网络通信的次数。

另外，在专利文献2中，公开了以下的通信系统。

在从客户端终端发行了某种处理的执行要求的情况下，服务器装置预测附随该执行要求而有被要求的可能性的处理，执行与实际上所发行的执行要求对应的处理，并且执行有附随地被要求(以下，称为“预测要求”)的可能性的处理。

服务器装置在将与实际上所发行的执行要求对应的处理结果回送到客户端终端之后，依次将与预测要求对应的处理结果回送到客户端终端。

在客户端终端中，如果猜中服务器装置中的预测，则能够利用与从服务器装置回送了的预测要求对应的处理结果，所以无需将新的执行要求发送到服务器装置，能够减轻与协作处理有关的瓶颈。

但是，在服务器装置将与预测要求对应的处理结果回送到客户端终端时，如果根据实际上所发行的执行要求预测的要求数增加，则通信处理负荷增大。

另外，在客户端终端中，不清楚服务器装置预测什么样的要求，所以在从服务器装置接收到与预测要求对应的处理结果之前，客户端终端有可能发行与该预测要求相同的要求。

如果客户端终端发行与预测要求相同的要求，则无法削减通信次数。另外，在服务器装置中，需要将与相同的要求对应的处理执行多次。

专利文献1：日本特开平7-160462号公报(段落编号[0017]到[0019])

专利文献2：日本特开2005-228228号公报(段落编号[0021]、[0037])

发明内容

以往的通信系统如以上那样构成，所以在专利文献1的情况下，如果画面伴随着利用者的操作而不转移，则无法进行再次的预测。因此，在使同一画面长时间显示那样的应用中，存在无法充分地削减与协作处理有关的网络通信的次数的课题。

另外，在专利文献2的情况下，存在如下课题：如果根据实际上所发行的执行要求而预测的要求数增加，则与预测要求对应的处理结果的通信负荷增大。另外，在客户端终端中，不清楚服务器装置预测什么样的要求，所以存在如下如下课题：在从服务器装置接收到与预测要求对应的处理结果之前客户端终端有可能发行与该预测要求相同的要求，如果客户端终端发行与预测要求相同的要求，则无法削减通信次数。

本发明是为了解决上述那样的课题而完成的，其目的在于得到一种能够充分削减与协作处理有关的网络通信的次数的通信系统。

在本发明的通信系统中，客户端终端包括：应答存储单元，存储从服务器装置回送了的应答；执行要求发行单元，发行服务的执行要求；要求模式生成单元，如果与由执行要求发行单元所发行的执行要求对应的应答存储在应答存储单元中，则输出指示将该应答输出到执行要求发行单元的意思的输出指令，另一方面，如果与该执行要求对应的应答未存储在应答存储单元中，则预测存在接着该执行要求而发行的可能性的要求，生成包含该预测要求和所述执行要求的要求模式；通信单元，将由要求模式生成单元所生成的要求模式发送到服务器装置，另一方面，接收与构成该要求模式的执行要求以及预测要求对应的从服务器装置所发送的应答；以及应答处理单元，如果从要求模式生成单元接收到输出指令，则将与在应答存储单元中存储着的执行要求对应的应答输出到执行要求发行单元，如果通过通信单元接收到与执行要求以及预测要求对应的应答，则将与该执行要求以及预测要求对应的应答储存到应答存储单元，并且将与该执行要求对应的应答输出到执行要求发行单元。

根据本发明，构成为设置有：要求模式生成单元，如果与由执行要求发行单元所发行的执行要求对应的应答存储在应答存储单元中，则输出指示将该应答输出到执行要求发行单元的意思的输出指令，另一方面，如果与该执行要求对应的应答未存储在应答存储单元中，则预测存在接着该执行要求而发行的可能性的要求，生成包含该预测要求和所述执行要求的要求模式；以及通信单元，将由要求模式生成单元所生成的要求模式发送到服务器装置，另一方面，接收与构成该要求模式的执行要求以及预测要求对应的从服务器装置所发送的应答，其中，应答处理单元如果从要求模式生成单元接收到输出指令，则将与在应答存储单元中存储着的执行要求对应的应答输出到执行要求发行单元，如果通过通信单元接收到与执行要求以及预测要求对应的应答，则将与该执行要求以及预测要求对应的应答储存到应答存储单元，并且将与该执行要求对应的应答输出到执行要求发行单元，所以如果与执行要求对应的应答存储在应答存储单元中，则无需发送该执行要求，其结果，具有能够充分削减与协作处理有关的网络通信的次数的效果。

附图说明

图1是示出本发明的实施方式1的通信系统的结构图。

图2是示出在本发明的实施方式1的通信系统中应用的GUI节点1的GUI处理模块11的结构图。

图3是示出在本发明的实施方式1的通信系统中应用的服务节点2的服务提供模块22的结构图。

图4是示出GUI节点1中的GUI处理装置32的处理序列(无与API执行要求对应的应答的存储的情况)的序列图。

图5是示出GUI节点1中的GUI处理装置32的处理序列(有与API执行要求对应的应答的存储的情况)的序列图。

图6是示出批量要求处理装置33判定是API执行要求、还是API执行要求以外的要求的处理的流程图。

图7是示出服务节点2中的服务提供模块22的处理序列的序列图。

图8是示出要求模式的数据构造的说明图。

图9是示出实际要求信息列表的数据构造的说明图。

图10是示出后续要求模式列表的数据构造的说明图。

图11是示出使用了实际要求信息列表数据构造以及后续要求模式列表数据构造的具体的要求模式的一个例子的说明图。

图12是示出处理对象列表的参照例的说明图。

图13是示出要求模式取得时的要求时间序列解析结果的更新处理的流程图。

图14是示出实际要求通知时的要求时间序列解析结果的更新处理的流程图。

图15是示出处理对象列表的参照例的说明图。

图16是示出处理对象列表的参照例的说明图。

图17是示出预测要求模式的组合例的说明图。

图18是示出利用URL的API的识别信息的记述例的说明图。

图19是示出利用URL的API的识别信息的记述例的说明图。

图20是示出用1个文本形式数据来表现了针对单一的服务的多个API、和针对各API的多个自变量列表的具体例的说明图。

图21是示出批量要求表现形式例的说明图。

图22是示出应答的具体的数据表现例的说明图。

图23是示出批量应答的具体的数据表现例的说明图。

图24是示出在GUI中显示的地图图像的一个例子的说明图。

图25是示出与地图更新相伴的要求例的序列图。

图26是示出与比例尺变更相伴的要求例的序列图。

图27是示出在GUI中显示的地图图像的一个例子的说明图。

图28是示出与图27的画面相伴的要求例的序列图。

图29是示出按照画面单位进行独立的要求模式管理时的要求时间序列解析结果的数据构造例的说明图。

图30是示出使预测要求模式数为最大5个时的要求模式数据的生成例的说明图。

图31是示出计算从上次的要求通知到本次的要求通知为止的经过时间的处理的流程图。

图32是示出利用了经过时间时的要求模式数据的生成例的说明图。

图33是示出应答提供管理表格的一个例子的说明图。

图34是示出应答删除要求事件的记述例的说明图。

图35是示出应答更新要求事件的记述例的说明图。

(符号说明)

1：GUI节点(客户端终端)；2：服务节点(服务器装置)；3：网络；11：GUI处理模块；12：显示器；13：输入接口；14：输出接口；21a、21b、21c：服务模块(应答生成单元)；22：服务提供模块；31：应答存储装置(应答存储单元)；32：GUI处理装置(执行要求发行单元)；33：批量要求处理装置(要求模式生成单元)；34：要求模式管理装置(要求模式生成单元)；35：通信装置(通信单元)；36：应答处理装置(应答处理单元)；41：通信装置(要求模式接收单元、应答发送单元)；42：批量要求解释装置(应答取得单元)；43：要求处理装置(应答取得单元)；44a、44b、44c：服务执行装置(应答生成单元)；45：批量应答生成装置(应答取得单元)；46：应答存储装置(应答取得单元)。

具体实施方式

以下，为了更详细地说明本发明，依照附图，说明用于实施本发明的实施方式。

实施方式1.

图1是示出本发明的实施方式1的通信系统的结构图。

在图1中，作为客户端终端的GUI节点1是安装GUI、并进行系统的GUI控制的节点。

即，GUI节点1是经由网络3而与服务节点2协作来实现作为系统的服务的节点，具体而言，将服务的执行要求经由网络3发行到服务节点2，从服务节点2经由网络3取得作为与执行要求对应的服务的处理结果的应答。

作为服务器装置的服务节点2是进行作为系统实现的服务的逻辑处理的节点，具体而言，执行与由客户端终端1所发行的执行要求对应的服务，生成作为该服务的处理结果的应答，将该应答经由网络3回送到客户端终端1。

GUI节点1包括：GUI处理模块11，进行与GUI有关的全面控制；显示器12，显示GUI；输入接口13，接受例如反应在GUI处理中的各种信息的输入；以及输出接口14，连接了包括例如扬声器的声音输出设备等。

其中，显示器12、输入接口13以及输出接口14既可以不存在于GUI节点1内，也可以根据需要而分散配置在与网络3连接的其他节点上。在该情况下，GUI节点1经由网络3而与其他节点进行协作动作。

在该实施方式1中，设想了GUI节点1由计算机构成的例子，事先将表示后述的GUI处理模块11的处理内容的程序储存到计算机的存储器，计算机的CPU执行在该存储器中储存着的程序，从而构筑GUI处理模块11。

另外，关于GUI处理模块11的内部结构在后面叙述，也可以用专用的硬件(例如，安装了CPU的半导体集成电路、或者单片式微型计算机)构成GUI处理模块11的各个构成要素。

服务节点2包括：服务模块21a、21b、21c，执行与各种执行要求对应的服务，生成作为该服务的处理结果的应答；以及服务提供模块22，与GUI节点1实施网络间通信，进行将与从GUI节点1所发送的执行要求对应的应答回送到GUI节点1的处理等。

在图1中，示出了服务节点2安装了3个服务模块21a、21b、21c的例子，但服务模块的安装数不限于3个，既可以小于3个，也可以是4个以上。

在该实施方式1中，设想了服务节点2由计算机构成了的例子，所以事先将表示后述的服务提供模块22以及服务模块21a、21b、21c的处理内容的程序储存到计算机的存储器，计算机的CPU执行在该存储器中储存着的程序，从而构筑服务提供模块22以及服务模块21a、21b、21c。

另外，关于服务提供模块22的内部结构在后面叙述，也可以用专用的硬件(例如，安装了CPU的半导体集成电路、或者单片式微型计算机)构成服务提供模块22的各个构成要素。

服务模块21a、21b、21c具有一个以上的用于调出在服务规格中定义了的功能的API(Application Program Interface，应用程序接口)，关于在哪个定时(timing)执行哪个API，这存在(1)依照服务节点2的内部控制逻辑的情况、和(2)依照从GUI节点1发送的API执行要求来决定的情况这2种情况。

在(1)的情况下，执行各服务模块具有的API，但在(2)的情况下，由接收到从GUI节点1所发送的API执行要求的服务提供模块22执行。

本发明涉及(2)的情况，所以在说明书中，未言及(1)的情况。

图2是示出在本发明的实施方式1的通信系统中应用的GUI节点1的GUI处理模块11的结构图。

在图2中，应答存储装置31由例如RAM、硬盘等记录介质构成，实施储存从服务节点2经由网络3回送了的应答的处理。另外，应答存储装置31构成了应答存储单元。

GUI处理装置32例如由安装了CPU的半导体集成电路、或者单片式微型计算机等构成，实施如下处理：发行API执行要求(服务的执行要求)，取得与该API执行要求对应的应答，将该应答显示于显示器12。

此处，示出了将与API执行要求对应的应答显示于显示器12的例子，但也可以用声音来输出该应答。具体而言，将该应答变换为声音数据，将该声音数据输出到输出接口14，与该输出接口14连接了的各种设备解释声音数据，从扬声器等输出声音即可。

另外，GUI处理装置32构成了执行要求发行单元。

批量要求处理装置33例如由安装了CPU的半导体集成电路、或者单片式微型计算机等构成，实施如下处理：如果与由GUI处理装置32所发行的API执行要求对应的应答储存在应答存储装置31中，则将指示把该应答输出到GUI处理装置32的输出指令输出到应答处理装置36，另一方面，如果与该API执行要求对应的应答未存储在应答存储装置31中，则进行有接着该API执行要求而发行的可能性的要求(以下，称为“预测要求”)的预测，对要求模式管理装置34指示生成包含该API执行要求和预测要求的要求模式，将由要求模式管理装置34所生成的要求模式输出到通信装置35。

要求模式管理装置34例如由安装了CPU的半导体集成电路、或者单片式微型计算机等构成，具备对API执行要求的时间序列模式进行动态解析、并管理该要求时间序列解析结果的功能，实施如下处理：参照该要求时间序列解析结果，预测有可能接着从批量要求处理装置33输出了的API执行要求而发行的要求，生成包含该API执行要求和预测要求的要求模式。

另外，由批量要求处理装置33以及要求模式管理装置34构成了要求模式生成单元。

通信装置35是针对网络3的接口设备，实施如下处理：将由要求模式管理装置34生成、并从批量要求处理装置33输出了的要求模式经由网络3而发送到服务节点2，另一方面，接收从与构成该要求模式的API执行要求以及预测要求对应的服务节点2所发送的应答。另外，通信装置35构成了通信单元。

应答处理装置36例如由安装了CPU的半导体集成电路、或者单片式微型计算机等构成，实施如下处理：如果从批量要求处理装置33接收到输出指令，则将与在应答存储装置31中存储着的API执行要求对应的应答输出到GUI处理装置32。

另外，应答处理装置36实施如下处理：将与由通信装置35接收到的API执行要求以及预测要求对应的应答储存到应答存储装置31，并且将与该API执行要求对应的应答输出到GUI处理装置32。另外，应答处理装置36构成了应答处理单元。

此处，示出了作为GUI处理模块11的构成要素的应答存储装置31、GUI处理装置32、批量要求处理装置33、要求模式管理装置34、通信装置35以及应答处理装置36各自由专用的硬件构成的例子，但GUI处理装置32、批量要求处理装置33、要求模式管理装置34、通信装置35以及应答处理装置36各自也可以由软件构筑。

在该情况下，将记述了GUI处理装置32、批量要求处理装置33、要求模式管理装置34、通信装置35以及应答处理装置36的处理内容的程序储存到GUI节点1的存储器，GUI节点1的CPU执行在该存储器中储存着的程序即可。

图3是示出在本发明的实施方式1的通信系统中应用的服务节点2的服务提供模块22的结构图。

在图3中，通信装置41是针对网络3的接口设备，实施如下处理：接收从GUI节点1所发送的要求模式，另一方面，将与构成该要求模式的API执行要求以及预测要求对应的应答经由网络3汇总起来回送到GUI节点1。另外，通信装置41构成了要求模式接收单元以及应答发送单元。

批量要求解释装置42例如由安装了CPU的半导体集成电路、或者单片式微型计算机等构成，实施如下处理：分解构成由通信装置41接收到的要求模式的API执行要求以及预测要求，将各个要求输出到要求处理装置43，另一方面，将与从要求处理装置43输出了的各个要求对应的应答输出到批量应答生成装置45，将由批量应答生成装置45所生成的批量应答(汇总了与各个要求对应的应答的应答)输出到通信装置41。

要求处理装置43例如由安装了CPU的半导体集成电路、或者单片式微型计算机等构成，实施如下处理：针对从批量要求解释装置42输出了的各个要求的每一个要求，确定执行与该要求对应的服务的服务模块21，将该要求提供给与该服务模块21对应的服务执行装置44，另一方面，取得从该服务执行装置44输出了的应答，将该应答输出到批量要求解释装置42。

例如，如果执行与该要求对应的服务的服务模块21是服务模块21a，则将该要求提供给服务执行装置44a，从该服务执行装置44a将与该要求对应的应答输出到批量要求解释装置42。

服务执行装置44a例如由安装了CPU的半导体集成电路、或者单片式微型计算机等构成，实施如下处理：通过将从要求处理装置43输出了的要求提供给服务模块21a，执行与该要求对应的服务，从服务模块21a取得作为服务的处理结果的应答，将该应答输出到要求处理装置43。

服务执行装置44b例如由安装了CPU的半导体集成电路、或者单片式微型计算机等构成，实施如下处理：通过将从要求处理装置43输出了的要求提供给服务模块21b，执行与该要求对应的服务，从服务模块21b取得作为服务的处理结果的应答，将该应答输出到要求处理装置43。

服务执行装置44c例如由安装了CPU的半导体集成电路、或者单片式微型计算机等构成，实施如下处理：通过将从要求处理装置43输出了的要求提供给服务模块21c，执行与该要求对应的服务，从服务模块21c取得作为服务的处理结果的应答，将该应答输出到要求处理装置43。

另外，由服务模块21a、21b、21c以及服务执行装置44a、44b、44c构成了应答生成单元。

批量应答生成装置45例如由安装了CPU的半导体集成电路、或者单片式微型计算机等构成，实施如下处理：如果从要求处理装置43接收到与各个要求对应的应答，则将该应答临时地储存到应答存储装置46，汇总与构成了要求模式的所有要求对应的应答，生成批量应答。

应答存储装置46例如由RAM、硬盘等记录介质构成，临时地储存应答。

另外，由批量要求解释装置42、要求处理装置43、批量应答生成装置45以及应答存储装置46构成了应答取得单元。

此处，示出了作为服务提供模块22的构成要素的通信装置41、批量要求解释装置42、要求处理装置43、服务执行装置44a、44b、44c、批量应答生成装置45以及应答存储装置46各自由专用的硬件构成的例子，但通信装置41、批量要求解释装置42、要求处理装置43、服务执行装置44a、44b、44c以及批量应答生成装置45各自也可以由软件构筑。

在该情况下，将记述了通信装置41、批量要求解释装置42、要求处理装置43、服务执行装置44a、44b、44c以及批量应答生成装置45的处理内容的程序储存到服务节点2的存储器，服务节点2的CPU执行在该存储器中储存着的程序即可。

接下来，说明动作。

经由网络3转送从GUI节点1向服务节点2的API执行要求。

服务节点2如果经由网络3接收到API执行要求，则执行与由该API执行要求指定了的服务有关的指定的API，将该API的执行结果作为应答，经由网络3回送到GUI节点1。

如上所述，通过GUI节点1和服务节点2协作，作为系统整体，将服务节点2具有的各种服务提供给用户。

以下，举出具体例，说明通过GUI节点和服务节点协作而能够实现服务的例子。

此处，设想将当前位置的周边地图图像显示于显示器12的通信系统。

在该情况下，需要定期地取得当前位置的坐标信息的处理(当前位置捕捉处理)、根据当前位置的坐标信息按照指定了的比例尺来生成地图图像的处理(地图生成处理)、以及将通过地图生成处理所生成的地图图像显示于显示器12的处理(地图显示处理)。

此时，当前位置捕捉处理被掌握为是提供与当前位置有关的信息的服务。同样地，地图生成处理也被掌握为是根据位置信息来提供当前位置的周边地图的服务。即，当前位置捕捉处理以及地图生成处理成为服务节点2的处理。

另一方面，地图显示处理是对当前位置捕捉处理以及地图生成处理的处理结果进行加工而显示于显示器12的处理，所以成为GUI节点1的处理。

接下来，说明服务节点2应提供给GUI节点1的API。

作为系统整体，将当前位置的周边地图图像显示于显示器12即可，所以服务节点2应提供给GUI节点1的API仅成为当前位置周边的地图提供API。

因此，如果服务节点2从GUI节点1接收到当前位置周边的地图提供API，则将通过实施当前位置捕捉处理而得到的当前位置信息作为参数来实施地图生成处理，将作为该处理结果的地图信息作为当前位置周边的地图提供API的处理结果，能够回送到作为要求源的GUI节点1即可。

在GUI节点1中，GUI处理模块11实施如下处理：对服务节点2，以一定间隔发行当前位置周边的地图提供API的API执行要求，另一方面，将从服务节点2作为API执行要求的应答而得到的地图信息加工为可在显示器12中显示的数据，从而将地图图像显示于显示器12。

由此，能够将作为系统所要求的服务提供给系统利用者。

在说明GUI节点1与服务节点2之间的具体的处理序列之前，说明GUI节点1处理的GUI记述数据。

作为记述了在GUI节点1中实现的GUI的GUI记述数据的一个例子，可以举出HTML(Hyper Text Markup Language，超文本标记语言)。

HTML是能够记述文档的构造、显示的样式等的标准记述语言，是指通过该记述语言而记述了的数据。

另外，在HTML中，能够利用对用HTML记述了的文档的外观的设定进行记述的CSS(Cascade Style Sheet，层叠样式表)、对用HTML记述了的文档内的目标等的控制进行记述的JavaScript(注册商标。以下省略)。

如上所述，HTML原本是记述文档的构造的语言，但功能被扩充，近年来还被用作应用、GUI的开发语言的情况变多。

一般，GUI能够分为对GUI中的目标、数据进行规定的Model、对GUI的外观进行规定的View、对Model、View的控制进行规定的Control来表现数据。

在通过HTML、CSS、JavaScript进行GUI的记述的情况下，GUI处理模块11能够作为浏览器来掌握。

通过在GUI记述数据中采用HTML，从而能够通过HTML来记述在画面中显示的文本、按钮等GUI所需的目标的配置、外观。另外，与针对各目标的用户操作、定时器等事件对应的控制、使用了HTTP(Hyper Text Transfer Protocol，超文本传输协议)等的通信控制能够通过JavaScript来记述。

通过将GUI节点1掌握为客户端终端、将服务节点2掌握为服务器装置，从而作为针对服务节点2的HTTP请求，能够用JavaScript来记述发行API执行要求的处理。

另外，通过在GUI处理模块11中执行该JavaScript，能够从GUI节点1向服务节点2发送API执行要求，作为HTTP响应，GUI节点能够接收与该API执行要求对应的处理结果。

在这以后，按照GUI记述数据利用HTML、CSS以及JavaScript、GUI节点1与服务节点2之间的通信协议采用HTTP的方式进行说明，但本发明不限于该方式，只要能够在GUI节点1中记述用于实现GUI的信息，并且是能够记述与服务节点2的通信的GUI记述数据即可。

另外，关于GUI记述数据，虽然可以由GUI节点1保持，但也可以是由服务节点2保持，并由GUI节点1根据需要从服务节点2取得的方式。

在该情况下，关于GUI记述数据的取得要求，处理为与上述API执行要求不同的要求。以后，如果没有特别说明，则在记述为要求的情况下，是指API执行要求。

另外，也可以设为如下方式：在与网络3连接的其他节点(例如，保管GUI记述数据，并根据要求来提供该GUI记述数据的GUI数据服务器)中保管GUI记述数据，GUI节点1根据需要，从其他节点取得。

接下来，说明GUI节点1发行API执行要求，取得API执行要求的处理结果时的处理内容。

图4以及图5是示出GUI节点1中的GUI处理装置32的处理序列的序列图。

其中，图4示出应答存储装置31未存储与API执行要求对应的应答时的处理序列，图5示出存储了与API执行要求对应的应答时的处理序列。

首先，GUI处理装置32发行API执行要求(步骤ST1)。

关于该API执行要求，能够与包括与成为执行对象的API有关的信息的要求(在图4以及图5中，记载为“要求A”)一起，指定在应答处理装置36取得了与该要求对应的应答时应执行的回调函数。

由此，GUI处理装置32能够将GUI节点1接受了与API执行要求对应的应答的事件作为触发，开始处理。

另外，在可通信的服务节点2是唯一的情况下，也可以不用参数来提供表示API执行要求的发送目的地的服务节点信息，但在可通信的服务节点2有多个的情况、或是唯一的情况下，也可以明示地将服务节点信息作为参数来提供。在该情况下，也可以将服务节点信息表现为URL。

批量要求处理装置33如果从GUI处理装置32接收到要求，则判定该要求是API执行要求、还是API执行要求以外的要求(步骤ST2)。

此处，图6是示出批量要求处理装置33判定是API执行要求、还是API执行要求以外的要求的处理的流程图。

批量要求处理装置33直至从GUI处理装置32输出要求为止待机，如果从GUI处理装置32输出了要求(步骤ST51)，则取得该要求(步骤ST52)。

批量要求处理装置33如果取得了要求，则判别该要求的类别，判定该要求是API执行要求、还是API执行要求以外的要求(步骤ST53)。

如果该要求是API执行要求以外的要求，则批量要求处理装置33将不变更该要求的内容而向要求目的地发送的指示输出到通信装置35(步骤ST54)。

另一方面，如果该要求是API执行要求，则变更该要求的内容，将把作为变更后的内容的要求模式(包含API执行要求以及预测要求的要求模式)发送到要求目的地的指示输出到通信装置35(步骤ST55)。

此处，示出了从GUI处理装置32输出了的要求是API执行要求的例子。

批量要求处理装置33如果判定为从GUI处理装置32输出了的要求是API执行要求，则确认与该API执行要求对应的应答(在图4以及图5中，记载为“应答A”)是否存储在应答存储装置31中(步骤ST3)，取得其确认结果(有无应答A)(步骤ST4)。

此处，说明与API执行要求对应的应答A未存储于应答存储装置31的情况。关于与API执行要求对应的应答A存储于应答存储装置31中的情况，在后面叙述。

批量要求处理装置33在与API执行要求对应的应答A未存储于应答存储装置31的情况下，需要将API执行要求发送到服务节点2，从服务节点2取得与API执行要求对应的应答A，所以进行有可能接着该API执行要求而发行的要求(以下，称为“预测要求”)的预测，对要求模式管理装置34指示生成包含该API执行要求(实际要求)和预测要求的要求模式(步骤ST5)。

另外，要求模式是包含API执行要求(实际要求)和1个以上的预测要求的要求群。

要求模式管理装置34如果从批量要求处理装置33接收到要求模式的生成指示，则参照过去发行的API执行要求的时间序列模式的动态解析结果，在过去发行的API执行要求中，预测接着从批量要求处理装置33输出了的API执行要求(实际要求)而发行的可能性最高的API执行要求，将该预测了的API执行要求决定为预测要求。

另外，要求模式管理装置34在过去发行的API执行要求中，预测接着该预测要求而发行的可能性最高的API执行要求，将该预测了的API执行要求决定为预测要求。详细后述，将该预测要求的决定处理重复实施1次以上。

要求模式管理装置34如果决定了1个以上的预测要求，则生成包含API执行要求(实际要求)和1个以上的预测要求的要求模式(API执行要求(实际要求)+预测要求+预测要求+……)(步骤ST6)，将该要求模式输出到批量要求处理装置33(步骤ST7)。

批量要求处理装置33如果从要求模式管理装置34接收到要求模式，则生成包括该要求模式的批量要求(步骤ST8)。

另外，批量要求处理装置33将用于把批量要求发送到服务节点2的句柄信息、批量要求以及与作为API执行要求(实际要求)的要求A对应的回调函数登记到应答处理装置36(步骤ST9、ST10)。

另外，批量要求处理装置33将把批量要求发送到服务节点2的指示输出到通信装置35(步骤ST11)，如果从通信装置35接受了批量要求的发送指示的受领通知(步骤ST12)，则将要求发行处理完成了的意思通知给GUI处理装置32(步骤ST13)。

通信装置35如果从批量要求处理装置33接受了批量要求的发送指示，则将该批量要求经由网络3发送到服务节点2。

另外，通信装置35如果从服务节点2接收到与构成批量要求中包含的要求模式的各个要求(API执行要求(实际要求)+预测要求+预测要求+……)对应的批量应答(API执行要求(实际要求)的应答+预测要求的应答+预测要求的应答+……)，则将该批量应答和通信句柄输出到应答处理装置36(步骤ST14)。

关于服务节点2的具体的处理内容，在后面叙述。

应答处理装置36如果从通信装置35接收到批量应答和通信句柄，则将在该批量应答中包含的API执行要求(实际要求)的应答、和1个以上的预测要求的应答储存到应答存储装置31(步骤ST15、ST16)。

另外，应答处理装置36将通信句柄作为关键字，从先前登记了的回调函数中，取出与作为API执行要求(实际要求)的要求A对应的回调函数，执行该回调函数，从而将与该要求A对应的应答A通知给GUI处理装置32(步骤ST17、ST18)。

GUI处理装置32如果接受了与该要求A对应的应答A，则例如将该应答A显示于显示器12。

接下来，说明与API执行要求对应的应答A存储于应答存储装置31的情况。

步骤ST1～ST4的处理内容与未存储与API执行要求对应的应答A的情况相同，所以省略说明。

批量要求处理装置33在与API执行要求对应的应答A存储于应答存储装置31的情况下，无需将作为API执行要求的要求A发送到服务节点2，所以将要求发行处理完成了的意思通知给GUI处理装置32(图5的步骤ST21)。

另外，批量要求处理装置33将发行了作为API执行要求的要求A的意思通知给要求模式管理装置34(步骤ST22、ST23)。

要求模式管理装置34如果接收到发行了作为API执行要求的要求A的意思的通知，则更新过去发行的API执行要求的时间序列模式的动态解析结果。

另外，批量要求处理装置33将与作为API执行要求的要求A对应的应答A作为从服务节点2所发送的应答来处理，所以向应答处理装置36输出指示将与在应答存储装置31中存储着的要求A对应的应答A输出到GUI处理装置32的意思的输出指令(步骤ST24)。

在图5中，将针对应答处理装置36的该指示记载为“疑似应答通知”，在该疑似应答通知中，包括作为API执行要求的要求A、和与要求A对应的回调函数。

应答处理装置36如果从批量要求处理装置33接收到疑似应答通知，则将在该疑似应答通知中包含的要求A作为关键字，从应答存储装置31取得与要求A对应的应答A(步骤ST25、ST26)。

另外，应答处理装置36通过执行在该疑似应答通知中包含的回调函数，将与该要求A对应的应答A通知给GUI处理装置32(步骤ST27、ST28)，并且向批量要求处理装置33通知将该应答A通知给了GUI处理装置32的意思(步骤ST29)。

如以上那样，通过在GUI节点1中进行处理，不用将已经接受了应答的要求发行给服务节点2，而能够使处理继续。

另外，在上述说明中，以接受要求的线程和接受应答的线程在不同的非同步处理中进行要求/应答的一连串的处理为前提，但无需一定是非同步处理。进行要求处理的线程也可以是直至接受应答为止等待的同步处理。

接下来，具体地说明服务节点2中的服务提供模块22的处理内容。

图7是示出服务节点2中的服务提供模块22的处理序列的序列图。

在服务提供模块22的通信装置41中，由于与作为API执行要求的要求A对应的应答A未存储于应答存储装置31，所以如果从GUI节点1发送了批量要求，则接收该批量要求，将该批量要求输出到批量要求解释装置42(步骤ST31)。

批量要求解释装置42如果从通信装置41接收到批量要求，则分解构成包含在该批量要求中的要求模式的各个要求(API执行要求(实际要求)+预测要求+预测要求+……)，抽出成为各个要求的要求目的地的服务的服务标识符(步骤ST32)。

批量要求解释装置42将各个要求和服务标识符的组依次输出到要求处理装置43(步骤ST33)。

另外，要求和服务标识符的组的输出顺序是要求模式中的排列顺序，最初输出API执行要求(实际要求)和服务标识符的组之后，输出接着API执行要求(实际要求)排列了的预测要求和服务标识符的组。以下，依次输出所有的预测要求和服务标识符的组。

要求处理装置43每当从批量要求解释装置42接收到要求和服务标识符的组时，参照该服务标识符，确定执行与该要求对应的服务的服务模块21(步骤ST34)，将该要求输出到与该服务模块21对应的服务执行装置44(步骤ST35)。

例如，如果执行与该要求对应的服务的服务模块是服务模块21a，则将该要求输出到服务执行装置44a，如果执行服务的服务模块是服务模块21b，则将该要求输出到服务执行装置44b，如果执行服务的服务模块是服务模块21c，则将该要求输出到服务执行装置44b。

服务执行装置44a、44b、44c如果从要求处理装置43接收到要求，则通过将该要求提供给服务模块21a、21b、21c，执行与该要求对应的服务，从服务模块21a、21b、21c取得作为服务的处理结果的应答，将该应答输出到要求处理装置43(步骤ST36)。

要求处理装置43如果从服务执行装置44a、44b、44c接收了与要求对应的应答，则将该应答输出到批量要求解释装置42(步骤ST37)。

批量要求解释装置42如果从要求处理装置43接收了与要求对应的应答，则将该应答输出到批量应答生成装置45(步骤ST38)。

批量应答生成装置45如果从要求处理装置43接收到与要求对应的应答，则将该应答登记到应答存储装置46(步骤ST39)。

应答存储装置46按照维持了登记顺序的列表形式，将与要求对应的应答存储到存储区域(步骤ST40、ST41)。

将步骤ST33～ST41的处理重复实施与构成要求模式的各个要求的个数相当的次数。

在批量要求解释装置42中，如果步骤ST33～ST41的处理完成，则将批量应答的生成要求输出到批量应答生成装置45(步骤ST42)。

批量应答生成装置45如果从批量要求解释装置42接收到批量应答的生成要求，则取得与已在应答存储装置46中登记的各个要求对应的应答(步骤ST43、ST44)，汇总这些应答，生成批量应答(步骤ST45)。

另外，在汇总多个应答的处理中，通过参照维持了登记顺序的应答列表，按照要求模式中的各个要求的排列顺序，汇总与各个要求对应的应答。

因此，批量应答的开头的应答是与作为API执行要求的要求A对应的应答，批量应答的第2个应答是与接着该要求A而排列的预测要求对应的应答。

在批量应答生成装置45中，如果生成了批量应答，则将该批量应答输出到批量要求解释装置42(步骤ST46)。

批量要求解释装置42如果从批量应答生成装置45接收到批量应答，则将该批量应答输出到通信装置41(步骤ST47)。

通信装置41如果从批量要求解释装置42接收到批量应答，则将该批量应答经由网络3回送到GUI节点1。

通过以上，GUI节点1与服务节点2之间的具体的处理序列变得明确，但以下，更具体说明GUI节点1中的构成要素的处理内容等。

[要求模式管理装置34的说明]

图8是示出要求模式的数据构造的说明图。

首先，API执行要求的时间序列模式的动态解析结果记录有由GUI处理装置32所发行的API执行要求的时间序列模式、和发行该API执行要求的频度。

在图8中，要求时间序列解析结果要素数据构造由“实际要求信息”和“后续模式列表”构成，后续模式列表要素数据构造由“可靠度参数”和“后续模式”构成。

“实际要求信息”是储存与由GUI处理装置32发行的API执行要求(以下称为“实际要求”)有关的信息的区域，“后续模式列表”由具有1个以上的跟在实际要求信息中储存的实际要求之后的模式来作为要素的列表构成。

“后续模式列表”形成列表构造，也可以按照接着实际要求的概率从高到低的顺序，对预测要求进行分类来管理。

后续模式列表要素数据构造表示后续模式列表的要素的一个例子，“可靠度参数”储存表示该模式的可靠性的信息，“后续模式”是按照时间序列顺序排列了后续模式的要求列表。

作为“可靠度参数”，设想确认了实际上发行了的次数(发行次数)等。

此外，作为实际上所发行的最新的日期时间信息、预测要求，也可以一并存储该预测成功了的次数、失败了的次数等每当决定预测要求时可用作参数的信息。

关于“后续模式”，按照时间序列顺序，列举了后续的要求信息。

应在“后续模式”的要素中记述的要求的内容可以是与“实际要求信息”等同的数据构造。除此以外，也可以一并地储存在执行时提供的自变量的值列表、表示预测要求列表的各要素是什么程度的可靠度的信息。在其具体例中，考虑每个要求的预测的成功/失败的次数等。

接下来，说明其他表现形式下的要求时间序列解析结果的具体例。

图9是示出实际要求信息列表的数据构造的说明图，图9所示的数据构造是与图8的要求模式的数据构造对应的数据构造。

“实际要求信息”是储存表示实际上发行的要求的信息的区域，意味着成为要求模式的开头要求。

“后续模式管理数据参照”是参照对与在实际要求信息之后实际上所发行的要求有关的解析结果进行管理的数据的区域。在该参照中，参照后续用要求模式列表数据。通过该参照，能够参照接着实际要求而过去发行了的要求的信息。

“下一实际要求参照”是在有其他实际要求信息列表数据的情况下可参照的区域。在该区域是NULL(空)的情况下，意味着其以上的实际要求信息列表数据不存在。

图10是示出后续要求模式列表的数据构造的说明图，图10所示的数据构造是与图8的后续模式列表要素数据构造对应的数据构造。

“后续要求信息”是储存预测为接下来发行的要求信息的区域。

“可靠度信息”是储存成为表示该预测要求可靠到什么程度的尺度的信息的区域。

“下一后续要求列表参照”是参照对与接在该后续要求之后实际上所发行的要求有关的解析结果进行管理的数据的区域。在该参照中，参照后续用要求模式列表数据。在该区域是NULL的情况下，意味着其以上不存在接下来所发行的要求。

“同列要求参照”是通过与该后续要求不同的要求来参照与按照同一时间序列顺序所发行的要求有关的后续要求模式列表数据的区域。在该区域是NULL的情况下，意味着其以上不存在在同列中所发行的要求。

图11是示出使用了实际要求信息列表数据构造以及后续要求模式列表数据构造的具体的要求模式的一个例子的说明图。

“实际要求信息列表”是将实际要求信息列表数据作为要素来构成列表数据，并列举了成为要求模式的开头的要求的列表数据。

在图11的例子中，示出了要求A和要求B是在过去实际上所发行的要求中曾经在开头发行了的要求。

根据“实际要求信息列表”的各要素的后续要求模式管理数据参照而参照的是将后续要求模式列表数据作为要素来构成树状数据、并对接在该实际要求之后的要求进行管理的树状数据。

从实际要求信息列表的要素直接参照着的后续要求模式列表的要素、和通过递归地追溯该要素的同列后续要求参照从而可到达的要素在“后续要求信息”中具有与紧接在实际要求之后所发行的要求有关的信息。

例如，在图11中，意味着从实际要求A直接参照着的要素的要求C、和通过递归地追溯要求C的要素的同列后续要求参照从而可到达的要求即要求B这二种是跟在要求A之后的要求。

同样地，后续要求模式列表的某个要素的接下来的后续要求列表参照中参照的要素的要求、和通过递归地追溯该要素的同列后续要求参照从而可参照的要素的要求全部在“后续要求信息”中具有与曾经在该要求模式内跟在某个要求之后的要求有关的信息。

例如，在图11中，意味着在将紧接在实际要求A之后发行的要求C考虑为基准的要求的情况下曾经跟在该要求C之后的要求是要求D和要求E。

通过重复以上，意味着在实际上发行了要求A的情况下，接着的要求模式是下述5个。

A

A→C

A→C→D

A→C→E

A→B

不同点在于，在图8所示的数据构造中，针对1个要求模式，设定了1个可靠度信息，但在图9以及图10所示的数据构造中，按照各后续要求单位设定了可靠度信息。

即，不同点在于，在图8所示的数据构造中，在可靠度信息中设定了与要求模式的发行有关的可靠度，相对于此，在图9以及图10所示的数据构造中，针对某个要求，将预测为接下来发行的每个要求的可靠度设定为可靠度信息。

以下，说明在通过图9以及图10所示的数据构造来管理要求模式的情况下要求模式管理装置34动态地更新该要求模式的具体例。

要求模式管理装置34获知在GUI节点1中实际上发行的要求的定时(timing)是从批量要求处理装置33输出的要求模式的生成指示时(图4的步骤ST5)、或者通过实际要求通知(图5的步骤ST22)接收实际要求作为参数时。

此时，在要求模式全体中，设表示被通知了的要求应从哪个位置检索的处理对象要求参照被输入到要求模式管理装置34，而进行以下的说明。

图12是示出处理对象列表的参照例的说明图。

图12与图11的要求模式等同，作为处理对象列表参照的具体例，示出了a、b、c、d这4种。而且，图13示出要求模式的生成指示时(图4的步骤ST5)的要求时间序列解析结果的更新流程，图14示出实际要求通知时(图5的步骤ST22)的要求时间序列解析结果的更新流程。

首先，说明要求模式的生成指示时的要求时间序列解析结果的更新处理。

要求模式管理装置34如果接收到要求模式的生成指示(图13的步骤ST101)，则例如从图12所示的实际要求信息列表，将作为要求模式生成要求的参数的实际要求作为关键字，从实际要求信息列表检索与实际要求对应的要素(步骤ST102)。

要求模式管理装置34如果发现了与实际要求对应的要素(步骤ST103)，则通过将与实际要求对应的要素的后续要求模式管理数据参照的值代入到处理对象列表参照，在接下来有实际要求通知的情况下，能够判别从哪个列表更新要求模式为宜，完成更新处理(步骤ST104)。

要求模式管理装置34在未发现与实际要求对应的要素的情况下(步骤ST103)，进行如下更新：将实际要求保持到实际要求信息中，生成在后续要求模式管理数据参照中设定了NULL要素的要素，并追加到列表(步骤ST105)。

之后，将在步骤ST105中所生成的NULL要素的列表代入到处理对象列表参照，完成更新处理(步骤ST106)。

例如，在处理对象列表参照处于图12的处理对象列表参照a的位置的情况下，当将实际要求B作为参数而接受时，由于在实际要求信息列表中有要求B的要素，所以通过步骤ST104的处理，处理对象列表参照被更新为处理对象列表参照b的位置。

或者，在将实际要求C接受到参数中的情况下，在实际要求信息列表中没有要求C的要素，所以通过步骤ST105、ST106的处理，如图15所示，与要求C有关的要素被追加到实际要求信息列表，该后续要求模式管理数据参照被设定为具有仅拥有NULL要素的预测要求模式列表e。另外，在处理对象列表参照中，如处理对象列表参照e那样，参照预测要求模式列表(1)。

接下来，说明实际要求通知时的要求时间序列解析结果的更新处理。

要求模式管理装置34如果接收到实际要求通知(图14的步骤ST111)，则在处理对象列表参照中，从参照列表检索与实际要求对应的要素(步骤ST112)。

要求模式管理装置34如果发现了与实际要求对应的要素(步骤ST113)，则更新与实际要求对应的要素的可靠度信息(步骤ST114)。

例如，在将可靠度信息设为实际上发行了实际要求的次数的情况下，使该值递增。

之后，要求模式管理装置34将与实际要求对应的要素的后续要求列表参照的值代入到处理对象列表参照，结束更新处理(步骤ST115)。

要求模式管理装置34在未发现与实际要求对应的要素的情况下(步骤ST113)，对在处理对象列表参照中参照的列表追加要素，在该后续要求信息中设为参数的实际要求，结束更新处理(步骤ST116)。

例如，在处理对象列表参照是图12的处理对象列表参照c的情况下，如果在实际要求通知中作为参数接收到实际要求C，则通过步骤ST114的处理，更新要求C的可靠度信息，通过步骤ST115的处理，处理对象列表参照被更新为处理对象列表参照d。

同样地，在作为参数接收到实际要求D的情况下，如图16所示，要求模式被更新。

具体而言，通过步骤ST116的处理，新生成与要求D有关的要素，在与处理对象列表参照c参照的列表的要求B有关的要素的同列后续要求参照中，参照与要求D有关的要素。另外，对与要求D有关的要素的可靠度信息进行初始化，在接下来的后续要求列表参照中参照具有NULL要素的列表。其中，通过步骤ST116的处理，如处理对象列表参照f那样，更新处理对象列表参照。

接下来，说明要求模式管理装置34的具体的处理。

要求模式管理装置34在要求模式的生成指示时(图4的步骤ST5)、或者实际要求通知时(图5的步骤ST22)进行处理。

[要求模式的生成指示时的处理内容]

在要求模式的生成指示时(图4的步骤ST5)，在与实际要求对应的应答未储存于应答存储装置31的状况下，从批量要求处理装置33对要求模式管理装置34进行要求。

要求模式管理装置34进行如下处理：将从批量要求处理装置33作为参数接受的实际要求作为关键字，根据要求时间序列解析结果，导出判定为最可能发行的要求模式(预测要求模式)，返回其导出结果。

具体而言，比较要求时间序列解析结果的全部要求时间序列解析结果要素数据的实际要求信息、和作为参数的实际要求，导出一致的要求时间序列解析结果要素数据。

在一致判定中，虽然设为要求内容完全一致也可以，但还可以是基于部分一致的判定等。具体而言，所要求的处理虽然一致，但作为参数提供的内容一部分不同的情况等被认为是部分一致。

接下来，从该要求时间序列解析结果要素数据的后续模式列表，使用可靠度参数，找出发行的概率最高的后续模式，将实际要求作为开头要素，将之后找出的后续模式的要求按照时间序列顺序连结，将由此得到的模式设为预测要求模式。

概率也可以根据在可靠度参数中储存的信息(例如，发行次数)的大小来决定。除此以外，也可以通过将在多个可靠度参数中储存的信息应用于计算概率的函数，来计算概率。

例如，也可以使用针对发行次数乘以当前日期时间与实际上所发行的最新的日期时间信息的差分时间的倒数等的函数，来计算概率。另外，也可以根据决定为系统的判定基准，计算概率。其结果，将概率最高的要求模式作为预测要求模式。

另外，作为其他方法的要求模式的决定方法，也可以将2种以上的要求模式选定为候补，组合多个预测要求模式作为新的1个预测要求模式。

图17是示出预测要求模式的组合例的说明图。

在图17的例子中，预测要求模式1是判定为发行的概率最高的预测要求模式，预测要求模式2是判定为发行的概率其次高的预测要求模式。

在该情况下，例如考虑求出2种预测要求模式1、2的逻辑和，将由该逻辑和构成了的预测要求模式3作为处理结果来返回。

通过采用该方法，能够将多个预测要求模式表现为1个预测要求模式，所以能够使发行的概率提高。

在该例子中，通过对发行概率为上位的2个预测要求模式进行逻辑和，生成了新的预测要求模式，但不限于此，也可以通过将多个预测要求模式应用于某个预定的合成函数，制作新的预测要求模式。

另外，作为其他预测要求模式的决定方法，也可以将在处理过程中导出了的预测要求模式的一部分作为预测要求模式。

例如，考虑如下方法：如果假设关于预测要求模式的各要求，在系统中对从开头到自身为止的要求模式进行了处理的结果，在其自身中保持了预测失败了的次数，则在该值成为某个阈值以上的情况下，将其以后的要求从要求模式排除，将此前的要求模式作为预测要求模式。

还考虑如下方法：在不考虑时间序列顺序，而只是将该要求模式作为处理结果时，假设在各要求中保持了预测成功了的次数、预测失败了的次数，用从要求模式起某阈值以上的所有要求来构成新的要求模式，将新的要求模式作为预测要求模式。

如上所述，将在系统中决定了的基准以上的预测要求模式根据要求时间序列解析结果而选定1个以上，并将它们组合从而决定1个预测为在实际要求之后发行的预测要求模式的处理，是与要求模式的生成指示时(图4的步骤ST5)对应的处理。

另外，在该处理之后，关于预测要求模式、在决定该预测要求模式时利用了的要求模式列表中包含的要求模式，直至该预测结果确定为止由要求模式管理装置34进行维持。以下，将这些要求模式称为预测对象要求模式。

[实际要求通知时的处理内容]

在实际要求通知时(图5的步骤ST22)，在与实际要求对应的应答储存于应答存储装置31的状况下，从批量要求处理装置33对要求模式管理装置34进行要求。

要求模式管理装置34如果从批量要求处理装置33作为参数接受了实际要求通知，则识别为构成在接收该通知之前所生成的要求模式的预测要求的预测(识别为按照预测所发行)。

因此，要求模式管理装置34更新与和该预测要求一致的要求A一起储存着的信息。

例如，考虑如下等更新：如果储存着的信息是成功次数，则进行该成功次数的递增，如果储存着的信息是临时的预测是否成功标志，则创建标志。

另外，也可以再计算后续模式列表中的各模式的可靠度参数，更新该值。通过更新可靠度参数，能够实施与该系统的利用状况对应的预测模式列表的构筑，能够提高预测准确性。

另外，在上述要求模式中没有与参数对应的要求的情况下，也可以将该要求连结到上述要求模式，构筑新的预测模式数据，新登记为预测模式列表的要素。通过进行新登记而能够预测新的要求模式，能够提高预测准确性。也可以是如下方法：不进行新登记，而追加该要求作为当前的要求模式的新的列表要素。

接下来，说明批量要求处理装置33的具体的处理。

[批量要求的生成处理]

作为通过HTTP进行从GUI节点1向服务节点2的要求的方法，考虑如下方法：通过URL(Uniform Resource Locator，统一资源定位符)记述要求目的地节点和要求资源。考虑多个利用URI的记述方式，例如可以举出图18所示那样的记述方法。

在图18的例子中，将作为服务节点2的域名的[服务节点域]记述为URL的主机名，在第1目录名中记述了作为要求的服务的名字的[服务名]，在第2目录名中记述了作为API(服务内的要求的API)的名字的[API名]。

通过这样使用URL，GUI节点1能够根据URL的主机名唯一地识别通信对方，服务节点2能够通过URL的[服务名]和[API名]，唯一地识别要求了哪个服务的哪个API。

但是，在图18的记述方式中，能够用1个URL发行的API执行要求被限定为单一的服务所具有的单一的API名，所以不适合于如本发明那样将多个API执行要求批量地发行的方式。

因此，考虑如下方法：如图19所示，从URL去除[服务名]和[API名]，将表示是批量要求的[批量要求识别名]记述到URL中。

在该情况下，通过将与服务名及API名相当的信息记述到HTTP通信时的主体部，能够将这些信息通知给要求目的地节点。

此处，服务节点2具有的API一般能够处理为函数，其大部分能够接受自变量。

即，作为在HTTP通信时应记述到主体部的信息，还包括针对API的自变量的值。另外，通常能够在API中设定多个自变量，所以将多个自变量汇总起来称为自变量列表。

图20是示出将针对单一的服务的多个API、和针对各API的多个自变量列表利用1个文本形式数据来表现的具体例的说明图。

关于该数据，以JSON(Java Script Object Notation，Java脚本对象符号)形式，作为多重排列目标而记述了上述信息。

在最上位的排列(服务要求排列目标)中，在第1个要素中记述了成为要求对象的服务的服务名。在第2个以后的要素中，将针对该服务要求的具体的API、和其自变量表现为排列目标(API排列目标)。

关于API排列目标，能够指定多个，在指定了多个的情况下，意味着要求针对该服务执行多个API。

关于API排列目标，在第1个要素中，表现所要求的API的名字，在第2个以后的要素中，列举了表现了执行该API时的自变量列表的排列目标(自变量排列目标)。

为了生成自变量排列目标，能够利用在要求模式的生成指示时(图4的步骤ST5)所取得的要求模式的各要求中附带的自变量列表来制作。

另外，API排列目标也能够同样地通过抽出在要求模式中包含的针对同一服务的API来制作。

在有多个自变量排列目标的情况下，意味着将API执行与自变量排列目标的个数相当的次数，在各执行中，意味着将各个自变量排列目标的内容作为自变量来提供并执行。

如图21所示，通过构成具有1个以上的服务要求排列目标的排列(批量要求排列目标)，能够构筑可对针对多个服务的要求进行批量表现的数据构造。

此处，在发行批量要求时，需要区分实际要求和预测要求。

作为区分的方法，考虑如下方法：关于实际要求，设置利用作为批量要求的第1要素的服务要求排列目标的第2要素(开头API排列目标)表现这样的规定。

除此以外，也可以在API排列目标的第1要素中，在实际要求的情况下追加具有“true”(“真”)的排列要素，在其以外的情况下，追加具有“false”(“假”)的排列要素，从而进行表现。

另外，在应保存要求的顺序的情况下，通过将实际要求作为开头，之后按照在预测要求模式中登记的预测要求的顺序来构成要素，也能够保存顺序。在该情况下，针对各服务的服务要求排列目标不必限定为1个。

能够在主体部中具有以上的批量要求排列目标，指定图19所示的URL，将进行POST命令的HTTP要求考虑为批量要求的一个具体例。

批量要求是通过由批量要求处理装置33根据图4的步骤ST11的处理向通信装置35发行来开始的，将其处理结果作为可否要求的标志，在步骤ST12中返回到批量要求处理装置33。

另外，在步骤ST13中向GUI处理装置32返回该可否要求标志。

[句柄信息、批量要求以及回调函数的登记处理]

批量要求处理装置33如果生成了批量要求，则将与该批量要求关联的信息登记到应答处理装置36。

作为关联的信息，考虑与从通信装置35接受的批量要求对应的句柄信息、在接收到与批量要求对应的处理时用于处理实际要求的回调函数等。

接受了与批量要求关联的信息的应答处理装置36将该信息保存到由自身管理的存储区域，将其处理结果回送到批量要求处理装置33。

[批量应答和通信句柄的通知处理]

通信装置35在将批量要求经由网络3发送到服务节点2之后，接收与从服务节点2发送的批量要求对应的批量应答。

通信装置35如果接收到与批量要求对应的批量应答，则将该批量应答通知给应答处理装置36，并且将表示发行了与该应答对应的要求的通信处理的句柄信息通知给应答处理装置36。

此处，说明从服务节点2回送的批量应答的具体例。

图22是示出应答的具体的数据表现例的说明图。

在图22的例子中，与要求的情况同样地，用JSON形式来表现数据。

在一般的函数中，存在函数的返回值、和利用参照自变量的应答这2种。关于返回值，通常仅成为1个目标，但关于参照自变量，能够设定多个。

因此，应答能够表现为在第1要素中储存函数的返回值、在第2要素以后储存参照自变量的JSON的排列目标。

另外，有返回值是void的情况，但在该情况下，能够通过在第1要素中设定null值或者空文字等来应对。

批量应答能够表现为将在上述中说明了的应答作为要素来具有的排列目标。图23是示出批量应答的具体的数据表现例的说明图。

在图23的例子中，维持在批量要求中储存着的要求的顺序，储存了各个应答。即，如果进行了最初的要求是实际要求的规定，则该批量应答的开头要素是与实际要求对应的实际应答。

应答处理装置36如果从通信装置35接收到批量应答和通信句柄，则从先前登记了的信息中检索与该通信句柄对应的信息，取得对应的批量要求和回调函数。

应答处理装置36将与在批量应答中汇总了的各个要求对应的应答与要求配对地保存到应答存储装置31。通过该处理，关于所有应答，按照能够将要求内容作为关键字进行检索的形式，储存到应答存储装置31。应答存储装置31将储存着的结果在步骤ST16中回送到应答处理装置36。

另外，应答处理装置36通过执行与作为API执行要求(实际要求)的要求A对应的回调函数，将与该要求A对应的应答A通知给GUI处理装置32。在回调函数中，将至少与实际要求对应的实际应答作为参数来传递而进行处理。在步骤ST18中，回调函数的处理结果被返回到应答处理装置36。

以下，例示向具体的服务的应用。

例如，将车辆导航系统中的描绘当前位置周边的地图图像的服务作为例子，使用图24的地图图像，说明进一步的具体例。

通常，在描绘当前位置周边的地图图像的服务的情况下，在GUI的画面中全面地描绘当前位置周边的地图图像，在该地图图像上，描绘表示当前位置的车本位置图标，视觉地表现地图上的当前位置。

除此以外，将描绘当前位置的住址等的地名显示、针对地图描绘内容的方位、表示地图的比例尺的地图比例尺、当前时刻描绘到地图图像上。

关于这些地图图像、当前位置、住址、方位、比例尺、当前时刻等信息，在GUI节点1中不生成，而对服务节点2进行询问(进行要求)，从而GUI节点1获得而用于描绘。

但是，在不应用本发明的系统的情况下，如图25所示，GUI节点1在步骤ST201、ST203、ST205、ST207的处理中，对服务节点2进行数据要求(地图要求、地图信息要求、当前位置要求、住址要求)，在步骤ST202、ST204、ST206、ST208的处理中，从服务节点2接受与数据要求对应的应答(地图图像、比例尺/方位、当前位置、当前住址)。

为了进行上述处理，在GUI节点1与服务节点2之间发生合计4次的通信。每当地图描绘定时时发生该处理。关于当前时刻，设想使用GUI节点1具有的时刻信息。

另一方面，在应用本发明的系统中，GUI节点1在将与步骤ST201的处理相当的地图要求发行到服务节点2之前，通过批量要求生成装置33和要求模式管理装置34，取得接着地图要求发行的可能性高的预测要求模式，汇总为批量要求而进行要求。

假设预测要求模式的一部分或者全部错误，也通过重复进行成为实际的要求的实际要求的发行，从而在要求模式管理装置34中，进行在地图要求之后接着的要求模式的更新，反映了在地图要求之后接着的要求是地图信息要求、当前位置要求、住址要求，能够长期地生成能够实施正确的预测的要求模式。

具体而言，在要求模式的生成指示时(图4的步骤ST5)、实际要求通知时(图5的步骤ST22)，能够利用与从批量要求处理装置33对要求模式管理装置34通知的实际要求有关的信息，根据此前所发行的实际要求的时间序列模式、预测对象要求模式，更新与各要求模式的发行次数有关的信息。即，每当发生地图更新时，按照地图要求、地图信息要求、当前位置要求、住址要求的顺序，发生要求，所以该要求模式的发行次数增加。

其结果，通过将发行次数最大的要求模式用作预测要求模式，能够实施正确的预测，能够长期地将需要4次的通信次数削减为1次。

另一方面，假设用户在途中进行了地图比例尺的强制变更的情况下，如图26所示，在步骤ST211的处理中，从GUI节点1向服务节点2将新的比例尺信息作为参数而发行比例尺变更要求，之后发行地图要求、地图信息要求、当前位置要求、住址要求。

在上述情况下，在最初进行比例尺变更时，将比例尺变更要求作为实际要求时的要求模式未保存于要求模式管理装置34中，所以对服务节点仅要求比例尺变更要求，从接下来的地图要求开始批量要求处理。通过该处理，要求模式管理装置34学习在比例尺变更要求之后连续地发行地图要求、地图信息要求、当前位置要求、住址要求，新制作该要求模式。

由此，在发行了第2次以后的比例尺变更要求的情况下，依照新制作了的要求模式，批量要求处理装置33制作地图要求、地图信息要求、当前位置要求、住址要求成为预测要求的批量要求，将该批量要求发送到服务节点2。

如以上说明，根据该实施方式1，设置有：批量要求处理装置33，如果与由GUI处理装置32所发行的执行要求对应的应答存储于应答存储装置31，则将指示把该应答输出到GUI处理装置32的意思的输出指令输出到应答处理装置36，另一方面，如果与该执行要求对应的应答未存储于应答存储装置31，则进行存在接着该执行要求而发行的可能性的要求的预测，对要求模式管理装置34指示包含该执行要求和预测要求的要求模式的生成，生成包括由要求模式管理装置34所生成的要求模式的批量要求；要求模式管理装置34，预测存在接着该执行要求而发行的可能性的要求，生成包含该执行要求和预测要求的要求模式；以及通信装置35，将由批量要求处理装置33所生成的批量要求发送到服务节点2，另一方面，接收与从服务节点2所发送的批量要求对应的批量应答，其中，如果应答处理装置36从批量要求处理装置33接收到输出指令，则将与在应答存储装置31中存储着的执行要求对应的应答输出到GUI处理装置32，如果通过通信装置35接收到批量应答，则将与在该批量应答中包含的执行要求以及预测要求对应的应答储存到应答存储装置31，并且将与该执行要求对应的应答输出到GUI处理装置32，所以如果与执行要求对应的应答存储于应答存储装置31，则无需发送其执行要求，其结果，起到能够充分地削减与协作处理有关的网络通信的次数的效果。

即，能够通过一连串的GUI节点1和服务节点2的处理，根据从GUI节点1实际上发行的单一的实际要求，决定1个以上的预测为接着其发行的要求。因此，能够生成将实际要求和1个以上的预测要求汇总起来的批量要求，将批量要求通知给服务节点2。

另外，服务节点2能够接受批量要求，在各服务中处理成为其内容的要求，并且能够生成汇总该1个以上的应答而成的批量应答，将批量应答回送到GUI节点1。

另外，接收到该批量应答的GUI节点1存储批量应答的内容，在发行与该存储了的结果对应的要求之前，在GUI节点1内随意使用该存储了的结果，从而成为能够削减向服务节点2的通信次数、能够避免与通信相伴的处理速度的降低的系统。

另外，是能够管理预测结果的成功与否信息的系统，根据系统的使用状况等来调整预测参数，从而能够更新预测要求的生成模式。

实施方式2.

在上述实施方式1中，示出了要求模式管理装置34预测存在接着API执行要求而发行的可能性的要求，并生成包含该API实施执行要求和预测要求的要求模式的例子，但也可以由要求模式管理装置34实施按照在GUI中显示的画面单位来管理由GUI处理装置32所发行的执行要求的历史、并更新执行要求的发行频度的处理，即使由GUI处理装置32新发行的执行要求是相同的执行要求，只要在GUI中显示的画面不同，就存在生成不同的要求模式的情况。

具体而言，如以下所述。

在设想了服务整体的情况下，设想如下情况：针对在GUI节点1中显示的每个画面，即使是相同的要求，之后接着的要求的模式也不同。

例如，即使是与图24所示那样的对当前位置周边的地图画面进行显示时的地图要求相同的要求，只要在画面中显示的内容不同，则之后接着的要求也不同的可能性高。

图27是GUI节点1所显示的其他画面例，直至在画面上描绘地图、并且描绘方位、车本位置图标为止，与图24的情况相同，但还描绘了用图标描绘某个地点存在于地图上的何处的地点图标、和以列表形式示出表示与该地点图标有关的基本信息(地点名、和从当前位置起的距离)的按钮的地点列表按钮。

在该情况下，直至在地图要求之后接着的要求是地图信息要求、当前位置要求的部分为止，与图24的情况相同，但如图28所示，在之后接着的是周边检索要求的点不同。

因此，要求模式管理装置34在图24的画面和图27的画面中以相同的要求时间序列解析结果进行了模式管理的情况、例如在图27的画面中片刻动作之后转移到图24的画面而动作了的情况下，存在如下问题：预测要求模式的最后的预测要求并非是住址要求而成为周边检索，无法将适合的要求模式作为预测要求模式。

因此，要求模式管理装置34通过按照画面单位进行独立的要求时间序列解析结果的生成，应对上述问题。

图29是示出按照画面单位进行独立的要求模式管理时的要求时间序列解析结果的数据构造例的说明图。

图29的要求时间序列解析结果是在要素中具有图8的要求时间序列解析结果要素数据构造的数据构造，成为将实际要求作为关键字而具有在该实际要求之后接着的后续模式列表的列表构造。

另外，图29的后续模式列表是在要素中具有图8的后续模式列表要素数据构造的数据构造，成为按后续模式而具有可靠度参数的列表构造。

要求模式管理装置34将实际要求作为关键字，从该要求时间序列解析结果取得对应的后续模式列表，根据该后续模式列表来决定预测要求模式。

在此前的说明中，即使画面变化也管理单一的要求时间序列解析结果，但通过导入按画面的列表，成为能够针对每个画面定义不同的要求时间序列解析结果、并针对每个画面管理不同的要求时间序列解析结果的数据构造。

通过针对每个画面定义要求时间序列解析结果，能够消除在图24以及图27的例子中说明那样的、无法针对每个画面通过基于同一要求时间序列解析结果的预测来生成适合的预测要求模式的问题。

要求模式管理装置34每当从批量要求处理装置33变更画面时接受当前处理中的画面信息，从而能够获知显示了按画面的列表中的哪个画面，能够进行以适合的实际要求列表为基准的要求模式管理以及预测要求的决定。

另外，批量要求处理装置33能够将从GUI处理装置32向服务节点2发行的GUI记述数据取得要求作为触发，将接下来的画面信息通知给要求模式管理装置34。或者，也可以将应答处理装置36接收到与来自服务节点2的GUI记述数据取得要求对应的应答的定时作为触发，进行同样的处理。

另外，在GUI节点1保持了画面信息的情况下，GUI处理装置32能够通过在发生画面转移的定时对要求模式管理装置34通知接下来的画面信息来进行对应。

例如，如果要求模式管理装置34具有图29的要求时间序列解析结果，设按画面的列表的画面A意味着图24所示的画面、设画面B意味着图27所示的画面，则在显示了图24的画面的情况下，要求模式管理装置34一边参照按画面的列表的画面A的要素所参照的实际要求列表一边进行处理。

此时，将GUI记述数据取得要求作为触发，批量要求处理装置33将成为转移目的地的画面信息即画面B通知给要求模式管理装置34。

要求模式管理装置34如果接收到该通知，则将成为处理对象的实际要求列表切换为按画面的列表的画面B的要素所参照的实际要求列表，在其以后的处理中，一边参照切换了的实际要求列表一边进行处理。

实施方式3.

在该实施方式3中，说明要求模式管理装置34中的要求时间序列解析结果的生成方式。

要求时间序列解析结果是对与紧接在发行了某个实际要求之后接着所发行的要求的模式有关的信息进行收集并解析而得到的结果，是由与1个以上且有限数量的要求有关的信息构成的模式的集合体。

关于该模式，根据从GUI处理装置32通知给批量要求处理装置33的API执行要求，生成成为对与该要求有关的信息、与发行该要求的时间序列顺序有关的信息等动态地进行收集并解析而得到的结果的要求时间序列解析结果。

另外，在要求模式管理装置34处理来自批量要求处理装置33的要求模式的生成指示的情况下，根据要求时间序列解析结果的内容来构成预测要求模式。

作为要求时间序列解析结果的具体的方式，例如有如下方法：针对图29所示那样的收集了的所有要求模式，实际上发行了该要求模式的开头的要求时，持有成为之后是否进行与对应的后续模式相同的模式的要求发行的尺度的可靠度参数来进行管理。在该情况下，将各个实际要求和后续要求模式进行了合并的要求模式中包含的要求数必须是有限的。

以下，说明用于将在要求时间序列解析结果中包含的要求模式设为有限的要求数的具体的方法。

(1)作为构成有限数量的要求模式的方法之一，考虑设定要求模式的要求数的最大数的方式。

例如，在将预测要求模式数的最大数设为5的情况下，要求模式管理装置34生成的所有预测要求模式最大是5个，能够构成由有限数量的要求来构成的模式。

图30是示出将预测要求模式数最大设为5个时的要求模式数据的生成例的说明图。

此处，为了简化说明，要求模式管理装置34最初成为不具有任何要求模式数据的状态。

设想如下状况：在该状态下，按照在要求发行时间序列列表中示出的箭头的顺序，从GUI处理装置32将要求通知给批量要求处理装置33。

如果向批量要求处理装置33通知了最初的要求A，则该要求A被通知给要求模式管理装置34，要求模式管理装置34生成实际要求信息A(参照要求时间序列解析结果(1))，并且生成具有初始值的要求模式列表，与实际要求信息A关联起来(参照要求时间序列解析结果(2))。

转移到如下阶段：直至之后接着的4个要求为止，插入到新生成的要求模式列表。

之后，如果依次通知了要求B、C、D、E，则要求模式管理装置34向紧接在之前生成的后续要求列表的最末尾依次插入要求(参照要求时间序列解析结果(3))。

在要求E被插入于后续要求列表的时间点，后续要求列表的要求数成为4个且实际要求成为1个，达到最大数的5个，所以要求模式管理装置34在被通知了接下来的要求时，转移到处理为实际要求信息的阶段。

之后，如果通知了要求F，则要求模式管理装置34确认在要求模式数据的实际要求信息列表中是否有与要求F一致的信息。

其结果，判明无一致的信息，要求模式管理装置34生成实际要求信息F(参照要求时间序列解析结果(4))，并且生成具有初始值的要求模式列表，与实际要求信息F关联起来(参照要求时间序列解析结果(5))。

转移到如下阶段：直至之后接着的4个要求为止，插入到新生成的要求模式列表。

之后，如果依次通知了要求G、H、I、J，则要求模式管理装置34向紧接在之前生成的后续要求列表的最末尾依次插入要求(参照要求时间序列解析结果(6))。

在后续要求列表中插入了要求J的时间点，后续要求列表的要求数成为4个且实际要求成为1个，达到最大数的5个，所以要求模式管理装置34在被通知了接下来的要求时，转移到处理为实际要求信息的阶段。

之后，如果通知了要求A，则要求模式管理装置34确认在要求模式数据的实际要求信息列表中是否有与A一致的信息。

其结果，如果判明了有一致的信息，则要求模式管理装置34针对一致的实际要求信息，生成具有初始值的要求模式列表，作为新的要素关联起来(参照要求时间序列解析结果(7))。

转移到如下阶段：直至之后接着的4个要求为止，插入到新生成的要求模式列表。

之后，如果依次通知了要求K、L、M、N，则要求模式管理装置34向紧接在之前生成的后续要求列表的最末尾依次插入要求(参照要求时间序列解析结果(8))。

在后续要求列表中插入了要求N的时间点，后续要求列表的要求数成为4个且实际要求成为1个，达到最大数的5个，所以要求模式管理装置34在被通知了接下来的要求时，转移到处理为实际要求信息的阶段。

通过重复以上的处理，能够构成固定地指定了要求最大数的要求模式。

此处，虽然是被固定的要求最大数，但也可以固定为系统整体，但例如也可以按照GUI画面单位，设为不同的值的固定值。除此以外，也可以根据状况，使固定值变动。例如，考虑如果从GUI节点1发行的批量要求的预测成功率(例如，在批量要求生成之后从GUI处理装置32实际上向批量要求处理装置33发行要求了实际要求以外的预测要求的概率)是某个阈值以上，则使该固定值递增，增加要求模式中可设定的要素数，增加在批量要求中发送的要求数，从而能够进一步削减通信次数等。

在根据该成功率进行变动的情况下，也可以是针对每个要求模式来设定固定值的方法。

(2)作为构成有限数量的要求模式的其他方法，考虑如下方法：利用从GUI处理装置32向批量要求处理装置33通知的API执行要求的时间间隔。

通常，在某一连串的处理开始，并在该一连串的处理中执行多个API的情况下，该API的执行间隔一般比用户操作间隔等更短的情况较多。因此，在一连串的处理完成之后，直至再次通过用户操作等触发而发生不同的一连串的处理为止的时间是比一连串的处理中的API的执行间隔更长的时间间隔的情况较多。

利用这样的状况，测量紧接在之前通知了的要求、和本次通知了的要求的时间间隔，如果该时间间隔小于规定的阈值(规定的时间间隔)，则能够判断为这2个要求包含于一连串的处理中。

具体而言，作为在图25的地图更新处理中包含的一连串的要求的地图要求、地图信息要求、当前位置要求、住址要求的要求之间的时间间隔变短，但直至从住址要求起发行接下来的地图要求为止成为直至发生新的画面更新定时为止，所以意味着时间间隔变长。

由于进行上述处理，所以采用了该方法的要求模式管理装置34需要在被通知了要求时，计算从上次的要求通知起的经过时间。

图31是示出计算从上次的要求通知到本次的要求通知为止的经过时间的处理的流程图。

要求模式管理装置34如果从批量要求处理装置33接收到成为本次的要求的要求A的通知(步骤ST301)，则取得当前时刻T1(步骤ST302)。

之后，计算上次的要求的通知时刻T0和时刻T1的差分dT(步骤ST303)。该差分dT成为针对要求A的经过时间。此处，在未设定T0的情况下，将dT设为0。

要求模式管理装置34通过代入T1的值作为新的T0的值，完成经过时间计算处理(步骤ST304)。

要求模式管理装置34在通过该处理计算出的经过时间dT小于作为系统决定了的阈值sT的情况下，实施如下处理：针对上次通知了的要求所属的要求模式，追加本次通知了的要求A。

另一方面，在经过时间dT是阈值sT以上的情况下，在上次通知了的要求所属的要求模式中，不追加本次通知了的要求A，而处理为新的实际要求。

图32是示出利用了经过时间时的要求模式数据的生成例的说明图。

设想如下状况：按照在要求发行时间序列列表中示出的箭头的顺序，从GUI处理装置32将要求通知给批量要求处理装置33。

另外，在箭头中，单线箭头意味着根据通知了箭头的右的要求的时刻和通知了左的要求的时刻的差分而计算出的经过时间小于阈值sT，双重线箭头意味着是sT以上。

如果通知了最初的要求A，则要求模式管理装置34计算经过时间，但由于没有上次的要求，所以将要求A判定为实际要求。其结果，生成实际要求信息A，并且生成具有初始值的要求模式列表，与实际要求信息A关联起来(参照要求时间序列解析结果(1))。

如果接下来通知了要求B，则要求模式管理装置34计算经过时间，其结果，判定经过时间小于阈值sT。

在经过时间小于阈值sT的情况下，针对上次的要求A所属的要求模式，要求B也属于该要求模式，所以将要求B作为实际要求A的最新的后续要求列表的要素而插入(参照要求时间序列解析结果(2))。

关于接着通知的要求C、D，由于经过时间小于阈值sT，所以也与要求B同样地，作为实际要求A的最新的后续要求列表的要素而插入(参照要求时间序列解析结果(3))。

如果接下来通知了要求E，则要求模式管理装置34计算经过时间，其结果，判定经过时间是阈值sT以上。

在经过时间是阈值sT以上的情况下，本次的要求不属于上次的要求所属的要求模式，所以将要求E判定为实际要求。其结果，生成实际要求信息E，并且生成具有初始值的要求模式列表，与实际要求信息E关联起来(参照要求时间序列解析结果(4))。

之后，如果通知了成为第2个的要求A，则要求模式管理装置34计算经过时间，其结果，判定经过时间是阈值sT以上。

在经过时间是阈值sT以上的情况下，本次的要求不属于上次的要求所属的要求模式，所以将要求A判定为实际要求。但是，实际要求信息A已经存在，所以本次不新生成，而是将既存的实际要求信息A作为处理对象，等待接下来的要求通知。

如果接下来依次通知了要求B、C、D，则计算他们所有的经过时间，判定所有的经过时间小于阈值sT，判定为是与实际要求A连续的要求模式。但是，此处，模式与既存的后续要求列表B、C、D一致，所以继续保持当前的要求是与该后续要求列表的哪个要素对应的内容。即，在通知了要求B的情况下，保持指示后续要求列表的第1个要求B的信息，在通知了要求C的情况下，保持指示后续要求列表的第2个要求C的信息，在通知了要求D的情况下，保持指示后续要求列表的第3个要求D的信息。

在最终通知了要求D的时间点，成为要求模式的A、B、C、D发行2次。

但是，如果接下来通知的要求E的经过时间小于阈值sT，则本次的要求模式尚未确定，但至少成为要求A、B、C、D、E、或者其以上的要求继续的要求模式。另一方面，如果是阈值sT以上，则确定本次的要求模式是A、B、C、D、E。

即，在是阈值sT以上的情况下，确定实际上通知了的要求的时间序列模式与既存的要求模式一致。在该情况下，在强化的方向上更新一致的既存的要求模式的可靠度参数。通过在强化的方向上进行更新，提高在批量要求时采用该要求模式的准确性，作为结果，能够提高预测成功的概率。

另一方面，在小于阈值sT的情况下，确定实际上通知了的要求的时间序列模式与既存的要求模式不一致，所以在该情况下，新生成具有初始值的要求模式列表，在其中的后续要求列表中设定要求B、C、D、E，与实际要求信息A关联起来(参照要求时间序列解析结果(6))。

如以上那样，利用根据从上次的要求通知到本次的要求通知为止的经过时间来判别要求模式的结构的方法，相比于对要求列表的要素最大数进行指定的方法，能够构成更长的模式的要求模式，并且能够实施与系统的动作状况对应的要求模式的判定。

(3)作为构成有限数量的要求模式的其他方法，考虑利用要求类别的方法。

关于从GUI节点1向服务节点2发行的要求，除了API执行要求以外，还有用于取得用来在GUI节点中显示接下来的画面的GUI记述数据的GUI记述数据取得要求、或向在网络上存在的节点全体进行广播来进行节点的存在确认等的系统信息取得要求等，能够根据所要求的内容来分类。

在发行了GUI记述数据取得要求的情况下，意味着在GUI节点1中在画面上显示的内容被更新，所以在其前后，不希望要求模式连续。如该GUI记述数据取得要求那样，将成为在其前后把要求模式的连续进行切断的基准的要求称为末端要求。

为了利用它来构成有限数量的要求模式，例如在通知了GUI记述数据取得要求的情况下，作为与上次的要求所属的要求模式不同的要求模式，要求模式管理装置34需要保持表示是否应处理该要求或者下次要通知的要求的末端要求内容表格。

作为末端要求内容表格的1个具体例，考虑将从GUI节点1向服务节点2发行的所有要求中的、应判定为末端要求的要求的识别信息登记到表格。

即，要求模式管理装置34每当被通知要求时，检索通知了的要求的识别信息是否在末端要求内容表格中，在有通知了的要求的识别信息的情况下，进行将下次要通知的要求判定为新的实际要求的准备，等待接下来的要求通知。

另一方面，在无通知了的要求的识别信息的情况下，进行针对上次通知了的要求所属的要求模式追加下次要通知的要求的准备，等待接下来的要求通知。此时，也可以将判定为末端要求的本次的要求追加到上次通知了的要求所属的要求模式。也可以将该基准记述到末端要求内容表格，依照该基准来决定向要求模式追加。

关于末端要求内容表格，也可以由要求模式管理装置34固定地保持。另一方面，关于末端要求内容表格，也可以由GUI节点1从服务节点2取得。

通过采用从服务节点2取得的方式，能够进行使用了适合于服务节点2提供的服务的末端要求内容表格的判定，所以能够生成准确性更高的批量要求。

作为进一步的实施例，说明新的要求模式管理装置34的动作。

要求模式管理装置34将根据从批量要求处理装置33输出的要求模式的生成指示而送来的要求作为关键字，决定预测为在该要求之后要求的1个以上的要求。此时，将从决定了的一个以上的要求中去除了某特定的要求得到的结果回送到批量要求处理装置33。

例如，在预测为之后要求的要求中包含有变更服务节点2的状态的要求(服务状态变更要求)的情况下，如果在包括该服务状态变更要求的状态下生成批量要求，并将该批量要求发送到服务节点2，则服务节点2通过执行服务状态变更要求，更新服务节点的状态。

但是，关于该服务状态变更要求，并未决定为在GUI节点1中实际上应要求的要求，所以该执行有可能引起对于GUI节点1而言未设想的服务节点2的状态。

从批量要求处理装置33接收到要求模式的生成指示的要求模式管理装置34通过在根据要求模式数据决定了对应的要求模式之后，从该要求模式去除某特定的要求，从而能够更新为不发生上述那样的GUI节点1未设想的服务节点2的状态变更的要求模式。

在上述例子中，在被分类为服务状态变更要求的要求包含于要求模式中的情况下，从要求模式去除该要求，构筑新的要求模式，将该要求模式返回到批量要求处理装置33。

另外，除了上述处理以外，也可以在要求模式管理装置34更新要求模式数据时，进行将成为去除对象的要求不储存于要求模式数据的控制，在从批量要求处理装置33接收到要求模式的生成指示时，不实施将成为去除对象的要求从要求模式去除的处理。

与上述2种处理方式一起，也可以将作为成为去除对象的要求模式的判定基准的信息在GUI节点1内保持为固定值。另外，关于成为判定基准的信息，也可以通过在系统起动时等对服务节点2进行取得要求，能够按照作为系统协作动作的每个服务节点2的基准来判定。

进而，除了上述处理以外，也可以包括成为去除对象的要求来生成批量要求，在从GUI节点1发行到服务节点2之后，服务节点2侧的批量要求解释装置42进行成为去除对象的要求判定，将判定为去除对象的要求不输出到要求处理装置43，而将错误应答通知给批量应答生成装置45。

在该情况下，进行在由GUI节点1的应答处理装置36检测到错误应答时不将该错误应答存储于应答存储装置31的控制。

实施方式4.

在上述实施方式1～3中，示出了应答处理装置36将与由通信装置35接收到的批量应答中包含的执行要求以及预测要求对应的应答等信息储存于应答存储装置31的例子，但在应答存储装置31中一旦存储了信息时，如果什么都不做则继续存储。

但是，如果始终持续存储该信息，则有可能成为该信息与实际的服务节点2的信息不一致的状态。

因此，在该实施方式4中，进行将在应答存储装置31中存储着的应答等信息在某个定时进行删除的控制。

作为删除在应答存储装置31中存储着的应答的1个方法，考虑以下的方法。

应答存储装置31如果从应答处理装置36接收到与某个应答有关的应答保存要求，则与接受时的时刻信息一起，保存该应答。

应答处理装置36按照一定时间间隔，针对由应答存储装置31当前保存的全部应答，计算从保存开始时间点起的经过时间，在某个应答的经过时间超过了某个固定的阈值的情况下，进行将该应答从应答存储装置31删除的控制。

通过进行上述控制，能够消除永久地持续保存特定的应答的状况。

作为删除应答的其他方法，考虑以下的方法。

应答存储装置31如果从应答处理装置36接收到与某个要求对应的应答的取得要求，则检索是否保存有针对指定了的要求的应答，在保存了的情况下，将该应答回送到应答处理装置36。

应答处理装置36在保存有针对要求的应答的情况下，进行将该应答从应答存储装置31删除的控制。

通过进行该控制，能够消除永久地持续保持特定的应答的状况。

关于上述控制，作为在第1次的取得要求中进行删除的例子进行了说明，但无需一定在第1次中删除，而可以在第N次的取得要求中删除。在该情况下，应答存储装置31对于要保存的应答，设置对实施了几次取得要求进行存储的区域来保存，在应答的保存时，在该区域中记录0，每当通过取得要求来处理时，进行递增。

应答处理装置36判定该区域的值是否为N，在成为N的时间点，删除该应答。

作为删除应答的其他方法，考虑以下的方法。

服务节点2的批量应答生成装置45在生成批量应答时，与各应答一起，将成为该应答在GUI节点1内的有效期限的信息(有效期限信息)、例如参照次数、生存时间等嵌入到批量应答而生成。

接收到批量应答的GUI节点1的应答处理装置36抽出在批量应答中包含的各应答和与其对应的有效期限信息，将它们作为组而保存于应答存储装置31。

在有效期限信息是参照次数的情况下，应答处理装置36在将与某个要求对应的应答的取得要求输出到应答存储装置31的定时，比较与该要求对应的应答的有效期限信息、和该要求的参照次数信息，如果有效期限信息更小，则进行将该应答从应答存储装置31删除的控制。

另外，在有效期限信息是生存时间的情况下，应答处理装置36按照一定时间间隔，针对在应答存储装置31中保存了的全部应答，计算从保存开始时间点起的经过时间，在某个应答的经过时间超过了某个固定的阈值的情况下，进行将该应答从应答存储装置31删除的控制。

关于该有效期限信息，也可以不设为在批量应答中每次储存的处理。例如，也可以定义记述了针对所有应答的有效期限信息的有效期限信息表格，GUI节点1将其保持，使用该有效期限信息表格的信息，判定超过了有效期限的应答，进行删除处理。

另外，也可以是如下方式：有效期限信息表格由服务节点2保持，作为来自GUI节点1的明示的有效期限信息表格的取得要求的应答，从服务节点2提供给GUI节点1。

作为删除应答的其他方法，考虑以下的方法。

服务节点2的批量应答生成装置45具备应答提供管理单元，该应答提供管理单元在生成批量应答时，管理将与哪个要求对应的应答以什么样的值发送到哪个GUI节点1。

在应答提供管理单元中，例如在图33所示那样的应答提供管理表格等中，管理将与哪个要求对应的应答以什么样的值发送到哪个GUI节点1。

在应答提供管理表格中，是具备表示是与哪个要求对应的应答的提供应答ID、表示所提供的应答的具体的值的提供应答值、以及表示将该应答提供给哪个GUI节点1的提供目的地GUI节点ID列表的表格。

但是，如果服务节点2协作的GUI节点1在系统上是唯一的，则提供目的地GUI节点ID列表也可以省略。

在图33的应答提供管理表格(1)中，示出了提供给GUI节点1的应答有2种的状态。

在提供应答ID中，示出了抽出成为与该应答对应的要求的URL的一部分而记述为ID的例子。

在提供应答值中，示出了储存成为应答的JSON形式的值的例子。

在提供目的地GUI节点ID列表中，示出了抽出成为要求源的GUI节点1的域名的一部分而记述为ID的例子。

例如，示出了将提供应答ID是“/srv1/getProps()”的应答提供给域名的一部分是“GUInode1”、或者“GUInode2”这2种的GUI节点1的例子。

在该应答提供管理表格(1)的状态下，批量应答生成装置45探测到提供应答ID为例如“/srv1/getProps()”的应答的值的全部或者一部分被更新。

在该情况下，批量应答生成装置45针对与提供应答ID为“/srv1/getProps()”对应的提供目的地GUI节点ID列表中登记了的GUI节点1，发行意味着将应答ID为“/srv1/getProps()”的应答从应答存储装置31删除的删除要求的应答删除要求事件。

图34是示出应答删除要求事件的记述例的说明图。

在图34的例子中，作为JSON形式的排列目标，记述了应答删除要求事件。在第1要素中记述了成为事件的识别信息的事件名，在第2要素中记述了成为删除对象的应答ID。

事件的识别信息无需限定于事件名，也可以是在各个事件中定义了的事件识别编号等。

另外，在图34的例子中，成为删除对象的应答ID成为1个，但关于第2要素以后的要素，也可以全部设为记述成为删除对象的应答ID的规格，而能够在1个应答删除要求事件中记述多个成为删除对象的应答ID。

另外，在利用了HTTP的客户端/服务器系统中，作为从服务器装置对客户端终端自发地发送信息的方法，能够通过利用Comet、Server-Sent Events、WebSocket API来实现。

在发行了应答删除要求事件之后，批量应答生成装置45将记述了与该事件对应的应答的要素从应答提供管理表格删除。

例如，在图33的应答提供管理表格(1)的状态下，针对应答ID为“/srv1/getProps()”的要素，发行了应答删除要求事件的情况下，删除对应的要素，应答提供管理表格被更新为图33的应答提供管理表格(2)的状态。

另一方面，在接收到应答删除要求事件的GUI节点1中，应答处理装置36解释应答删除要求事件，对应答存储装置31要求删除与成为删除对象的应答ID对应的应答，从而进行将该应答从应答存储装置31删除的控制。

通过进行以上的控制，能够避免如下状况：直至在GUI节点1的应答存储装置31中存储着的应答不与服务节点2内的状态一致为止，应答存储装置31继续进行存储。

另外，在批量应答生成装置45探测到某个应答值的更新的情况下，也可以并非发行应答删除要求事件，而是发行应答更新要求事件。

应答更新要求事件是以使将在GUI节点1的应答存储装置31中存储着的特定的应答更新为在该事件中记述了的应答的值的方式记述了从服务节点2向GUI节点1的要求的事件。

图35是示出应答更新要求事件的记述例的说明图。

在图35的例子中，作为JSON形式的排列目标，记述了应答更新要求事件。在第1要素中记述了成为事件的识别信息的事件名，在第2要素中记述了成为更新对象的应答ID，在第3要素中记述了应更新的应答的值。

事件的识别信息无需限定于事件名，也可以是在各个事件中定义了的事件识别编号等。

另外，在图35的例子中，成为更新对象的应答ID和其应更新的应答的值仅记述了一组，但也可以记述多个。

在发行了应答更新要求事件之后，批量应答生成装置45从应答提供管理表格中检索记述了与该事件对应的应答的要素，将该要素的提供应答值改写为应更新的应答的值。

例如，在图33的应答提供管理表格(1)的状态下针对应答ID为“/srv1/getProps()”的要素，发行了图35所示的应答更新要求事件的情况下，将对应的要素的提供应答值的值改写为应答更新要求事件的应更新的应答的值，更新为图33的应答提供管理表格(3)的状态。

另外，也可以针对成为发行应答更新要求事件的对象的应答，对一部分的应答施加限制。

例如，与用于参照服务节点2保持的内部变量的API的执行要求对应的应答伴随着服务节点2的内部状态的变更而被频繁地更新。

另一方面，关于与调出服务的某个特定的功能、并作为应答而返回处理成功/失败标志那样的API的执行要求对应的应答，如果是正常处理，则在大多数的情况下，会返回成功标志，应答被更新的频度低。

因此，也可以仅限于频繁地要求的应答、并且频繁地更新应答那样的表示上述服务节点的内部状态的变量的参照要求API，发行应答更新要求事件。

在该情况下，通过具有如下功能而能够实现：在批量应答生成装置45构筑应答提供管理表格时，判定是否为与应答更新要求事件的发行对象的要求对应的应答，在并非发行对象的情况下，跳过向应答提供管理表格的登记处理。

另外，考虑对服务节点2的内部状态进行参照的GUI节点1中的处理依赖于在GUI节点1中处理中的GUI内容而大幅变化。

因此，考虑按照GUI记述数据来管理批量应答生成装置45具有的应答提供管理表格，抑制事件发生。

关于接收到GUI记述数据取得要求的服务节点2，也可以由批量应答生成装置45删除此前构筑了的应答提供管理表格，构筑新的应答提供管理表格。

在该情况下，在与服务节点2协作的GUI节点1有多个的情况下，按照GUI节点1来构筑批量应答生成装置45管理的应答提供管理表格，在从各GUI节点1接收到GUI记述数据取得要求的情况下，通过仅删除与该GUI节点1对应的应答提供管理表格，从而即使在与多个GUI节点1协作的情况下也能够对应。

另外，无需仅将GUI记述数据取得要求作为触发而进行对应的应答提供管理表格的删除，也可以将1个以上的特定的要求的接收作为触发，还可以将设定了某个参数的某个特定的要求的接收作为触发。

另外，本申请发明能够在本发明的范围内，实现各实施方式的自由的组合、或者各实施方式的任意的构成要素的变形、或者在各实施方式中省略任意的构成要素。

产业上的可利用性

本发明适用于需要充分削减与协作处理有关的网络通信的次数的通信系统。

Claims (15)

1.一种通信系统，具备：客户端终端，发行服务的执行要求；以及服务器装置，执行与由所述客户端终端所发行的执行要求对应的服务，生成作为所述服务的处理结果的应答，将所述应答回送到所述客户端终端，所述通信系统的特征在于，

所述客户端终端包括：

应答存储单元，存储从所述服务器装置回送了的应答；

执行要求发行单元，发行服务的执行要求；

要求模式生成单元，如果与由所述执行要求发行单元所发行的执行要求对应的应答存储在所述应答存储单元中，则输出指示将所述应答输出到所述执行要求发行单元的意思的输出指令，另一方面，如果与所述执行要求对应的应答未存储在所述应答存储单元中，则预测存在接着所述执行要求而发行的可能性的要求，生成包含该预测要求和所述执行要求的要求模式；

通信单元，将由所述要求模式生成单元所生成的要求模式发送到所述服务器装置，另一方面，接收与构成所述要求模式的执行要求以及预测要求对应的从所述服务器装置所发送的应答；以及

应答处理单元，如果从所述要求模式生成单元接收到输出指令，则将与在所述应答存储单元中存储着的执行要求对应的应答输出到所述执行要求发行单元，如果通过所述通信单元接收到与执行要求以及预测要求对应的应答，则将与所述执行要求以及所述预测要求对应的应答储存到所述应答存储单元，并且将与所述执行要求对应的应答输出到所述执行要求发行单元。

2.根据权利要求1所述的通信系统，其特征在于，

服务器装置包括：

1个以上的应答生成单元，执行与各种执行要求对应的服务，生成作为所述服务的处理结果的应答；

要求模式接收单元，接收从客户端终端所发送的要求模式；

应答取得单元，针对构成由所述要求模式接收单元接收到的要求模式的各个要求的每一个要求，确定执行与该要求对应的服务的应答生成单元，将该要求提供给所述应答生成单元，取得由所述应答生成单元所生成的应答；以及

应答发送单元，将与由所述应答取得单元所取得的各个要求对应的应答汇总起来发送到所述客户端终端。

3.根据权利要求1所述的通信系统，其特征在于，

要求模式生成单元实施如下处理：管理由执行要求发行单元所发行的执行要求的历史，在发行了某个执行要求之后，更新接着所述执行要求而发行了的执行要求的发行频度，另一方面，

实施如下处理：如果从所述执行要求发行单元新发行了执行要求，则将所述执行要求决定为要求模式的开头要素，并且在过去接着所述执行要求而发行了的执行要求之中，将发行频度最高的执行要求决定为所述要求模式的下一要素，

将决定所述要求模式的下一要素的处理重复实施1次以上。

4.根据权利要求3所述的通信系统，其特征在于，

要求模式生成单元实施如下处理：按照在GUI中显示的画面单位，管理由执行要求发行单元所发行的执行要求的历史，更新执行要求的发行频度，

即使由所述执行要求发行单元新发行的执行要求是相同的执行要求，如果在GUI中所显示的画面不同，则有时生成不同的要求模式。

5.根据权利要求1所述的通信系统，其特征在于，

要求模式生成单元以使要求模式中包含的要求的个数不超过预先设定的上限数的方式生成要求模式。

6.根据权利要求1所述的通信系统，其特征在于，

如果由执行要求发行单元上次所发行的执行要求的发行时刻与本次所发行的执行要求的发行时刻的时刻差是阈值以上，则要求模式生成单元使上次所发行的执行要求和本次所发行的执行要求包含于不同的要求模式中。

7.根据权利要求1所述的通信系统，其特征在于，

要求模式生成单元以在要求模式中不包括特定的要求的方式生成要求模式。

8.根据权利要求7所述的通信系统，其特征在于，

要求模式生成单元将由服务器装置执行的服务的状态的变更要求设为特定的要求，不使该变更要求包含于要求模式中。

9.根据权利要求2所述的通信系统，其特征在于，

应答取得单元在由要求模式接收单元接收到的要求模式中包含的要求是特定的要求的情况下，对应答发送单元指示针对客户端终端通知错误应答。

10.根据权利要求2所述的通信系统，其特征在于，

应答处理单元删除在应答存储单元中存储着的1个以上的应答中的满足规定的删除条件的应答。

11.根据权利要求10所述的通信系统，其特征在于，

应答处理单元在删除条件是保存期间的情况下，删除在应答存储单元中存储着的期间超过所述保存期间的应答。

12.根据权利要求10所述的通信系统，其特征在于，

应答处理单元在删除条件是参照次数的情况下，删除输出到执行要求发行单元的次数超过所述参照次数的应答。

13.根据权利要求10所述的通信系统，其特征在于，

应答取得单元设定由应答生成单元所生成的应答的删除条件，

应答发送单元在将与各个要求对应的应答发送到客户端终端时，将由所述应答取得单元所设定的删除条件发送到所述客户端终端。

14.一种客户端终端，具备：

应答存储单元，存储从服务器装置回送了的应答；

执行要求发行单元，发行服务的执行要求；

要求模式生成单元，如果与由所述执行要求发行单元所发行的执行要求对应的应答存储在所述应答存储单元中，则输出指示将所述应答输出到所述执行要求发行单元的意思的输出指令，另一方面，如果与所述执行要求对应的应答未存储在所述应答存储单元中，则预测存在接着所述执行要求而发行的可能性的要求，生成包含该预测要求和所述执行要求的要求模式；

通信单元，将由所述要求模式生成单元所生成的要求模式发送到所述服务器装置，另一方面，接收与构成所述要求模式的执行要求以及预测要求对应的从所述服务器装置所发送的应答；以及

应答处理单元，如果从所述要求模式生成单元接收到输出指令，则将与在所述应答存储单元中存储着的执行要求对应的应答输出到所述执行要求发行单元，如果通过所述通信单元接收到与执行要求以及预测要求对应的应答，则将与所述执行要求以及所述预测要求对应的应答储存到所述应答存储单元，并且将与所述执行要求对应的应答输出到所述执行要求发行单元。

15.一种服务器装置，具备：

1个以上的应答生成单元，执行与各种执行要求对应的服务，生成作为所述服务的处理结果的应答；

要求模式接收单元，接收从客户端终端所发送的要求模式；

应答取得单元，针对构成由所述要求模式接收单元接收到的要求模式的各个要求的每一个要求，确定执行与该要求对应的服务的应答生成单元，将该要求提供给所述应答生成单元，取得由所述应答生成单元所生成的应答；以及

应答发送单元，将与由所述应答取得单元所取得的各个要求对应的应答汇总起来发送到所述客户端终端。