边缘系统、信息处理方法以及信息处理程序

技术领域

本发明涉及一种IoT(Internet of Things：物联网)。

背景技术

在IoT中，存在如下事例：遍及多个域的多个应用程序(以下还仅称为应用)共用作为大数据被积蓄在云系统(以下还仅称为云)上的各种物体(传感器)的信息。在该情况下，期望应用无需意识到传感器的域知识(设置场所、收集的数据的种类、精度等)而能够利用。

作为与IoT有关的标准化组织的oneM2M正在推进从应用接受语义的查询、并对查询进行响应的水平集成(horizontally integrated)型IoT平台的标准化(例如专利文献1)。在水平集成型IoT平台中，使用本体(ontology)对赋予了注释的传感器数据进行管理。另外，在水平集成型IoT平台中，通过推理器来实现对应用的语义的查询的响应。由此，应用无需传感器的域知识而能够利用数据。

另外，还提出了如下技术：对传感器侧和应用侧赋予元数据，使用本体来进行元数据彼此的匹配，提取能够提供满足应用的请求的传感器数据的传感器的候选(例如专利文献2)。

专利文献1：日本特表2018-503905号公报

专利文献2：日本特开2018-81377号公报

发明内容

发明要解决的问题

以往的水平集成型IoT平台设想在云上集中地进行处理。因此，如果利用水平集成型IoT平台的应用显著增加，则有可能处理负荷变高，响应性能下降。即使在通过规模放大(scaling up)、规模扩展(scaling out)来应对的情况下，也需要由应用一律负担其费用。另外，在云上的集中处理中产生通信延迟，因此存在无法满足无法容许通信延迟的应用的请求的情况。

为了减轻负荷集中到云的情况且消除通信延迟，还设想使用边缘系统。然而，边缘系统的计算资源和存储容量有限。因此，需要通过边缘系统的有限的计算资源和存储容量来对来自应用的查询准确地进行响应。

本发明是鉴于这样的情况而完成的。更具体地说，主要目的在于，在水平集成型IoT平台中，使边缘系统能够对来自应用的查询准确地进行响应。

用于解决问题的方案

本发明所涉及的边缘系统是对应于水平集成型IoT(Internet of Things)平台的边缘系统，具有：

语义引擎；

深度获取部，获取作为对于所述语义引擎的搜索的深度的请求的响应深度；以及

搜索控制部，使所述语义引擎重复搜索，直到所述语义引擎的搜索的深度达到所述响应深度为止。

发明的效果

本发明所涉及的边缘系统使语义引擎重复搜索，直到语义引擎的搜索的深度达到响应深度为止。因此，边缘系统能够对来自应用的查询准确地进行响应。

附图说明

图1是表示实施方式1所涉及的IoT系统的结构例的图。

图2是表示实施方式1所涉及的边缘系统的功能结构例的图。

图3是表示实施方式1所涉及的边缘系统的动作例的流程图。

图4是表示实施方式1所涉及的响应深度判定处理的详情的流程图。

图5是表示实施方式2所涉及的IoT系统的结构例的图。

图6是表示实施方式2所涉及的边缘系统(主系统)、边缘系统(从系统)以及网络存储设备的功能结构例的图。

图7是表示实施方式2所涉及的边缘系统(主系统)的动作例的流程图。

图8是表示实施方式2所涉及的语义引擎选择处理的详情的流程图。

图9是表示实施方式2所涉及的边缘系统(从系统)的动作例的流程图。

图10是表示实施方式3所涉及的边缘系统和云系统的功能结构例的图。

图11是表示实施方式4所涉及的边缘系统的功能结构例的图。

图12是表示实施方式4所涉及的边缘系统的动作例的流程图。

图13是表示实施方式4所涉及的关联性判定处理(查询)的详情的流程图。

图14是表示实施方式4所涉及的关联性判定处理(执行结果)的详情的流程图。

图15是表示实施方式5所涉及的边缘系统的功能结构例的图。

图16是表示实施方式5所涉及的边缘系统的动作例的流程图。

图17是表示实施方式5所涉及的结果扩展处理的详情的流程图。

图18是表示实施方式6所涉及的边缘系统和云系统的功能结构例的图。

图19是表示实施方式6所涉及的边缘系统的动作例的流程图。

图20是表示实施方式6所涉及的云系统的动作例的流程图。

图21是表示实施方式7所涉及的边缘系统的功能结构例的图。

图22是表示实施方式7所涉及的Linked Data(链接数据)的例子的图。

图23是表示实施方式1所涉及的深度确定表的图。

图24是表示实施方式2所涉及的端点确定表的图。

(附图标记说明)

1：IoT系统；10：边缘系统；11：云系统；12：传感器；13：因特网；14：内部网；15：网络存储设备；16：边缘系统(从系统)；100：通信部；101：数据收集部；102：数据湖；103：应用；104：响应深度控制部；105：语义引擎；106：本体；107：语义引擎选择部；108：关联性判定部；109：结果扩展部；110：词表；111：本体获取部；112：记分部；200：通信部；201：本体提取部；202：本体；203：数据收集部；204：数据湖；205：语义引擎；300：通信部；301：数据获取部；400：通信部；401：语义引擎；402：本体；600：通信装置；601：处理器；602：存储装置；700：通信装置；701：处理器；702：存储装置；800：通信装置；801：处理器；802：存储装置；900：通信装置；901：处理器；902：存储装置；1000：深度确定表；2000：端点确定表。

具体实施方式

以下，使用图来说明本发明的实施方式。在以下的实施方式的说明和图中，附加了相同的符号的部分表示相同的部分或相当的部分。

实施方式1.

***结构的说明***

图1表示本实施方式所涉及的IoT系统1的结构例。

在本实施方式中，云系统11连接于因特网13。另外，多个边缘系统10连接于因特网13和内部网(Intranet)14。另外，多个传感器12连接于内部网14。

在本实施方式中，各边缘系统10代替云系统11来进行对于来自应用的语义的查询的响应。各边缘系统10的计算资源和存储容量少于云系统11的计算资源和存储容量。然而，通过以下所示的处理，边缘系统10能够对来自应用的语义的查询准确地进行响应。其结果，能够减轻负荷集中到云系统11的情况，而且能够消除通信延迟。

此外，由边缘系统10进行的动作相当于信息处理方法和信息处理程序。

图2表示边缘系统10的功能结构例。

边缘系统10经由内部网14收集由传感器12测量出的数据、或者由传感器12进行了统计处理等的已处理的数据。另外，边缘系统10根据需要经由因特网13访问云系统11，将数据积蓄在云系统11中。另外，边缘系统10还能够将处理的一部分委托给云系统11。

以后，将由传感器12测量出的数据、或者由传感器12进行了统计处理等的已处理的数据合称为测量数据。

边缘系统10是具有通信装置900、处理器901以及存储装置902来作为硬件的计算机。

另外，边缘系统10具有通信部100、数据收集部101、数据湖(data lake)102、应用103、响应深度控制部104、语义引擎(semantic engine)105以及本体106来作为功能结构。

通信部100接收来自传感器12的测量数据。

数据收集部101对测量数据赋予收集时刻等元数据。另外，数据收集部101如果有必要则对测量数据实施统计处理或标准化。然后，数据收集部101将由通信部100接收到的测量数据(或者是统计处理或标准化后的测量数据)保存到数据湖102中。

应用103将包含查询和响应深度的应用元数据输出到响应深度控制部104。

在此，响应深度是指用于得到应用所请求的结果的参数。也就是说，响应深度是对于语义引擎105的搜索的深度(以下还称为执行深度)的请求。例如，执行深度是执行语义引擎105的次数(递归次数)。也就是说，应用103能够将对于递归次数的请求指定为响应深度。另外，执行深度也可以是本体的父子关系的深度(在本体是树结构的情况下，从节点到根节点的边缘数)。父子关系的深度例如由在图23所示的深度确定表1000中规定的抽象度来表示。也就是说，应用103能够将对于图23所示的抽象度的级别(1、2、3等)的请求指定为响应深度。

响应深度控制部104获取包含查询和响应深度的应用元数据。

另外，响应深度控制部104向语义引擎105委托搜索。另外，响应深度控制部104使语义引擎105重复搜索，直到语义引擎105的搜索的深度达到响应深度为止。例如，响应深度控制部104进行执行语义引擎105的次数的调整。

响应深度控制部104相当于深度获取部和搜索控制部。另外，由响应深度控制部104进行的处理相当于深度获取处理和搜索控制处理。

语义引擎105具体是使用机器学习或/和RDF(Resource Description Framework：资源描述框架)的推理器等。语义引擎105也可以仅使用机器学习和RDF的一部分。另外，语义引擎105也可以将机器学习和RDF并行或串行地使用。

通过程序来实现数据收集部101、应用103、响应深度控制部104以及语义引擎105。由处理器901执行实现数据收集部101、应用103、响应深度控制部104以及语义引擎105的程序。

另外，也可以通过专用的硬件来实现数据收集部101、响应深度控制部104以及语义引擎105。

在图1中，示出通过程序来实现数据收集部101、应用103、响应深度控制部104以及语义引擎105、且由处理器901执行程序的例子。

通过通信装置900来实现通信部100。

数据湖102和本体106设置于存储装置902(包括存储器、辅助存储装置)内。此外，也可以通过专用的硬件来实现数据湖102和本体106。

***动作的说明***

图3表示本实施方式所涉及的边缘系统10的动作例。

首先，响应深度控制部104从应用103获取包含查询和响应深度的应用元数据(步骤S01)。

接着，响应深度控制部104从数据湖102和本体106获取机器学习所需的测量数据和推理器所需的Linked Data来作为输入数据(步骤S02)。

然后，响应深度控制部104将输入数据输出到语义引擎105。

接着，语义引擎105按照包含在应用元数据中的查询进行搜索(步骤S03)。

此外，语义引擎105也可以使用应用元数据和保存在数据湖102中的测量数据的元数据来进行搜索。具体地说，语义引擎105能够利用期间、传感器的设置场所等来缩减数据。另外，语义引擎105还能够使用上次的执行结果来递归地进行搜索。

在语义引擎105内使用RDF的情况下，为了降低Linked Data的加载负荷，也可以在边缘系统10启动时使响应深度控制部104预先读入Linked Data。

在执行语义引擎105之后，响应深度控制部104进行响应深度判定处理(步骤S04)。也就是说，响应深度控制部104判定语义引擎105的搜索的深度(递归次数、抽象度)是否达到响应深度。在响应深度判定处理的结果是继续进行处理的情况下(步骤S05中“是”)，重复进行获取输入数据(S02)以后的处理。另一方面，在不继续进行处理的情况下(步骤S05中“否”)，响应深度控制部104将语义引擎105的执行结果返回给应用103(步骤S06)。

图4表示响应深度判定处理(图3的步骤S04)的详情。

响应深度控制部104从应用元数据获取应用所请求的响应深度(步骤S601)。

接着，响应深度控制部104根据语义引擎105的执行结果或本体的父子关系的深度确定执行深度(步骤S602)。

如前所述，执行深度例如是语义引擎105的递归次数或图23中例示的抽象度。

在执行深度小于响应深度的情况下(步骤S603中“是”)，响应深度控制部104决定继续进行语义引擎105的处理(步骤S604)。

在执行深度为响应深度以上的情况下(步骤S603中“否”)，响应深度控制部104决定结束语义引擎105的处理(步骤S605)。

此外，即使语义引擎105的执行结果为多个，也针对各个执行结果独立地实施响应深度判定处理(图3的步骤S04)。

***实施方式的效果的说明***

这样，在本实施方式中，响应深度控制部104使语义引擎105重复搜索，直到语义引擎105的执行深度达到响应深度为止。因此，即使是计算资源和存储容量有限的边缘系统10，也能够与云系统11同样地对来自应用103的查询准确地进行响应。也就是说，在本实施方式中，能够以与应用103的请求相应的任意的响应深度(抽象度)进行响应。

另外，在本实施方式中，在内部网14上的边缘系统10中，IoT系统的大部分的功能进行动作。因此，根据本实施方式，即使在由于无法利用因特网13等原因而不能使用云系统11的状况下，也能够向应用103提供IoT系统的功能(可用性的提高)。

另外，在本实施方式中，不需要按每个应用103构建专用的IoT系统(成本的降低、开发的效率化)。

此外，在本实施方式中，用递归次数或抽象度进行了判定，但是也可以用在递归执行的过程中得到的结果的总数来判定递归处理的结束条件。并且，也可以根据是否得到了在实施方式7中叙述的记分结果的前n位(n为自然数)来判定递归处理的结束条件。此外，设为在应用元数据中记载使用哪个递归处理的结束条件。

实施方式2.

在本实施方式中，说明能够实现边缘系统的规模扩展或规模缩小((scalingdown)的结构。

在本实施方式中，主要说明与实施方式1的差异。

此外，以下未说明的事项与实施方式1同样。

***结构的说明***

图5表示本实施方式所涉及的IoT系统1的结构例。

在图5中，采用了容易实现的主从模型(master-slave model)。

在本实施方式中，在内部网14上新配置网络存储设备15和边缘系统(从系统)16。另外，在本实施方式中，表述为边缘系统(主系统)。

网络存储设备15不是必须的。但是，通过将边缘系统(主系统)10和边缘系统(从系统)16共同使用的测量数据保存在网络存储设备15中，测量数据的管理变得容易。

此外，边缘系统(从系统)16也可以是多个。

图6表示网络存储设备15、边缘系统(主系统)10、边缘系统(从系统)16的功能结构例。

在本实施方式中，在实施方式1中说明的数据收集部101和数据湖102不是配置于边缘系统(主系统)10，而是配置于网络存储设备15。另一方面，在边缘系统(主系统)10中追加语义引擎选择部107。

语义引擎选择部107根据应用的查询或者递归执行时的查询的域，选择语义引擎。更具体地说，语义引擎选择部107从边缘系统(主系统)10所包括的语义引擎105和边缘系统(从系统)16所包括的语义引擎401中选择进行搜索的语义引擎。然后，语义引擎选择部107使选择出的语义引擎进行搜索。

语义引擎选择部107例如基于图24所示的端点确定表2000，选择边缘系统(主系统)10的语义引擎105和边缘系统(从系统)16的语义引擎401中的任意语义引擎。在图24中，按每个查询的域(搜索的种类)定义了应该选择的语义引擎的端点URI(Uniform ResourceIdentifier：统一资源标识符)。语义引擎选择部107参照图24的端点确定表2000来选择与来自应用103的查询的域(domain)对应的语义引擎。此外，图24的端点确定表2000相当于选择基准信息。

语义引擎选择部107是例如通过程序来实现并由处理器901执行的。另外，也可以通过专用的硬件来实现语义引擎选择部107。

在网络存储设备15中，数据收集部101经由内部网14和通信部300收集传感器12的测量数据。数据收集部101将收集到的测量数据与实施方式1同样地保存到数据湖102中。

数据获取部301根据边缘系统(主系统)10或边缘系统(从系统)16的请求从数据湖102取出数据。另外，数据获取部301将取出的数据发送到边缘系统(主系统)10或边缘系统(从系统)16。

通过程序来实现数据收集部101和数据获取部301。由处理器701执行实现数据收集部101和数据获取部301的程序。

另外，也可以通过专用的硬件来实现数据收集部101和数据获取部301。

在图6中，示出通过程序来实现数据收集部101和数据获取部301并由处理器701执行程序的例子。

通过通信装置700来实现通信部300。

数据湖102设置于存储装置702(包括存储器、辅助存储装置)内。此外，也可以通过专用的硬件来实现数据湖102。

边缘系统(从系统)16基于来自边缘系统(主系统)10的查询，执行语义引擎401。然后，边缘系统(从系统)16将语义引擎401的执行结果返回给边缘系统(主系统)10。另外，边缘系统(从系统)16根据需要从网络存储设备15或本体402获取语义引擎401的执行所需的输入数据。

通过通信装置600来实现通信部400。

由处理器601执行语义引擎401。也可以通过专用的硬件来实现语义引擎401。

在图6中，表示由处理器601执行语义引擎401的例子。

本体402设置于存储装置602(包括存储器、辅助存储装置)内。此外，也可以通过专用的硬件来实现本体402。

***动作的说明***

图7表示本实施方式所涉及的边缘系统(主系统)10的动作例。

以下，仅说明与实施方式1的差异。

步骤S01与实施方式1同样，因此省略说明。

接着，语义引擎选择部107选择语义引擎(步骤S07)。

语义引擎选择部107选择了边缘系统(主系统)10内的语义引擎105(语义引擎105的端点URI)的情况下(步骤S08中“是”)，进行与实施方式1同样的处理(步骤S02～S06)。

另一方面，在语义引擎选择部107选择了边缘系统(从系统)16的语义引擎401(语义引擎401的端点URI)的情况下(步骤S08中“否”)，语义引擎选择部107对边缘系统(从系统)16的端点URI发出查询(步骤S09)。然后，语义引擎选择部107从边缘系统(从系统)16获取执行结果。

此外，虽然在图7中未图示，但是在语义引擎选择部107无法确定语义引擎的端点URI的情况下，语义引擎选择部107不执行该查询而跳过。或者，语义引擎选择部107将错误通知返回给应用103。

获取语义引擎的执行结果之后的处理与实施方式1同样(步骤S04～S06)。

图8表示图7的语义引擎选择处理(步骤S07)的详情。

语义引擎选择部107根据应用元数据或语义引擎的执行结果来生成本次执行的查询。然后，语义引擎选择部107确定该查询的域(步骤S701)。

接着，语义引擎选择部107在图24的端点确定表2000中确定与确定出的查询的域对应的语义引擎的端点URI(步骤S702)。

图9表示边缘系统(从系统)16的动作例。

更具体地说，图9表示针对在图7的步骤S09中发出的查询的处理过程。

首先，语义引擎401经由通信部400从边缘系统(主系统)10接收查询(S901)。

接着，语义引擎401获取需要的输入数据(步骤S902)。

在需要测量数据的情况下，语义引擎401向网络存储设备15的数据获取部301询问，得到测量数据。另外，在需要用于执行RDF的Linked Data的情况下，语义引擎401从本体402加载Linked Data。

然后，语义引擎401使用输入数据执行搜索(步骤S903)。

然后，语义引擎401经由通信部400将执行结果返回给边缘系统(主系统)10(步骤S904)。

此外，在规模扩展时，与边缘系统(从系统)16同等的边缘系统(从系统)被追加在内部网14上。之后，语义引擎选择部107对端点确定表2000追加记录新追加的边缘系统(从系统)所担当的查询的域和端点URI。

另一方面，在规模缩小时，从内部网14上排除删除对象的边缘系统(从系统)。语义引擎选择部107从端点确定表2000删除所排除的边缘系统(从系统)所担当的查询的域和端点URI。

此外，在本实施方式中，以主从模型类型为例进行了说明。但是，也可以利用使用如纯P2P那样的边缘系统的功能对称的雇工方式(servant)的模型。

另外，在本实施方式中，说明了使用配置于内部网14的边缘系统(从系统)16的例子。也可以取而代之地，在因特网13中配置边缘系统(从系统)16，使用配置于因特网13的边缘系统(从系统)16。

***实施方式的效果的说明***

以上，根据本实施方式，容易进行规模扩展和规模缩小。也就是说，根据本实施方式，能够容易地增强处理能力，另外，能够容易地削减处理能力。

另外，根据本实施方式，通过准备多台具有相同的功能的边缘系统(从系统)，能够实现冗余化，可用性提高。

实施方式3.

在本实施方式中，说明选择云系统的语义引擎的结构。

在本实施方式中，主要说明与实施方式2的差异。

此外，以下未说明的事项与实施方式2同样。

***结构的说明***

图10表示本实施方式所涉及的边缘系统10和云系统11的功能结构例。

边缘系统10的功能结构与实施方式1同样。

在云系统11中，数据收集部203从边缘系统10收集传感器12的测量数据。然后，数据收集部203将收集到的测量数据保存到数据湖204中。

边缘系统10能够选择向云系统11发送的测量数据。另外，边缘系统10也可以将向云系统11发送的测量数据通过设为统计值等来进行匿名化。

由处理器801执行数据收集部203和语义引擎205。

另外，也可以通过专用的硬件来执行数据收集部203和语义引擎205。

在图10中，表示由处理器801执行数据收集部203和语义引擎205的例子。

通过通信装置800来实现通信部200。

数据湖204和本体202设置于存储装置802(包括存储器、辅助存储装置)内。也可以通过专用的硬件来实现数据湖204和本体202。

***动作的说明***

本实施方式所涉及的边缘系统10的处理与实施方式2的边缘系统(主系统)10大致同样，因此仅说明差异。

语义引擎选择部107为了利用云系统11的语义引擎205，对图24的端点确定表2000追加记录语义引擎205所担当的查询的域和端点URI。

然后，语义引擎选择部107基于端点确定表2000，选择边缘系统10的语义引擎105和云系统11的语义引擎205中的任意语义引擎。

在云系统11中，语义引擎205在从边缘系统10接收到查询时，获取执行搜索所需的输入数据。

在需要测量数据的情况下，语义引擎205从数据湖204得到测量数据。

在需要用于执行RDF的Linked Data的情况下，语义引擎205从本体202加载LinkedData。

然后，语义引擎205使用输入数据执行搜索。

然后，语义引擎205经由通信部200将执行结果返回给边缘系统10。

***实施方式的效果的说明***

根据本实施方式，通过使资源丰富的云系统担当语义引擎的搜索处理的一部分，能够扩充对应用的响应变化。

另外，根据本实施方式，能够根据应用的请求来判断有没有使用云系统，因此能够避免负荷集中到云系统的情况。

实施方式4.

在本实施方式中，说明从语义引擎的执行结果去除与来自应用的查询的关联性低的结果来提高执行结果的精度的结构。

在本实施方式中，主要说明与实施方式1的差异。

此外，以下未说明的事项与实施方式1同样。

***结构的说明***

图11是本实施方式所涉及的边缘系统10的功能结构例。

仅说明与实施方式1的差异。

在图11中，关联性判定部108被追加在语义引擎105与响应深度控制部104之间。

关联性判定部108从响应深度控制部104获取对语义引擎105的查询。然后，关联性判定部108预测语义引擎105对获取到的查询的执行结果。然后，关联性判定部108判定预测出的执行结果是否与应用103所要求的执行结果一致。关联性判定部108在预测出的执行结果与应用103所要求的执行结果不一致的情况下，将该查询废弃。

另外，关联性判定部108获取语义引擎105的执行结果。将来自应用103的查询与语义引擎105的执行结果进行比较。然后，关联性判定部108判定在语义引擎105的执行结果中是否存在与查询不一致的执行结果。在语义引擎105的执行结果中存在与查询不一致的执行结果的情况下，关联性判定部108将与查询不一致的执行结果废弃。

关联性判定部108相当于查询废弃部和结果废弃部。

***动作的说明***

图12表示本实施方式所涉及的边缘系统10的动作例。

此外，以下，仅说明与实施方式1的差异。

步骤S01与实施方式1同样，因此省略说明。

接着，关联性判定部108实施对语义引擎105的查询的关联性判定(步骤S10)。

也就是说，关联性判定部108预测语义引擎105对查询的执行结果，在预测出的执行结果与应用103所要求的执行结果不一致的情况下，将该查询废弃。

步骤S02及步骤S03与实施方式1同样，因此省略说明。

接着，关联性判定部108实施语义引擎105的执行结果的关联性判定(步骤S11)。

也就是说，关联性判定部108在语义引擎105的执行结果中存在与查询不一致的执行结果的情况下，将与查询不一致的执行结果废弃。

图13表示关联性判定处理(查询)(图12的步骤S10)的详情。

关联性判定部108从响应深度控制部104获取应用元数据(步骤S1001)。

接着，关联性判定部108计算由语义引擎105输出的全部的应答的集合(输出集合)与应用元数据的相似度(步骤S1002)。

即，关联性判定部108预测由语义引擎105输出的全部的应答。接着，关联性判定部108计算预测出的全部的应答的各应答与应用元数据的相似度。

关联性判定部108例如如下计算相似度。

在此，考虑在应用元数据中作为查询包含有“室内的行动”。设作为语义引擎的输出集合，得到了“走过(室内的)走廊”、“(在外面)正在散步”以及“上楼梯”。关联性判定部108将欧几里德距离、相关函数、似然函数等用作相似度。在此，设关联性判定部108利用似然函数。

如下定义似然函数L。

在将P(A|B＝b)设为在发生了B＝b的情况下产生A的条件概率时，表示为L(b|A)＝∝P(A|B＝b)(∝是比例符号)。

“走过(室内的)走廊”的相似度为L(室内的行动|走过(室内的)走廊)>0。即，“走过(室内的)走廊”这样的现象作为室内的行动似乎是合理的。

同样地，L(室内的行动|(在外面)正在散步)＝0，L(室内的行动|上楼梯)＝1/2。“上楼梯”现象在室内和室外均有可能发生，因此为1/2。

接着，关联性判定部108针对全部的输出集合将相似度与阈值进行比较(步骤S1003)。

相似度为阈值以上的输出哪怕存在一个的情况下(步骤S1003中“是”)，关联性判定部108将查询输出到语义引擎105(步骤S1004)。

另一方面，在输出集合的相似度均小于阈值的情况下(步骤S1003中“否”)，关联性判定部108不将查询输出到语义引擎105，将查询排除(步骤S1005)。此时，关联性判定部1082向响应深度控制部104通知不存在有效的响应的意思。

图14表示关联性判定处理(执行结果)(图12的步骤S11)的详情。

关联性判定部108从响应深度控制部104获取应用元数据(步骤S1101)。

接着，关联性判定部108计算语义引擎105的执行结果与应用元数据的相似度(步骤S1102)。

关联性判定部108利用与图13的步骤S1002的计算方法同样的计算方法来计算相似度。

接着，关联性判定部108针对全部的执行结果将相似度与阈值进行比较(步骤S1103)。

在相似度小于阈值的情况下(步骤S1103中“否”)，关联性判定部108将对应的语义引擎执行结果排除(步骤S1104)。

另一方面，如果相似度为阈值以上(步骤S1103中“是”)，则关联性判定部108向响应深度控制部104输出执行结果。

***实施方式的效果的说明***

根据本实施方式，通过抑制不需要的递归处理，能够降低消耗资源。

另外，根据本实施方式，对应用的响应中噪声变少。

实施方式5.

在本实施方式中，说明通过词表(thesaurus)(同义词、相关词、联想词)来扩展语义引擎的执行结果的结构。通过语义引擎使用被扩展的执行结果来递归地执行搜索，能够增加执行结果的变化。

在本实施方式中，主要说明与实施方式1的差异。

此外，以下未说明的事项与实施方式1同样。

***结构的说明***

图15表示本实施方式所涉及的边缘系统10的功能结构例。

仅说明与实施方式1的差异。

在图15中，结果扩展部109被追加在语义引擎105与响应深度控制部104之间。

结果扩展部109获取语义引擎105的执行结果。然后，结果扩展部109使用词表110来扩展语义引擎105的执行结果。结果扩展部109将被扩展的执行计划返回给响应深度控制部104。

***动作的说明***

图16表示本实施方式所涉及的边缘系统10的动作例。

此外，以下，仅说明与实施方式1的差异。

步骤S01～S03与实施方式1同样，因此省略说明。

接着，结果扩展部109扩展语义引擎105的执行结果(步骤S12)。

其结果，递归执行时的向语义引擎105的输入的变化增加。

步骤S04～S06与实施方式1同样，因此省略说明。

图17表示结果扩展处理(图16的步骤S12)的详情。

结果扩展部109获取语义引擎105的执行结果(步骤S1201)。

接着，结果扩展部109使用词表110来确定从执行结果类推的同义词、相关词、联想词等(步骤S1202)。

然后，结果扩展部109将语义引擎105的执行结果和在步骤S1202中确定出的词输出到响应深度控制部104。

***实施方式的效果的说明***

根据本实施方式，通过防止因词的波动引起的推理的失察，向应用回答的结果的精度提高。

实施方式6.

在本实施方式中，说明从云系统获取边缘系统的语义引擎所使用的RDF的本体(Linked Data)和机器学习的模型数据的结构。通过从云系统获取本体(Linked Data)和模型数据，能够动态地控制语义引擎的行为。

在本实施方式中，主要说明与实施方式1的差异。

此外，以下未说明的事项与实施方式1同样。

***结构的说明***

图18表示本实施方式所涉及的边缘系统10和云系统11的功能结构例。

此外，在图18中，仅示出了与本体(Linked Data)和机器学习的模型数据的获取及提取有关的结构。

也就是说，在本实施方式所涉及的边缘系统10中，对实施方式1的结构追加了本体获取部111。另外，在本实施方式所涉及的云系统11中，对实施方式3的结构追加了本体提取部201。

在边缘系统10中，本体获取部111从云系统11获取语义引擎105所使用的本体(Linked Data)和机器学习的模型数据的至少某一个。

在云系统11中，本体提取部201基于来自边缘系统10的请求，提取语义引擎105所使用的本体(Linked Data)和机器学习的模型数据的至少某一个。然后，本体提取部201将提取出的本体(Linked Data)或/和模型数据发送到边缘系统10。

***动作的说明***

图19表示本实施方式所涉及的边缘系统10的动作例。

此外，以下说明本体获取部111接收Linked Data和模型数据的例子，但是本体获取部111也可以仅接收Linked Data和模型数据的某一方。另外，如果是语义引擎105所使用的数据，则本体获取部111也可以接收Linked Data、模型数据以外的数据。

首先，本体获取部111获取应用元数据(步骤S11101)。

接着，本体获取部111向云系统11发送用于获取Linked Data和模型数据的查询(步骤S11102)。该查询中包含有应用元数据。

接着，本体获取部111从云系统11接收Linked Data和模型数据，另外，将接收到的Linked Data和模型数据保存到本体106中(步骤S11103)。

图20表示本实施方式所涉及的云系统11的动作例。

此外，以下说明本体提取部201提取Linked Data和模型数据的例子，但是本体提取部201也可以仅提取Linked Data和模型数据的某一方。另外，如果是语义引擎105所使用的数据，则本体提取部201也可以提取Linked Data、模型数据以外的数据。

首先，本体提取部201从边缘系统10接收查询，从查询提取应用元数据(步骤S20101)。

接着，本体提取部201基于应用元数据的信息，从本体202提取符合条件的LinkedData和模型数据(步骤S20102)。

具体地说，本体提取部201利用应用的域(例如人的行动、疾病的种类、设备的动作等)或统计信息(其它相似的应用的到目前为止的使用实绩等)，来缩减符合条件的LinkedData和模型数据。此外，本体提取部201在提取Linked Data的情况下，也可以从LinkedData去掉不需要的链接。此时，本体提取部201也可以使用机器学习、统计信息等来判定是否需要链接。

接着，本体提取部201将提取出的Linked Data和模型数据返回给边缘系统10(步骤S20103)。

***实施方式的效果的说明***

根据本实施方式，能够适当地更新边缘系统的本体。因此，根据本实施方式，能够提高向应用输出的执行结果的精度。

另外，根据本实施方式，能够利用云系统来统一管理本体。因此，根据本实施方式，能够将知识转用于其它边缘系统上的相似的应用。其结果，能够从其它边缘系统的运行的初期起提高语义引擎的执行结果的精度。

实施方式7.

在本实施方式中，说明对语义引擎的执行结果设定优先顺序的结构。其结果，应用能够识别执行结果中的重要度。

在本实施方式中，主要说明与实施方式1的差异。

此外，以下未说明的事项与实施方式1同样。

***结构的说明***

图21表示本实施方式所涉及的边缘系统10的功能结构例。

仅说明与实施方式1的差异。

在图21中，记分部112被追加在响应深度控制部104与应用103之间。

记分部112对语义引擎105的执行结果设定优先顺序。更具体地说，记分部112基于语义引擎105的推理过程，对语义引擎105的执行结果设定优先顺序。

此外，在图21中，仅图示了说明记分部112所需的结构。

***动作的说明***

接着，说明记分部112的动作。

图22是在语义引擎105的RDF中使用的Linked Data的例子。

Linked Data(链接数据)3000包括作为主语和宾语的至少某一个的节点3001、3003、3004、3005、3006、3007和将节点连接的谓语3002的有向图。

设为在语义引擎105的第一次的执行中，根据测量数据并通过机器学习推理出节点3001，进一步通过RDF推理出节点3003、3004。设为在语义引擎105的第二次的执行中，推理出节点3005、3006、3007。记分部112按每个节点记录在推理时经过了哪个节点。在图22的例子中，针对节点3001、3003、3004、3006、3007分别记录1次的经过，针对节点3005记录2次的经过。

记分部112将经过次数作为分数来处理。然后，记分部112按分数从高到低的顺序对语义引擎105的执行结果设定优先顺序。并且，记分部112将优先顺序高的执行结果优先提示给应用。在上述的例子中，节点3005的优先顺序最高。节点3001、3003、3004、3006、3007的优先顺序全部相同。

***实施方式的效果的说明***

根据本实施方式，能够利用推理的过程的信息实施记分，因此能够确认结果的正当性。

另外，根据本实施方式，应用容易判断哪个执行结果是重要的。

***硬件结构的说明***

最后，进行边缘系统10的硬件结构的补充说明。

处理器901是进行处理的IC(Integrated Circuit：集成电路)。

处理器901是CPU(Central Processing Unit：中央处理单元)、DSP(DigitalSignal Processor：数字信号处理器)等。

存储装置902是RAM(Random Access Memory：随机存取存储器)、ROM(Read OnlyMemory：只读存储器)、快闪存储器、HDD(Hard Disk Drive：硬盘驱动器)等。

通信装置900是执行数据的通信处理的电子电路。

通信装置900例如是通信芯片或NIC(Network Interface Card：网络接口卡)。

另外，在存储装置902中还存储有OS(Operating System：操作系统)。

而且，由处理器901执行OS的至少一部分。

处理器901一边执行OS的至少一部分，一边执行实现数据收集部101、应用103、响应深度控制部104、语义引擎105、语义引擎选择部107、关联性判定部108、结果扩展部109、本体获取部111、记分部112的功能的程序。

通过由处理器901执行OS，进行任务管理、存储器管理、文件管理、通信控制等。

另外，表示数据收集部101、应用103、响应深度控制部104、语义引擎105、语义引擎选择部107、关联性判定部108、结果扩展部109、本体获取部111、记分部112的处理的结果的信息、数据、信号值以及变量值的至少某一个被存储在存储装置902、处理器901内的寄存器以及高速缓冲存储器的至少某一个。

另外，实现数据收集部101、应用103、响应深度控制部104、语义引擎105、语义引擎选择部107、关联性判定部108、结果扩展部109、本体获取部111、记分部112的功能的程序也可以被保存在磁盘、软盘、光盘、高密度磁盘、蓝光(注册商标)盘、DVD等可移动记录介质。然后，也可以使保存有实现数据收集部101、应用103、响应深度控制部104、语义引擎105、语义引擎选择部107、关联性判定部108、结果扩展部109、本体获取部111、记分部112的功能的程序的可移动记录介质在商业上流通。

另外，也可以将数据收集部101、响应深度控制部104、语义引擎选择部107、关联性判定部108、结果扩展部109、本体获取部111、记分部112的“部”改读为“电路”或“工序”或“过程”或“处理”。

另外，也可以通过处理电路来实现边缘系统10。处理电路例如是逻辑IC(Integrated Circuit：集成电路)、GA(Gate Array：门阵列)、ASIC(Application SpecificIntegrated Circuit：专用集成电路)、FPGA(Field-Programmable Gate Array：现场可编程门阵列)。

此外，在本说明书中，将处理器与处理电路的上位概念称为“处理线路(processing circuitry)”。

也就是说，处理器和处理电路分别是“处理线路”的具体例。