IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 松本 政志の特許一覧

特開2023-80708データ保管装置、データ保管方法、及びデータ保管プログラム
<>
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図1
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図2
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図3
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図4
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図5
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図6
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図7
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図8
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図9
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図10
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図11
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図12
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図13
  • 特開-データ保管装置、データ保管方法、及びデータ保管プログラム 図14
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023080708
(43)【公開日】2023-06-09
(54)【発明の名称】データ保管装置、データ保管方法、及びデータ保管プログラム
(51)【国際特許分類】
   G06F 16/483 20190101AFI20230602BHJP
   G06V 30/00 20220101ALI20230602BHJP
   G06F 16/81 20190101ALI20230602BHJP
【FI】
G06F16/483
G06K9/00 S
G06F16/81
【審査請求】有
【請求項の数】9
【出願形態】OL
(21)【出願番号】P 2021194193
(22)【出願日】2021-11-30
(71)【出願人】
【識別番号】521523741
【氏名又は名称】松本 政志
(74)【代理人】
【識別番号】110000198
【氏名又は名称】弁理士法人湘洋特許事務所
(72)【発明者】
【氏名】松本 政志
【テーマコード(参考)】
5B064
5B175
【Fターム(参考)】
5B064AA01
5B064BA01
5B064CA08
5B064EA32
5B175CA02
5B175GA03
(57)【要約】
【課題】入力データの内容を示すテキストをコンピュータ内で活用できるようにすること。
【解決手段】データ保管装置は、複数の入力データを取得する取得部と、前記入力データの特徴に基づいて、複数の前記入力データの各々を前記特徴ごとに複数のグループに分類する分類部と、前記入力データの内容をテキストに変換する複数の変換プログラムが前記グループごとに割り当てられており、複数の前記変換プログラムの各々を用いて前記入力データごとに前記内容を複数の前記テキストに変換する変換部と、複数の前記テキストに基づいて、前記入力データの前記内容を示すタグ情報を生成する生成部と、前記入力データを識別するデータ識別子と、当該入力データに係るタグ情報とを対応付けて記憶部に保管する保管処理部とを有する。
【選択図】図1
【特許請求の範囲】
【請求項1】
複数の入力データを取得する取得部と、
前記入力データの特徴に基づいて、複数の前記入力データの各々を前記特徴ごとに複数のグループに分類する分類部と、
前記入力データの内容をテキストに変換する複数の変換プログラムが前記グループごとに割り当てられており、複数の前記変換プログラムの各々を用いて前記入力データごとに前記内容を複数の前記テキストに変換する変換部と、
複数の前記テキストに基づいて、前記入力データの前記内容を示すタグ情報を生成する生成部と、
前記入力データを識別するデータ識別子と、当該入力データに係るタグ情報とを対応付けて記憶部に保管する保管処理部と、
を有することを特徴とするデータ保管装置。
【請求項2】
請求項1に記載のデータ保管装置であって、
前記生成部は、複数の前記テキストの各々に出現する文字列のうち、出現する頻度が最も高い文字列を前記タグ情報として出力することを特徴とするデータ保管装置。
【請求項3】
請求項1に記載のデータ保管装置であって、
複数の前記変換プログラムごとに、前記変換の精度の高さを示す重みが割り当てられており、
前記生成部は、一つの前記入力データから変換された複数の前記テキストの各々に相異なる文字列が出現した場合に、前記重みが最も大きい前記変換プログラムが変換した前記テキストに出現した前記文字列を、当該入力データに対応したタグ情報として生成することを特徴とするデータ保管装置。
【請求項4】
請求項1~3のいずれか一項に記載のデータ保管装置であって、
前記分類部は、同一の前記特徴を有する複数の前記入力データを同一の前記グループに分類し、
前記変換部は、前記分類部が同一の前記特徴を有する複数の前記入力データを同一の前記グループに分類した後に、同一の前記グループに属する複数の前記入力データの各々の前記内容を前記テキストに変換することを特徴とするデータ保管装置。
【請求項5】
請求項1~4のいずれか一項に記載のデータ保管装置であって、
前記グループは前記入力データの様式に対応しており、
前記分類部は、前記入力データの様式と前記特徴とを対応付けた特徴情報を参照することにより、前記様式に対応した前記グループに前記入力データを分類し、
前記変換部は、前記変換プログラムを識別するプログラム識別子と前記様式とを対応付けた変換情報を参照することにより、前記様式に対応した前記グループに複数の前記変換プログラムを割り当て、
複数の前記グループのいずれにも属さない新たな前記様式を前記入力データが有する場合に、前記新たな様式と当該入力データの前記特徴とを対応付けて前記特徴情報に格納する特徴情報格納部と、
新たな前記様式に対応した新たな複数の前記変換プログラムの各々の前記プログラム識別子を、新たな前記様式と対応付けて前記変換情報に格納する変換情報格納部とを更に有することを特徴とするデータ保管装置。
【請求項6】
請求項1~5のいずれか一項に記載のデータ保管装置であって、
前記入力データは、画像データ、音声データ、及び動画データのいずれかであり、
前記変換プログラムは、前記入力データが画像データの場合には文字認識処理を含み、前記入力データが音声データの場合には音声認識処理を含み、前記入力データが動画データの場合には画像認識処理を含むことを特徴とするデータ保管装置。
【請求項7】
請求項1~6のいずれか一項に記載のデータ保管装置であって、
前記入力データは、画像データ、音声データ、及び動画データのいずれかであり、
前記複数の変換プログラムの少なくとも一つは、前記入力データの内容に関する属性情報を抽出し、前記属性情報をテキストに変換することを特徴とするデータ保管装置。
【請求項8】
コンピュータが、
複数の入力データを取得するステップと、
前記入力データの特徴に基づいて、複数の前記入力データの各々を前記特徴ごとに複数のグループに分類するステップと、
前記入力データの内容をテキストに変換する複数の変換プログラムが前記グループごとに割り当てられており、複数の前記変換プログラムの各々を用いて前記入力データごとに前記内容を複数の前記テキストに変換するステップと、
複数の前記テキストに基づいて、前記入力データの前記内容を示すタグ情報を生成するステップと、
前記入力データを識別する識別子と、当該入力データに係る前記タグ情報とを対応付けて記憶部に保管するステップと、
を実行することを特徴とするデータ保管方法。
【請求項9】
複数の入力データを取得するステップと、
前記入力データの特徴に基づいて、複数の前記入力データの各々を前記特徴ごとに複数のグループに分類するステップと、
前記入力データの内容をテキストに変換する複数の変換プログラムが前記グループごとに割り当てられており、複数の前記変換プログラムの各々を用いて前記入力データごとに前記内容を複数の前記テキストに変換するステップと、
複数の前記テキストに基づいて、前記入力データの前記内容を示すタグ情報を生成するステップと、
前記入力データを識別する識別子と、当該入力データに係る前記タグ情報とを対応付けて記憶部に保管するステップと、
をコンピュータに実行させるためのデータ保管プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
データ保管装置、データ保管方法、及びデータ保管プログラムに関する。
【背景技術】
【0002】
従来、銀行や保険等の様々な業界において、顧客が手書きで文字を記入するための帳票が使用されている。手書きの文字をコンピュータが処理可能なテキストデータに変換すると、コンピュータが帳票に対して様々な処理を実行することができる。
【0003】
手書きの文字をテキストデータに変換するにはOCR(Optical character recognition)技術が用いられることが多い。但し、OCR技術は、罫線や文字の位置等を基準にしてテキストを抽出するため、罫線や文字の位置等の様式が異なる複数の帳票に同一のOCR技術を適用したのでは、これらの帳票からテキストを抽出するのが困難となる。この問題を解決するために、複数の帳票を様式ごとにクラスタリングし、同一のクラスタ内の帳票に対しては同一のOCR技術を使用することで、テキスト抽出の精度を高める方法が提案されている(特許文献1)。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開2021-125040号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、特許文献1の方法では単に帳票からテキストを抽出するに留まっており、抽出したテキストをコンピュータ内で活用する方法まで考慮されていない。更に、将来的には帳票等の紙媒体だけでなく、画像、音声、及び動画等の様々な種類の入力データから検索用のテキストを抽出したいというニーズが生まれる場合が想定される。この場合も、入力データの様式に関わらず精度よくテキストを抽出し、それをコンピュータ内で活用できるようにするのが望まれる。
【0006】
本発明は、このような現状を鑑みてなされたものであり、様々な種類の入力データの内容を示すテキストをコンピュータ内で活用できるようにすることを目的とする。
【課題を解決するための手段】
【0007】
本願は、上記課題の少なくとも一部を解決する手段を複数含んでいるが、その例を挙げるならば、以下のとおりである。
【0008】
上記課題を解決すべく、本発明の一態様に係るデータ保管装置は、複数の入力データを取得する取得部と、前記入力データの特徴に基づいて、複数の前記入力データの各々を前記特徴ごとに複数のグループに分類する分類部と、前記入力データの内容をテキストに変換する複数の変換プログラムが前記グループごとに割り当てられており、複数の前記変換プログラムの各々を用いて前記入力データごとに前記内容を複数の前記テキストに変換する変換部と、複数の前記テキストに基づいて、前記入力データの前記内容を示すタグ情報を生成する生成部と、前記入力データを識別するデータ識別子と、当該入力データに係るタグ情報とを対応付けて記憶部に保管する保管処理部とを有する。
【0009】
前記生成部は、複数の前記テキストの各々に出現する文字列のうち、出現する頻度が最も高い文字列を前記タグ情報として出力することができる。
【0010】
複数の前記変換プログラムごとに、前記変換の精度の高さを示す重みが割り当てられており、前記生成部は、一つの前記入力データから変換された複数の前記テキストの各々に相異なる文字列が出現した場合に、前記重みが最も大きい前記変換プログラムが変換した前記テキストに出現した前記文字列を、当該入力データに対応したタグ情報として生成することができる。
【0011】
前記分類部は、同一の前記特徴を有する複数の前記入力データを同一の前記グループに分類し、前記変換部は、前記分類部が同一の前記特徴を有する複数の前記入力データを同一の前記グループに分類した後に、同一の前記グループに属する複数の前記入力データの各々の前記内容を前記テキストに変換することができる。
【0012】
前記グループは前記入力データの様式に対応しており、前記分類部は、前記入力データの様式と前記特徴とを対応付けた特徴情報を参照することにより、前記様式に対応した前記グループに前記入力データを分類し、前記変換部は、前記変換プログラムを識別するプログラム識別子と前記様式とを対応付けた変換情報を参照することにより、前記様式に対応した前記グループに複数の前記変換プログラムを割り当て、複数の前記グループのいずれにも属さない新たな前記様式を前記入力データが有する場合に、前記新たな様式と当該入力データの前記特徴とを対応付けて前記特徴情報に格納する特徴情報格納部と、新たな前記様式に対応した新たな複数の前記変換プログラムの各々の前記プログラム識別子を、新たな前記様式と対応付けて前記変換情報に格納する変換情報格納部とを更に有することができる。
【0013】
前記入力データは、画像データ、音声データ、及び動画データのいずれかであり、前記変換プログラムは、前記入力データが画像データの場合には文字認識処理を含み、前記入力データが音声データの場合には音声認識処理を含み、前記入力データが動画データの場合には画像認識処理を含むことができる。
【0014】
前記入力データは、画像データ、音声データ、及び動画データのいずれかであり、前記複数の変換プログラムの少なくとも一つは、前記入力データの内容に関する属性情報を抽出し、前記属性情報をテキストに変換することができる。
【0015】
本発明の他の態様に係るデータ保管方法は、コンピュータが、複数の入力データを取得するステップと、前記入力データの特徴に基づいて、複数の前記入力データの各々を前記特徴ごとに複数のグループに分類するステップと、前記入力データの内容をテキストに変換する複数の変換プログラムが前記グループごとに割り当てられており、複数の前記変換プログラムの各々を用いて前記入力データごとに前記内容を複数の前記テキストに変換するステップと、複数の前記テキストに基づいて、前記入力データの前記内容を示すタグ情報を生成するステップと、前記入力データを識別する識別子と、当該入力データに係る前記タグ情報とを対応付けて記憶部に保管するステップとを実行する。
【0016】
本発明の更に他の態様に係るデータ保管プログラムは、複数の入力データを取得するステップと、前記入力データの特徴に基づいて、複数の前記入力データの各々を前記特徴ごとに複数のグループに分類するステップと、前記入力データの内容をテキストに変換する複数の変換プログラムが前記グループごとに割り当てられており、複数の前記変換プログラムの各々を用いて前記入力データごとに前記内容を複数の前記テキストに変換するステップと、複数の前記テキストに基づいて、前記入力データの前記内容を示すタグ情報を生成するステップと、前記入力データを識別する識別子と、当該入力データに係る前記タグ情報とを対応付けて記憶部に保管するステップとをコンピュータに実行させる。
【発明の効果】
【0017】
本発明によれば、様々な種類の入力データの内容を示すテキストをコンピュータ内で活用できるようにすることができる。
【図面の簡単な説明】
【0018】
図1図1は、本実施形態に係るデータ保管システムのシステム構成図である。
図2図2は、入力データの一例を示す模式図である。
図3図3は、入力データの他の例を示す模式図である。
図4図4は、特徴情報の模式図である。
図5図5は、入力データをグループに分類する方法について説明するための模式図である。
図6図6は、変換情報の模式図である。
図7図7は、OCRエンジンA-1の処理内容を示す模式図である。
図8図8は、生成部の処理内容について示す模式図である。
図9図9は、タグ情報の正確性を向上させる方法について示す模式図である
図10図10は、データベースの模式図である。
図11図11は、本実施形態に係るデータ保管方法のフローチャートである。
図12図12は、入力データが音声データである場合のデータベースの模式図である。
図13図13は、入力データが動画データである場合のデータベースの模式図である。
図14図14は、本実施形態に係るデータ保管装置のハードウェア構成図である。
【発明を実施するための形態】
【0019】
以下、本発明に係る一実施形態を図面に基づいて説明する。なお、一実施形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下の実施形態において、その構成要素(要素ステップ等も含む)は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではないことは言うまでもない。また、「Aからなる」、「Aよりなる」、「Aを有する」、「Aを含む」と言うときは、特にその要素のみである旨明示した場合等を除き、それ以外の要素を排除するものでないことは言うまでもない。同様に、以下の実施形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に明らかにそうでないと考えられる場合等を除き、実質的にその形状等に近似または類似するもの等を含むものとする。
【0020】
<データ保管システム>
図1は、本実施形態に係るデータ保管システムのシステム構成図である。データ保管システム1は、画像データ、音声データ、及び動画データ等の入力データ2をキーワード等のテキストで検索できるようにするためのシステムであって、端末装置3とデータ保管装置4とを備える。
【0021】
このうち、端末装置3は、テキスト検索を行うユーザが操作するコンピュータである。一例として、端末装置3は、PC(Personal Computer)、スマートフォン、及びタブレット型端末等のコンピュータである。以下では、入力データ2が、帳票を写した画像ファイルである場合を例にして説明する。この場合、不図示のスキャナが帳票をスキャンしてその画像ファイルを生成する。そして、端末装置3が、その画像ファイルを入力データ2として取得する。
【0022】
一方、データ保管装置4は、ネットワーク10を介して端末装置3に接続されたサーバやPC等のコンピュータである。なお、データ保管装置4は物理マシンに限定されず仮想マシンでもよい。なお、データ保管装置4の全ての機能を一つのコンピュータで実現せずに、物理的に分散して配置された複数のコンピュータでデータ保管装置4の機能を実現するようにしてもよい。更に、Google社やAWS(Amazon Web Service)が提供するAPI(Application Programing Interface)を利用して、データ保管装置4の各機能を実現してもよい。
【0023】
この例では、データ保管装置4は、通信部11、処理部12、及び記憶部13を備える。通信部11は、データ保管装置4をネットワーク10に接続するためのインターフェースである。
【0024】
処理部12は、データ保管装置4の各部を制御する。一例として、処理部12は、取得部15、分類部16、変換部17、生成部18、保管処理部19、特徴情報格納部20、変換情報格納部21、及び検索部22を備える。
【0025】
取得部15は、ネットワーク10を介して端末装置3から複数の入力データ2を取得し、それらを記憶部13に格納する処理部である。なお、取得部15が、端末装置3とは異なるコンピュータから入力データ2を取得してもよい。更に、データ保管装置4にスキャナを直接接続し、スキャナが出力した帳票の画像ファイルを取得部15が入力データ2として取得してもよい。
【0026】
図2は、入力データ2の一例を示す模式図である。ここでは、入力データ2の元となる帳票が生命保険の契約書である場合を例示してある。この場合、入力データ2には、契約者の欄2aと被保険者の欄2bとが含まれる。
【0027】
各欄2a、2bの位置は生命保険契約書の様式によって異なる。例えば、図2のように「A保険会社」の様式では、契約者の欄2aは生命保険契約書の上部に位置し、被保険者の欄2bは生命保険契約書の中央部に位置する。
【0028】
一方、図3は、入力データ2の他の例を示す模式図である。図3の例では、入力データ2の元となる帳票が、図2の「A保険会社」とは異なる「B保険会社」の生命保険契約書である場合を例示してある。図2の例とは異なり、図3の例では、契約者の欄2aが生命保険契約書の左上部に位置し、かつ被保険者の欄2bが生命保険契約書の右上部に位置している。
【0029】
また、図2図3のいずれの場合であっても、各欄2a、2bには契約者の手書き文字が記述される。
【0030】
再び図1を参照する。分類部16は、入力データ2の特徴に基づいて、記憶部13に格納されている複数の入力データ2の各々をそれらの特徴ごとに複数のグループに分類する処理部である。分類に際し、分類部16は、記憶部13に格納されている特徴情報25を参照する。
【0031】
図4は、特徴情報25の模式図である。特徴情報25は、入力データ2の「様式」と入力データ2の「特徴」とを対応付けた情報であって、データ保管システム1の管理者によって予め記憶部13に格納される。入力データ2の「特徴」は特に限定されないが、本実施形態では生命保険契約書における各欄2a、2bの位置を入力データ2の「特徴」として採用する。また、「様式」は、各欄2a、2bの位置から推定される生命保険契約書の様式を示す。例えば、契約者の欄2aの位置が「上部」であり、かつ被保険者の欄2bの位置が「中央部」の場合には、図2のような「A保険会社」の様式となる。
【0032】
分類部16は、入力データ2に含まれる罫線の位置に基づいて、入力データ2の「特徴」として各欄2a、2bの位置を特定する。そして、分類部16は、特定した各欄2a、2bの位置に対応した「様式」を特徴情報25に基づいて特定する。その後、分類部16は、特定した「様式」ごとに複数の入力データ2を複数のグループに分類する。
【0033】
図5は、入力データ2をグループに分類する方法について説明するための模式図である。ここでは、分類部16は、「A生命保険会社」~「C生命保険会社」の各々の様式ごとに、記憶部13にある全ての入力データ2をそれぞれ「グループA」~「グループC」に分類する。また、「A生命保険会社」~「C生命保険会社」のいずれの様式にも対応しない特徴を入力データ2が備えている場合は、分類部16は、その入力データ2を「未分類」のグループに分類する。
【0034】
再び図1を参照する。変換部17は、OCRエンジンを用いることにより、入力データ2の手書きの内容をテキストに変換する処理部である。
【0035】
なお、OCRエンジンは、入力データ2に含まれる罫線の位置等を基準にして手書き文字の位置を推定し、推定された位置にある手書き文字を文字認識処理で文字として認識することで、手書き文字をテキストに変換する変換プログラムである。
【0036】
そのため、図2図3のように相異なる様式の入力データ2に対して同一のOCRエンジンを用いると、入力データ2ごとに罫線の位置が異なってしまうため、OCRエンジンによるテキスト化の精度が低下するおそれがある。
【0037】
そこで、本実施形態では、分類部16が分類したグループごとに、当該グループに含まれる入力データ2に適したOCRエンジンを割り当てる。割り当て方法は特に限定されない。本実施形態では、記憶部13に格納されている変換情報26を利用して変換部17が各グループにOCRエンジンを割り当てる。
【0038】
図6は、変換情報26の模式図である。変換情報26は、複数のOCRエンジンの各々を一意に識別するプログラム名と、入力データ2の様式とを対応付けた情報であって、データ保管システム1の管理者によって予め記憶部13に格納される。なお、プログラム名はプログラム識別子の一例である。
【0039】
例えば、「A保険会社の様式」について考える。図6によれば、「A保険会社の様式」には「OCRエンジンA-1」、…、「OCRエンジンA-N」のN個のOCRエンジンが割り当てられている。これらのOCRエンジンは、図4の特徴情報25において「A保険会社」の様式の特徴に適した変換プログラムである。例えば、「OCRエンジンA-1」は、契約者の欄2aの位置が上部にあり、かつ被保険者の欄の位置が中央部にあることを前提としたOCRエンジンであり、これらの位置にある手書き文字を契約者情報や被保険者情報としてテキスト化する。「OCRエンジンA-2」、…、「OCRエンジンA-N」についても同様である。
【0040】
なお、この例では手書き文字をテキストに変換する変換プログラムとしてOCRエンジンを採用したが、機械学習によって手書き文字をテキストに変換する変換プログラムを用いてもよい。
【0041】
変換部17は、変換情報26を参照することにより、同一のグループに属する複数の入力データ2の各々に対し、そのグループに係る様式に対応した複数のOCRエンジンを適用することになる。例えば、ある入力データ2が「A保険会社」の様式に対応した「グループA」に属する場合を考える。この場合、変換部17は、「OCRエンジンA-1」、…、「OCRエンジンA-N」のN個のOCRエンジンの各々を入力データ2に適用することになる。
【0042】
図7は、OCRエンジンA-1の処理内容を示す模式図である。図7に示すように、OCRエンジンA-1は、「グループA」に属する入力データ2に含まれる手書き文字をテキスト31に変換する。この例では、OCRエンジンA-1は、契約者の欄2a(図2参照)にある複数の罫線を基準として利用することで、「氏名」、「郵便番号」、「住所1」~「住所4」、及び「電話番号」の各項目に記述されている手書き文字をテキスト31に変換する。なお、「氏名」は欄2aにおける「氏名」であり、「郵便番号」は欄2aにおける「郵便番号」である。また、「住所1」~「住所4」は、それぞれ欄2aにおける「都道府県 市町村」、「区」、「番地」、及び「ビル名」である。そして、「電話番号」は欄2aにおける「電話番号」である。
【0043】
更に、OCRエンジンA-1は、入力データ2に対して画像認識処理を行うことにより入力データ2における押印の有無を判定し、その判定結果をテキスト31の「押印の有無」の欄に記述する。
【0044】
なお、手書き文字からテキストへの変換精度が不十分な場合には、テキスト31に不正確な文字列が現れることがある。図7の例では、「住所1」は「神奈川県横浜市」となるべきであるが、OCRエンジンA-1の変換精度が不十分なため「押茉川県横浩市」となっている。
【0045】
また、変換部17は、「グループA」に属する入力データ2に対し、更に「OCRエンジンA2」、…、「OCRエンジンA-N」も適用する。これにより、変換部17は、OCRエンジンの個数に等しいN個のテキスト31を一つの入力データ2から生成することになる。
【0046】
再び図1を参照する。生成部18は、一つの入力データ2から得られた複数のテキスト31に基づいて、当該入力データ2の内容を示すタグ情報27を生成し、それを記憶部13に格納する処理部である。
【0047】
図8は、生成部18の処理内容について示す模式図である。図8の例では、変換部17が、「グループA」に属する一つの入力データ2に対し、「OCRエンジンA-1」~「OCRエンジンA-3」の3個のOCRエンジンを適用した場合を想定している。この場合、OCRエンジンの個数に等しい3個のテキスト31が変換部17によって生成される。
【0048】
生成部18は、これらの3個のテキスト31に基づいて、入力データ2の内容を示すタグ情報27を生成する。タグ情報27の生成方法は特に限定されない。図8の例では、生成部18は、3個のテキスト31に出現する2文字以上の文字列のうち、出現する頻度が最も高い文字列を項目ごとに特定し、特定した文字列をタグ情報27として生成する。
【0049】
例えば、項目「住所1」について考える。項目「住所1」においては、黒太字で示す「横浜市」という文字列が2回出現している。一方、白抜きで示すその他の文字列については1回しか出現していないか、あるいは2回以上出現していてもその文字列の文字数は1文字である。よって、生成部18は、項目「住所1」の内容を示す文字列として「横浜市」を特定する。
【0050】
なお、項目「住所1」においては文字列「市」の出現頻度が3回であり、「横浜市」の出現頻度(2回)よりも多いが、「市」は1文字であって2文字未満であるため無視する。このように1文字の文字列を無視するのは、1文字では入力データ2の内容を十分に表すことができないためである。なお、1文字でも入力データ2の内容を十分に表すことができる場合は、1文字の文字列を無視しなくてもよい。
【0051】
同様に、項目「住所2」では文字列「川区」の出現回数が2回であり、他の文字列よりも出現回数が高い。よって、生成部18は、項目「住所2」の内容を示す文字列として「川区」を特定する。その他の項目の内容を示す文字列についても同様にして生成部18が特定する。
【0052】
そして、生成部18は、上記のようにして項目ごとに生成した文字列を、入力データ2の内容を示すタグ情報27として生成し、それを記憶部13に格納する。
【0053】
なお、タグ情報27の生成方法は上記に限定されない。例えば、「OCRエンジンA-1」~「OCRエンジンA-3」の各々にテキスト変換の精度の高さを示す重みを割り当てておき、その重みに基づいて生成部18がタグ情報27を生成してもよい。
【0054】
一例として、「OCRエンジンA-1」、「OCRエンジンA-2」、及び「OCRエンジンA-3」の各々の重みが「1」、「2」、及び「3」であり、値が大きいほどテキスト変換の精度が高くなるものとする。この場合に、各OCRエンジンに対応した3個のテキスト31の各々に相異なる文字列が出現したときは、生成部18は、重みが「3」で最も大きい「OCRエンジンA-3」に対応したテキスト31の文字列をタグ情報27として生成すればよい。これにより、テキスト変換の精度が高いOCRエンジンが生成したテキスト31がタグ情報27に含まれる可能性が高くなるため、タグ情報27に含まれるテキストにより入力データ2の内容を良好に表すことができる。
【0055】
タグ情報27は、入力データ2を検索するときのキーワード集として機能するため、入力データ2の内容を正確に反映しているのが好ましい。そこで、例えば以下のようにしてタグ情報27の正確性を向上させてもよい。
【0056】
図9は、タグ情報27の正確性を向上させる方法について示す模式図である。図9の例では、データ保管システム1の管理者が、「OCRエンジンA-2」を改良することにより、「OCRエンジンA-2」が生成するテキスト31の精度を高める場合を想定している。これにより、複数のテキスト31に基づいて生成されるテキスト情報32の正確性が向上する。
【0057】
また、データ保管システム1の管理者が、データ保管装置4に新たに「OCRエンジンA-4」を追加してもよい。これによりテキスト31の個数が増えるため、テキスト31に基づいて生成されるテキスト情報32の正確性が向上する。なお、このように管理者がOCRエンジンの改良や追加を行わず、処理部12がテキスト情報32の正確性を向上させてもよい。例えば、機械学習によって手書き文字をテキストに変換する変換プログラム(OCRエンジンの一部に人工知能を使うものも含む)の場合、変換情報格納部21は、上述したような生成部18による複数の変換プログラムが出力したテキストの比較結果に基づき、学習用データ(正解データ、不正解データなど)を生成し、その学習用データを用いて各変換プログラムが機械学習(すなわち改良)を行ってもよい。また、変換情報格納部21は、新規の変換プログラムを自動生成し、それを記憶部13に追加してもよい。
【0058】
再び図1を参照する。保管処理部19は、ユーザがテキスト検索に使用するデータベース28を記憶部13に格納する処理部である。
【0059】
図10は、データベース28の模式図である。図10に示すように、データベース28は、「ファイル名」、「データ種別」、「内容」、及び「タグ情報」の各々を対応付けた情報である。このうち、「ファイル名」は、複数の入力データ2の各々を一意に識別するデータ識別子の一例である。
【0060】
また、「データ種別」は、入力データ2が画像、音声、及び動画のどのフォーマットであるかを示す文字列である。例えば、保管処理部19は、入力データ2のファイル名の拡張子が「jpg」の場合にはデータ種別として「画像」を格納する。また、例えば拡張子が「mp3」の場合は、保管処理部19は、データ種別として「音声」を格納する。そして、例えば拡張子が「mp4」の場合は、保管処理部19は、データ種別として「動画」を格納する。
【0061】
「内容」は入力データ2の内容であって、この例では「帳票」が「内容」となる。例えば、入力データ2の内容が帳票であることを示す情報を端末装置3が入力データ2のヘッダ部分に書き込んでおき、その情報に基づいて保管処理部19が「内容」に「帳票」を格納し得る。
【0062】
「タグ情報」は、生成部18が生成したタグ情報27である。
【0063】
保管処理部19は、このように「ファイル名」、「データ種別」、「内容」、及び「タグ情報」の各々が対応付けられたデータベース28を記憶部13に格納する。これにより、データ保管装置4の検索部22が、端末装置3から検索キーワードを受け付けたときに、検索キーワードを含むタグ情報27を特定し、そのタグ情報27に対応するファイル名を端末装置3に返すことができる。
【0064】
再び図1を参照する。特徴情報格納部20は、前述の特徴情報25を記憶部13に格納する処理部である。
【0065】
なお、図5に示したように、特徴情報25に存在しない新しい特徴を入力データ2が備えている場合、当該入力データ2は「未分類」のグループに分類される。特徴情報格納部20は、このように「未分類」のグループに分類された入力データ2の新しい特徴と新しい様式とを対応付けて特徴情報25に格納する。例えば、特徴情報格納部20は、「未分類」のグループに属する入力データ2を、機械学習によりクラスタリングし、各クラスタを代表する入力データ2の特徴と様式とを対応付けて特徴情報25に格納する。
【0066】
一方、変換情報格納部21は、前述の変換情報26を記憶部13に格納する処理部である。前述のように「未分類」のグループが存在する場合は、変換情報格納部21は、「未分類」のグループに属する入力データ2が備える新しい様式と、その様式に適したOCRエンジンのプログラム名とを対応付けて変換情報26に格納する。また、上述したように、変換情報格納部21は、既存の変換プログラムを機械学習等により改良してもよい。また、変換情報格納部21は、新しい様式に対応した変換プログラムを自動生成し、それを記憶部13に格納してもよい。
【0067】
検索部22は、端末装置3から検索キーワードを受け付けて、その検索キーワードをキーにしてデータベース28を検索する処理部である。例えば、検索部22は、検索キーワードと一致するテキスト31を含むタグ情報27を特定し、そのタグ情報27に対応した入力データ2のファイル名を端末装置3に返す。この場合、端末装置3は、自装置が実行するwebブラウザから検索キーワードを検索部22に通知し、検索結果であるファイル名をwebブラウザで取得し得る。
【0068】
なお、検索部22の機能を端末装置3に持たせてもよい。その場合、検索部22の機能を実現するためのアプリケーションプログラムを端末装置3が実行すればよい。
【0069】
<データ保管方法>
次に、本実施形態に係るデータ保管方法について説明する。
【0070】
図11は、本実施形態に係るデータ保管方法のフローチャートである。まず、取得部15が、ネットワーク10を介して端末装置3から入力データ2を取得し、それを記憶部13に格納する(ステップS1)。
【0071】
次に、分類部16が、特徴情報25に基づいて、入力データ2をその特徴に応じたグループに分類する(ステップS2)。例えば、分類部16は、図5に示したように入力データ2の様式ごとに各入力データ2をグループに分類する。なお、入力データ2の特徴が特徴情報25に存在しない新たな特徴である場合は、分類部16は、当該入力データ2を「未分類」のグループに分類する。
【0072】
次いで、分類部16が、取得部15が取得していない入力データ2がまだあるかを判定する(ステップS3)。例えば、取得部15が入力データ2を取得する前に予め入力データ2の総数を端末装置3から取得しておき、記憶部13に格納されている入力データ2の個数が当該総数未満の場合、入力データはまだある(YES)と判定される。このようにステップS3で入力データはまだある(YES)と判定された場合にはステップS1に戻る。
【0073】
一方、ステップS3でNOと判定された場合は、分類部16が、「未分類」のグループがあるかを判定する(ステップS4)。ここで「未分類」のグループがある(YES)と判定された場合はステップS5に移る。
【0074】
ステップS5においては、特徴情報格納部20が、「未分類」のグループに含まれる各入力データ2の新たな特徴と新たな様式とを対応付けて特徴情報25に格納する。
【0075】
次いで、変換情報格納部21が、新たな様式に適した新たな複数のOCRエンジンの各々のプログラム名を、新たな様式と対応付けて変換情報26に格納する(ステップS6)。その後、ステップS2に戻る。
【0076】
一方、ステップS4において「未分類」のグループがない(NO)と判定された場合にはステップS7に移る。ステップS7においては、変換部17が、変換情報26を参照することにより、同一のグループに係る様式に対応した複数のOCRエンジンを特定する。そして、変換部17は、特定した複数のOCRエンジンを用いて、同一のグループに属する各々の入力データ2の手書きの内容を複数のテキスト31に変換する。そして、変換部17は、複数のグループごとにこのようなテキスト31への変換を行う。
【0077】
このようにステップS2でグループ化を終えた後にテキスト31への変換を行うことで、一つのグループ内の全ての入力データ2に対し、当該グループに係る複数のOCRエンジンを連続して適用することができる。その結果、グループ化とテキスト31への変換とを交互に行う場合と比較して効率的にテキスト31を生成することができる。
【0078】
次に、生成部18が、図8に例示した方法に従って入力データ2ごとにタグ情報27を生成し、それを記憶部13に格納する(ステップS8)。
【0079】
続いて、保管処理部19が、入力データ2を識別するファイル名と、当該入力データ2に係るタグ情報27とを対応付けてデータベース28に格納する(ステップS9)。以上により、本実施形態に係るデータ保管方法の基本的な処理を終える。
【0080】
上記した本実施形態によれば、保管処理部19が、入力データ2のファイル名とタグ情報27と対応付けてデータベース28に格納する。そのため、検索部22が、検索キーワードと一致するテキスト31を含むタグ情報27を特定し、そのタグ情報に対応したファイル名を検索できる。その結果、入力データ2の内容を示すテキスト31を端末装置3やデータ保管装置4等のコンピュータ内で活用することができる。
【0081】
しかも、図6に示したように、本実施形態では、変換部17が、罫線の位置等が異なる複数の様式ごとに、当該罫線を基準にして手書き文字の位置を推定するOCRエンジンを割り当てる。そのため、罫線の位置等が異なる複数の様式に同一のOCRエンジンを割り当てる場合と比較して、OCRエンジンが手書き文字を高い精度でテキストに変換することができる。
【0082】
更に、図11に示したように、特徴情報25には存在しない新たな様式の入力データ2を取得部15が取得した場合は、特徴情報格納部20が、新たな様式と入力データ2の特徴とを対応付けて特徴情報25に格納する(ステップS5)。更に、変換情報格納部21が、新たな様式に対応した新たな複数のOCRエンジンの各々のプログラム名を、新たな様式と対応付けて変換情報26に格納する(ステップS6)。これにより、新たな様式の入力データ2を取得部15が取得した場合であっても、特徴情報25に基づいて分類部16が当該入力データ2をグループに分類できる。更に、変換情報26に基づいて変換部17が当該入力データ2の内容をテキスト31に変換できる。
【0083】
<その他の実施形態>
入力データ2は画像データに限定されず、音声データや動画データであってもよい。
【0084】
図12は、入力データ2が音声データである場合のデータベース28の模式図である。ここでは、コールセンタが受信した電話の音声データが入力データ2である場合を想定している。
【0085】
この場合、分類部16は、音声データに含まれる「〇〇コールセンタです」という発話を特定し、コールセンタの名前を示す「〇〇」の部分を当該入力データ2の特徴として認識する。そして、分類部16は、当該特徴とコールセンタの名前とを対応付けた特徴情報25(図4参照)に基づいて、コールセンタの名前ごとに入力データ2を分類する。
【0086】
更に、変換部17が入力データ2に含まれる音声をテキストに変換し、そのテキストを音声キーワードとして含むタグ情報27を生成部18が生成する。例えば、変換部17は、音声認識処理を含む変換プログラムや機械学習によって音声をテキストに変換する。これにより、検索部22が、検索キーワードを音声キーワードとして含むタグ情報27を特定し、そのタグ情報27に対応する音声データのファイル名を端末装置3に返すことができる。なお、変換部17が、APIを介して外部のコンピュータシステムの音声認識処理に音声を送信し、外部のコンピュータシステムが変換したテキストを取得してもよい。
【0087】
図13は、入力データ2が動画データである場合のデータベース28の模式図である。ここでは、ドライブレコーダが記録した動画データが入力データ2である場合を想定している。
【0088】
この場合、分類部16は、動画データに含まれる画像の明度を当該動画の特徴として特定する。そして、分類部16は、明度と、朝・昼・夜等の時間帯とを対応付けた特徴情報25(図4参照)に基づいて、時間帯ごとに入力データ2を分類する。
【0089】
更に、変換部17が、画像中の物体を認識してそれをテキストに変換する画像認識処理と、音声をテキストに変換する音声認識処理とを行う変換プログラムを入力データ2に適用する。このとき、朝・昼・夜の各時間帯に適した変換プログラムのプログラム名と時間帯とを対応付けて変換情報26に格納し、各時間帯に適した変換プログラムを変換部17が入力データ2に適用する。なお、変換部17が、APIを介して外部のコンピュータシステムの画像認識処理と音声認識処理の各々に画像と音声とを送信し、外部のコンピュータシステムから物体の認識結果やテキストを取得してもよい。
【0090】
そして、生成部18が、画像認識処理で得られた認識物体と、音声認識処理で得られた音声キーワードとを含むタグ情報27を生成する。なお、音声認識処理や画像認識処理として機械学習を採用してもよい。これにより、検索部22が、検索キーワードを音声キーワードや認識物体として含むタグ情報27を特定し、そのタグ情報27に対応する動画データのファイル名を端末装置3に返すことができる。
【0091】
なお、タグ情報27の元となるテキスト31は、OCR、音声認識、及び画像認識で得られたテキストに限定されない。例えば、変換部17が、何等かの解析エンジン(変換プログラム)によって様々な属性情報(メタ情報)を入力データ2から抽出し、これを人間が理解できるテキスト31に変換してもよい。そして、このテキスト31に基づいて生成部18がタグ情報27を生成してもよい。属性情報を抽出する解析エンジン(変換プログラム)は、例えば機械学習や深層学習に基づく人工知能技術を利用したものがある。
【0092】
更に、変換部17が、APIを通じて外部の解析サービスにアクセスし、その解析サービスを利用して入力データ2からテキスト31を生成してもよい。更に、変換部17が自動的にインターネット検索をすることで、入力データ2を表現するテキスト31を生成してもよい。
【0093】
更に、入力データ2の内容も上記に限定されない。例えば、入力データ2が音声データの場合には、会話、音楽、及び環境音等が入力データ2に含まれ得る。この場合、変換部17が、解析エンジンあるいは外部の解析サービスを用いて、会話、音楽、及び環境音等の属性情報を取得して、その属性情報をテキスト31に変換してもよい。また、会話の場合には、コールセンタや会議等における会話の状況を示す属性情報を変換部17が解析エンジンあるいは外部の解析サービスを用いて取得してもよい。そのような属性情報としては、例えば参加者の人数、年齢、及び性別声紋情報がある。更に、音楽の場合には、曲名、作曲家、曲調、ジャンル、一部の波形・音符等が属性情報となる。
【0094】
また、入力データ2は、静止画を示す画像データであってもよい。その場合、変換部17は、画像の種別、例えば書類、絵画、及び写真等の種別に係る属性情報を示すテキスト31を生成する。更に、変換部17が、画像に含まれる人物や風景等の属性情報を示すテキスト31を生成してもよい。
【0095】
更に、入力データ2が動画データの場合には、動画の内容(人、物)が属性情報となる。また、動画が示す状況(ドライブ、会議、スポーツ、風景、街)を属性情報としてもよい。更に、動画の被写体である人の人数、年齢、性別や、物の数、色等を属性情報としてもよい。変換部17は、これらの属性情報を示すテキスト31を生成する。
【0096】
また、データベース28(図10図12図13)の検索対象はタグ情報27に限定されず、ファイル名、データ種別、内容をテキスト検索の対象としてもよい。
【0097】
<ハードウェア構成>
次に、本実施形態に係るデータ保管装置4のハードウェア構成について説明する。
【0098】
図14は、本実施形態に係るデータ保管装置4のハードウェア構成図である。図14に示すように、データ保管装置4は、記憶装置4a、メモリ4b、プロセッサ4c、通信インターフェース4d、及び媒体読み取り装置4eを有する。これらの各部はバス4gにより相互に接続される。
【0099】
このうち、記憶装置4aは、HDD(Hard Disk Drive)やSSD(Solid State Drive)等の不揮発性の記憶装置であって、本実施形態に係るデータ保管プログラム40を記憶する。
【0100】
なお、データ保管プログラム40をコンピュータが読み取り可能な記録媒体4fに記録させておき、プロセッサ4cに記録媒体4fのデータ保管プログラム40を読み取らせるようにしてもよい。
【0101】
そのような記録媒体4fとしては、例えばCD-ROM(Compact Disc - Read Only Memory)、DVD(Digital Versatile Disc)、及びUSB(Universal Serial Bus)メモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体4fとして使用してもよい。
【0102】
更に、公衆回線、インターネット、及びLAN(Local Area Network)等に接続された装置にデータ保管プログラム40を記憶させてもよい。その場合は、プロセッサ4cがそのデータ保管プログラム40を読み出して実行すればよい。
【0103】
一方、メモリ4bは、DRAM(Dynamic Random Access Memory)等のようにデータを一時的に記憶するハードウェアであって、その上にデータ保管プログラム40が展開される。
【0104】
プロセッサ4cは、データ保管装置4の各部を制御するCPU(Central Processing Unit)やGPU(Graphical Processing Unit)である。そのプロセッサ4cがメモリ4bと協働してデータ保管プログラム40を実行することにより図1の処理部12が実現される。
【0105】
また、図1の記憶部13は、記憶装置4aとメモリ4bにより実現される。更に、通信インターフェース4dは、データ保管装置4をネットワーク10に接続するためのNIC(Network Interface Card)等のハードウェアである。
【0106】
そして、媒体読み取り装置4eは、記録媒体4fに記録されているデータを読み取るためのUSBリーダ等のハードウェアである。
【0107】
本発明は、上述した実施形態に限定されるものではなく、更に様々な変形が可能である。例えば、上述した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある変形例の一部を他の変形例に置き換えたり、変形例を組み合わせたりすることが可能である。
【0108】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【0109】
1…データ保管システム、2…入力データ、3…端末装置、4…データ保管装置、10…ネットワーク、11…通信部、12…処理部、13…記憶部、15…取得部、16…分類部、17…変換部、18…生成部、19…保管処理部、20…特徴情報格納部、21…変換情報格納部、22…検索部、25…特徴情報、26…変換情報、27…タグ情報、28…データベース、31…テキスト、32…テキスト情報、40…データ保管プログラム。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14