特開2022-92337 | 知財ポータル「IP Force」

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

▶ 近畿日本鉄道株式会社の特許一覧

特開2022-92337乗車判定システム、設定プログラム、携帯端末、及び、管理サーバ

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2022092337

(43)【公開日】2022-06-22

(54)【発明の名称】乗車判定システム、設定プログラム、携帯端末、及び、管理サーバ

(51)【国際特許分類】

G06F 16/53 20190101AFI20220615BHJP

H04N 5/232 20060101ALI20220615BHJP

G06T 7/11 20170101ALI20220615BHJP

G06T 7/00 20170101ALI20220615BHJP

G01C 21/26 20060101ALI20220615BHJP

G08G 1/005 20060101ALI20220615BHJP

G06Q 50/10 20120101ALI20220615BHJP

【ＦＩ】

G06F16/53

H04N5/232 060

G06T7/11

G06T7/00 650Z

G01C21/26 P

G08G1/005

G06Q50/10

【審査請求】有

【請求項の数】10

【出願形態】ＯＬ

(21)【出願番号】P 2020205099

(22)【出願日】2020-12-10

(11)【特許番号】

(45)【特許公報発行日】2022-04-22

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＪＡＶＡＳＣＲＩＰＴ

(71)【出願人】

【識別番号】515332975

【氏名又は名称】近畿日本鉄道株式会社

(74)【代理人】

【識別番号】100100376

【弁理士】

【氏名又は名称】野中誠一

(74)【代理人】

【識別番号】100142077

【弁理士】

【氏名又は名称】板谷真之

(74)【代理人】

【識別番号】100143199

【弁理士】

【氏名又は名称】磯邉毅

(72)【発明者】

【氏名】伊東剛志

(72)【発明者】

【氏名】古川真則

(72)【発明者】

【氏名】溝口雄斗

【テーマコード（参考）】

2F129

5B175

5C122

5H181

5L049

5L096

【Ｆターム（参考）】

2F129AA02

2F129CC31

2F129CC33

2F129EE21

2F129EE52

2F129EE82

2F129EE88

2F129EE89

2F129FF11

2F129FF20

2F129FF32

2F129FF47

2F129FF49

2F129FF66

2F129FF70

2F129FF73

2F129FF75

2F129HH12

2F129HH35

5B175DA02

5B175HB03

5B175JC07

5C122DA09

5C122EA63

5C122FA08

5C122FA11

5C122FH11

5C122GC14

5C122GC54

5H181AA27

5H181BB04

5H181CC04

5H181EE05

5L049CC17

5L096BA08

5L096BA17

5L096CA02

5L096DA02

5L096FA44

5L096KA09

(57)【要約】

【課題】利用者が乗車選択した乗り物の選択の正否を、簡易且つ高精度に判定できる乗車判定システムを提供する。
【解決手段】列車情報を提供する情報提供サーバ２から必要な列車情報を取得する携帯端末１と、携帯端末１から撮影画像を文字情報と共に取得する管理サーバ３と、を有し、管理サーバ３は、所定のシャッター速度、携帯端末１で規定されている絞り値、及び、シャッター速度と絞り値に対応して規定されるＩＳＯ感度の撮影条件で撮影された撮影画像を受けて、その撮影画像が、文字情報との関係で適切か否かの判定結果を返信する。
【選択図】図４

【特許請求の範囲】

【請求項1】

交通機関の交通情報を提供する情報提供サーバと、前記情報提供サーバから必要な交通情報を取得可能に構成された携帯端末と、前記携帯端末から、交通情報に関する撮影画像と、これに対応する文字情報を取得可能に構成された管理サーバと、を有して構成され、
前記管理サーバは、所定のシャッター速度、前記携帯端末で規定されている絞り値、及び、前記シャッター速度と前記絞り値に対応して規定される所定のＩＳＯ感度の撮影条件で撮影された撮影画像を受けて、その撮影画像が、前記文字情報との関係で適切か否かの判定結果を、前記携帯端末に返信するよう構成されている乗車判定システム。

【請求項2】

交通機関の交通情報を提供する情報提供サーバと、前記情報提供サーバから必要な交通情報を取得可能に構成された携帯端末と、前記携帯端末から、交通情報に関する撮影画像と、これに対応する文字情報を取得可能に構成された管理サーバと、を有して構成され、
前記管理サーバは、連写撮影された複数枚の撮影画像か、動画撮影された動画フレームの撮影画像を受けて、その撮影画像が、前記文字情報との関係で適切か否かの判定結果を、前記携帯端末に返信するよう構成されている乗車判定システム。

【請求項3】

前記文字情報を特定可能なＩＤ情報に対応して、一又は複数個の特徴量を記憶する特徴パラメータテーブルを備えて構成され、
前記特徴量は、前記携帯端末から受信する可能性のある撮影画像ごとに予め注出されて、前記特徴パラメータテーブルに記憶されている請求項１又は２に記載の乗車判定システム。

【請求項4】

前記管理サーバが取得した撮影画像が、前記文字情報との関係で適切か否かの判定は、
前記撮影画像から注出される特徴量と、前記特徴パラメータテーブルに記憶されている特徴量と、を比較して実行される請求項３に記載の乗車判定システム。

【請求項5】

前記特徴量は、撮影画像に含まれている、交通機関の行先及び／又は種別に関して注出される請求項３又は４に記載の乗車判定システム。

【請求項6】

交通機関の行先と、当該交通機関の種別とに関する複数の組合せに対応して、組合せ毎に前記ＩＤ情報が付されている請求項５に記載の乗車判定システム。

【請求項7】

前記携帯端末には、所定のシャッター速度、当該携帯端末で規定されている絞り値、及び、前記シャッター速度と前記絞り値に対応して規定される所定のＩＳＯ感度の撮影条件を設定する設定プログラムがインストールされている請求項１に記載の乗車判定システム。

【請求項8】

所定のシャッター速度、携帯端末で規定されている絞り値、及び、前記シャッター速度と前記絞り値に対応して規定される所定のＩＳＯ感度の撮影条件を前記携帯端末に設定する設定プログラム。

【請求項9】

請求項８に記載の設定プログラムがインストールされた携帯端末。

【請求項10】

所定のシャッター速度、携帯端末で規定されている絞り値、及び、前記シャッター速度と前記絞り値に対応して規定される所定のＩＳＯ感度の撮影条件で撮影された撮影画像を、これに対応する文字情報と共に、前記携帯端末から受けて、その撮影画像が、前記文字情報との関係で適切か否かの判定結果を、前記携帯端末に返信するよう構成されている管理サーバ。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、乗車しようとしている乗り物が、正しいか否かを、簡易、且つ確実に判定できる乗車判定システムに関し、特に、旅行客に対して好適に機能する。

【背景技術】

【0002】

現地の地理に明るくない観光客にとって、乗車すべき列車やバスを正確に把握することは容易でなく、特に、外国人観光客にとっては、その困難が顕著である。そこで、鉄道駅員などの係員は、観光客から頻繁に質問を受けることになるが、労働力の不足が問題視される中で、このまま、人による対応を続けた場合、サービスレベルを維持するのが難しくなるおそれがある。

【0003】

そこで、かかる点を考慮して、携帯端末のカメラで撮影した車両や案内表示板の画像を判定して、携帯端末に適切な情報を返信するシステムも提案されている（特許文献１～特許文献２）。

【0004】

例えば、特許文献１には、「（端末装置から受けた経路探索条件を満たす、出発地から目的地までの案内経路を探索して）案内経路（データ）を取得する第１手段と、撮影部を制御して交通機関の乗車案内表示物の撮影画像を取得する第２手段と、上記撮影画像中の表示内容を抽出する第３手段と、上記案内経路と、上記表示内容から特定された路線、駅名および進行方向のうち少なくとも１つと、に基づいて、上記路線が適切であるか否かなどを含む案内情報を生成する第４手段と、上記案内情報を出力する第５手段と、を備えた情報処理システム」が開示されている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特許第６０１７６３６号公報

【特許文献2】特許第５７７５０７６号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

この特許文献１に記載の構成では、案内経路を取得することが必須要件となっているが、第１手段や第４手段を実現することが、現実的には容易でない。この点を、具体的に確認すると、先ず、利用者は、端末装置を操作して出発地と目的地とを含む経路探索条件を、ナビゲーションサーバへ送信する煩雑な処理が必要となる。

【0007】

しかも、ナビゲーションサーバでは、経路探索条件を満たす出発地から目的地までの案内経路を、交通網データベースから探索して、案内経路データを生成する必要があり、この処理も、ナビゲーションサーバにとって大きな処理負担となる。

【0008】

かかる点を考慮すると、利用者の処理負担が少なく、且つ、サーバ側の処理負担も軽いシステムの完成が望まれるところである。特に、携帯端末の内蔵カメラを最適に動作させることができるシステムの完成が望まれる。

【0009】

本発明は、上記の課題に鑑みてなされたものであって、携帯端末の内蔵カメラを最適に動作させることで、利用者が乗車選択した乗り物の選択の正否を、簡易且つ高精度に判定できる乗車判定システムを提供することを目的とする。

【課題を解決するための手段】

【0010】

上記の目的を達成するため、請求項１に係る乗車判定システムは、交通機関の交通情報を提供する情報提供サーバと、前記情報提供サーバから必要な交通情報を取得可能に構成された携帯端末と、前記携帯端末から、交通情報に関する撮影画像と、これに対応する文字情報を取得可能に構成された管理サーバと、を有して構成され、前記管理サーバは、所定のシャッター速度、前記携帯端末で規定されている絞り値、及び、前記シャッター速度と前記絞り値に対応して規定される所定のＩＳＯ感度の撮影条件で撮影された撮影画像を受けて、その撮影画像が、前記文字情報との関係で適切か否かの判定結果を、前記携帯端末に返信するよう構成されている。

【0011】

また、請求項２に係る乗車判定システムは、交通機関の交通情報を提供する情報提供サーバと、前記情報提供サーバから必要な交通情報を取得可能に構成された携帯端末と、前記携帯端末から、交通情報に関する撮影画像と、これに対応する文字情報を取得可能に構成された管理サーバと、を有して構成され、前記管理サーバは、連写撮影された複数枚の撮影画像か、動画撮影された動画フレームの撮影画像を受けて、その撮影画像が、前記文字情報との関係で適切か否かの判定結果を、前記携帯端末に返信するよう構成されている。

【0012】

上記した何れの発明でも、交通情報に関する撮影画像が、これに対応する文字情報と共に、携帯端末から送信されるので、管理サーバは、撮影画像と文字情報の整合性を判定するだけでよく、制御負担が大幅に軽減される。すなわち、管理サーバは、与えられた条件（経路探索条件）を満たす出発地から目的地までの案内経路を探索する必要は全くない。

【0013】

また、管理サーバは、撮影画像と共に、これに対応する文字情報を携帯端末から受けるので、文字認識処理を経ることなく、撮影画像と文字情報だけで、利用者が乗車選択した乗り物の選択の正否情報を返信することができる。

【0014】

一方、本発明は、所定のシャッター速度、携帯端末で規定されている絞り値、及び、前記シャッター速度と前記絞り値に対応して規定される所定のＩＳＯ感度の撮影条件を前記携帯端末に設定する設定プログラム、又は、前記設定プログラムがインストールされた携帯端末でもある。

【0015】

また、本発明は、所定のシャッター速度、携帯端末で規定されている絞り値、及び、前記シャッター速度と前記絞り値に対応して規定される所定のＩＳＯ感度の撮影条件で撮影された撮影画像を、これに対応する文字情報と共に、前記携帯端末から受けて、その撮影画像が、前記文字情報との関係で適切か否かの判定結果を、前記携帯端末に返信するよう構成されている管理サーバでもある。

【0016】

上記の発明を利用することで、携帯端末を最適条件で動作させることができ、管理サーバの判定精度を上げることができる。

【0017】

交通機関には、少なくとも、列車、バス、飛行機、船、及びタクシーが含まれる。情報提供サーバは、管理サーバと同一ドメインでも良いし、異なるドメインでもよい。

【0018】

画像撮影データは、静止画であっても、動画であっても良い。画像撮影データは、典型的には、列車などの交通機関の側面プレート（行先表示器）を撮影したデータである。但し、駅ホーム（Platform）などに配置された列車案内表示板を撮影したものでもよい。

【発明の効果】

【0019】

本発明によれば、携帯端末の内蔵カメラを最適に動作させることで、利用者が乗車選択した乗り物の選択の正否を、簡易且つ高精度に判定することができる。

【図面の簡単な説明】

【0020】

【図1】列車側面の行先表示器を撮影する場合の最適なシャッター速度を検討した検討結果である。

【図2】第１駅～第３駅の列車案内表示板や行先表示器について、最適なＩＳＯ感度を検討した検討結果である。

【図3】第４駅～第６駅の列車案内表示板や行先表示器について、最適なＩＳＯ感度を検討した検討結果である。

【図4】実施例に係る乗車判定システムの全体構成を示す構成図である。

【図5】携帯端末に配信されるＷｅｂページを例示した図面である。

【図6】画像修復処理と反射除去処理の処理結果を示す図面である。

【図7】明度（Value ）を示すＶ値の出現ヒストグラムから、Ｖ値の閾値ＴＨ２を特定する手法を説明する図面である。

【図8】別の実施例に係る乗車判定システムの全体構成を示す構成図である。

【発明を実施するための形態】

【0021】

以下、実施例に基づいて、本発明を詳細に説明する。先ず、携帯端末の内蔵カメラを最適に動作させる撮影条件を特定するべく実施した撮影調査と、この調査結果から得られた最適撮影条件について説明する。
＜最適撮影条件の特定＞

【0022】

本発明者は、駅ホームに設置された列車案内表示板と、列車側面の行先表示器をカメラで正確に撮影できる撮影条件を検討した。なお、列車側面の行先表示器には、文字がシートに印刷されている「字幕タイプ」のものと、ＬＥＤ表示器を使用する「ＬＥＤタイプ」のものとが存在する。また、列車案内表示板としては、液晶表示器を使用する「液晶タイプ」のものが一般的である。

【0023】

また、スマートフォンなどの携帯端末の内蔵カメラを使用して、列車案内表示板や行先表示器を正確に撮影できるか否かは、カメラのレンズを通過してくる光の総量や、画像そのものの明るさに関連し、これらは、レンズの絞り値と、露光時間と、フィルム感度（実際には撮像素子の感度）と、の組み合わせによって決まる。
［調査検討１（シャッター速度について）］

【0024】

そこで、先ず、最適なシャッター速度について検討した。ここで、シャッター速度とは、カメラによる写真撮影の際に、シャッターが開放され、フィルムまたは撮像素子が、レンズを通した光に晒される時間（露光時間）を意味し、露光時間が短いほどシャッター速度が速く、露光時間が長いほどシャッター速度が遅い関係にある。

【0025】

このシャッター速度の調査では、携帯端末の内蔵カメラについて、(1) 手ぶれ補正機能＝ＯＦＦ設定、(2) 絞り値＝自動設定、(3) ＩＳＯ感度＝自動設定にして、各駅において、シャッター速度を、１／４０００秒、１／１０００秒、１／４００秒、１／１２５秒、１／５秒、その他に多様に変更しつつ、多数の画像を撮影し、撮影画像が適切か否かを目視判定した。

【0026】

撮影画像の適切性は、撮影画像の明るい／暗いは問題にせず、コンピュータによる画像認識が可能か否かの観点で判定し、文字が途切れないことを最優先の条件とした。これは、ＬＥＤタイプの行先表示器は、いわゆるダイナミック点灯方式を採っている場合が多く、シャッター速度が速すぎると、途切れた文字しか撮影できないためである。また、「液晶タイプ」の列車案内表示板も、全ての画素が同時に点灯される訳ではなく、文字の途切れが懸念されるためである。

【0027】

先ず、図１（ａ）に示す通り、「字幕タイプ」の行先表示器の調査結果では、シャッター速度１／５秒の場合に、手振れが生じたものの、シャッター速度に関係なく撮影可能と結論された。

【0028】

次に、図１（ｂ）に示す通り、「液晶タイプ」の列車案内表示板については、１／５秒と１／２０秒における手ぶれ以外は撮影に成功した。したがって、「液晶タイプ」の列車案内表示板についても、シャッター速度に関係なく撮影が可能と結論される。

【0029】

「ＬＥＤタイプ」の行先表示器は、ダイナミック点灯の動作態様が必ずしも一定しない。そのため、シャッター速度１／１６０秒でも文字が途切れる場合があるが、シャッター速度１／１０００秒より速いと殆ど正確に撮影できなかった（図１（ｃ）参照）。一方、シャッター速度が遅すぎると手ぶれの心配があるので、一枚も失敗が無かった１／４０～１／１２５秒が最適と結論される。

【0030】

以上の通り、(1) 字幕タイプの場合は、シャッター速度が１／５秒より速ければ問題が無いこと、(2) 液晶タイプの場合は、１／４０秒よりシャッター速度が速ければ問題が無いこと、(3) ＬＥＤタイプの場合は、シャッター速度１／４０～１／１２５秒であれば問題が無いこと、が明らかとなった。そこで、本発明者は、シャッター速度１／４０～１／１２５秒が好適な数値範囲であると結論した。
［調査検討２（明るさ調査）］

【0031】

続いて、正しい明るさで撮影できる設定値を導くべく、明るさについて調査検討した。なお、明るさには、シャッター速度と、ＩＳＯ感度と、絞り値の全てが関係する。

【0032】

先ず、ＩＳＯ感度は、写真フィルム（携帯端末では撮像素子）のＩＳＯ規格（International Organization for Standardization）であって、ある撮像素子が、どの程度弱い光まで対応できるかを示している。例えば、ＩＳＯ感度２００の撮像素子は、受光能力が、ＩＳＯ感度１００の２倍あるため、ＩＳＯ感度１００の半分の強さの光まで対応できることになる。

【0033】

このＩＳＯ感度は、対数表記Ｉ’又は算術表記Ｉされるが、対数表記Ｉ’と、算術表記Ｉとの間には、Ｉ＝１０^{（Ｉ’－１）／１０}・・・（式１）や、Ｉ’＝１０Ｌｏｇ_１０Ｉ＋１・・・（式２）の近似式が成立する。（式１）では、算術表記Ｉが、最も近い値の標準的感度に丸められ、（式２）では、対数表記Ｉ’が四捨五入によって整数化される。

【0034】

したがって、例えば、ＩＳＯ感度２０（算術表記Ｉ＝２０）は、対数表記では、Ｉ’＝１０Ｌｏｇ_１０２０＋１≒１４となる。つまり、ＩＳＯ感度（算術表記）２０は、対数表記では１４であって、２０≒１０^１．３の関係が成立する。

【0035】

また、絞り値Ｆは、レンズの焦点距離と、有効口径（直径）とに基づいて、絞り値Ｆ＝焦点距離／有効口径（直径）・・・（式３）と特定される。したがって、同じレンズでは、絞り値が小さいほど撮影画像が明るくなり、例えば、絞り値２．０は、絞り値４．０より４倍明るいことになる。

【0036】

以上を踏まえて、調査２では、(1) シャッター速度＝１／１２５秒、(2) 絞り値＝２．２、(3) 手ぶれ補正＝ＯＦＦ設定の条件で、ＩＳＯ感度を、１００，２００，４００，８００，１６００，３２００，４０００，８０００に変化させて、設置環境が異なる複数の駅で、列車案内表示板や行先表示器を撮影した画像について、その明るさの適否を判定した。

【0037】

図２（ａ）は、照度４４０～９２０ルクスの地下駅１について、ＩＳＯ感度を変えて列車案内表示板や、行先表示器を撮影した多数の撮影サンプルを評価して、適正割合の％表記を示したものである。

【0038】

ＩＳＯ感度１６００を超えると明る過ぎて半分以上が失敗と評価され、一方、ＩＳＯ感度を１００まで下げると暗すぎて３割ほど失敗することが判明した。したがって、この地下駅１では、ＩＳＯ感度２００～４００が適切と考えられる。

【0039】

図２（ｂ）は、照度５９０～１１３０ルクスの地上駅２についての調査結果である。ＩＳＯ感度が８００を超えると半分以上が失敗と評価され、ＩＳＯ感度が低ければ低いほど、撮影成功率が高いことが判明した。なお、ＩＳＯ感度２００、４００の失敗は、回送電車を撮影したためであり無視することができる。したがって、地上駅２では、ＩＳＯ感度１００～４００が適切と考えられる。

【0040】

図２（ｃ）は、照度１４０～１９００ルクスの地上駅３についての調査結果である。この地上駅３では、ＩＳＯ感度２００～４００が適切であると評価される。

【0041】

図３（ａ）は、照度６００～１０６０ルクスの地上駅４についての調査結果である。この調査結果によれば、地上駅４では、ＩＳＯ感度１００～２００での撮影が適切であると評価される。

【0042】

図３（ｂ）は、照度２８０～５５００ルクスの地上駅５についての調査結果である。地上駅５では、ＩＳＯ感度が低ければ低い程、撮影成功率が高いことが確認される。そして、ＩＳＯ感度８００を超えると半分以上失敗するので、ＩＳＯ感度１００～２００での撮影が適切であると評価される。

【0043】

図３（ｃ）は、照度５万～２０万ルクスの地上駅６についての調査結果である。地上駅６は、直射日光を受けて、目を開けているのも辛い明るさであり、ＩＳＯ感度８０まで下げても高い確率で失敗する。絞り値を４以上に設定すれば、直射日光下でも撮影は可能であるが、好適なシャッター速度（１／４０～１／１２５秒）を考慮すると、シャッター速度を１／１２５秒より速くできないという条件下では、携帯端末でここまで暗く設定することはできない。

【0044】

以上の通り、絞り値＝２．２、シャッター速度＝１／１２５秒の条件において、(1) 地下駅１では、ＩＳＯ感度２００～４００が適切であること、(2) 地上駅２では、ＩＳＯ感度１００～４００が適切であること、(3) 地上駅３では、ＩＳＯ感度２００～４００が適切であること、(4) 地上駅４では、ＩＳＯ感度１００～２００が適切であること、(5) 地上駅５では、ＩＳＯ感度１００～２００が適切であること、(6) 地上駅６では、携帯端末での撮影は難しいこと、が明らかなとなった。そこで、本発明者は、撮影時には直射日光を避けるという条件付きで、ＩＳＯ感度２００が望ましいと結論した。

【0045】

但し、上記の結論は、あくまで絞り値が２．２の場合であり、携帯端末によって絞り値が異なる。しかも、この絞り値は、一般に、自由に変更することはできない。そこで、この制限を踏まえて、どんな携帯端末でも、適切な条件で動作する構成を特定する必要がある。

【0046】

そこで、更に検討した結果、本発明者は、三つのパラメータである(1) シャッター速度、(2) ＩＳＯ感度、及び、(3) 絞り値は、互いに影響し合い、一つ正しい設定値を見つければ、どの数値を変えても他の数値で補完することができることに思い至った。すなわち、(1) シャッター速度は、シャッターが開放され撮像素子が、レンズを通した光に晒される時間（露光時間）であるので、シャッター速度Ｓが遅くなればなるほど、撮影画像が明るくなり、例えば、シャッター速度Ｓ＝１／５００秒は、Ｓ＝１／１０００秒よりも２倍明るいと言える。

【0047】

(2) ＩＳＯ感度は、撮像素子がどの程度弱い光まで対応できるかのパラメータであり、ＩＳＯ感度が大きいほど、撮影画像が明るくなり、例えば、ＩＳＯ感度１０００は、ＩＳＯ感度５００よりも２倍明るいと言える。

【0048】

(3) また、絞り値Ｆ＝焦点距離／有効口径（直径）・・・（式３）より、絞り値は、その数値（有効口径）が小さいほど、撮影画像が明るくなり、例えば、絞り値２．０は絞り値４．０より４倍明るいと言える。

【0049】

これら、(1) シャッター速度Ｓと、(2) ＩＳＯ感度Ｉと、(3) 絞り値Ｆによれば、下記の（式４）が成立するように、シャッター速度Ｓと、ＩＳＯ感度Ｉと、絞り値Ｆの各値を調整することで、一定の明るさを保つことができると考えられる。
Ｓ×Ｉ／Ｆ^２＝一定・・・（式４）
そして、先の調査結果の最適値（Ｓ＝１／１２５，Ｉ＝２００，Ｆ＝２．２）より、（式４）の一定値は、最適条件において、ほぼ０．３３（≒１／１２５×２００／２．２^２）であると特定される。

【0050】

すなわち、（式４）の算出値が０．３３となるよう、(1) シャッター速度Ｓと、(2) ＩＳＯ感度Ｉと、(3) 絞り値Ｆについて、各値を設定すれば、どの携帯端末でも正しい明るさで行先表示器や列車案内表示板を撮影することができることになる。

【0051】

一般に、携帯端末は、カメラレンズの絞り値Ｆが固定値である。また、調査の結果、ある程度暗めの撮影が求められることから、シャッター速度は最適範囲（１／４０～１／１２５秒）のうち最速の１／１２５秒に固定し、携帯端末の絞り値Ｆに応じて、ＩＳＯ感度Ｉを、（式４）に基づいて算出し、そのＩＳＯ感度に調整するのが望ましいと結論した。

【0052】

すなわち、以下に説明する実施例では、使用する携帯端末のカメラレンズの絞り値Ｆに基づき、ＩＳＯ感度Ｉを、Ｉ＝０．３３×Ｆ^２×１２５・・・（式５）に設定して行先表示器や列車案内表示板を撮影することにする。

【0053】

但し、（式５）を、そのまま使用すると、Ｆ＝２．０の場合に、Ｉ＝１６５となり、Ｆ＝２．２の場合に、Ｉ＝１９９．６５となるなど、採用可能なＩＳＯ感度に完全には一致しない。そこで、予め、決定テーブルＣＮＶを用意しておき、例えば、Ｆ＝２．０の場合に１６０を採用し、Ｆ＝２．２の場合にＩＳＯ感度２００を採用するよう構成している。

【0054】

【表1】

【0055】

＜乗車判定システム＞
図４は、携帯端末の内蔵カメラを、上記した最適撮影条件で動作させる乗車判定システムを示すブロック図である。なお、ここでは、一例として、地理に不案内な旅行者（システム利用者）が、目的駅に行くために乗車選択した列車の選択が、正しいか否かを判定する場合について説明する。

【0056】

一般に、駅ホームに設置された列車案内表示板は、その駅ホームからの発車時刻と、発車予定の列車の種別と、行先駅（終着駅又は乗換駅）とを表示している。また、列車側面の行先表示器には、列車の種別と、行先駅（終着駅又は乗換駅）とが一般に表示されている。

【0057】

ここで、種別とは、全ての列車を、普通／準急／急行／快速急行／特急などに区分する情報であり、行先駅への到着時刻の優劣関係や、途中停車駅の違いなどを特定している。

【0058】

図４に示す通り、実施例の乗車判定システムは、カメラ付きの携帯端末１と、目的駅に到着するために必要な列車情報を提供する列車情報提供サーバ２と、所定の文字情報と画像情報を携帯端末１から受ける共に、画像認識サーバ４から受ける情報に基づいて、利用者による列車選択の適否を携帯端末１に返信する管理サーバ３と、管理サーバ３から転送される画像情報を、登録済みの画像情報を比較して、必要な判定情報を返信する画像認識サーバ４と、を有して構成されている。

【0059】

列車情報提供サーバ２と、管理サーバ３と、画像認識サーバ４は、各々、インターネット回線ＮＥＴに接続されたＨＴＴＰサーバである。また、携帯端末１は、内蔵カメラを有すると共に、移動体通信回線ＭＯＢを経由して、インターネット回線ＮＥＴ上のＷＥＢページを取得するブラウザが搭載されている。

【0060】

また、携帯端末１には、内蔵ブラウザと協働して、以下に説明する処理を実行する乗車判定アプリ（アプリ名はJUDG）が、決定テーブルＣＮＶ（表１）と共に、予めインストールされている。

【0061】

この乗車判定アプリJUDGは、Ｗｅｂページに記載された所定ボタンを、利用者がタップすると起動するよう構成されている。但し、何ら、この構成に限定されず、乗車判定アプリ自体がブラウザ機能を発揮して、アプリ内でＷｅｂページを表示して、利用者の操作を待つ構成を採っても良い。

【0062】

何れの構成を採る場合でも、乗車判定アプリJUDGの起動時に実行される初期設定処理によって、内蔵カメラのシャッター速度Ｓが、１／１２５秒に設定されると共に、当該携帯端末１の絞り値Ｆに対応するＩＳＯ感度Ｉが、表１に示す決定テーブルＣＮＶに基づく最適値に設定される。

【0063】

また、列車情報提供サーバ２は、携帯端末１（ＷＥＢクライアント）からの指示に基づき、任意の出発駅と目的駅に関して、発車時刻などの列車情報などを掲載したＷＥＢページ（図５参照）を配信するよう構成されている。

【0064】

図５に示すように、このＷｅｂページには、出発駅（〇〇）から到着駅（××）に移動する列車種別（図示例は特急）と、出発時間及び到着時刻が、運賃などと共に掲載されている。また、このＷｅｂページには、「行先判定ボタン」が配置されており、このボタンを利用者がタップすると、インストール済みの乗車判定アプリJUDGが起動するよう構成されている。

【0065】

このＷｅｂページは、具体的には、例えば、ＵＲＬスキームが活用され、anchorタグのスキーム名の部分に、通信プロトコルを特定するhttpに代えて、アプリ名（JUDG）を指定することで、インストール済みのアプリJUDGが実行可能となっている。すなわち、このＷｅｂページには、例えば、<a href = "JUDG://">行先判定</a>のようなanchorタグが記載されている。

【0066】

そして、利用者のタップ操作に対応して、乗車判定アプリJUDGが起動すると、内蔵カメラが起動すると共に、シャッター速度Ｓが１／１２５秒に設定され、当該携帯端末１の絞り値Ｆに対応する最適なＩＳＯ感度Ｉが設定される。

【0067】

次に、「乗車しようとする列車について、その列車側面の行先表示器か、列車案内表示板を撮影して下さい。」との案内画面が立ち上がる。そのため、利用者は、内蔵カメラを、列車側面の行先表示器か、駅ホームの列車案内表示板に向けた後、シャッターを切ることになる。

【0068】

また、このＷｅｂページには、hidden属性のinput タグに、行先駅と、列車種別（普通／準急／急行／快速急行／特急）と、出発駅と、発車時刻と、が隠しデータとして記載されている。更に、このＷｅｂページには、シャッター操作などに基づき機能するJavaScriptプログラムが記載されており、行先駅と列車種別と出発駅と発車時刻とは、内蔵カメラが撮影した撮影データと共に、例えばＰＯＳＴデータとして、管理サーバ３に送信されるようになっている。

【0069】

具体的な手法は、適宜であるが、ＨＴＭＬ５（Hyper Text Markup Language version5 ）では、携帯端末１の内蔵カメラの機能をJavaScriptから直接利用できるので、シャッターを切った瞬間の画像を、Ｗｅｂページの適当なタグ（例えばcanvasタグ）に貼り付け、他の情報と共に、管理サーバ３に向けてＰＯＳＴ送信すれば良い。

【0070】

以上、携帯端末１の内蔵ブラウザが、列車情報提供サーバ２をアクセスする構成について説明した。このような構成を採る場合には、大部分の処理がJavaScriptによって実行可能であるので、乗車判定アプリJUDGは、内蔵カメラの撮影条件を最適設定し、その後の操作を案内する処理だけを実行すれば足りることになる。

【0071】

但し、列車情報提供サーバ２は、上記したJavaScriptプログラムを記載したＷｅｂページであって、且つ、アプリ名JUDGを記載したanchorタグで構成された「行先判定ボタン」を用意する必要がある。そこで、この煩雑さを解消するには、乗車判定アプリ自体にブラウザ機能を持たせ、乗車判定アプリJUDGが、列車情報提供サーバ２を直接アクセスする構成を採るのが好ましい。

【0072】

このような後者の構成を採る場合には、列車情報提供サーバ２が、特別なＷｅｂページを用意する必要がなくなり、スキーム名をhttpとする通常のanchorタグを埋め込んだ「行先判定ボタン」を配置し、行先駅と列車種別と出発駅と発車時刻とを、例えばhidden属性で記載したＷｅｂページを配信することになる。この場合、乗車判定アプリJUDGは、初期設定処理だけでなく、利用者による「行先判定ボタン」のタップ操作に対応して、上記した一連の処理を全て実行することになる。

【0073】

続いて、管理サーバ３について説明する。管理サーバ３は、原則として、乗車判定アプリJUDGが搭載された携帯端末１との交信を予定しており、携帯端末１から受けた情報（行先駅／列車種別／出発駅／発車時刻／撮影データ）を、適宜な作業領域ＷＯＲＫに一時記憶すると共に、撮影データについては、これを画像認識サーバ４に転送するよう構成されている。

【0074】

この管理サーバ３の構成に対応して、画像認識サーバ４は、撮影データの受信に対応して画像認識プログラムRECOG が起動するよう構成されている。この画像認識プログラムRECOG は、転送されてきた撮影データから複数の特徴量を注出する注出アルゴリズムを有して構成されている。

【0075】

また、画像認識サーバ４は、本システムで転送されてくる可能性がある全ての行先表示器と、全ての案内表示板についての模範的な撮影データ（模範撮影データ）を予め受けている。そして、画像認識プログラムRECOG は、全ての模範撮影データから、特徴量の注出処理を完了しており、注出された特徴量は、一意の画像ＩＤと共に、特徴パラメータテーブルＴＢＬ２に記憶されている。

【0076】

すなわち、列車側面に配置された行先表示器には、必ず、列車種別と行先駅が表示されており、画像認識サーバ４の画像認識プログラムRECOG は、列車種別と行先駅の全ての組み合わせについて、予め取得した模範撮影データから、必要な特徴量の注出を終えている。

【0077】

この点は、駅ホームに設置されている案内表示板についても同様であり、画像認識サーバ４（画像認識プログラムRECOG ）は、案内表示板に表示される可能性のある列車種別と行先駅の全ての組み合わせについて、予め取得した模範撮影データから、必要な特徴量の注出を終えている。

【0078】

なお、カメラで撮影した画像には、通常、列車種別や行先駅だけでなく、行先表示器の輪郭画像や他の文字情報も映り込んでいる。しかし、画像認識サーバ４の画像認識プログラムRECOG は、転送されてきた判定対象の撮影データから注出した複数の特徴量と、特徴パラメータＴＢＬ２に登録されている特徴量とを、画像ＩＤごとに順番に対比して、一致する特徴量が最大個数となる画像ＩＤと、この画像ＩＤを選択したことの正解率（スコア値）を特定して管理サーバ３に返信している。したがって、ターゲット情報（列車種別／行先駅）以外の情報は、事実上、無視されることになる。なお、正解率は、特徴量の一致個数などに基づいて算出される。

【0079】

一方、管理サーバ３には、画像認識サーバ４の特徴パラメータテーブルＴＢＬ２に対応して、参照テーブルＴＢＬ１が、出発駅ごとに設けられている。この参照テーブルＴＢＬ１には、全ての行先表示器と、全ての案内表示板について、行先駅と、列車種別の文字情報が、特徴パラメータテーブルＴＢＬ１と同一の画像ＩＤで特定されて記憶されている。また。この参照テーブルＴＢＬ１には、画像ＩＤ毎に、当該列車の発車時刻が一又は複数個記憶されている。
＜乗車判定システム各部の動作＞

【0080】

以上、図４に基づいて、乗車判定システムの構成を説明したので、システム利用者が乗車選択した列車の選択が正しいか否かを判定する一連の動作を説明する。

【0081】

なお、以下の説明では、（１）列車情報提供サーバ２は、スキーム名をhttpとする通常のanchorタグを埋め込んだ「行先判定ボタン」を配置し、行先駅／列車種別／出発駅／発車時刻をhidden属性で記載したＷｅｂページを配信し、（２）乗車判定アプリJUDGは、自らの内部処理としてブラウザ機能を発揮して、Ｗｅｂページを表示し操作する場合について説明する。また、以下の説明では、システム利用者は、駅ホームにおいて、自分が乗車しようとする列車を選択したタイミングであるとする。
［図４の第１ステップ～第３ステップ（携帯端末１の動作）］

【0082】

利用者が、乗車判定アプリJUDGを起動させると、起動した乗車判定アプリJUDGは、内蔵カメラを最適撮影条件に設定した後、ブラウザ機能を発揮する。すなわち、初期設定処理後は、任意のＨＴＴＰサーバがアクセス可能となるので、システム利用者は、列車情報提供サーバ２をアクセスして、自分が今いる出発駅と、自分が行きたい行先駅に関するＷｅｂページを取得して、図５のような列車案内画面をアプリ内に表示させる。

【0083】

そして、出発時間などを確認した上で、システム利用者が「行先判定ボタン」をタップすると、内蔵カメラが起動して、「列車側面の行先表示器か、又は、駅ホームの列車案内表示板を撮影して下さい。」との案内画面が表示される。この場合、内蔵カメラの表示画面には、行先表示器や列車案内表示板に対応する縦横比を有する、横長のフレーム枠が表示されるようになっている。

【0084】

そこで、利用者は、内蔵カメラを行先表示器か列車案内表示板に向け、横長のフレーム枠に、車種と行先駅を捉えたタイミングで、撮影シャッターを押すことになる。

【0085】

すると、このシャッター操作に対応して、乗車判定アプリJUDGは、内蔵カメラが撮影した撮影データを、Ｗｅｂページにhidden属性で記載されている行先駅／列車種別／出発駅／発車時刻と共に、管理サーバ３にＰＯＳＴ送信する。
［図４の第４ステップ（管理サーバ３の動作）］

【0086】

先に説明した通り、携帯端末１からＰＯＳＴデータを受けた管理サーバ３は、行先駅／列車種別／出発駅／発車時刻を、作業領域ＷＯＲＫに一時記憶する。また、管理サーバ３は、撮影データを、画像認識サーバ４に転送して、画像認識サーバ４からの返信を待つ。なお、携帯端末１から受けた出発駅に基づいて、出発駅に対応する参照テーブルＴＢＬ１が特定される。
［図４の第５ステップ（画像認識サーバ４の動作）］

【0087】

画像認識サーバ４は、管理サーバ３から受信した撮影データについて特徴量を注出すると共に、注出した特徴量を、特徴パラメータテーブルＴＢＬ２に記載の特徴量と順次対比して、一致する特徴量が最大個数となる画像ＩＤと、この画像ＩＤを選択したことの正解率（スコア値）を特定して管理サーバ３に返送する。

【0088】

ここで、正解率は、画像認識サーバ４に転送された撮影データと、画像ＩＤで特定される模範撮影データとの類似度合いを示している。したがって、撮影画像が不鮮明で、特徴量を注出できない場合や、転送された撮影データと類似する模範撮影データが検出されない場合は、正解率が０となる。

【0089】

なお、管理サーバ３に返信される画像ＩＤと正解率は、必ずしも一組である必要はなく、正解率が所定レベル以上であれば、複数組の画像ＩＤ及び正解率が、管理サーバ３に返送される。
［図４の第６ステップ（管理サーバ３の動作）］

【0090】

待機状態の管理サーバ３が、画像認識サーバ４から画像ＩＤ及び正解率を受けると、管理サーバ３は、出発駅に対応する参照テーブルＴＢＬ１を参照して、画像ＩＤに基づいて、行先駅と列車種別を特定する。

【0091】

そして、参照テーブルＴＢＬ１から注出される行先駅と、列車種別が、作業領域ＷＯＲＫに一時記憶されている行先駅と列車車種に一致するか否かを判定する。この判定結果には、Ｇ判定(a) ：正解率の高い画像ＩＤを受け、それが一時記憶中の行先及び種別と一致する場合と、Ｇ判定(b) ：正解率の高い画像ＩＤを受けたにも拘わらず、一時記憶中の行先や種別と一致しない場合と、ＮＧ判定(c) ：正解率＝０の判定結果を受けた場合や、正解率の低い画像ＩＤしか受信できない場合と、に区分される。

【0092】

ここで、Ｇ判定(a) やＧ判定(b) の場合には、管理サーバ３は、発車時刻の正当性を確認した上で、携帯端末１に認識結果を返信する。返信内容は、例えば「はい、その電車は、特急××駅行きです。・・・」、又は、「その電車ではありません。他の電車を探してください。」と表示したＷｅｂページとなる。なお、このＷｅｂページには、ユーザが撮影した撮影データと、管理サーバ３から受けた画像ＩＤに基づいて特定される模範撮影データとが対比して携帯端末１に表示される。

【0093】

但し、ＮＧ判定(c) の場合には、以下に説明する画像修復処理と反射除去処理を、この順番で実行した上で、再度、第４ステップの処理に戻り、画像認識サーバ４に補正撮影データを送信する。

【0094】

そして、画像認識サーバ４から返信された画像ＩＤが、管理サーバ３に一時記憶されている情報に一致するか否かを判定し（第５ステップ）、Ｇ判定(a) か、Ｇ判定(b) であれば、対応する回答を携帯端末１に返信することになる（第６ステップ）。

【0095】

一方、補正撮影データについても、再度、ＮＧ判定(c) の場合には、「画像が不鮮明で判定できません。」との回答を携帯端末１に返信することになる（第６ステップ）。
＜画像修復処理（Ａ）と反射除去処理（Ｂ）＞

【0096】

続いて、管理サーバ３が、画像認識サーバ４から、一回目のＮＧ判定(c) を受けた後の動作について説明する。ＮＧ判定(c) を受けた管理サーバ３は、以下に説明する画像修復処理（Ａ）と、反射除去処理（Ｂ）を、この順番に実行して、補正撮影データを生成する。

【0097】

先ず、画像修復処理（Ａ）は、蛍光灯などの反射光により、本来の文字情報が潜在化した場合に、この欠損部分の文字画像情報を、その周りの画像情報に基づいて補完する処理を意味する。
［画像修復（Ａ）第１処理］

【0098】

画像修復処理（Ａ）では、管理サーバ３は、作業領域ＷＯＲＫに一時保存されている撮影画像データから色情報を削除するため、撮影画像データをグレースケール化する。

【0099】

グレースケール化の具体的な手法は、適宜に選択されるが、本実施例では、コンピュータビジョン向けライブラリOpen CV （Open Source Computer Vision Library ）のDecolor 関数を、プログラミング言語Pythonの動作環境において使用した。なお、以下の説明は、全て、プログラミング言語Pythonの動作環境における説明である。

【0100】

Decolor 関数を使用する場合、Pythonでは、Grayscale.color_boost = cv.deColor(src) の書式となる。ここで、撮影画像がＮ個のピクセルで構成されている場合、cv.deColor関数の第１引数src は、要素数３＊Ｎの配列Photo(R,G,B)を意味し、この配列には、ＲＧＢデータが、各１バイト長で記憶されている。

【0101】

一方、戻り値は、要素数Ｎの配列GS(i) であり、各ピクセルの濃淡情報（Gray Scale値）が１バイト長で格納される。なお、値が大きいほど明るく、小さいほど暗く、０は真っ黒、２５５は真っ白を意味する。
［画像修復（Ａ）第２処理］

【0102】

次に、画像修復第１処理で求めたGray Scale値（以下、GS値と略す）について、所定の閾値TH1 より明るいピクセルを抽出する。具体的には、Open CV のinRange 関数を使用するが、Pythonでは、dst = cv.inRange(src, lowerb, upperb) の書式となる。

【0103】

ここで、inRange 関数の第１引数src は、画像修復第１処理で算出した、要素数Ｎの結果配列GS(i) であって、ピクセル毎に、そのGS値が１バイト長で記憶されている。また、第２引数lowerbと第３引数upperbは、各々、スカラー値であって、ここでは、lowerb = 0、upperb = TH1としている。

【0104】

一方、戻り値dst は、要素数Ｎの結果配列を示しており、この結果配列DST(i)には、２５５又は０が記憶される。具体的には、明るいピクセル（ＧＳ値＞ＴＨ１）は０となり、そうでない、０≦ＧＳ値≦ＴＨ１のピクセルは、２５５となる。この結果配列DST(i)は、反射光による有効情報の欠損領域を０で示すことになる。通常、この欠損領域は、蛍光灯の発光である場合が多く、そのような場合は、欠損領域は、所定の幅を有した直線帯として形成される。
［画像修復（Ａ）第３処理］

【0105】

続いて、欠損部分の画像情報を、その回りの画像情報から補完する。具体的には、Open CV のinpaint 関数を使用して欠損領域のピクセル情報（ＲＧＢ各８ビット）を、周囲のピクセル情報から補完する。Pythonでは、例えば、st = cv.inpaint(src, Mask, Radius, flags) の書式となる。

【0106】

ここで、第１引数src は、撮影したピクセル数Ｎの撮影画像データを記憶する要素数３＊Ｎの配列Photo(R,G,B)であり、ＲＧＢデータが、各１バイト長で記憶されている。第２引数Maskは、この実施例では、画像修復第２処理で算出したマスク配列DST(i)であって、要素数がＮの配列である。先に説明した通り、マスク配列DST(i)の要素において、０は、修復されるべき箇所（欠損領域）を示している。

【0107】

一方、第３引数Radiusは、修復されるべき箇所を含んだ近傍の円形領域の半径であり、欠損領域の幅に基づいて適宜に決定される。また、第４引数flags は、補完アルゴリズムを特定するフラグ値で、Navier-Stokes に基づく手法か、Alexandru Telea による手法かが特定可能となっている。なお、この実施例では、Alexandru Telea による手法を指定した。

【0108】

また、結果配列dst は、入力配列src と同一サイズ、同一タイプの配列Repair(R, G, B) であり、画像修復後のＲＧＢデータが保存される。以上の処理の結果、蛍光灯などの反射光の部分の文字情報が、ある程度復元される。図６（ａ）は、欠損部分を補完したカラー画像を示しており、左上部に表示されている反射光の傾斜ラインと、右下部に表示される白色領域について、各々の発光が有意に緩和されている。
［反射除去（Ｂ）第１処理］

【0109】

続く、反射除去処理では、画像修復処理（Ａ）を終えた画像データ（以下、修復画像データという）の各ピクセルについて、先ず、ＲＧＢ各８ビットデータからＨＳＶ色空間のＨ，Ｓ，Ｖを算出する。ここで、ＨＳＶ色空間とは、あるピクセルの色彩を、「色相（Hue ）」「彩度（Saturation）」「明度（Value ）」の３つの組み合わせで表現する手法である。Ｈ，Ｓ，Ｖ値の算出手法は、特に限定されないが、ここでは、Open CV のcvtColor関数を使用し、例えば、Pythonでは、dst = cv.cvtColor(src, code)の書式となる。

【0110】

修復画像データがＮ個のピクセルで構成されている場合、上記のPython書式において、cv.cvtColor 関数の第１引数src で指定する入力配列SRC は、画像修復処理（Ａ）の結果配列Repair(R, G, B) である。

【0111】

この結果配列Repair(R, G, B) には、ピクセル毎のＲＧＢデータが、Ｂ→Ｇ→Ｒの順番で記憶されている。なお、第２引数codeによって、実行すべき処理が、ＨＳＶ色空間への変換であることを指示する。そして、戻り値dst は、要素数３＊Ｎの結果配列であり、cvtColor関数の処理によって、結果配列DST(i)には、Ｈ値とＳ値とＶ値がピクセル毎に記憶されることになる。

【0112】

そこで、本実施例では、次に、反射除去第１処理の結果配列DST(i)に基づいて、Ｎ個のピクセルのＶ値を記憶した要素数ＮのＶ値配列Value(i)を生成する。
［反射除去（Ｂ）第２処理］

【0113】

次に、反射除去第１処理で生成したＮ個の明度値についてのＶ値配列Value(i)について、全ピクセルに対する出現頻度のヒストグラムを作成し、明度（Value ）を示すＶ値について、適宜な閾値ＴＨ２を特定する。

【0114】

図７は、撮影画像と、Ｖ値の出現頻度ヒストグラムを図示したものである。なお、ここでは、撮影画像の全体を表示しているが、実際の運用では、横長のフレーム枠の外側は、全て黒色に処理される。

【0115】

何れにしても、反射除去処理に供される画像の場合には、図示のように、Ｖ値＝０の出現頻度が圧倒的であり、その他のＶ値の出現頻度は極めて低いが、０を超えるＶ値（＞０）において、何れかのＶ値で出現頻度がピークとなる。そこで、本実施例では、ピーク値を示すＶ値より上側のＶ値であって、例えば、ピーク値の７０％位置のＶ値を閾値ＴＨ２として選択することにする。
［反射除去（Ｂ）第３処理］

【0116】

次に、反射除去第３処理では、反射除去第２処理で特定した閾値ＴＨ２より高い明度のピクセルを抽出する。例えば、Open CV のinRange 関数を使用するが、Pythonでは、dst = cv.inRange(src, lowerb, upperb) の書式となる。

【0117】

ここで、第１引数src は、反射除去第２処理で得られたＶ値についてのＶ値配列Value(i)である。また、第２引数lowerbと第３引数upperbは、各々、ＨＳＶに関するスカラー値であって、ここでは、lowerb = TH2、upperb = 255としている。

【0118】

一方、戻り値dst は、要素数Ｎの結果配列Mask(i) を示しており、この結果配列Mask(i) には、２５５又は０が記憶される。具体的には、高明度（ＴＨ２≦Ｖ値≦２５５）のピクセルは、白（２５５）となり、そうでない、Ｖ値＜ＴＨ２の通常ピクセルは、黒（０）となる。この処理は、Ｎ個のピクセルについて、各ピクセルを採用するか否かを、結果配列Mask(i) に特定する処理に他ならない。
［反射除去（Ｂ）第４処理］

【0119】

続いて、反射除去第３処理で高明度ピクセルと判定されたピクセルについて、画像修復処理（Ａ）の結果配列Repair(R, G, B) から、ＲＧＢ画像データを抽出する。ここでは、例えば、Open CV のbitwise_and 関数を使用するが、Pythonでは、dst = cv.bitwise_and(src1, src2, dst, mask) の書式となる。

【0120】

ここで、第１引数src1と第２引数src2は、反射除去第１処理で使用した配列、つまり、画像修復（Ａ）による修復画像ＲＧＢデータを保存した修復画像配列Repair(R, G, B) となる。また、第３引数dst は、出力配列を意味し、要素数３＊Ｎ個の配列Take(R, G, B) を示している。

【0121】

一方、第４引数maskは、マスク配列を意味する。具体的には、反射除去第３処理で算出された要素数Ｎの結果配列MASK(i) を使用する。このbitwise_and 関数では、MASK(i) ≠０の場合にだけ、dst(i) = src1(i)Λsrc2(i) の論理演算が実行される。なお、Λは、ＡＮＤ演算を意味する。

【0122】

先に説明した通り、本実施例では、マスク配列MASK(i) の各要素は、高明度（ＴＨ２≦Ｖ値≦２５５）のピクセルについて２５５となり、そうでないピクセルについて０となっている。したがって、マスク配列MASK(i) の要素が２５５である高明度のピクセルに対してだけ、以下の処理が実行され、修復画像ＲＧＢデータを保存した修復画像配列Repair (R, G, B)が、出力配列Take(R, G, B) にコピーされることなる。具体的な処理内容を示すと、Reject(R, G, B) = Repair(R, G, B) Λ Repair(R, G, B)となる。

【0123】

一方、マスク配列MASK(i) の要素が（０）となる通常明度のピクセルに対しては、上記のAND 演算が実行されない。すなわち、結果配列Take(R, G, B) の要素は、初期状態（0, 0, 0 ）のままとなるので、結局、結果配列Take(R, G, B) には、高明度の重要部分だけが保存されることになる。

【0124】

鉄道用の列車案内表示板において、「発車時刻」、「電車の車種」、「目的駅名」は、その重要性に基づき、他の部分より明るく表示されている。そして、反射除去処理で、高明度の部分だけを切り出すことで、映り込みが緩和され、必要部分のみが抽出される。すなわち、反射光の映り込みによって何を表す画像が分からなかった画像が、しっかりと、行先駅や種別を表示した画像に変換されることになる。図６（ｂ）は、反射除去処理の処理結果を示しており、重要部分の文字情報がより鮮明化されていることが確認される。

【0125】

なお、図６（ｂ）は、反射除去処理の効果を対比的に示すため、列車案内表示板が、敢えて、３行にわたって撮影されているが（行先が三カ所）、実際の運用では、カメラに横長のフレーム枠を表示することで、単一の行先駅しか取得されない。

【0126】

以上の通り、画像修復処理（Ａ）と反射除去処理（Ｂ）を実行することで、反射除去処理第３処理の結果配列Take(R, G, B) には、文字情報が修復され、且つ、反射光が緩和された補正撮影データが保存されることになる。そこで、管理サーバ３は、補正撮影データを、画像認識サーバ４に送信して、判定結果を待つことになる（図４の第４ステップ）。

【0127】

そして、管理サーバ３は、画像認識サーバ４から返信された画像ＩＤが、管理サーバ３に一時記憶されている情報に一致するか否かを判定し、Ｇ判定(a) か、Ｇ判定(b) であれば、対応する回答を携帯端末１に返信することになる。

【0128】

一方、補正撮影データについても、ＮＧ判定(c) の場合には、「画像が不鮮明で判定できません。」との回答を携帯端末１に返信することになる。

【0129】

以上、図４に示す乗車判定システムについて詳細に説明したが、ここまでの説明は、携帯端末１に乗車判定アプリJUDGがインストールされていることを前提にしている。しかし、乗車判定アプリJUDGがインストールされていない携帯端末１では、JavaScriptプログラムによって、内蔵カメラを最適に設定することは、ＨＴＭＬ５ではできない。

【0130】

そこで、そのような場合に備えて、乗車判定アプリJUDGがインストールされていない携帯端末に対しては、内蔵カメラを連写モードで動作させるか、動画モードで動作させるのが好ましい。

【0131】

具体的な手法は、適宜であるが、例えば、「行先判定ボタン」のタップ操作に対応して、列車情報提供サーバ２が配信するＷｅｂページに、注意書きとして、「乗車判定アプリを使用されない場合は、連写モードか動画モードで行先表示器／列車案内表示板を撮影して下さい。」と表示することが考えられる。

【0132】

次に、この注意書きに対応してシステム利用者がカメラを操作した場合を説明する。管理サーバ３が、撮影画像データを連続的に受信する場合や、動画フレームデータを受信する場合には、それらを全て作業領域ＷＯＲＫに一時保存すると共に、連写画像の適当枚、又は、動画フレーム画像の複数枚を重ね合わせて、撮影画像データとして、画像認識サーバ４に転送する（第４ステップの処理）。

【0133】

なお、この第４ステップの処理は、携帯端末１から動画や連写画像が送信される第３ステップの処理に連続して実行しても良いし、画像認識サーバ４から、ＮＧ判定(c) を受けた後、つまり、第５ステップに続いて実行しても良い。

【0134】

連写画像の１枚や、動画から切り出した１枚のフレーム画像によって、画像認識サーバ４から、Ｇ判定(a) か、Ｇ判定(b) を受ける可能性は、低くないので、好適には、後者の手順とすべきである。すなわち、画像認識サーバ４から、ＮＧ判定(c) を受けた後に限り、複数枚の画像データを重ね合わせて、撮影画像データとして、画像認識サーバ４に再送すべきである。

【0135】

以上、本発明の実施例について、詳細に説明したが、具体的な記載内容は、何ら本発明を限定せず、適宜に変更可能である。特に、プログラミング言語Pythonの動作環境を前提にする必要は全くない。但し、Open CV の関数を使用することは、プログラムを簡素化する上で効果的である。

【0136】

また、上記の実施例では、乗車判定アプリJUDGがインストールされていない携帯端末について、連写モードや動画モードで動作させる構成を説明したが、乗車判定アプリJUDGがインストールされている携帯端末についても、同様の動作モードを設けても良い。

【0137】

また、上記の説明では、鉄道車両について説明したが、バス、飛行機、船、乗合タクシーなどへの搭乗時の判定処理にも、ほぼ同じ構成を採用することができる。また、シャッター速度Ｓその他のカメラ設定値について、具体的に記載したが、一例を記載したに過ぎず、特に本発明を限定するものではない。

【0138】

ところで、上記の実施例では、システム利用者が、駅ホームにおいて列車情報提供サーバ２をアクセスする場合を説明したが、何ら限定されない。例えば、列車情報提供サーバ２をアクセスして、必要情報（行先駅／列車種別／出発駅／発車時刻）を管理サーバ３に送信する第１処理と、駅ホームにおいて、列車側面の行先表示器か、又は、駅ホームの列車案内表示板を撮影して、管理サーバ３に撮影画像データを送信する第２処理に、有意な時間差を設けても良い。

【0139】

図８は、このような実施例を説明する図面である。図８には、列車情報提供サーバ２をアクセスして、必要情報（行先駅／列車種別／出発駅／発車時刻）を管理サーバ３に送信する第１処理が、第１ステップ～第３ステップとして示されている。この処理は、例えば、乗車予定の前日などに、ホテルその他において実行される。

【0140】

一方、管理サーバ３は、第１処理で送信された必要情報（行先駅／列車種別／出発駅／発車時刻）を、一意のユーザＩＤと共に、適宜な作業領域ＷＯＲＫに保存する。なお、作業領域ＷＯＲＫを適正に管理するため、受付日時も合わせて保存する。

【0141】

そして、管理サーバ３は、前記したユーザＩＤを、「必要情報を受け取った旨」を表示するＷｅｂページと共に、携帯端末１に返送する（図８の第４ステップ）。そして、このユーザＩＤは、例えば、クッキーＤＡＴＡとして、携帯端末１に保存される。

【0142】

次に、所定時間経過後、駅ホームにおいて、システム利用者が、携帯端末の乗車判定アプリJUDGを起動すると、起動した乗車判定アプリJUDGは、内蔵カメラを最適撮影条件に設定した後、ブラウザ機能と内蔵カメラを起動させて、横長のフレーム枠と共に、「列車側面の行先表示器か、又は、駅ホームの列車案内表示板を撮影して下さい。」との案内画面を表示する。

【0143】

【0144】

すると、このシャッター操作に対応して、乗車判定アプリJUDGは、内蔵カメラが撮影した撮影データを、ユーザＩＤと共に管理サーバ３に送信する（図８の第５ステップ）。

【0145】

その後の処理は、図４の構成の場合と同じであり、管理サーバ３は、撮影データを、画像認識サーバ４に転送して、画像認識サーバ４からの返信を待つ（図８の第６ステップ）。なお、参照テーブルＴＢＬ１は、作業領域ＷＯＲＫに記憶されている出発駅に基づいて特定される。

【0146】

一方、画像認識サーバ４は、管理サーバ３から受信した撮影データについて特徴量を注出すると共に、注出した特徴量を、特徴パラメータテーブルＴＢＬ２に記載の特徴量と順次対比して、一致する特徴量が最大個数となる画像ＩＤと、この画像ＩＤを選択したことの正解率（スコア値）を特定して管理サーバ３に返送する（図８の第７ステップ）。

【0147】

すると、待機状態の管理サーバ３は、画像認識サーバ４から受けた画像ＩＤ及び正解率に基づいて、携帯端末１に判定結果を返送するか（図８の第８ステップ）、或いは、撮影データを補正して画像認識サーバに再送信する（図８の第６ステップ）。なお、作業領域ＷＯＲＫの保存データは、その必要が無くなったタイミングか、受付日からの保存期間が過ぎたタイミングで消去される。

【0148】

この構成を採る場合には、システム利用者は、前日の夜など、時間に余裕のある状態で列車を選択でき、当日は、駅ホームで写真撮影するだけで足りるメリットがある。なお、乗車判定アプリJUDGがインストールされていない携帯端末１では、内蔵カメラを、連写モードか動画モードで機能させるのは図４の場合と同じである。

【0149】

以上、二つの実施例について説明したが、本発明の範囲に含まれる限り、適宜な変更が可能である。特に、上記の各実施例では、発車時刻を問題にしているが、簡素化の観点からは、管理サーバ３が、発車時刻を問題にすることなく、認識結果を携帯端末１に返信する構成を採るのも好適である。

【符号の説明】

【0150】

１携帯端末
２情報提供サーバ
３管理サーバ

【図1】