信息处理系统、信息处理方法及计算机可读介质与流程

1.本公开涉及信息处理系统、信息处理方法及计算机可读介质。


背景技术：

2.在文档的管理系统中，有时能够由用户赋予任意的属性名。在该情况下，属性名的自由度高，因此，由于用户的差异等，在属性名中容易出现表述不一致，相似的属性名有时会杂乱。例如通过手动作业或者由管理系统替换为其他属性名，来消除该表述不一致。此外，作为关联技术文献，例如举出日本特开2008-310626号公报。


技术实现要素：

3.虽然通过属性名的替换消除了表述不一致，但如果导致替换前的属性名消失，则可能引起如下情况：即便不知道属性名被替换的用户用自己赋予的属性名检索文档，也无法找到设想的文档。
4.本公开的目的在于，即便在汇集为相似的属性的代表值之后，也能够进行使用了汇集前的属性的检索。
5.根据本公开的第1方案，提供一种信息处理系统，其中，所述信息处理系统具有处理器，所述处理器进行如下处理：受理对文档赋予的属性的输入作为检索文档的检索关键字，在作为在要素中包含含义相似的多个第1属性的集合的代表值而设定有第2属性的情况下，当在受理到的检索关键字中包含该第1属性时，使用该第1属性所属的集合的代表值来检索文档。
6.根据本公开的第2方案，所述处理器检索被赋予了作为在要素中包含所述第1属性的集合的代表值的所述第2属性的文档。
7.根据本公开的第3方案，所述第2属性是以在文档的层级管理中使用的目录为单位而被赋予的。
8.根据本公开的第4方案，提供一种信息处理系统，其中，所述信息处理系统具有处理器，所述处理器进行如下处理：受理对文档赋予的属性的输入作为检索文档的检索关键字，在作为在要素中包含含义相似的多个第1属性的集合的代表值而设定有第2属性的情况下，当在受理到的检索关键字中包含该第1属性时，使用该第1属性所属的集合的全部要素来检索文档。
9.根据本公开的第5方案，所述处理器检索被赋予了在要素中包含所述第1属性的集合的全部要素中的任意要素的文档。
10.根据本公开的第6方案，所述第1属性由用户赋予。
11.根据本公开的第7方案，在以在文档的层级管理中使用的目录为单位而赋予所述第2属性的情况下，所述处理器生成对属于所述目录的文档赋予的含义相似的所述第1属性的集合和提供该集合的代表值的所述第2属性。
12.根据本公开的第8方案，所述处理器在所述集合的要素存在变化的情况下，更新所
述第1属性与所述第2属性的关联。
13.根据本公开的第9方案，所述处理器在用户对文档赋予所述第1属性的情况下，基于使用频度的历史来提示所述第2属性。
14.根据本公开的第10方案，所述处理器按照检索关键字的使用频度从高到低的顺序提示所述第1属性。
15.根据本公开的第11方案，所述处理器在存在属于作为所述集合的第1集合和第2集合双方的所述第1属性的情况下，按照预先决定的规则更新该第1属性与所述第2属性的关联。
16.根据本公开的第12方案，所述处理器在所述第1集合整体包含于所述第2集合的情况下，将提供该第1集合的代表值的所述第2属性追加到该第2集合的要素中。
17.根据本公开的第13方案，所述处理器在所述第1集合的一部分与所述第2集合的一部分重复且一方不包含另一方的情况下，将重复部分的所述第1属性设定为要素数量较少的一方的集合的要素。
18.根据本公开的第14方案，所述处理器在所述第1集合的一部分与所述第2集合的一部分重复且一方不包含另一方的情况下，将重复部分的所述第1属性设定为对应的文档所属的目录更下位的集合的要素。
19.根据本公开的第15方案，提供一种计算机可读介质，其存储有使计算机执行处理的程序，其中，所述处理具有如下步骤：受理对文档赋予的属性的输入作为检索文档的检索关键字；以及在作为在要素中包含含义相似的多个第1属性的集合的代表值而设定有第2属性的情况下，当在受理到的检索关键字中包含该第1属性时，使用该第1属性所属的集合的代表值来检索文档。
20.根据本公开的第16方案，提供一种计算机可读介质，其存储有使计算机执行处理的程序，其中，所述处理具有如下步骤：受理对文档赋予的属性的输入作为检索文档的检索关键字；以及在作为在要素中包含含义相似的多个第1属性的集合的代表值而设定有第2属性的情况下，当在受理到的检索关键字中包含该第1属性时，使用该第1属性所属的集合的全部要素来检索文档。
21.根据本公开的第17方案，提供一种信息处理方法，其中，所述信息处理方法具有如下步骤：受理对文档赋予的属性的输入作为检索文档的检索关键字；以及在作为在要素中包含含义相似的多个第1属性的集合的代表值而设定有第2属性的情况下，当在受理到的检索关键字中包含该第1属性时，使用该第1属性所属的集合的代表值来检索文档。
22.发明的效果
23.根据所述第1方案，即便在汇集为相似的属性的代表值之后，也能够执行使用了汇集前的属性的检索。
24.根据所述第2方案，即便在提供第1属性作为检索关键字的情况下，也能够检索与第1属性所属的集合关联的全部的文档。
25.根据所述第3方案，能够提高利用检索关键字检索的文档与目录的关联性。
26.根据所述第4方案，即便在汇集为相似的属性的代表值之后，也能够执行使用了汇集前的属性的检索。
27.根据所述第5方案，即便在提供第1属性作为检索关键字的情况下，也能够检索与
第1属性所属的集合关联的全部的文档。
28.根据所述第6方案，即便使用设想表述不一致的第1属性，也能够检索关联的文档。
29.根据所述第7方案，能够不需要由用户赋予第2属性。
30.根据所述第8方案，能够降低与第1属性与第2属性的关联的更新相伴的处理负荷。
31.根据所述第9方案，能够减少用户赋予的第1属性的表述不一致。
32.根据所述第10方案，能够减少用户赋予的第1属性的表述不一致。
33.根据所述第11方案，能够不由于集合间的关系而使作为检索结果而输出的文档数量过于增加。
34.根据所述第12方案，在提供第1集合所包含的第1属性作为检索关键字的情况下，能够将作为检索结果而输出的文档限制为与第1集合关联的文档。
35.根据所述第13方案，在提供第1集合所包含的第1属性作为检索关键字的情况下，能够缩减作为检索结果而输出的文档数量。
36.根据所述第14方案，在提供第1集合所包含的第1属性作为检索关键字的情况下，能够缩减作为检索结果而输出的文档数量。
37.根据所述第15方案，即便在汇集为相似的属性的代表值之后，能够执行使用了汇集前的属性的检索。
38.根据所述第16方案，即便在汇集为相似的属性的代表值之后，能够执行使用了汇集前的属性的检索。
39.根据所述第17方案，即便在汇集为相似的属性的代表值之后，能够执行使用了汇集前的属性的检索。
附图说明
40.图1是概要地示出在实施方式1中使用的文档管理系统的整体结构的例子的图。
41.图2是说明在实施方式1中使用的共享服务器的硬件结构的一例的图。
42.图3是说明由处理器实现的功能的一部分的图。
43.图4是说明文档db的结构例的图。
44.图5是说明存储于属性组db的属性组的例子的图。
45.图6是示出属性组的构造例的图。
46.图7是说明在实施方式1中使用的共享服务器所执行的处理动作中的与属性组的登记相关的处理动作的一例的流程图。
47.图8是说明实施方式1中的分组处理后的文件夹与属性组的关系的图。
48.图9是说明在实施方式1中使用的共享服务器所执行的处理动作中的与文档的检索相关的处理动作的一例的流程图。
49.图10是说明实施方式1的执行检索的过程的一例的图。
50.图11是说明在实施方式2中使用的共享服务器所执行的与属性组的登记相关的处理动作中的分组处理的一例的流程图。
51.图12是说明实施方式2中的分组处理的中途阶段的状态的图。
52.图13是说明实施方式2中的分组处理完成后的状态的图。
53.图14是说明在实施方式2中使用的共享服务器所执行的处理动作中的与文档的检
memory：随机存取存储器)、存储bios(＝basic input/output system：基本输入输出系统)等的rom(＝read only memory：只读存储器)。
76.在本实施方式中设想的图像形成装置除了具备在纸张上打印图像的功能之外，还具备以光学的方式读取原稿等的图像的功能和执行传真通信的功能。这种图像形成装置也被称为复合机。另外，针对图像形成装置所罗列的功能只不过是一例，不妨碍具备其他功能。
77.此外，对于储存器，使用硬盘装置或能够改写的非易失性的半导体存储器。
78.在图1中描绘出多台用户终端20，但用户终端20也可以为1台。
79.共享服务器30提供支援文档的共享的云服务。在图1的情况下，共享服务器30为1台，但物理上也可以由多台服务器构成。例如共享服务器30也可以构成为所谓的云服务器。不过，共享服务器30也可以是内部部署型的服务器。
80.本实施方式中的共享服务器30是信息处理系统的一例。
81.＜共享服务器的结构＞
82.图2是说明在实施方式1中使用的共享服务器30的硬件结构的一例的图。
83.共享服务器30具有控制装置整体的动作的处理器31、半导体存储器32、硬盘装置33、以及通信模块34。它们通过信号线或总线而连接。
84.处理器31通过执行程序而实现各种功能。本实施方式中的处理器31例如提供使用了属性名的文档的检索服务。
85.半导体存储器32例如由rom和ram构成。ram是主存储装置的一例。
86.这里的处理器31和半导体存储器32构成所谓的计算机。
87.通信模块34例如是以太网(注册商标)模块、无线lan用的模块、第五代移动通信系统(即5g)用的模块。
88.硬盘装置33是辅助存储装置的一例，例如存储操作系统和应用程序。不过，也可以代替硬盘装置33而使用大容量的半导体存储器。
89.在本实施方式的硬盘装置33中，存储有用于存储作为共享对象的文档的文档数据库(以下称为“文档db”)331、以及对赋给各文档的属性中的含义相似的属性名的集合进行管理的属性组的数据库(以下称为“属性组db”)332。
90.属性名在对应的属性值这一组中使用。属性名是属性的一例。
91.属性名提供属性的性质或种类。在属性名中例如具有“文件名”、“制作者”、“制作日”、“发送目的地”、“承认状况”。
92.属性值是与属性名对应的具体值。在属性值中例如具有“abc提议书”、“富士太郎”、“2020/08/30”、“xyz系统”、“已承认”。
93.本实施方式中的属性组db 332是对含义相似的属性名的集合进行管理的数据库。由于用户能够输入自由词作为属性名而出现多个含义相似的属性名。在含义相似的属性名中有时表述不一致。另外，含义的相似不限于表现的相似或通用词典中的记载，也包含将特定行业或特定业界中的共同知识作为前提的相似。
94.对构成属性组db 332的各个属性组赋予属性名的代表值。
95.在本实施方式的情况下，属性组db 332在从文档db 331检索文档时被使用。在本实施方式的情况下，将成为按层级管理文档时的文档存放处的目录作为单位来管理相似的
属性名。
96.图3是说明由处理器31实现的功能的一部分的图。在图3中，作为处理器31实现的功能的一部分，表示出属性赋予部311、属性组管理部312、登记完成通知部313、检索受理部314、以及检索执行部315。这些功能通过处理器31执行程序而实现。
97.属性赋予部311实现按照来自用户终端20(参照图1)的指示而向共享服务器30(参照图1)所存储的文档赋予属性名的功能。
98.属性名能够由操作用户终端20的用户自由地指定。因此，产生表述不一致。在本实施方式的情况下，对1个文档赋予的属性名的数量没有设置限制。
99.也能够通过操作系统或应用程序来对文档赋予属性名。
100.属性组管理部312是管理对文档db 331(参照图2)所存储的文档赋予的属性名中的含义相似的属性名的集合(以下也称为“属性组”)的功能。
101.属性组可以由用户手动地生成，也可以由操作系统或应用程序按照预先决定的规则而生成。属性组管理部312例如按照预先决定的日程等而生成属性组。
102.在本实施方式的情况下，以文件夹(即目录)为单位而生成属性组。即，在本实施方式中，将1个层级的文件夹作为单位，但也能够将处于父子关系或兄弟关系的多个文件夹作为单位。不过，也可以与父子关系等无关地管理属性组。这里的父子关系是指在文档的管理中使用树结构的情况下的上位节点与下位节点的关系。一方，兄弟关系是指具有共同的上位节点的多个下位节点的关系。
103.本实施方式中的属性组db 332具有将属性组、属性组的代表值以及对应于属性组的文件夹的位置对应起来的无模式(schemaless)构造。
104.登记完成通知部313实现在属性名的分组完成的情况下发布促使用户确认处理结果的通知的功能。
105.检索受理部314实现受理共享服务器30(参照图1)所存储的文档的检索的功能。检索查询从用户终端20(参照图1)被提供。检索查询中例如包含1个或多个检索词。本实施方式中的检索词是属性名。检索词是检索关键字的一例。
106.检索受理部314也从用户终端20取得确定指示执行检索的用户的信息、指示了执行检索的日期时间、检索查询的信息等并进行存储。
107.检索执行部315实现检索满足所指定的检索查询的文档并将检索的结果向用户终端20输出的功能。
108.＜文档db的例子＞
109.图4是说明文档db 331(参照图2)的结构例的图。本实施方式中使用的文档db 331与对应于树结构的节点的文件夹关联地存储文档。
110.在各文件夹附加有识别用的id(＝identifier：标识符)。
111.在图4的情况下，位于根目录的文件夹的id是“001”，与其子节点相对应的文件夹的id是“0011”。
112.位于根目录的文件夹是不具有父节点的文件夹。子节点的文件夹是位于根目录的文件夹的下位的文件夹。在图4中，子节点处于从根目录数起第1个层级，但也可以处于第若干个层级。此外，在图4中，子节点为1个，但子节点也可以为多个。
113.在本实施方式的情况下，识别用的id例如用于与属性组的关联。
114.在图4的情况下，在由识别用的id“0011”确定的文件夹中存储有多个文档。在图4中，作为多个文档的一例而例示出文档a、文档b、文档c。
115.另外，在文档a中，作为属性名而赋予了“制作者”和“已经承认”。
116.这里，与“制作者”对应的属性值是“x先生/女士”。此外，与“已经承认”对应的属性值是“true”。“true”表示已经承认的状态。
117.在文档b中，作为属性名而赋予了“制作者”和“已承认”。这里，与制作者对应的属性值是“y先生/女士”。在文档b中y先生/女士赋予的属性名的“已承认”与在文档a中x先生/女士赋予的属性名的“已经承认”的含义相同，但表述不同。“已承认”与“已经承认”是表述不一致的一例。在文档b的情况下，与“已承认”对应的属性值是“false”。“false”表示没有承认的状态。
118.在文档c中，作为属性名而赋予了“制作者”和“完成”。这里，与制作者对应的属性值是“y先生/女士”。在文档c中y先生/女士赋予的属性名的“完成”也与在文档a中x先生/女士赋予的属性名的“已经承认”以及在文档b中y先生/女士赋予的属性名的“已承认”为相同的含义，但表述不同。“已经承认”、“已承认”以及“完成”均是含义相似的属性名的一例。
119.此外，与“完成”对应的属性值是“false”。
120.在图4的例子中，仅表示出被赋予含义相似的属性名的文档，但属于相同文件夹的属性名不一定全部相似。例如“制作者”与“已经承认”的含义不相似。
121.此外，在图4的例子中，对各文档赋予了2个属性名，但所赋予的属性名的数量也可以为1个，还可以为3个以上。
122.＜属性组db的例子＞
123.图5是说明存储于属性组db 332(参照图2)的属性组的例子的图。
124.图5所示的属性组表示对属于图4所示的文件夹id“0011”的文档赋予的属性名中的含义相似的属性名的集合。因此，在属性组中，包含上述的“已经承认”、“已承认”以及“完成”作为要素。“已经承认”、“已承认”以及“完成”是第1属性的一例。
125.此外，在图5的情况下，作为属于相同属性组的3个属性名的代表值而指定了“已承认”。作为代表值的“已承认”是第2属性的一例。在图5的情况下，代表值与作为要素的1个属性名相同，但不一定与作为要素的属性名相同。
126.在本实施方式的情况下，代表值由用户指定。不过，也能够由操作系统或应用程序提供代表值。
127.图6是示出属性组的构造例的图。图6的例子表示代表值为“已承认”的属性组。
128.在图6的情况下，作为属于属性组的属性名而例示出“已承认”、“已经承认”、“完成”。此外，作为属性组，将更新标志设定为“true”。
129.本实施方式中的更新标志表示是否需要执行分组处理。
[0130]“true”表示需要执行分组处理，例如用于变更了代表值的情况、作为要素的属性名的数量进行了增减的情况、在作为要素的属性名的内容中存在变更的情况。换言之，在属性组中存在变化的情况下，将更新标志设定为“true”。
[0131]
在本实施方式的情况下，例如如每日上午1点那样定期地执行属性组的管理。当分组处理结束后，将更新标志从“true”变更为“false”。
[0132]
更新标志为“true”的属性组成为属性组管理部312所进行的分组处理的对象。在
分组处理中，将属性名所属的属性组与被赋予作为要素的属性名的文档关联起来。另一方面，更新标志为“false”的属性组从属性组管理部312所进行的分组处理的对象中排除。
[0133]
＜处理动作＞
[0134]
＜属性组的登记＞
[0135]
图7是说明在实施方式1中使用的共享服务器30(参照图1)所执行的处理动作中的与属性组的登记相关的处理动作的一例的流程图。图中所示的记号s是指步骤。
[0136]
另外，图7所示的处理动作由处理器31(参照图2)执行。
[0137]
处理器31将属性组和其代表值登记于属性组db 332(参照图2)(步骤1)。
[0138]
在本实施方式的情况下，属性组的代表值和作为属性组的要素的属性名由利用服务的用户或具有登记的权限的管理者(以下称为“用户等”)指定。
[0139]
在这里的登记中，不仅包括新的登记，还包括对现有的属性组的变更。
[0140]
接着，处理器31判定作为处理对象的文件夹的各文档的属性名是否属于属性组(步骤2)。
[0141]
在文档的属性名不包含于在步骤1中登记的属性组的要素的情况下，处理器31在步骤2中得到否定结果。另一方面，在文档的属性名包含于在步骤1中登记的属性组的要素的情况下，处理器31在步骤2中得到肯定结果。
[0142]
在步骤2中得到否定结果的情况下，处理器31通过登记完成通知部313的功能，对用户终端20(参照图1)通知登记的完成(步骤4)。
[0143]
另一方面，在步骤2中得到肯定结果的情况下，处理器31通过属性组管理部312的功能执行分组处理(步骤3)，之后，通知登记的完成(步骤4)。
[0144]
在本实施方式的分组处理中，进行属性组与将其要素包含在属性名中的文档的文件夹的关联。通过将属性组与文件夹关联，在提供属性组的要素即属性名中的任意一个属性名作为检索查询的情况下，具有作为属性组的要素的属性名的文档包含在检索结果中。
[0145]
在本实施方式中，如图6所示，执行了属性组与文件夹id的关联。
[0146]
在本实施方式中，1个属性组与1个文件夹被关联，但也能够与多个文件夹关联。
[0147]
图8是说明实施方式1中的分组处理后的文件夹与属性组的关系的图。在图8中，针对与图4的对应部分标注对应的标号而示出。
[0148]
在图8的情况下，文件夹id为“0011”的文件夹与属性组的“已承认”组被关联。在组名中，使用作为代表值的“已承认”。
[0149]
在“已承认”组中，在要素中包含对与文件夹id为“0011”的文件夹关联的文档a、文档b及文档c赋予的属性名的“已经承认”、“已承认”、“完成”。
[0150]
＜文档的检索＞
[0151]
图9是说明在实施方式1中使用的共享服务器30(参照图1)所执行的处理动作中的与文档的检索相关的处理动作的一例的流程图。图中所示的记号s是指步骤。
[0152]
在文档的检索中，用户操作用户终端20(参照图1)，输入检索查询。所输入的检索查询被提供给共享服务器30。
[0153]
收到检索查询的处理器31(参照图2)从用户输入的检索查询中提取检索词(步骤11)。
[0154]
接着，处理器31判定是否存在在要素中包含检索词的属性组(步骤12)。例如判定
提取出的检索词是否包含在上述的“已承认”组中。也可以存在多个成为判定对象的属性组。
[0155]
在步骤12中得到肯定结果的情况下，处理器31生成使用了属性组的新的检索查询(步骤13)。在本实施方式中，处理器31生成并列地罗列了属于属性组的属性名的新的检索查询。
[0156]
在步骤13结束之后或者在步骤12中得到否定结果之后，处理器31执行基于检索查询的检索(步骤14)。
[0157]
图10是说明实施方式1的执行检索的过程的一例的图。
[0158]
如上所述，首先，提取检索词。在图10中，提取出“已经承认”。
[0159]
接着，检索包含提取出的“已经承认”的属性组。这里，发现“已承认”组。“已承认”组的要素为“已承认”、“已经承认”以及“完成”这3个要素。
[0160]
因此，检索查询被改写为“已承认”或“已经承认”或“完成”。
[0161]
结果是，当使用改写后的检索查询时，不仅被赋予“已经承认”这一属性名的文档a包含在检索结果中，被赋予含义相似的属性名的文档b和文档c也包含在检索结果中。
[0162]
如以上那样，在由不确定的用户自由地赋予了属性名的文档成为检索对象的情况下，即便不知道含义相似的属性名的全部，用户也能够仅通过指定自身知晓的属性名而取得关联的文档作为检索结果。
[0163]
＜实施方式2＞
[0164]
在上述实施方式中，设想了文档db 331(参照图2)所存储的文档的属性名保持登记时的属性名不变的情况，但在本实施方式中，针对将属性组的代表值追加到关联的各文档的属性名的情况进行说明。
[0165]
＜属性组的登记＞
[0166]
图11是说明在实施方式2中使用的共享服务器30(参照图1)所执行的与属性组的登记相关的处理动作中的分组处理的一例的流程图。在图11中，针对与图7的对应部分标注对应的标号而示出。
[0167]
另外，分组处理以外的处理动作与图7的处理动作相同。
[0168]
图11所示的分组处理是步骤3a。步骤3a是在步骤2(参照图7)中得到肯定结果的情况下执行的。
[0169]
首先，处理器31判定对文档赋予的属性名是否与属性组的代表值相同(步骤31)。在相同的情况下，在步骤31中得到肯定结果，在不同的情况下，在步骤31中得到否定结果。
[0170]
针对在步骤31中得到肯定结果的文档，处理器31无需进行本实施方式中的分组处理。因此，处理器31针对相符的文档进入步骤4。
[0171]
另一方面，针对在步骤31中得到否定结果的文档，处理器31判定在1个文档内是否存在属于多个属性组的属性名(步骤32)。
[0172]
在步骤32中得到否定结果的情况下，处理器31向作为对象的文档的属性名追加代表值(步骤33)。由此，文档与特定的属性组关联。
[0173]
另一方面，在步骤32中得到肯定结果的情况下，处理器31向用户通知未进行分组处理(步骤34)。在该情况下，用户单独地研究对文档赋予的属性名。
[0174]
图12是说明实施方式2中的分组处理的中途阶段的状态的图。在图12中，针对与图
8的对应部分标注对应的标号而示出。
[0175]
在图12的情况下，“已承认”组与文件夹id为“0011”的文件夹被关联。另外，示出“已承认”组的更新标志为“true”，为分组处理的对象。在图12的阶段，不存在“已承认”组与文档的关联。
[0176]
图13是说明实施方式2中的分组处理完成后的状态的图。在图13中，针对与图12的对应部分标注对应的标号而示出。
[0177]
在图13的情况下，针对被赋予与“已承认”组的代表值相同的属性名的文档b以外的文档a和文档c，追加作为代表值的“已承认”。结果是，成为在被赋予含义相似的属性名的文档中包含属性组的代表值的状态。
[0178]
＜文档的检索＞
[0179]
图14是说明在实施方式2中使用的共享服务器30(参照图1)所执行的处理动作中的与文档的检索相关的处理动作的一例的流程图。在图14中，针对与图9的对应部分标注对应的标号而示出。
[0180]
在本实施方式的情况下，用户也操作用户终端20(参照图1)，输入检索查询。
[0181]
收到检索查询的处理器31(参照图2)从用户输入的检索查询中提取检索词(步骤11)。
[0182]
接着，处理器31判定是否存在在要素中包含检索词的属性组(步骤12)。例如判定提取出的检索词是否包含在上述的“已承认”组中。也可以存在多个成为判定对象的属性组。
[0183]
在步骤12中得到肯定结果的情况下，处理器31生成使用了属性组的代表值的新的检索查询(步骤13a)。
[0184]
在本实施方式的情况下，如果检索查询的检索词与属性组的代表值相同，则直接使用所输入的检索词，但在检索查询的检索词与属性组的代表值不同时，将检索词改写为代表值。
[0185]
在步骤13a结束之后或者在步骤12中得到否定结果之后，处理器31执行基于检索查询的检索(步骤14)。
[0186]
图15是说明实施方式2的执行检索的过程的图。
[0187]
如上所述，首先，提取检索词。在图15中，提取出“已经承认”。
[0188]
接着，检索包含提取出的“已经承认”的属性组。这里，发现“已承认”组。“已承认”组的要素为“已承认”、“已经承认”以及“完成”这3个要素。
[0189]
在本实施方式的情况下，检索查询被改写为作为“已承认”组的代表值的“已承认”。
[0190]
结果是，当使用改写后的检索查询时，不仅被赋予“已经承认”这一属性名的文档a包含在检索结果中，被赋予含义相似的属性名的文档b和文档c也包含在检索结果中。这是因为，在本实施方式的情况下，在各文档的属性名中包含“已承认”。
[0191]
如以上那样，在由不确定的用户自由地赋予了属性名的文档成为检索对象的情况下，即使不知道含义相似的全部属性名，用户也能够仅通过指定自身知晓的属性名而取得关联的文档作为检索结果。
[0192]
另外，本实施方式的情况也如实施方式1的情况那样，也能够使用“已承认”组的要
素包含“已承认”、“已经承认”以及“完成”这3个要素的检索查询来执行检索。
[0193]
＜实施方式3＞
[0194]
在本实施方式中，针对通过属性组的代表值来替换各文档的属性名的情况进行说明。本实施方式相当于实施方式2的变形例。
[0195]
＜属性组的登记＞
[0196]
图16是说明在实施方式3中使用的共享服务器30(参照图1)所执行的与属性组的登记相关的处理动作中的分组处理的一例的流程图。在图16中，针对与图11的对应部分标注对应的标号而示出。
[0197]
另外，分组处理以外的处理动作与图7的处理动作相同。
[0198]
图16所示的分组处理是步骤3b。步骤3b是在步骤2(参照图7)中得到肯定结果的情况下执行的。
[0199]
首先，处理器31判定对文档赋予的属性名是否与属性组的代表值相同(步骤31)。在相同的情况下，在步骤31中得到肯定结果，在不同的情况下，在步骤31中得到否定结果。
[0200]
针对在步骤31中得到肯定结果的文档，处理器31无需进行本实施方式中的分组处理。因此，处理器31针对相符的文档进入步骤4。
[0201]
另一方面，针对在步骤31中得到否定结果的文档，处理器31判定在1个文档内是否存在属于多个属性组的属性名(步骤32)。
[0202]
在步骤32中得到否定结果的情况下，处理器31将作为对象的文档的属性名替换为代表值(步骤33a)。由此，文档与特定的属性组被关联。与实施方式2的不同之处在于，属性名的数量不增加这一点和用户赋予的属性名未残留在文档中这一点。
[0203]
另一方面，在步骤32中得到肯定结果的情况下，处理器31向用户通知未进行分组处理(步骤34)。在该情况下，用户单独地研究对文档赋予的属性名。
[0204]
图17是说明实施方式3中的分组处理完成后的状态的图。在图17中，针对与图13的对应部分标注对应的标号而示出。
[0205]
另外，分组处理的中途阶段的状态与实施方式2中说明的图12相同。
[0206]
在图17的情况下，被赋予与“已承认”组的代表值相同的属性名的文档b以外的文档a和文档c的属性名被替换为作为属性组的代表值的“已承认”。在本实施方式的情况下，属于属性名相同的属性组的文档中的属性名全部统一为相同的代表值。
[0207]
＜文档的检索＞
[0208]
在本实施方式的情况下，与文档的检索相关的处理动作与实施方式2中说明的处理动作相同。即，在本实施方式中也使用图14所示的处理动作。即，使用属性组的代表值来执行实际的检索。因此，执行检索的过程成为与实施方式2中说明的图15相同的内容。
[0209]
因此，即便在文档的属性名中存在表述不一致，在检索词中包含属性组的要素的情况下，具有与输入的检索词一致的属性名的文档b和文档c也包含在检索结果中。
[0210]
但是，在本实施方式的情况下，文档的属性名与作为登记者的用户的意愿无关地会被改写。因此，在用户确认文档的属性的情况下，可能对与自身赋予的属性名的差异感到惊讶。
[0211]
图18是说明实施方式中的文档的属性的显示例的图。在图18的情况下，例示出文档a。
[0212]
文档a的属性名与上述的属性名不同，追加了[g]的标记。该[g]的标记表示被替换为属性组的代表值。因此，确认到“已承认[g]”的表述的用户能够知晓改写为代表值的事实。
[0213]
如以上那样，在不确定的用户自由地赋予了属性名的文档成为检索对象的情况下，即便不知道含义相似的全部属性名，用户也能够仅通过指定自身知晓的属性名而取得关联的文档作为检索结果。
[0214]
＜实施方式4＞
[0215]
在上述实施方式的情况下，设想属性组及其代表值被事先提供的情况。在本实施方式中，针对共享服务器30(参照图1)具有自动地生成属性组及其代表值的功能的情况进行说明。
[0216]
＜系统的结构＞
[0217]
图19是说明由在实施方式4中使用的共享服务器30的处理器31a实现的功能的一部分的图。在图19中，针对与图3的对应部分标注对应的标号而示出。
[0218]
在图19所示的处理器31a中，追加有属性组生成部316这一点与上述的其他实施方式不同。
[0219]
属性组生成部316依次读出存储于文档db 331(参照图2)的文档，提取分别对文档赋予的属性名。此外，汇集提取出的属性名而生成属性组。
[0220]
在含义是否相似的判定中，例如使用预先准备的相似词词典。相似词词典可以通过人工来编辑，也可以通过机器学习而生成。
[0221]
在本实施方式的情况下，以文件夹为单位来汇集含义相似的属性名。这是因为，属于相同文件夹的文档的内容被推测为关联性高。此外，也因为关联性低的文档不包含在检索结果中。
[0222]
＜文档db的例子＞
[0223]
图20是用于说明文档db 331(参照图2)的结构例的图。本实施方式中使用的文档db 331也与对应于树结构的节点的文件夹关联地存储有文档。
[0224]
在图20的情况下，位于根目录的文件夹的id为“001”，在其子节点的位置存在2个文件夹。1个是，id为“0011”的“合约”文件夹，1个是id为“0012”的“设计”文件夹。
[0225]“合约”文件夹是第1集合的一例，“设计”文件夹是第2集合的一例。
[0226]
在图20所示的“设计”文件夹中存储有2个文档，即文档aa和文档bb。另外，与文档aa的制作者对应的属性值是“p先生/女士”，与“已经设计”对应的属性值是“true”。与文档bb的制作者对应的属性值是“q先生/女士”，与“完成”对应的属性值是“false”。
[0227]
在图20的例子中，作为具有属性名“完成”的文档而例示出文档c和文档bb，但相同的文档c也可以包含在“合约”文件夹和“设计”文件夹双方。
[0228]
在图20的情况下，在“合约”文件夹中已经关联了属性组的“已承认”组。另外，“已承认”组的更新标志为“false”。
[0229]
在图20中，向根目录文件夹新登记属性组。在该情况下，上述的属性组生成部316从位于子节点的2个文件夹取得5个文档，生成分别对5个文档赋予的属性名中的含义相似的属性名的组。
[0230]
图21是说明实施方式4中的属性组的生成例的图。
[0231]
图21所示的属性组的例子是根据属于图20所示的根目录文件夹的5个文档而生成的。
[0232]
如图21所示，对5个文档赋予的属性名能够分类为2个属性组。1个是在其他实施方式中也进行了说明的“已承认”组，1个是“交付完成”组。关于代表值，也可以从作为集合的要素的属性名中选择1个，但在图21的例子中，由用户事先提供。
[0233]
在图21的情况下，属性名“完成”属于2个属性组。即，属性名“完成”存在于2个属性组的重复部分。在该情况下，例如在步骤32(参照图11)等中得到肯定结果。
[0234]
在该情况下，将被赋予“完成”这一属性名的文档与哪个属性组关联成为问题。
[0235]
这里，也能够将被赋予“完成”这一属性名的文档c和文档bb双方与“已承认”组和“交付完成”组双方关联。
[0236]
但是，在将1个属性名与多个属性组关联时，在检索结果中，不仅存在用户设想的文档，还可能混杂大量没有关联性的文档。例如在想要检索文档aa和文档bb的情况下，可能发生文档a、文档b、文档c也包含在检索结果中的情况。
[0237]
于是，在本实施方式的处理器31a(参照图19)中，按照预先决定的规则来执行分组处理。即，执行属性组与文档的关联处理。以下说明预先决定的规则的具体例。
[0238]
＜属性组的登记＞
[0239]
图22是说明在实施方式4中使用的共享服务器30(参照图1)所执行的与属性组的登记相关的处理动作中的分组处理的一例的流程图。在图22中，针对与图7的对应部分标注对应的标号而示出。
[0240]
另外，分组处理以外的处理动作与图7的处理动作相同。
[0241]
图22所示的分组处理是步骤3c。步骤3c是在步骤2(参照图7)中得到肯定结果的情况下执行的。
[0242]
首先，处理器31判定在作为处理对象的属性组中是否存在也属于其他属性组的属性名(步骤301)。具体而言，判定是否包含与图21的“完成”对应的属性名。
[0243]
在作为处理对象的属性组中存在满足判定的条件的属性名的情况下，在步骤301中得到肯定结果。另一方面，在作为处理对象的属性组中不存在满足判定的条件的属性名的情况下，在步骤301中得到否定结果。
[0244]
在步骤301中得到否定结果的情况下，处理器31执行作为处理对象的属性组和具有作为其要素的属性名的文档的分组(步骤302)。这里的分组通过在实施方式1～3中说明的任意一个方法来进行。
[0245]
在步骤301中得到肯定结果的情况下，处理器31判定具有共同的属性名的多个属性组的一方是否与另一方的全部重叠(步骤303)。
[0246]
图23是说明多个属性组之间的关系的图。(a)示出一方的属性组包含另一方的属性组的全部的关系，(b)示出一方的属性组与另一方的属性组在一部分重叠但一方不包含另一方的关系。
[0247]
图23的(a)的例子是在属性组“保管文档”中包含属性组“交付完成”的全部的情况。另外，图23的(b)的例子是在2个属性组之间仅仅属性名“完成”重复的例子。
[0248]
返回图22的说明。
[0249]
在步骤303中得到肯定结果的情况下，处理器31将被包含这一侧的属性组的代表
值追加到对应的文档的属性名(步骤304)。如果是图23的(a)的例子，则属性名“已经设计”和“完成”与关联于“交付完成”组的文件夹的5个文档关联。
[0250]
该例对应于在实施方式2中说明的分组处理。另外，在分组处理的方法中，也能够使用在实施方式1中说明的方法或在实施方式3中说明的方法。
[0251]
另一方面，在步骤303中得到否定结果的情况下，处理器31求出与各属性组对应的文件夹所包含的文档的数量，将文档的数量较少的一方的属性组的优先度设为上位(步骤305)。
[0252]
接着，处理器31判定优先度相同的属性组是否存在多个(步骤306)。
[0253]
在优先度相同的属性组不存在多个的情况下，处理器31在步骤306中得到否定结果，按照优先度从高到低的顺序执行分组(步骤307)。
[0254]
具体而言，针对与属性组对应的文档的数量较少的一方而关联属性名。如果是图23的(b)的例子，则属性名“完成”与“已承认”组关联。
[0255]
另外，在优先度相同的属性组存在多个的情况下，处理器31在步骤306中得到肯定结果，向用户通知未进行分组处理(步骤308)。在该情况下，用户单独地研究对文档赋予的属性名。
[0256]
在本实施方式的情况下，属于多个属性组的属性名被关联到与属性组对应的文件夹的文档的数量较少的一方。
[0257]
因此，与关联到其他属性组的情况相比，作为使用了所提供的检索词的检索的结果而向用户提示的文档的数量较少。
[0258]
当所提示的文档的数量过多时，直至确定目标文档为止的时间容易变长。但是，如本实施方式那样，文档被关联到所关联的文档的数量较少的属性组，因此，使用了属性组的检索的结果的数量变少，直至确定目标文档为止的时间可以较短。
[0259]
包含相同属性名且对应的文件夹所包含的文档的一部或全部重叠这样的属性组彼此能够看作是相似的属性组。对此，也可以将相似的属性组关联地存储于属性组db 332。
[0260]
图24示出存储于属性组db 332的“已承认”组的构造例。在图24中，针对与图6的对应部分标注对应的标号而示出。
[0261]
在图24的情况下，作为属于属性组的属性名也例示出“已承认”、“已经承认”、“完成”。此外，作为属性组，更新标志被设定为“true”。这里，“已承认”组和“保管文档”组包含相同的“已经承认”这样的属性名，并且是对应的文件夹所包含的文档一部分重复的状态，是相似的属性组。
[0262]
图24所示的属性组的构造与图6所示的属性组的构造的差异在于，在图24的情况下，作为“similar group”而存在与相似的属性组相关的项目这一点。通过像这样预先存储相似的属性组，当用户以“已承认”组的代表值或者属于“已承认”组的属性名执行了检索时，也可以向用户提示存在“保管文档”作为相似的属性组，促使重新检索。
[0263]
此外，图24所示的属性组的构造与图6所示的属性组的构造不同，作为“priority”还存在优先度的项目。这样，也可以将上述的优先度数值化而与属性组对应地存储于属性组db 332。在新成为分组处理的对象的文件夹中包含存储有以前判定的优先度的多个文件夹，且它们的优先度的关系性不改变的情况下，也可以省略再次判定优先度的处理。
[0264]
＜实施方式5＞
[0265]
在本实施方式中，针对共享服务器30(参照图1)具有辅助用户赋予属性名的功能的情况进行说明。
[0266]
＜系统的结构＞
[0267]
图25是说明由在实施方式5中使用的共享服务器30的处理器31b实现的功能的一部分的图。在图25中，针对与图19的对应部分标注对应的标号而示出。
[0268]
在图25所示的处理器31b中，在追加有属性名输入辅助部317这一点与上述的实施方式4不同。
[0269]
属性名输入辅助部317辅助对上传到共享服务器30的新文档赋予的属性名的输入。
[0270]
本实施方式中的属性名输入辅助部317按照用户的使用频度从高到低的顺序对现有的属性组进行排序，将其代表值作为属性名的候选提示给用户。由此来抑制属性名的表述不一致。用户的使用频度作为使用频度的历史而被存储。
[0271]
这里，在用户的使用频度中，例如使用执行检索的情况下的输入率或属性名的赋予率。输入率被计算为作为检索词而输入的次数相对于用户检索的总次数的商。此外，赋予率被计算为赋予了特定的属性名的次数相对于用户赋予了属性名的总次数的商。
[0272]
图26是示出登记新文档的用户终端20(参照图1)的显示部所显示的属性名的画面100的例子的图。
[0273]
在图26所示的画面100中，显示出“文档a”作为文档名101，显示出“制作者”作为第1个属性名102，显示出4个候选103a作为第2个属性名103。
[0274]
在图26的情况下，作为代表名的“已承认”为第1个候选，第2个候选为“已经承认”，第3个候选为“完成”，第4个候选为“其他”。候选的排列是基于输入率或赋予率而决定的。在该例的情况下，关于用户的使用频度，候选1最高，接下来为候选2，接下来为候选3。
[0275]
另外，在候选103a的下方显示有促使用户的操作的说明文104。
[0276]
通过将图26所示的画面100提示给上传文档的用户，属性名的表述不一致变少。
[0277]
＜其他实施方式＞
[0278]
以上，对本公开的实施方式进行了说明，但本公开的技术范围不限于上述实施方式所记载的范围。根据权利要求书的记载可清楚对上述实施方式加以各种变更或改良的实施方式也包含在本公开的技术范围内。
[0279]
在上述实施方式中，设想了将属性名用于检索关键字的情况，但也可以将属性值用于检索关键字。关于属性值，通过用户自由地登记而产生表述不一致，但通过管理相似的属性值的集合，从而消除因表述不一致引起的检索遗漏。属性值也是属性的一例。
[0280]
上述各实施方式中的处理器是指广义上的处理器，除了包含通用的处理器(例如cpu等)之外，还包含专用的处理器(例如gpu、asic(＝application specific integrated circuit：专用集成电路)、fpga、程序逻辑器件等)。
[0281]
此外，上述各实施方式中的处理器的动作可以由1个处理器单独地执行，但也可以通过存在于物理上分离的位置的多个处理器协同配合地执行。此外，处理器中的各动作的执行顺序不仅仅限定于上述各实施方式所记载的顺序，也可以单独地变更。