JP7345897B2 - データ保管装置、データ保管方法、及びデータ保管プログラム - Google Patents

Description

データ保管装置、データ保管方法、及びデータ保管プログラムに関する。

従来、銀行や保険等の様々な業界において、顧客が手書きで文字を記入するための帳票が使用されている。手書きの文字をコンピュータが処理可能なテキストデータに変換すると、コンピュータが帳票に対して様々な処理を実行することができる。

手書きの文字をテキストデータに変換するにはOCR(Optical character recognition)技術が用いられることが多い。但し、OCR技術は、罫線や文字の位置等を基準にしてテキストを抽出するため、罫線や文字の位置等の様式が異なる複数の帳票に同一のOCR技術を適用したのでは、これらの帳票からテキストを抽出するのが困難となる。この問題を解決するために、複数の帳票を様式ごとにクラスタリングし、同一のクラスタ内の帳票に対しては同一のOCR技術を使用することで、テキスト抽出の精度を高める方法が提案されている（特許文献１）。

特開２０２１－１２５０４０号公報

しかしながら、特許文献１の方法では単に帳票からテキストを抽出するに留まっており、抽出したテキストをコンピュータ内で活用する方法まで考慮されていない。更に、将来的には帳票等の紙媒体だけでなく、画像、音声、及び動画等の様々な種類の入力データから検索用のテキストを抽出したいというニーズが生まれる場合が想定される。この場合も、入力データの様式に関わらず精度よくテキストを抽出し、それをコンピュータ内で活用できるようにするのが望まれる。

本発明は、このような現状を鑑みてなされたものであり、様々な種類の入力データの内容を示すテキストをコンピュータ内で活用できるようにすることを目的とする。

本願は、上記課題の少なくとも一部を解決する手段を複数含んでいるが、その例を挙げるならば、以下のとおりである。

上記課題を解決すべく、本発明の一態様に係るデータ保管装置は、複数の入力データを取得する取得部と、前記入力データの特徴に基づいて、複数の前記入力データの各々を前記特徴ごとに複数のグループに分類する分類部と、前記入力データの内容をテキストに変換する複数の変換プログラムが前記グループごとに割り当てられており、複数の前記変換プログラムの各々を用いて前記入力データごとに前記内容を複数の前記テキストに変換する変換部と、複数の前記テキストに基づいて、前記入力データの前記内容を示すタグ情報を生成する生成部と、前記入力データを識別するデータ識別子と、当該入力データに係るタグ情報とを対応付けて記憶部に保管する保管処理部とを有する。

前記生成部は、複数の前記テキストの各々に出現する文字列のうち、出現する頻度が最も高い文字列を前記タグ情報として出力することができる。

複数の前記変換プログラムごとに、前記変換の精度の高さを示す重みが割り当てられており、前記生成部は、一つの前記入力データから変換された複数の前記テキストの各々に相異なる文字列が出現した場合に、前記重みが最も大きい前記変換プログラムが変換した前記テキストに出現した前記文字列を、当該入力データに対応したタグ情報として生成することができる。

前記分類部は、同一の前記特徴を有する複数の前記入力データを同一の前記グループに分類し、前記変換部は、前記分類部が同一の前記特徴を有する複数の前記入力データを同一の前記グループに分類した後に、同一の前記グループに属する複数の前記入力データの各々の前記内容を前記テキストに変換することができる。

前記グループは前記入力データの様式に対応しており、前記分類部は、前記入力データの様式と前記特徴とを対応付けた特徴情報を参照することにより、前記様式に対応した前記グループに前記入力データを分類し、前記変換部は、前記変換プログラムを識別するプログラム識別子と前記様式とを対応付けた変換情報を参照することにより、前記様式に対応した前記グループに複数の前記変換プログラムを割り当て、複数の前記グループのいずれにも属さない新たな前記様式を前記入力データが有する場合に、前記新たな様式と当該入力データの前記特徴とを対応付けて前記特徴情報に格納する特徴情報格納部と、新たな前記様式に対応した新たな複数の前記変換プログラムの各々の前記プログラム識別子を、新たな前記様式と対応付けて前記変換情報に格納する変換情報格納部とを更に有することができる。

前記入力データは、画像データ、音声データ、及び動画データのいずれかであり、前記変換プログラムは、前記入力データが画像データの場合には文字認識処理を含み、前記入力データが音声データの場合には音声認識処理を含み、前記入力データが動画データの場合には画像認識処理を含むことができる。

前記入力データは、画像データ、音声データ、及び動画データのいずれかであり、前記複数の変換プログラムの少なくとも一つは、前記入力データの内容に関する属性情報を抽出し、前記属性情報をテキストに変換することができる。

本発明の他の態様に係るデータ保管方法は、コンピュータが、複数の入力データを取得するステップと、前記入力データの特徴に基づいて、複数の前記入力データの各々を前記特徴ごとに複数のグループに分類するステップと、前記入力データの内容をテキストに変換する複数の変換プログラムが前記グループごとに割り当てられており、複数の前記変換プログラムの各々を用いて前記入力データごとに前記内容を複数の前記テキストに変換するステップと、複数の前記テキストに基づいて、前記入力データの前記内容を示すタグ情報を生成するステップと、前記入力データを識別する識別子と、当該入力データに係る前記タグ情報とを対応付けて記憶部に保管するステップとを実行する。

本発明の更に他の態様に係るデータ保管プログラムは、複数の入力データを取得するステップと、前記入力データの特徴に基づいて、複数の前記入力データの各々を前記特徴ごとに複数のグループに分類するステップと、前記入力データの内容をテキストに変換する複数の変換プログラムが前記グループごとに割り当てられており、複数の前記変換プログラムの各々を用いて前記入力データごとに前記内容を複数の前記テキストに変換するステップと、複数の前記テキストに基づいて、前記入力データの前記内容を示すタグ情報を生成するステップと、前記入力データを識別する識別子と、当該入力データに係る前記タグ情報とを対応付けて記憶部に保管するステップとをコンピュータに実行させる。

本発明によれば、様々な種類の入力データの内容を示すテキストをコンピュータ内で活用できるようにすることができる。

図１は、本実施形態に係るデータ保管システムのシステム構成図である。 図２は、入力データの一例を示す模式図である。 図３は、入力データの他の例を示す模式図である。 図４は、特徴情報の模式図である。 図５は、入力データをグループに分類する方法について説明するための模式図である。 図６は、変換情報の模式図である。 図７は、OCRエンジンA-1の処理内容を示す模式図である。 図８は、生成部の処理内容について示す模式図である。 図９は、タグ情報の正確性を向上させる方法について示す模式図である 図１０は、データベースの模式図である。 図１１は、本実施形態に係るデータ保管方法のフローチャートである。 図１２は、入力データが音声データである場合のデータベースの模式図である。 図１３は、入力データが動画データである場合のデータベースの模式図である。 図１４は、本実施形態に係るデータ保管装置のハードウェア構成図である。

以下、本発明に係る一実施形態を図面に基づいて説明する。なお、一実施形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。また、以下の実施形態において、その構成要素（要素ステップ等も含む）は、特に明示した場合および原理的に明らかに必須であると考えられる場合等を除き、必ずしも必須のものではないことは言うまでもない。また、「Ａからなる」、「Ａよりなる」、「Ａを有する」、「Ａを含む」と言うときは、特にその要素のみである旨明示した場合等を除き、それ以外の要素を排除するものでないことは言うまでもない。同様に、以下の実施形態において、構成要素等の形状、位置関係等に言及するときは、特に明示した場合および原理的に明らかにそうでないと考えられる場合等を除き、実質的にその形状等に近似または類似するもの等を含むものとする。

＜データ保管システム＞
図１は、本実施形態に係るデータ保管システムのシステム構成図である。データ保管システム１は、画像データ、音声データ、及び動画データ等の入力データ２をキーワード等のテキストで検索できるようにするためのシステムであって、端末装置３とデータ保管装置４とを備える。

このうち、端末装置３は、テキスト検索を行うユーザが操作するコンピュータである。一例として、端末装置３は、PC(Personal Computer)、スマートフォン、及びタブレット型端末等のコンピュータである。以下では、入力データ２が、帳票を写した画像ファイルである場合を例にして説明する。この場合、不図示のスキャナが帳票をスキャンしてその画像ファイルを生成する。そして、端末装置３が、その画像ファイルを入力データ２として取得する。

一方、データ保管装置４は、ネットワーク１０を介して端末装置３に接続されたサーバやPC等のコンピュータである。なお、データ保管装置４は物理マシンに限定されず仮想マシンでもよい。なお、データ保管装置４の全ての機能を一つのコンピュータで実現せずに、物理的に分散して配置された複数のコンピュータでデータ保管装置４の機能を実現するようにしてもよい。更に、Google社やAWS(Amazon Web Service)が提供するAPI(Application Programing Interface)を利用して、データ保管装置４の各機能を実現してもよい。

この例では、データ保管装置４は、通信部１１、処理部１２、及び記憶部１３を備える。通信部１１は、データ保管装置４をネットワーク１０に接続するためのインターフェースである。

処理部１２は、データ保管装置４の各部を制御する。一例として、処理部１２は、取得部１５、分類部１６、変換部１７、生成部１８、保管処理部１９、特徴情報格納部２０、変換情報格納部２１、及び検索部２２を備える。

取得部１５は、ネットワーク１０を介して端末装置３から複数の入力データ２を取得し、それらを記憶部１３に格納する処理部である。なお、取得部１５が、端末装置３とは異なるコンピュータから入力データ２を取得してもよい。更に、データ保管装置４にスキャナを直接接続し、スキャナが出力した帳票の画像ファイルを取得部１５が入力データ２として取得してもよい。

図２は、入力データ２の一例を示す模式図である。ここでは、入力データ２の元となる帳票が生命保険の契約書である場合を例示してある。この場合、入力データ２には、契約者の欄２ａと被保険者の欄２ｂとが含まれる。

各欄２ａ、２ｂの位置は生命保険契約書の様式によって異なる。例えば、図２のように「A保険会社」の様式では、契約者の欄２ａは生命保険契約書の上部に位置し、被保険者の欄２ｂは生命保険契約書の中央部に位置する。

一方、図３は、入力データ２の他の例を示す模式図である。図３の例では、入力データ２の元となる帳票が、図２の「A保険会社」とは異なる「B保険会社」の生命保険契約書である場合を例示してある。図２の例とは異なり、図３の例では、契約者の欄２ａが生命保険契約書の左上部に位置し、かつ被保険者の欄２ｂが生命保険契約書の右上部に位置している。

また、図２と図３のいずれの場合であっても、各欄２ａ、２ｂには契約者の手書き文字が記述される。

再び図１を参照する。分類部１６は、入力データ２の特徴に基づいて、記憶部１３に格納されている複数の入力データ２の各々をそれらの特徴ごとに複数のグループに分類する処理部である。分類に際し、分類部１６は、記憶部１３に格納されている特徴情報２５を参照する。

図４は、特徴情報２５の模式図である。特徴情報２５は、入力データ２の「様式」と入力データ２の「特徴」とを対応付けた情報であって、データ保管システム１の管理者によって予め記憶部１３に格納される。入力データ２の「特徴」は特に限定されないが、本実施形態では生命保険契約書における各欄２ａ、２ｂの位置を入力データ２の「特徴」として採用する。また、「様式」は、各欄２ａ、２ｂの位置から推定される生命保険契約書の様式を示す。例えば、契約者の欄２ａの位置が「上部」であり、かつ被保険者の欄２ｂの位置が「中央部」の場合には、図２のような「A保険会社」の様式となる。

分類部１６は、入力データ２に含まれる罫線の位置に基づいて、入力データ２の「特徴」として各欄２ａ、２ｂの位置を特定する。そして、分類部１６は、特定した各欄２ａ、２ｂの位置に対応した「様式」を特徴情報２５に基づいて特定する。その後、分類部１６は、特定した「様式」ごとに複数の入力データ２を複数のグループに分類する。

図５は、入力データ２をグループに分類する方法について説明するための模式図である。ここでは、分類部１６は、「A生命保険会社」～「C生命保険会社」の各々の様式ごとに、記憶部１３にある全ての入力データ２をそれぞれ「グループA」～「グループC」に分類する。また、「A生命保険会社」～「C生命保険会社」のいずれの様式にも対応しない特徴を入力データ２が備えている場合は、分類部１６は、その入力データ２を「未分類」のグループに分類する。

再び図１を参照する。変換部１７は、OCRエンジンを用いることにより、入力データ２の手書きの内容をテキストに変換する処理部である。

なお、OCRエンジンは、入力データ２に含まれる罫線の位置等を基準にして手書き文字の位置を推定し、推定された位置にある手書き文字を文字認識処理で文字として認識することで、手書き文字をテキストに変換する変換プログラムである。

そのため、図２や図３のように相異なる様式の入力データ２に対して同一のOCRエンジンを用いると、入力データ２ごとに罫線の位置が異なってしまうため、OCRエンジンによるテキスト化の精度が低下するおそれがある。

そこで、本実施形態では、分類部１６が分類したグループごとに、当該グループに含まれる入力データ２に適したOCRエンジンを割り当てる。割り当て方法は特に限定されない。本実施形態では、記憶部１３に格納されている変換情報２６を利用して変換部１７が各グループにOCRエンジンを割り当てる。

図６は、変換情報２６の模式図である。変換情報２６は、複数のOCRエンジンの各々を一意に識別するプログラム名と、入力データ２の様式とを対応付けた情報であって、データ保管システム１の管理者によって予め記憶部１３に格納される。なお、プログラム名はプログラム識別子の一例である。

例えば、「A保険会社の様式」について考える。図６によれば、「A保険会社の様式」には「OCRエンジンA-1」、…、「OCRエンジンA-N」のN個のOCRエンジンが割り当てられている。これらのOCRエンジンは、図４の特徴情報２５において「A保険会社」の様式の特徴に適した変換プログラムである。例えば、「OCRエンジンA-1」は、契約者の欄２ａの位置が上部にあり、かつ被保険者の欄の位置が中央部にあることを前提としたOCRエンジンであり、これらの位置にある手書き文字を契約者情報や被保険者情報としてテキスト化する。「OCRエンジンA-2」、…、「OCRエンジンA-N」についても同様である。

なお、この例では手書き文字をテキストに変換する変換プログラムとしてOCRエンジンを採用したが、機械学習によって手書き文字をテキストに変換する変換プログラムを用いてもよい。

変換部１７は、変換情報２６を参照することにより、同一のグループに属する複数の入力データ２の各々に対し、そのグループに係る様式に対応した複数のOCRエンジンを適用することになる。例えば、ある入力データ２が「A保険会社」の様式に対応した「グループA」に属する場合を考える。この場合、変換部１７は、「OCRエンジンA-1」、…、「OCRエンジンA-N」のN個のOCRエンジンの各々を入力データ２に適用することになる。

図７は、OCRエンジンA-1の処理内容を示す模式図である。図７に示すように、OCRエンジンA-1は、「グループA」に属する入力データ２に含まれる手書き文字をテキスト３１に変換する。この例では、OCRエンジンA-1は、契約者の欄２ａ（図２参照）にある複数の罫線を基準として利用することで、「氏名」、「郵便番号」、「住所１」～「住所４」、及び「電話番号」の各項目に記述されている手書き文字をテキスト３１に変換する。なお、「氏名」は欄２ａにおける「氏名」であり、「郵便番号」は欄２ａにおける「郵便番号」である。また、「住所１」～「住所４」は、それぞれ欄２ａにおける「都道府県 市町村」、「区」、「番地」、及び「ビル名」である。そして、「電話番号」は欄２ａにおける「電話番号」である。

更に、OCRエンジンA-1は、入力データ２に対して画像認識処理を行うことにより入力データ２における押印の有無を判定し、その判定結果をテキスト３１の「押印の有無」の欄に記述する。

なお、手書き文字からテキストへの変換精度が不十分な場合には、テキスト３１に不正確な文字列が現れることがある。図７の例では、「住所１」は「神奈川県横浜市」となるべきであるが、OCRエンジンA-1の変換精度が不十分なため「押茉川県横浩市」となっている。

また、変換部１７は、「グループA」に属する入力データ２に対し、更に「OCRエンジンA2」、…、「OCRエンジンA-N」も適用する。これにより、変換部１７は、OCRエンジンの個数に等しいN個のテキスト３１を一つの入力データ２から生成することになる。

再び図１を参照する。生成部１８は、一つの入力データ２から得られた複数のテキスト３１に基づいて、当該入力データ２の内容を示すタグ情報２７を生成し、それを記憶部１３に格納する処理部である。

図８は、生成部１８の処理内容について示す模式図である。図８の例では、変換部１７が、「グループA」に属する一つの入力データ２に対し、「OCRエンジンA-1」～「OCRエンジンA-3」の３個のOCRエンジンを適用した場合を想定している。この場合、OCRエンジンの個数に等しい３個のテキスト３１が変換部１７によって生成される。

生成部１８は、これらの３個のテキスト３１に基づいて、入力データ２の内容を示すタグ情報２７を生成する。タグ情報２７の生成方法は特に限定されない。図８の例では、生成部１８は、３個のテキスト３１に出現する２文字以上の文字列のうち、出現する頻度が最も高い文字列を項目ごとに特定し、特定した文字列をタグ情報２７として生成する。

例えば、項目「住所１」について考える。項目「住所１」においては、黒太字で示す「横浜市」という文字列が２回出現している。一方、白抜きで示すその他の文字列については１回しか出現していないか、あるいは２回以上出現していてもその文字列の文字数は１文字である。よって、生成部１８は、項目「住所１」の内容を示す文字列として「横浜市」を特定する。

なお、項目「住所１」においては文字列「市」の出現頻度が３回であり、「横浜市」の出現頻度（２回）よりも多いが、「市」は１文字であって２文字未満であるため無視する。このように１文字の文字列を無視するのは、１文字では入力データ２の内容を十分に表すことができないためである。なお、１文字でも入力データ２の内容を十分に表すことができる場合は、１文字の文字列を無視しなくてもよい。

同様に、項目「住所２」では文字列「川区」の出現回数が２回であり、他の文字列よりも出現回数が高い。よって、生成部１８は、項目「住所２」の内容を示す文字列として「川区」を特定する。その他の項目の内容を示す文字列についても同様にして生成部１８が特定する。

そして、生成部１８は、上記のようにして項目ごとに生成した文字列を、入力データ２の内容を示すタグ情報２７として生成し、それを記憶部１３に格納する。

なお、タグ情報２７の生成方法は上記に限定されない。例えば、「OCRエンジンA-1」～「OCRエンジンA-3」の各々にテキスト変換の精度の高さを示す重みを割り当てておき、その重みに基づいて生成部１８がタグ情報２７を生成してもよい。

一例として、「OCRエンジンA-1」、「OCRエンジンA-2」、及び「OCRエンジンA-3」の各々の重みが「1」、「2」、及び「3」であり、値が大きいほどテキスト変換の精度が高くなるものとする。この場合に、各OCRエンジンに対応した３個のテキスト３１の各々に相異なる文字列が出現したときは、生成部１８は、重みが「3」で最も大きい「OCRエンジンA-3」に対応したテキスト３１の文字列をタグ情報２７として生成すればよい。これにより、テキスト変換の精度が高いOCRエンジンが生成したテキスト３１がタグ情報２７に含まれる可能性が高くなるため、タグ情報２７に含まれるテキストにより入力データ２の内容を良好に表すことができる。

タグ情報２７は、入力データ２を検索するときのキーワード集として機能するため、入力データ２の内容を正確に反映しているのが好ましい。そこで、例えば以下のようにしてタグ情報２７の正確性を向上させてもよい。

図９は、タグ情報２７の正確性を向上させる方法について示す模式図である。図９の例では、データ保管システム１の管理者が、「OCRエンジンA-2」を改良することにより、「OCRエンジンA-2」が生成するテキスト３１の精度を高める場合を想定している。これにより、複数のテキスト３１に基づいて生成されるテキスト情報３２の正確性が向上する。

また、データ保管システム１の管理者が、データ保管装置４に新たに「OCRエンジンA-4」を追加してもよい。これによりテキスト３１の個数が増えるため、テキスト３１に基づいて生成されるテキスト情報３２の正確性が向上する。なお、このように管理者がOCRエンジンの改良や追加を行わず、処理部１２がテキスト情報３２の正確性を向上させてもよい。例えば、機械学習によって手書き文字をテキストに変換する変換プログラム（OCRエンジンの一部に人工知能を使うものも含む）の場合、変換情報格納部２１は、上述したような生成部１８による複数の変換プログラムが出力したテキストの比較結果に基づき、学習用データ（正解データ、不正解データなど）を生成し、その学習用データを用いて各変換プログラムが機械学習（すなわち改良）を行ってもよい。また、変換情報格納部２１は、新規の変換プログラムを自動生成し、それを記憶部１３に追加してもよい。

再び図１を参照する。保管処理部１９は、ユーザがテキスト検索に使用するデータベース２８を記憶部１３に格納する処理部である。

図１０は、データベース２８の模式図である。図１０に示すように、データベース２８は、「ファイル名」、「データ種別」、「内容」、及び「タグ情報」の各々を対応付けた情報である。このうち、「ファイル名」は、複数の入力データ２の各々を一意に識別するデータ識別子の一例である。

また、「データ種別」は、入力データ２が画像、音声、及び動画のどのフォーマットであるかを示す文字列である。例えば、保管処理部１９は、入力データ２のファイル名の拡張子が「jpg」の場合にはデータ種別として「画像」を格納する。また、例えば拡張子が「mp3」の場合は、保管処理部１９は、データ種別として「音声」を格納する。そして、例えば拡張子が「mp4」の場合は、保管処理部１９は、データ種別として「動画」を格納する。

「内容」は入力データ２の内容であって、この例では「帳票」が「内容」となる。例えば、入力データ２の内容が帳票であることを示す情報を端末装置３が入力データ２のヘッダ部分に書き込んでおき、その情報に基づいて保管処理部１９が「内容」に「帳票」を格納し得る。

「タグ情報」は、生成部１８が生成したタグ情報２７である。

保管処理部１９は、このように「ファイル名」、「データ種別」、「内容」、及び「タグ情報」の各々が対応付けられたデータベース２８を記憶部１３に格納する。これにより、データ保管装置４の検索部２２が、端末装置３から検索キーワードを受け付けたときに、検索キーワードを含むタグ情報２７を特定し、そのタグ情報２７に対応するファイル名を端末装置３に返すことができる。

再び図１を参照する。特徴情報格納部２０は、前述の特徴情報２５を記憶部１３に格納する処理部である。

なお、図５に示したように、特徴情報２５に存在しない新しい特徴を入力データ２が備えている場合、当該入力データ２は「未分類」のグループに分類される。特徴情報格納部２０は、このように「未分類」のグループに分類された入力データ２の新しい特徴と新しい様式とを対応付けて特徴情報２５に格納する。例えば、特徴情報格納部２０は、「未分類」のグループに属する入力データ２を、機械学習によりクラスタリングし、各クラスタを代表する入力データ２の特徴と様式とを対応付けて特徴情報２５に格納する。

一方、変換情報格納部２１は、前述の変換情報２６を記憶部１３に格納する処理部である。前述のように「未分類」のグループが存在する場合は、変換情報格納部２１は、「未分類」のグループに属する入力データ２が備える新しい様式と、その様式に適したOCRエンジンのプログラム名とを対応付けて変換情報２６に格納する。また、上述したように、変換情報格納部２１は、既存の変換プログラムを機械学習等により改良してもよい。また、変換情報格納部２１は、新しい様式に対応した変換プログラムを自動生成し、それを記憶部１３に格納してもよい。

検索部２２は、端末装置３から検索キーワードを受け付けて、その検索キーワードをキーにしてデータベース２８を検索する処理部である。例えば、検索部２２は、検索キーワードと一致するテキスト３１を含むタグ情報２７を特定し、そのタグ情報２７に対応した入力データ２のファイル名を端末装置３に返す。この場合、端末装置３は、自装置が実行するwebブラウザから検索キーワードを検索部２２に通知し、検索結果であるファイル名をwebブラウザで取得し得る。

なお、検索部２２の機能を端末装置３に持たせてもよい。その場合、検索部２２の機能を実現するためのアプリケーションプログラムを端末装置３が実行すればよい。

＜データ保管方法＞
次に、本実施形態に係るデータ保管方法について説明する。

図１１は、本実施形態に係るデータ保管方法のフローチャートである。まず、取得部１５が、ネットワーク１０を介して端末装置３から入力データ２を取得し、それを記憶部１３に格納する（ステップＳ１）。

次に、分類部１６が、特徴情報２５に基づいて、入力データ２をその特徴に応じたグループに分類する（ステップＳ２）。例えば、分類部１６は、図５に示したように入力データ２の様式ごとに各入力データ２をグループに分類する。なお、入力データ２の特徴が特徴情報２５に存在しない新たな特徴である場合は、分類部１６は、当該入力データ２を「未分類」のグループに分類する。

次いで、分類部１６が、取得部１５が取得していない入力データ２がまだあるかを判定する（ステップＳ３）。例えば、取得部１５が入力データ２を取得する前に予め入力データ２の総数を端末装置３から取得しておき、記憶部１３に格納されている入力データ２の個数が当該総数未満の場合、入力データはまだある（YES）と判定される。このようにステップＳ３で入力データはまだある（YES）と判定された場合にはステップＳ１に戻る。

一方、ステップＳ３でNOと判定された場合は、分類部１６が、「未分類」のグループがあるかを判定する（ステップＳ４）。ここで「未分類」のグループがある（YES）と判定された場合はステップＳ５に移る。

ステップＳ５においては、特徴情報格納部２０が、「未分類」のグループに含まれる各入力データ２の新たな特徴と新たな様式とを対応付けて特徴情報２５に格納する。

次いで、変換情報格納部２１が、新たな様式に適した新たな複数のOCRエンジンの各々のプログラム名を、新たな様式と対応付けて変換情報２６に格納する（ステップＳ６）。その後、ステップＳ２に戻る。

一方、ステップＳ４において「未分類」のグループがない（NO）と判定された場合にはステップＳ７に移る。ステップＳ７においては、変換部１７が、変換情報２６を参照することにより、同一のグループに係る様式に対応した複数のOCRエンジンを特定する。そして、変換部１７は、特定した複数のOCRエンジンを用いて、同一のグループに属する各々の入力データ２の手書きの内容を複数のテキスト３１に変換する。そして、変換部１７は、複数のグループごとにこのようなテキスト３１への変換を行う。

このようにステップＳ２でグループ化を終えた後にテキスト３１への変換を行うことで、一つのグループ内の全ての入力データ２に対し、当該グループに係る複数のOCRエンジンを連続して適用することができる。その結果、グループ化とテキスト３１への変換とを交互に行う場合と比較して効率的にテキスト３１を生成することができる。

次に、生成部１８が、図８に例示した方法に従って入力データ２ごとにタグ情報２７を生成し、それを記憶部１３に格納する（ステップＳ８）。

続いて、保管処理部１９が、入力データ２を識別するファイル名と、当該入力データ２に係るタグ情報２７とを対応付けてデータベース２８に格納する（ステップＳ９）。以上により、本実施形態に係るデータ保管方法の基本的な処理を終える。

上記した本実施形態によれば、保管処理部１９が、入力データ２のファイル名とタグ情報２７と対応付けてデータベース２８に格納する。そのため、検索部２２が、検索キーワードと一致するテキスト３１を含むタグ情報２７を特定し、そのタグ情報に対応したファイル名を検索できる。その結果、入力データ２の内容を示すテキスト３１を端末装置３やデータ保管装置４等のコンピュータ内で活用することができる。

しかも、図６に示したように、本実施形態では、変換部１７が、罫線の位置等が異なる複数の様式ごとに、当該罫線を基準にして手書き文字の位置を推定するOCRエンジンを割り当てる。そのため、罫線の位置等が異なる複数の様式に同一のOCRエンジンを割り当てる場合と比較して、OCRエンジンが手書き文字を高い精度でテキストに変換することができる。

更に、図１１に示したように、特徴情報２５には存在しない新たな様式の入力データ２を取得部１５が取得した場合は、特徴情報格納部２０が、新たな様式と入力データ２の特徴とを対応付けて特徴情報２５に格納する（ステップＳ５）。更に、変換情報格納部２１が、新たな様式に対応した新たな複数のOCRエンジンの各々のプログラム名を、新たな様式と対応付けて変換情報２６に格納する（ステップＳ６）。これにより、新たな様式の入力データ２を取得部１５が取得した場合であっても、特徴情報２５に基づいて分類部１６が当該入力データ２をグループに分類できる。更に、変換情報２６に基づいて変換部１７が当該入力データ２の内容をテキスト３１に変換できる。

＜その他の実施形態＞
入力データ２は画像データに限定されず、音声データや動画データであってもよい。

図１２は、入力データ２が音声データである場合のデータベース２８の模式図である。ここでは、コールセンタが受信した電話の音声データが入力データ２である場合を想定している。

この場合、分類部１６は、音声データに含まれる「〇〇コールセンタです」という発話を特定し、コールセンタの名前を示す「〇〇」の部分を当該入力データ２の特徴として認識する。そして、分類部１６は、当該特徴とコールセンタの名前とを対応付けた特徴情報２５（図４参照）に基づいて、コールセンタの名前ごとに入力データ２を分類する。

更に、変換部１７が入力データ２に含まれる音声をテキストに変換し、そのテキストを音声キーワードとして含むタグ情報２７を生成部１８が生成する。例えば、変換部１７は、音声認識処理を含む変換プログラムや機械学習によって音声をテキストに変換する。これにより、検索部２２が、検索キーワードを音声キーワードとして含むタグ情報２７を特定し、そのタグ情報２７に対応する音声データのファイル名を端末装置３に返すことができる。なお、変換部１７が、APIを介して外部のコンピュータシステムの音声認識処理に音声を送信し、外部のコンピュータシステムが変換したテキストを取得してもよい。

図１３は、入力データ２が動画データである場合のデータベース２８の模式図である。ここでは、ドライブレコーダが記録した動画データが入力データ２である場合を想定している。

この場合、分類部１６は、動画データに含まれる画像の明度を当該動画の特徴として特定する。そして、分類部１６は、明度と、朝・昼・夜等の時間帯とを対応付けた特徴情報２５（図４参照）に基づいて、時間帯ごとに入力データ２を分類する。

更に、変換部１７が、画像中の物体を認識してそれをテキストに変換する画像認識処理と、音声をテキストに変換する音声認識処理とを行う変換プログラムを入力データ２に適用する。このとき、朝・昼・夜の各時間帯に適した変換プログラムのプログラム名と時間帯とを対応付けて変換情報２６に格納し、各時間帯に適した変換プログラムを変換部１７が入力データ２に適用する。なお、変換部１７が、APIを介して外部のコンピュータシステムの画像認識処理と音声認識処理の各々に画像と音声とを送信し、外部のコンピュータシステムから物体の認識結果やテキストを取得してもよい。

そして、生成部１８が、画像認識処理で得られた認識物体と、音声認識処理で得られた音声キーワードとを含むタグ情報２７を生成する。なお、音声認識処理や画像認識処理として機械学習を採用してもよい。これにより、検索部２２が、検索キーワードを音声キーワードや認識物体として含むタグ情報２７を特定し、そのタグ情報２７に対応する動画データのファイル名を端末装置３に返すことができる。

なお、タグ情報２７の元となるテキスト３１は、OCR、音声認識、及び画像認識で得られたテキストに限定されない。例えば、変換部１７が、何等かの解析エンジン（変換プログラム）によって様々な属性情報（メタ情報）を入力データ２から抽出し、これを人間が理解できるテキスト３１に変換してもよい。そして、このテキスト３１に基づいて生成部１８がタグ情報２７を生成してもよい。属性情報を抽出する解析エンジン（変換プログラム）は、例えば機械学習や深層学習に基づく人工知能技術を利用したものがある。

更に、変換部１７が、APIを通じて外部の解析サービスにアクセスし、その解析サービスを利用して入力データ２からテキスト３１を生成してもよい。更に、変換部１７が自動的にインターネット検索をすることで、入力データ２を表現するテキスト３１を生成してもよい。

更に、入力データ２の内容も上記に限定されない。例えば、入力データ２が音声データの場合には、会話、音楽、及び環境音等が入力データ２に含まれ得る。この場合、変換部１７が、解析エンジンあるいは外部の解析サービスを用いて、会話、音楽、及び環境音等の属性情報を取得して、その属性情報をテキスト３１に変換してもよい。また、会話の場合には、コールセンタや会議等における会話の状況を示す属性情報を変換部１７が解析エンジンあるいは外部の解析サービスを用いて取得してもよい。そのような属性情報としては、例えば参加者の人数、年齢、及び性別声紋情報がある。更に、音楽の場合には、曲名、作曲家、曲調、ジャンル、一部の波形・音符等が属性情報となる。

また、入力データ２は、静止画を示す画像データであってもよい。その場合、変換部１７は、画像の種別、例えば書類、絵画、及び写真等の種別に係る属性情報を示すテキスト３１を生成する。更に、変換部１７が、画像に含まれる人物や風景等の属性情報を示すテキスト３１を生成してもよい。

更に、入力データ２が動画データの場合には、動画の内容（人、物）が属性情報となる。また、動画が示す状況（ドライブ、会議、スポーツ、風景、街）を属性情報としてもよい。更に、動画の被写体である人の人数、年齢、性別や、物の数、色等を属性情報としてもよい。変換部１７は、これらの属性情報を示すテキスト３１を生成する。

また、データベース２８（図１０、図１２、図１３）の検索対象はタグ情報２７に限定されず、ファイル名、データ種別、内容をテキスト検索の対象としてもよい。

＜ハードウェア構成＞
次に、本実施形態に係るデータ保管装置４のハードウェア構成について説明する。

図１４は、本実施形態に係るデータ保管装置４のハードウェア構成図である。図１４に示すように、データ保管装置４は、記憶装置４ａ、メモリ４ｂ、プロセッサ４ｃ、通信インターフェース４ｄ、及び媒体読み取り装置４ｅを有する。これらの各部はバス４ｇにより相互に接続される。

このうち、記憶装置４ａは、HDD(Hard Disk Drive)やSSD(Solid State Drive)等の不揮発性の記憶装置であって、本実施形態に係るデータ保管プログラム４０を記憶する。

なお、データ保管プログラム４０をコンピュータが読み取り可能な記録媒体４ｆに記録させておき、プロセッサ４ｃに記録媒体４ｆのデータ保管プログラム４０を読み取らせるようにしてもよい。

そのような記録媒体４ｆとしては、例えばCD-ROM(Compact Disc - Read Only Memory)、DVD(Digital Versatile Disc)、及びUSB(Universal Serial Bus)メモリ等の物理的な可搬型記録媒体がある。また、フラッシュメモリ等の半導体メモリやハードディスクドライブを記録媒体４ｆとして使用してもよい。

更に、公衆回線、インターネット、及びLAN(Local Area Network)等に接続された装置にデータ保管プログラム４０を記憶させてもよい。その場合は、プロセッサ４ｃがそのデータ保管プログラム４０を読み出して実行すればよい。

一方、メモリ４ｂは、DRAM(Dynamic Random Access Memory)等のようにデータを一時的に記憶するハードウェアであって、その上にデータ保管プログラム４０が展開される。

プロセッサ４ｃは、データ保管装置４の各部を制御するCPU(Central Processing Unit)やGPU(Graphical Processing Unit)である。そのプロセッサ４ｃがメモリ４ｂと協働してデータ保管プログラム４０を実行することにより図１の処理部１２が実現される。

また、図１の記憶部１３は、記憶装置４ａとメモリ４ｂにより実現される。更に、通信インターフェース４ｄは、データ保管装置４をネットワーク１０に接続するためのNIC(Network Interface Card)等のハードウェアである。

そして、媒体読み取り装置４ｅは、記録媒体４ｆに記録されているデータを読み取るためのUSBリーダ等のハードウェアである。

本発明は、上述した実施形態に限定されるものではなく、更に様々な変形が可能である。例えば、上述した実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある変形例の一部を他の変形例に置き換えたり、変形例を組み合わせたりすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１…データ保管システム、２…入力データ、３…端末装置、４…データ保管装置、１０…ネットワーク、１１…通信部、１２…処理部、１３…記憶部、１５…取得部、１６…分類部、１７…変換部、１８…生成部、１９…保管処理部、２０…特徴情報格納部、２１…変換情報格納部、２２…検索部、２５…特徴情報、２６…変換情報、２７…タグ情報、２８…データベース、３１…テキスト、３２…テキスト情報、４０…データ保管プログラム。

Claims (11)

1. 画像データ、音声データ、及び動画データのいずれかである複数の入力データを取得する取得部と、
   前記入力データの特徴に基づいて、複数の前記入力データの各々を前記特徴ごとに複数のグループに分類する分類部と、
   前記入力データの内容をテキストに変換する複数の変換プログラムであって、前記画像データに対しては文字認識処理を含み、前記音声データに対しては音声認識処理を含み、前記動画データに対しては画像認識処理を含む変換プログラムが前記グループごとに割り当てられており、複数の前記変換プログラムの各々を用いて前記入力データごとに前記内容を複数の前記テキストに変換する変換部と、
   複数の前記テキストに基づいて、前記入力データの前記内容を示すタグ情報を生成する生成部と、
   前記入力データを識別するデータ識別子と、当該入力データに係るタグ情報とを対応付けて記憶部に保管する保管処理部と、
   を有することを特徴とするデータ保管装置。
2. 請求項１に記載のデータ保管装置であって、
   前記複数の変換プログラムの少なくとも一つは、前記入力データの前記内容に関する属性情報を抽出し、前記属性情報を前記テキストに変換することを特徴とするデータ保管装置。
3. 請求項１又は請求項２に記載のデータ保管装置であって、
   前記分類部は、前記音声データに含まれる発話の内容ごとに前記音声データを分類することを特徴とするデータ保管装置。
4. 請求項１又は請求項２に記載のデータ保管装置であって、
   前記分類部は、前記動画データが録画された時間帯ごとに当該動画データを分類することを特徴とするデータ保管装置。
5. 請求項１又は請求項２に記載のデータ保管装置であって、
   前記保管処理部は、前記入力データが前記画像データ、前記音声データ、及び前記動画データのうちのどれであるかを示すデータ種別と、前記データ識別子と、前記タグ情報とを対応付けて前記記憶部に保管することを特徴とするデータ保管装置。
6. 請求項１～５のいずれか一項に記載のデータ保管装置であって、
   前記生成部は、複数の前記テキストの各々に出現する文字列のうち、出現する頻度が最も高い文字列を前記タグ情報として出力することを特徴とするデータ保管装置。
7. 請求項１～６のいずれか一項に記載のデータ保管装置であって、
   複数の前記変換プログラムごとに、前記変換の精度の高さを示す重みが割り当てられており、
   前記生成部は、一つの前記入力データから変換された複数の前記テキストの各々に相異なる文字列が出現した場合に、前記重みが最も大きい前記変換プログラムが変換した前記テキストに出現した前記文字列を、当該入力データに対応した前記タグ情報として生成することを特徴とするデータ保管装置。
8. 請求項１～７のいずれか一項に記載のデータ保管装置であって、
   前記分類部は、同一の前記特徴を有する複数の前記入力データを同一の前記グループに分類し、
   前記変換部は、前記分類部が同一の前記特徴を有する複数の前記入力データを同一の前記グループに分類した後に、同一の前記グループに属する複数の前記入力データの各々の前記内容を前記テキストに変換することを特徴とするデータ保管装置。
9. 請求項１～８のいずれか一項に記載のデータ保管装置であって、
   前記グループは前記入力データの様式に対応しており、
   前記分類部は、前記入力データの前記様式と前記特徴とを対応付けた特徴情報を参照することにより、前記様式に対応した前記グループに前記入力データを分類し、
   前記変換部は、前記変換プログラムを識別するプログラム識別子と前記様式とを対応付けた変換情報を参照することにより、前記様式に対応した前記グループに複数の前記変換プログラムを割り当て、
   複数の前記グループのいずれにも属さない新たな前記様式を前記入力データが有する場合に、前記新たな様式と当該入力データの前記特徴とを対応付けて前記特徴情報に格納する特徴情報格納部と、
   新たな前記様式に対応した新たな複数の前記変換プログラムの各々の前記プログラム識別子を、新たな前記様式と対応付けて前記変換情報に格納する変換情報格納部とを更に有することを特徴とするデータ保管装置。
10. コンピュータが、
    画像データ、音声データ、及び動画データのいずれかである複数の入力データを取得するステップと、
    前記入力データの特徴に基づいて、複数の前記入力データの各々を前記特徴ごとに複数のグループに分類するステップと、
    前記入力データの内容をテキストに変換する複数の変換プログラムであって、前記画像データに対しては文字認識処理を含み、前記音声データに対しては音声認識処理を含み、前記動画データに対しては画像認識処理を含む変換プログラムが前記グループごとに割り当てられており、複数の前記変換プログラムの各々を用いて前記入力データごとに前記内容を複数の前記テキストに変換するステップと、
    複数の前記テキストに基づいて、前記入力データの前記内容を示すタグ情報を生成するステップと、
    前記入力データを識別する識別子と、当該入力データに係る前記タグ情報とを対応付けて記憶部に保管するステップと、
    を実行することを特徴とするデータ保管方法。
11. 画像データ、音声データ、及び動画データのいずれかである複数の入力データを取得するステップと、
    前記入力データの特徴に基づいて、複数の前記入力データの各々を前記特徴ごとに複数のグループに分類するステップと、
    前記入力データの内容をテキストに変換する複数の変換プログラムであって、前記画像データに対しては文字認識処理を含み、前記音声データに対しては音声認識処理を含み、前記動画データに対しては画像認識処理を含む変換プログラムが前記グループごとに割り当てられており、複数の前記変換プログラムの各々を用いて前記入力データごとに前記内容を複数の前記テキストに変換するステップと、
    複数の前記テキストに基づいて、前記入力データの前記内容を示すタグ情報を生成するステップと、
    前記入力データを識別する識別子と、当該入力データに係る前記タグ情報とを対応付けて記憶部に保管するステップと、
    をコンピュータに実行させるためのデータ保管プログラム。

Images