JP2023048038A

JP2023048038A - システム、管理装置及びプログラム等

Info

Publication number: JP2023048038A
Application number: JP2021157289A
Authority: JP
Inventors: 和範阿部; Kazunori Abe; 勇喜清水; Yuki Shimizu
Original assignee: Yupiteru Corp
Current assignee: Yupiteru Corp
Priority date: 2021-09-27
Filing date: 2021-09-27
Publication date: 2023-04-06

Abstract

【課題】安全な運転を支援する、自車両の状態を、他のユーザと共有するシステム、管理装置及びプログラムを提供する。【解決手段】車両５０に配置可能な電子機器１０と、メッセージングサービスを提供するサービス提供装置３０（サービス提供用のサーバ装置）とがネットワークＮＷを解して接続可能に構成されているシステム１において、電子機器１０は、車両の状態を取得する取得部と、前記車両の状態を参照し、メッセージングサービスに投稿するメッセージを含むメッセージ情報を生成する生成部と、メッセージ情報をメッセージングサービスに投稿する制御部と、を備える。車両の状態としては、例えば、交通上の所定の事象に接した状態、特に、車両の進行が妨げられる原因となり得る事象とする。【選択図】図１

Description

本発明は、システム等に関する。

従来から、電子機器等のシステムにおいて各種情報を表示する機器が知られている。例えば、特許文献１には、ユーザから投稿サーバに投稿された情報に基づいて、交通監視活動（速度取締地点）や事故等に関する情報をレーダー探知機に表示する発明が開示されている。

また、特許文献２には、ソーシャルメディアに投稿された意見を対象として、抽出したいイベント（事故等）を検出する発明が開示されている。

また、特許文献３には、ソーシャルメディアへの投稿情報に基づいて精度良く事故等のイベントの検出を行う発明が開示されている。

特許６６４３６０６号特許５７０２７５３号特開２０１３－１６８０２１号公報

本発明の目的の一つは、例えば、自車両の状態を、メッセージングサービスへの投稿を通じて他のユーザと共有すること等、従来技術を改善することである。

本発明の目的はこれに限定されず、本明細書及び図面等に開示される構成の部分から奏する効果を得ることを目的とする構成についても分割出願・補正等により権利取得する意思を有する。例えば本明細書において「～できる」「～可能である」などと記載した箇所を「～が課題である」と読み替えた課題が本明細書には開示されている。課題はそれぞれ独立したものとして記載しているものであり、各々の課題を解決するための構成についても単独で分割出願・補正等により権利取得する意思を有する。課題が明細書の記載から黙示的に把握されるものであっても、本出願人は本明細書に記載の構成の一部を補正又は分割出願にて特許請求の範囲とする意思を有する。またこれら独立の課題を組み合わせた課題を解決する構成についても開示しているものであり、権利取得する意思を有する。

（１）車両の状態に基づいて、メッセージングサービスに投稿するメッセージを含むメッセージ情報を生成する生成部と、前記メッセージ情報をメッセージングサービスに投稿する制御部とを備えることを特徴とするシステムとするとよい。

このようにすれば、ユーザは、車両の状態を、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。他のユーザと共有することの効果として、例えば、安全な運転を支援するユーザ側のメリットや、ＳＮＳ利用者の多い若年層へのアピールや購買欲の向上への期待といった、車載用装置の販売事業者の認知度向上や販売促進といった販売事業者側のメリットを期待することができる。車両の状態とは、車両自体の状態とするとよいが、車両の周辺の状態としてもよい。車両の状態としては、例えば、交通上の所定の事象に接した状態とするとよく、特に、車両の進行が妨げられる原因となり得る事象とするとよい。このような事象としては、車両の周辺で渋滞していること、事故が起こったこと、工事が行われていること、速度取締が行われていること、悪天候であること、火災、土砂崩れ、冠水その他の災害が発生したこと、及び通行止めその他の交通規制が行われていること、の少なくともいずれかとするとよい。車両の周辺で渋滞していることのように、事象に接したことで車両の進行が妨げられていることは、車両の車両速度に基づいて特定するとよく、位置情報取得部（詳しくは、後述する）が取得した位置情報の変化に基づいて車両速度を特定してもよいが、車両から車速の情報を取得して車両速度を特定するとよい。当該システムが車載用装置に実装されている場合のように車両から情報を取得できる場合は、ＯＢＤII（「II」は「２」のローマ数字である。）コネクタを介して車両速度を取得するとよい。

ここで、車両は特に原動機付きの二輪車又は四輪車とするとよいが、乗用車、トラック、バス等の道路を走行する車両としてもよい。車両の状態は、車両の備えるセンサ等から取得した情報に基づいて取得するとよいが、特に、車両にセンサを備えて取得した情報に基づいて判定するようにしてもよい。センサとしては、例えば、加速度センサ、ジャイロセンサ、ＧＰＳモジュール等とするとよい。車両の状態を判定することは、センサから取得した情報と予め記憶しておいた情報とを比較して行うとよい。車両の状態がある状態にあるとみなすこととしては、所定の状態そのものにあることのみとしてもよいが、所定の状態に類似する状態にあることも含むと尚良い。車両の周辺の状態としては、例えば、後続車が異様に接近している状態（例えば、後続車があおり運転をしている状態）、他車の危険運転に遭遇した状態、又は逆走の車両がある状態等とするとよい。

車両の状態に基づいてメッセージ情報を生成することは、車両の状態を反映したメッセージを含むように、メッセージ情報を生成することとするとよい。メッセージ情報に含まれるメッセージの全部を、ユーザによる文字の入力操作なしに、つまり手入力せずに自動的に生成することとするとよいが、メッセージの一部を生成してもよい。前者は、特に、運転者等のユーザのメッセージの作成に係るユーザの操作の負担を軽減し、簡単に投稿できる点で有利であり、後者は、特に、投稿するメッセージの作成の自由度を向上させ、多様なメッセージ情報を投稿可能にする点で有利である。車両の状態を反映することは、ユーザが車両の状態を直接又は間接的に把握することを可能にすることとするとよい。メッセージングサービスとしては、例えば、ソーシャルネットワーキングサービスとしてのＴｗｉｔｔｅｒ（登録商標）等とするとよい、Ｔｗｉｔｔｅｒにおいて、各ユーザが作成、投稿したメッセージは、ツイートとも呼ばれる。

（２）前記生成部は、前記車両の状態として、前記車両が前記車両の進行が妨げられる原因となり得る事象に接したと判定した場合に、前記事象に接したことを示す前記メッセージ情報を生成するとよい。

このようにすれば、ユーザは、車両の状態として、車両がその車両の進行が妨げられる原因となり得る事象に接したことを示すメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。車両の進行が妨げられる原因となり得る事象については、上述したとおりである。車両が、車両の進行が妨げられる原因となり得る事象に接したと判定したときに投稿する機能を備えるとよい。このようにすると、メッセージングサービスで第三者は、リアルタイムで車両の進行が妨げられる原因となり得る事象に関する情報を受け取ることができる。また、その情報を実際に車両の状態に基づいて生成しているため、ユーザが手入力でメッセージ情報の全部を作成、投稿するのと比べて、簡単に作成、投稿することができる。また、その情報を実際に車両の状態に基づいて生成しているため、ユーザは、より正しい情報を第三者と共有することができる。車両の進行が妨げられる原因となり得る事象として、渋滞は、ユーザが接する機会が比較的多い事象で、その情報の共有をすることは特に価値があるものであるが、ユーザは、このような渋滞に関するメッセージを簡単に作成、投稿することができる。

（３）位置情報を取得する位置情報取得部を備え、前記生成部は、前記メッセージに、前記事象に関する内容と、前記位置情報に基づいた内容とを含めるとよい。

このようにすれば、ユーザは、車両の進行が妨げられる原因となり得る事象が発生していることだけでなく、位置情報についても解るメッセージングサービスを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。位置情報は、車両が、車両の進行が妨げられる原因となり得る事象に接した位置を示すようにするとよい。この位置情報は、車両の進行が妨げられる原因となり得る事象が発生している位置またはその周辺を示す。このようにすると、ユーザは、その事象が発生している位置は、車両が現在いる位置であり、正確性の高いメッセージを第三者と共有することができる。また、第三者もメッセージをみたときに、車両の進行が妨げられる原因となり得る事象が発生していること、及びその事象が発生している位置を認識することができる。事象が渋滞である場合は、渋滞に関する内容と、位置情報に基づいた内容とを含めたメッセージを生成することとなる。

（４）前記生成部は、前記事象に関する事象詳細情報を取得し、前記メッセージ情報に含まれるメッセージは、前記事象詳細情報に基づいて生成するとよい。

このようにすれば、ユーザは、更に、車両の進行が妨げられる原因となり得る事象に関する詳細な情報に基づいて生成したメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。例えば、その事象に関する詳細な情報は、例えば、その事象の発生している状況や、実際にその事象を回避するのにかかった時間等とするとよい。このようにすると、第三者は、単に車両の進行が妨げられる原因となり得る事象が発生していることを知るだけでなく、更に詳細な情報を認識することができる。事象が渋滞である場合は、渋滞に関する渋滞詳細情報に基づいてメッセージを生成するとよく、このようにすると、渋滞に関する詳細な情報を共有することができる。

（５）前記事象詳細情報には、前記事象の発生原因となることを示す内容を含とよい。

このようにすれば、ユーザは、車両の進行が妨げられる原因となり得る事象の発生原因を含めたメッセージ、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。このようにすると、第三者は、その発生原因を認識することができる。車両の進行が妨げられる原因となり得る事象の発生原因として、例えば「事故」「工事」「土砂崩れ」「冠水」「火災」「災害」といったような発生原因を示す情報をメッセージに含めるとよい。このようにすると、第三者は、発生原因がいつもの理由なのか、普段にはない理由なのか、その事象が解消するのに時間がかかりそうかといったことを判断することができる。事象とその発生原因とが組になっていればよく、例えば、車両の進行が妨げられる原因となり得る事象が「渋滞」で、その発生原因が「事故」としたり、車両の進行が妨げられる原因となり得る事象が「事故」で、その発生原因が「車両同士の衝突」としたりしてもよい。事象が渋滞である場合は、渋滞に関する渋滞詳細情報に基づいてメッセージを生成するとよく、このようにすると、渋滞に関する詳細な情報を共有することができる。第三者は、渋滞の発生原因がいつもの理由なのか、普段にはない理由なのか、渋滞のが解消するのに時間がかかりそうかといったことを判断することができる。発生原因としては、「事故」「工事」「土砂崩れ」「冠水」「火災」「災害」、「車両同士の衝突」等があるが、原因が明らかでなければ、「原因不明」が用いられてもよい。

（６）前記事象詳細情報には、前記事象の発生範囲を示す内容が含むとよい。

このようにすれば、ユーザは、車両の進行が妨げられる原因となり得る事象の範囲を、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。渋滞の範囲は、例えば第１の地点から第２の地点まで発生しているといった範囲とするとよい。第１の地点は、例えば、事象の範囲の開始地点又はその周辺とするとよい。第２の地点は、事象の範囲の終了地点又はその周辺とするとよい。第三者は、その事象が普段も発生している場所かを確認したり、その事象の発生している距離を確認したりすることができる。このようにすると、例えば第三者はその事象が発生している範囲に含まれるルートを迂回するといった判断をすることができる。事象が渋滞である場合は、事象の発生範囲としては、車列の先頭から最後尾までの範囲や、渋滞を構成する車列の長さ等とするとよい。

（７）前記発生範囲は、前記車両の状態が前記事象に接したと最初に判定された第１の地点及び／又は前記車両の状態が前記事象に接した状態を脱したと判定された第２の地点を示す内容を含むとよい。

このようにすれば、ユーザは、車両の進行が妨げられる原因となり得る事象の発生範囲として、その事象に接したと最初に判定された第１の地点、及びその事象に接した状態を脱したと判定された第２の地点を、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。第三者はメッセージを確認して、その事象が発生している開始地点、及び終了地点に関する第１の地点、及び第２の地点がどこであるかや、その発生範囲がどの程度の長さかを認識することができる。また、このようにすると、例えば第三者は、その事象が発生している範囲を確認できることから、例えばその事象に接するのを回避するルートを選定しやすくなる。事象が渋滞である場合は、車両は、渋滞の発生地点と、どこで渋滞から脱したかを共有することができるので、第三者は、ユーザの渋滞の発生から脱するまでの実際の経験に基づいて情報を確認することができる。

（８）前記事象詳細情報は、前記事象の発生範囲の距離及び／又は前記事象の発生範囲の通過時間を示す内容を含むことにしてもよい。

このようにすれば、ユーザは、車両の進行が妨げられる原因となり得る事象の発生範囲として、その範囲の距離や時間に関する情報を併せたメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。メッセージを確認した第三者は、その事象の発生範囲の長さから、そのまま走行するか、その発生範囲を避けたルートを走行するかを判断しやすくなる。事象が渋滞である場合は、渋滞の発生範囲と、その発生範囲に車両が進入した場合の通過時間を投稿するとよく、このようにすると、第三者は渋滞の発生範囲や通過時間を確認して、ルート選択や移動時間の推定等にこれを利用することができる。

（９）前記事象詳細情報は、前記車両の状態が前記事象に接していることを示す状態であるとき、当該車両が走行している道路名称を含むとよい。

このようにすれば、ユーザは、車両が走行している道路において、車両の進行が妨げられる原因となり得る事象が発生しているときに、その道路名称を含むメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。メッセージに道路名称が含まれていることから、第三者はその事象が発生している道路がどこであるかを把握することができる。また、道路名称がメッセージに含まれることから、第三者は、いわゆるラジオ等のニュース番組で放送される交通情報に近い感覚で、その事象に関する情報を知ることができる。事象が渋滞である場合は、第三者は、どの道路名称の道路で渋滞が発生しているかを確認でき、車両で移動するときのルート選択や移動時間の推定等にこれを利用することができる。

（１０）前記事象詳細情報は、前記車両の状態として走行状態と、前記道路名称とから、前記事象が発生している当該道路の方向を含むとよい。

このようにすれば、ユーザは、車両が走行している道路名称だけでなく、車両の進行が妨げられる原因となり得る事象が生じている道路の方向を、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。道路の方向は、道路に対して決められた車両が進行すべき方向とするとよく、例えば、上り／下り、東行き／西行き、南行き／北行き、外回り／内回り等とするとよい。このようにすると、第三者は、道路名称だけでなく、道路の方向までメッセージで確認することができる。ユーザは、自分の進行方向により渋滞が影響あるか否かを判定しやすくなる。事象が渋滞である場合は、第三者は、車両の走行状態とともに、どの名称の道路で渋滞が発生しているか、渋滞が発生している道路の方向といったより詳細な情報を確認でき、車両で移動するときのルート選択や移動時間の推定等にこれを利用することができる。

（１１）前記生成部は、前記位置情報に基づいた地図を前記メッセージに含め、前記地図は、前記事象詳細情報に基づいて識別表示がされるとよい。

このようにすれば、ユーザは、メッセージに位置情報に基づいた地図が含まれ、かつその地図が車両の進行が妨げられる原因となり得る事象の詳細な情報に基づいて識別表示された状態で、メッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。第三者は、メッセージを確認したときに、例えばテキスト情報だけでなく、その事象の詳細な情報に基づいて識別表示された地図も併せて確認することができる。位置情報に基づいた地図は、その位置情報が示す位置の周辺の地図とするよく、例えば、位置を中心とした所定の距離の範囲の地図とするとよい。識別表示された状態としては、例えば、事象が発生している場所、事象の発生範囲を識別表示することとするとよい。このようにすると、第三者は、その事象の発生範囲や距離を視覚的に判断することができる事象が渋滞である場合は、第三者は、地図上に渋滞に関する詳細な情報を表現し、その第三者が渋滞に関する詳細な情報を把握しやすくなる。メッセージングサービスとして、例えば、Ｔｗｉｔｔｅｒ等とするとよい。Ｔｗｉｔｔｅｒにおいて、テキスト情報は、各ユーザが投稿するテキスト情報であり、ツイートとも呼ばれる。テキスト情報は、タグを含むとよく、そのタグとしてはハッシュタグとするとよい。地図は、Ｔｗｉｔｔｅｒの機能に搭載された画像ファイルを添付する機能を用いて投稿されるとよい。

（１２）前記生成部は、前記事象詳細情報に基づいてタグを生成し、当該タグを前記メッセージに含めるとよい。

このようにすれば、ユーザは、事象詳細情報に基づいて生成されたタグをメッセージに含めた上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。タグは、例えば、事象詳細情報に含まれる項目を示すテキスト情報とするとよく、例えば、車両の進行が妨げられる原因となり得る事象が発生している位置、及び道路の名称等とするとよい。このようにすると、第三者は、メッセージングサービスにおいて、タグを選択することで、その詳細な情報を容易に検索することができる。メッセージングサービスとして、例えば、Ｔｗｉｔｔｅｒ等とするとよい。Ｔｗｉｔｔｅｒにおいて、タグを含むとよく、そのタグとしてはハッシュタグとするとよい。事象が渋滞である場合は、車両の周辺で発生した渋滞に関する情報をタグに含めて共有するので、タグを見た第三者は、より確実に渋滞に関する情報を受け取りやすくなる。

（１３）前記生成部は、前記位置情報に基づいた内容として、緯度経度情報、市区町村の名称、ランドマーク名、及び交差点名の少なくとも１つを前記メッセージに含めるとよい。

このようにすれば、ユーザは、位置情報として、緯度経度情報や、市区町村の名称、ランドマーク名、及び交差点名といった、車両の進行が妨げられる原因となり得る事象が発生している位置を示す具体的な内容をメッセージに含めた上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。第三者は、その事象に関する渋滞を知りたい場合、緯度経度情報や、市区町村の名称、ランドマーク名、及び交差点名の少なくともいずれかを指定して検索することが考えられるため、所望するメッセージに容易にたどり着きやすくなる。

（１４）前記生成部は、前記事象詳細情報に基づいて絵文字を前記メッセージに含めるとよい。

このようにすれば、ユーザは、事象詳細情報に基づいた絵文字をメッセージに含めた上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。ここでの絵文字は、メッセージングサービスにおいて利用可能な絵文字とするとよい。また、他の人のメッセージ（つぶやき）に含まれている絵文字を利用するとよい。絵文字を利用することで、感情や状態を表してもよい。また、ユーザが利用した絵文字がメッセージングサービスと、車両側の表示とで同じ絵文字が表示されるようにするとよい。このようにすると、見た目も同一の絵文字が表示されるので、ユーザと第三者とは、メッセージングサービスと、車両側の表示とで同じ絵文字を使用したメッセージを見ることができる。絵文字の外観が異なっていてもよいが、同じ内容を意味する絵文字を表示するとよい。例えば、「笑顔」の絵文字であれば、絵文字を示す文字コードが少なくとも同一とするとよい。事象が渋滞である場合は、第三者は、絵文字を通じて、渋滞の状況を直観的に把握することができる。

（１５）前記生成部は、前記事象の発生範囲の大きさ及び／又は前記事象の発生範囲の通過時間に応じて、前記絵文字の数又は内容を変えて前記メッセージに含めるとよい。

このようにすれば、ユーザは、車両の進行が妨げられる原因となり得る事象の発生範囲の大きさ及び／又はその発生範囲の通過時間に応じて絵文字の数又は内容を変えたメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。例えば、その事象の発生範囲が大きい場合には、多くの絵文字を繰り返し表示するとよい。例えば、その発生範囲の通過時間がかかる場合は、絵文字は１個等とするとよい。例えば、絵文字の内容を変える場合は、その事象の発生範囲に応じてユーザの心境を表現した絵文字を変えるとよい。例えば、その事象の発生範囲が小さい場合は、「笑顔」や「無表情」といった心境を表現する顔文字とし大きい場合には、その事象の発生範囲が大きい場合は、「怒り」や「悲しみ」といった心境を表現する顔文字とするとよい。このようにすると、第三者は、絵文字を見れば車両の進行が妨げられる原因となり得る事象の発生の程度を、容易に判定することができる。事象が渋滞である場合は、渋滞の距離が２ｋｍ、５ｋｍ、８ｋｍ・・・という具合に所定距離増えるごとに、絵文字の数を増やしたり、内容を変えたりするとよい。このようにすると、第三者は、絵文字を見れば、発生している渋滞が長いのか、短いのかを容易に判定することができる。

（１６）前記生成部は、画像を記憶する記憶部に記憶された画像に関する情報を前記メッセージに含めるとよい。

このようにすれば、ユーザは、画像を記憶する記憶部に記憶された画像に関する情報をメッセージに含めた上で、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。画像に関する情報は、画像ファイルの形式とするとよい。また、画像に関する情報は、画像ファイルを示すリンク情報（例えばＵＲＬ）としてもよい。このようにすると、第三者は、単なるテキストだけでメッセージを確認するだけでなく、併せて画像ファイルにより表現される画像を確認することができることから、より解りやすく情報を得ることができる。画像に関する情報は、例えば、車両の進行が妨げられる原因となり得る事象の発生の状況を把握するのに役立つ情報とするよい。このようにすると、ユーザは、その発生の状況を正確な内容で第三者と共有しやすくすることができる。画像に関する情報は、記憶部に記憶された画像自体としてもよいが、記憶部に記憶された画像から生成した情報としてもよい。画像から生成した情報としては、その画像の内容を説明する情報としてもよく、例えば、テキスト情報としてもよい。テキスト情報としては、例えば、画像認識して、認識した結果に基づき事象の発生状況を説明したテキスト情報を生成するとよい。記憶部は、車両に配置された装置に内蔵された記憶部と把握されてもよいが、その装置の外部の記憶部としてもよい。内蔵された記憶部は、フラッシュメモリ、ＲＡＭといった車載用装置で一般的に用いられる記憶部とするとよい。外部の記憶部は、ＳＤカード等の装置に着脱可能な記憶媒体や、スマートフォンその他の車両の中の人が携帯する情報処理端末に内蔵された記憶部、ネットワーク上に確保された記憶部などとするとよい。

（１７）前記画像は、前記車両の運転を支援するための表示画面をキャプチャしたキャプチャ画像とするとよい。

このようにすれば、ユーザは、車両の運転を支援するための表示画面をキャプチャした画像に関する情報をメッセージに含めた上で、そのメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。車両の運転を支援するための表示画面を表示する装置としては、スマートフォンなどのユーザが携帯する情報処理端末としてもよいが、もっぱら車両の運転を支援するための機能を提供する車載用装置の表示画面とするとよい。車載用装置としては、例えば、撮影及び録画機能を提供するドライブレコーダ、ルート案内等のナビゲーション機能を提供するナビゲーション、及び速度取締地点と所定の接近関係を有することを報知する報知機能を有する探知機（例えば、レーダー探知機、レーザー探知機）等とするとよい。車両の運転を支援するための表示画面においては、地図を表示することも多い。そこで、例えば、車両の運転を支援するための表示画面として地図を含む表示画面をキャプチャして、その地図を含めた画像を含むメッセージを生成するとよい。位置（例えば住所や道路名称）を含む表示画面をキャプチャして、その位置を含めた画像を含むメッセージを生成するとよい。このようにすると、第三者は、メッセージに含まれた画像から、車両の進行が妨げられる原因となり得る事象が発生している付近の地図や、場所を画像からも確認することができるようになる。キャプチャの実行は、ユーザの手入力によって指示されるとよく、例えばワンタッチの操作できるようにするとよい。キャプチャはユーザの明示の指示なしに実行されてもよく、例えば、所定のイベントが発生した場合に実行されたり、定期的に実行されたりするとよい。投稿に用いられる画像は、ユーザが指示してもよいし、その指示無しに選択されてもよい。

（１８）前記画像は、車両の外を撮影する撮影装置が撮影した画像であるとよい。

このようにすれば、車両の外を撮影した画像に関する情報をメッセージに含めた上で、そのメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。車両の外としては、車両の前方、後方、及び側方の少なくともいずれかの方向を含むとよいが、特に前方を含むとよい。第三者は、画像に車両の進行が妨げられる原因となり得る事象を撮影した様子が映っていれば、どの程度の状態が発生しているかを視覚的に確認することができる。事象が渋滞である場合は、車両の外として、特に車両の前方を撮影するとよい。このようにすると、第三者は、渋滞の車列等からどの程度の状態が発生しているかを視覚的に確認することができる。ここで撮影装置は、車載用装置に備えられてもよいが、車載用装置とは別の構成であってもよい。例えば、車載用装置に車両の前方を撮影するカメラを備えてもよい。また、車両に備えられているドライブレコーダの画像を利用してもよい。また、ユーザが所有するスマートフォンその他の情報処理装置に備えられたカメラを利用してもよい。

（１９）前記画像は、前記位置情報に基づいた地図であるとよい。

このようにすれば、ユーザは、位置情報に基づいた地図をメッセージに含めた上で、そのメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。位置情報に基づいた地図は、その位置情報が示す位置の周辺の地図とするよく、例えば、位置を中心とした所定の距離の範囲の地図とするとよい。このようにすると、第三者は、地図を確認することで、具体的にどの位置で車両の進行が妨げられる原因となり得る事象が発生しているかを把握することができる。事象が渋滞である場合は、渋滞が発生している場所周辺の地図の画像が用いられるとよい。このようにすると、第三者は、場所と渋滞の発生状況との関係を理解しやすい。

（２０）前記生成部は、前記位置情報に基づいてタグを生成し、当該タグを前記メッセージに含めるとよい。

このようにすれば、ユーザは、位置情報に基づいて生成されたタグをメッセージに含めた上で、そのメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。位置情報に基づいて生成されたタグとして、例えば市区町村名、道路名称、又はランドマーク名といったタグとするとよい。第三者はタグを利用することで、容易に所定の位置情報に関連するメッセージを検索することができる。例えば、同じ地域のメッセージを有する者とコミュニケーションが取りやすくなるといったことも考えられる。事象が渋滞である場合は、渋滞に関するタグを生成するとよい。このようにすると、第三者は、渋滞と位置情報とに関連するメッセージを検索することができる。

（２１）前記生成部は、前記車両の状態として、少なくとも前記車両が渋滞に接したことを示す前記メッセージ情報を生成するとよい。

このようにすると、ユーザは、車両の進行が妨げられる原因となり得る事象として、渋滞に関するメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。渋滞は、車両の進行が妨げられる原因となり得る事象の中でも、車両にいるユーザが接する機会が比較的多い事象であるが、第三者にとっては、渋滞に関するメッセージが共有されることで、渋滞により受ける影響を抑えることができる。また、車両の状況が渋滞に接していることであることは、車両の車両速度から判定するとよいが、特に、車両速度が所定速度以下の状態が所定時間継続したことから判定するとよい。所定速度や所定時間は、車両が走行中の道路の種類によって変えすると良い。このようにすると、渋滞の判定精度を向上させることができる。

（２２）前記生成部は、前記車両の状態から、車両又は車両の周辺に発生した事象の種類として、少なくともあおり運転、取り締まり、通行止め又は危険運転があったことを判定した場合に、当該発生した事象の種類を示す前記メッセージ情報を生成するとよい。

このようにすれば、ユーザは、少なくともあおり運転、取り締まり、通行止め又は危険運転といった、発生した事象の種類を示すメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。発生した事象の種類は、発生した事象の種類をカテゴリーとするとよい。

（２３）前記生成部は、前記発生した事象の種類と、当該事象が発生した時刻に関連する情報と、当該事象が発生した道路の道路名称と、当該事象が発生した住所との少なくともいずれかを含むメッセージを生成するとよい。

このようにすれば、ユーザは、事象の種類と、事象が発生した時刻に関連する情報と、事象が発生した道路の道路名称と、事象が発生した住所との少なくともいずれかを含むメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。事象が発生した時刻に関連する情報としては、例えば、事象が発生した時刻だけに限らず、例えば事象が発生してから経過した時間を含めるとよい。また、事象が発生した道路名称としては、例えば、国道Ｘ号線のように、番号表記であってもよいし、○○通りといった通り名とするとよい。また、事象が発生した住所は、例えば、都道府県名、市区町村名とするとよいが、町名、番地までも含めてもよい。また、発生した住所に基づく情報として、例えば、施設名・ランドマーク名を含めるとよい。施設名・ランドマーク名としては、例えば、役所（市区町村の役所、警察署、消防署等）、駅、空港、ＰＡ／ＳＡ、公園、遊園地、ショッピングモール、ガソリンスタンド等の施設名を含めるとよい。

（２４）前記生成部は、前記道路名称及び／又は住所をタグとして前記メッセージに含めることにしてもよい。

このようにすれば、ユーザは、前記発生した事象の種類、当該事象が発生した時刻に関連する情報、当該事象が発生した道路の道路名称、当該事象が発生した住所をメッセージに含める場合に、タグとしてメッセージに含めた上で、そのメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。とくに、道路名称や住所は、タグを用いた検索に用いられやすいという知見に基づき、これをタグ化してメッセージに含めている。このようにすると、第三者は、メッセージングサービスにおいて扱われるタグを利用して、道路名称及び／又は住所と関連付けてメッセージを表示確認しやすくなる。

（２５）ユーザの選択により前記事象の種類を選択する選択部を更に備え、前記生成部は、前記選択部により選択された事象の種類を示す前記メッセージ情報を生成するとよい。

このようにすれば、ユーザは、実際に発生した事象の種類をより正確に特定した上で、その事象の種類を含めたメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。事象の種類の選択肢としては、ユーザが接する可能性が高い事象の選択肢があるとよく、例えば、渋滞、事故、速度取締等とするとよい。例えば、ユーザが任意のタイミングで「事故」に関するメッセージを投稿したいときには、「事故」を選択することで、「事故」と文字が含まれたメッセージを投稿することができる。

（２６）前記選択部は、タッチパネル又は音声認識装置を有するとよい。

このようにすれば、ユーザは事象を選択するときに、タッチパネルや音声認識において選択することができ、ユーザは簡単な方法で事象を選択することができる。タッチパネル又は音声認識装置は、車両に配置された車載用装置に設けられているとよい。このようにすると、車両内のユーザにとっても操作しやすい。音声認識で選択する構成のもとでは、例えば、ユーザが運転中の場合、音声認識を利用することで、手を離さずに簡単に事象を選択することができる。したがって、ユーザは安全運転に配慮して、装置の操作ができるようになる。

（２７）前記車両の状態に関するメッセージに対応した操作ボタンを更に設け、前記生成部は、ユーザにより前記操作ボタンにより操作があったことを検出して、前記メッセージを生成するとよい。

このようにすれば、ユーザは操作ボタンを選択することで、その操作ボタンに対応した車両の状態に関するメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。また、この操作ボタンは、メッセージを生成し投稿するボタンとは独立して設けられるとよい。このようにすると、ユーザは操作に迷いにくくなる。また、ユーザが必要に応じて他のユーザと共有すべきと判断した情報を、簡単に他のユーザとメッセージングサービスを介して共有しやすくなる。操作ボタンは、表示画面に表示されるソフトボタンとするとよいが、物理ボタンとしてもよい。

（２８）前記操作ボタンは、複数設けられており、前記生成部は、前記ユーザにより操作された前記操作ボタンに対応したメッセージを生成するとよい。

このようにすれば、ユーザは、複数の操作ボタンの各操作ボタンに対応した車両の状態に関するメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。例えば事象毎に操作ボタンを割り当てられていたり、生成するメッセージ毎に操作ボタンが割り当てられていたりするとよい。例えば、第１のボタンには単にテキストでメッセージを生成する機能を割り当て、第２のボタンには、画像付き（例えば、車両の前方を撮影した画像を含む）メッセージを生成する機能を割り当てるとよい。

（２９）前記操作ボタンは、少なくとも事故を示すボタン、及び渋滞を示すボタンの何れかを設けているとよい。

このようにすれば、ユーザは、車両の利用中に接する可能性が相対的に高いと考えられる、「事故」や「渋滞」に関するメッセージを容易に作成し、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。

（３０）ユーザからの音声入力を受け付ける音声入力部を更に備え、前記生成部は、前記音声入力部から音声入力があったときに、前記メッセージを生成することにしてもよい。

このようにすれば、ユーザからの音声入力に基づいてメッセージを生成した上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。ユーザからの音声入力は、ユーザが発した音声とするとよい。ユーザが発した音声を認識したことをトリガとして、メッセージを生成するとよい。例えば、ユーザが発した所定のキーワード（例えば、「危ない」や、「混んでる」）に対応付けて事象のメッセージを生成し、投稿してもよい。メッセージは、ユーザが発した所定のキーワード自体を含んでもよいが、そのキーワードから推測される事象を説明したメッセージを生成すると、第三者にとって解りやすい。また、入力されたユーザの音声の音量が所定の音量以上のときにメッセージを生成してもよい。また、入力された音声に基づいて音声認識を行い、音声認識の結果を含めてメッセージを生成してもよい。

（３１）前記生成部は、前記音声入力された音声データを前記メッセージ情報に含めることよい。

このようにすれば、ユーザは、音声自体をメッセージに含めた上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。ユーザは、音声自体をメッセージに含めることで、より簡単にメッセージを投稿することができる。メッセージングサービスとして、例えば、ソーシャルネットワーキングシステムとしてのＴｗｉｔｔｅｒ等とするとよい。Ｔｗｉｔｔｅｒにおいては、音声メッセージを投稿する機能があるので、これを利用するとよい。

（３２）前記生成部は、アンケート機能を実行するための前記メッセージを生成することにしてもよい。

このようにすれば、ユーザは、車載用装置を通じて、第三者を対象としたアンケートを取ることができる。メッセージングサービスとして、例えば、ソーシャルネットワーキングシステムとしてのＴｗｉｔｔｅｒ等とするとよい。Ｔｗｉｔｔｅｒにおいては、アンケート機能を取るがあるので、これを利用するとよい。アンケート機能は、ダイレクトにメッセージ等を利用して実現されてもよい。アンケート機能を実行して、例えば、ユーザが投稿したメッセージが正しいかどうかを第三者に確認するアンケートを行い、そのメッセージをアンケートで評価できるようにするとよい。アンケート機能によるアンケートの内容は、ユーザが手入力で設定できるようにしてもよいが、その設定なしに決定してもよい。例えば、車両の状態に応じてアンケートの内容を決定するとよい。例えば、渋滞が発生していると判定したときにアンケート機能を実行して、渋滞が発生しているルートを選択した方がよいのか、渋滞を回避したルートを選択した方がよいのかを第三者にアンケートで確認するとよい。

（３３）前記生成部は、予め定められたキーワードを前記メッセージに含めるとよい。

このようにすれば、予め定められたキーワードをメッセージに含めた上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。予め定められたキーワードとしては、例えば、ユーザがいつもメッセージに含めたいことや、挨拶などを含めたメッセージとするとよい。予め定められたキーワードとしては、例えば、ユーザの店舗の告知や、ユーザのプロフィールのページへのリンク等を含めるとよい。また、予め定められたキーワードとしては、ユーザが所定のタグをいつも付けているときは、そのタグをキーワードとして予め設定するとよい。予め定められたキーワードとしては、ユーザが手入力で指定してもよいが、車載用装置側で判断してユーザの指定なしに挿入してもよい。

なお、予め設定するとは、その都度入力ではなく、車載用装置を利用中に常に同じキーワードが利用されるということである。したがって、工場出荷時にキーワードを記憶してもよいし、車載用装置に設定情報として記憶してもよい。

（３４）前記キーワードは、前記車両の状態を取得する装置の製造会社名及び／又は製品名であるとよい。

このようにすれば、車両の状態を取得する装置の製造会社名及び／又は製品名をメッセージに含めた上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。第三者は、当該製品を利用すれば同じ機能が実現できると考えることから、同じ製品を購入しようとする動機付けとなることが期待できる等、宣伝効果が期待できる。車両の状態を取得する装置としては、上述したような、ドライブレコーダ、ナビゲーション、探知機（例えば、レーダー探知機、レーザー探知機）等とするとよい。メッセージには、車両の状態を取得する装置の製造会社や製品名を毎回挿入するとよい。このようにすると、より高い宣伝効果が期待できる。また、例えば、当該装置の製造会社名及び／又は製品名を利用している事実が明らかとなるので、第三者は当該装置からメッセージが投稿されていることが解り、当該メッセージの信頼性が高いと認識することが期待できる。

（３５）前記生成部は、前記車両の状態を取得する装置の製造会社名及び／又は製品名のキーワードを含める場合は、前記車両の状態と区別可能にして前記メッセージに含めるとよい。

このようにすると、車両の状態のメッセージがどれであるかを他のユーザに分かるようにしつつ、メッセージングサービスへの投稿を通じて、ユーザにより使用されている装置の製造会社名及び／又は製品名を第三者と共有することができる。例えば、メッセージングサービスとして、ソーシャルネットワーキングシステムとしてのＴｗｉｔｔｅｒ等のＳＮＳ利用者は、若年層や購買層が多く、これらの層へのアピールや購買欲の向上への期待といった、装置の販売事業者の認知度向上や販売促進といった販売事業者側のメリットを期待することができる。

（３６）車載用装置と、管理装置とを含むシステムであって、前記車載用装置は、車両の状態を取得する取得部と、前記車両の状態を参照し、投稿情報を生成する投稿情報生成部と、前記投稿情報を前記管理装置に送信する制御を行う制御部部と、を備え、前記管理装置は、前記投稿情報を受信し、前記投稿情報から、メッセージングサービスに投稿するメッセージを含むメッセージ情報を生成する生成部と、前記メッセージ情報をメッセージングサービスに投稿する投稿部と、を備えるシステムであってもよい。

このようにすると、ユーザは、車載用装置と、一度中継装置となる管理装置とを含むシステムを利用して、メッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。例えば、上述したような、メッセージングサービスへのメッセージの投稿に関する機能を、管理装置に搭載することができる分だけ、車載用装置の構成の簡素化が期待することができる。

（３６）メッセージングサービスのメッセージから交通関連のキーワードを含むメッセージを取得する取得部を更に備え、前記生成部は、前記取得したメッセージに基づいて投稿するメッセージを生成するとよい。

このようにすれば、ユーザは、メッセージングサービスのメッセージから、交通関連のキーワードを含むメッセージをメッセージングサービスに投稿することができる。例えば、メッセージングサービスには、色々なメッセージが投稿されているが、交通関連のキーワードを含むメッセージだけを取得して投稿することになり他のユーザに交通関連のメッセージだけを共有することができる。

（３７）前記生成部は、前記取得したメッセージから特定される事象と、事象に関する位置を含む前記投稿するメッセージを生成するとよい。

このようにすれば、ユーザは、メッセージにメッセージから特定される事象と、事象に関する位置をメッセージに含めて投稿し、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。メッセージに特定される事象と、事象に関する位置とが含まれることから、他のユーザはメッセージングサービスのメッセージの中から特定される事象、事象に関する位置を容易に把握することができる。

（３８）前記交通関連のキーワードは、渋滞、事故又は逆走に関する、１又は複数の何れかであるとよい。

このようにすれば、ユーザは、交通関連のキーワードとして「渋滞」「事故」又は「逆走」に基づいて、メッセージングサービスにメッセージを投稿し、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。そして、新たな投稿メッセージとして、渋滞、事故、又は逆走に関するメッセージを生成することができる。これらのキーワードは、第三者にとっても必要性が高いキーワードと考えられ、ユーザは、第三者にとって必要性の高いメッセージを投稿しやすくすることができる。

（３９）前記生成部は、前記取得したメッセージから関連するメッセージを判定し、関連するメッセージをまとめて１つの投稿メッセージを生成するとよい。

このようにすれば、ユーザにとっては、電子機器において、関連するメッセージが複数表示されることがなく、まとめて１つの投稿メッセージとして確認ことができる。例えば、メッセージングサービスにおいて分散しているメッセージを、まとめて投稿メッセージを生成し、投稿するとよい。このようにすると第三者も、当該投稿メッセージを参照することで、必要な情報が含まれる投稿メッセージに接しやすくなる。

（４０）前記生成部は、前記関連するメッセージを表示可能なリンクに関する情報を前記投稿メッセージに含めるとよい。

このようにすれば、ユーザに、関連するメッセージを表示させたい場合にはリンクを選択することで、その関連するメッセージを見ることができる。リンクが選択されると、関連するメッセージを一覧で表示するようにするとよい。また、関連するメッセージをスレッド表示にするとよい。このようにすると、ユーザは、閲覧性の高い状態でメッセージを見ることができる。

（４１）前記生成部は、前記リンクに対応した２次元コードを示す画像を前記投稿メッセージに含めることにしてもよい。

このようにすれば、ユーザは、例えばスマートフォン等の端末装置において、２次元コードを読み込むことにより、リンクに関連付けられている、関連するメッセージを確認ことができる。例えば、２次元コードに含まれているリンクから、関連メッセージを一覧表示するサイトにジャンプして、端末装置に表示させるようにするとよい。なお、２次元コード以外の、情報を符号化した符号化画像を用いることとしてもよい。

（４２）前記生成部は、前記投稿メッセージに、前記取得したメッセージに含まれている内容を一部又は全部含めるとよい。

このようにすれば、ユーザは、投稿メッセージを参照することで、取得したメッセージの内容を確認することができる。このとき、取得したメッセージに含まれる全ての内容を含めてもよいが、一部の内容だけを含めるとい。ユーザは、投稿メッセージに取得したメッセージが含まれることから、投稿したユーザがどのような内容でメッセージを投稿したかを容易に確認することができる。

（４３）前記生成部は、前記取得したメッセージが、再投稿によるメッセージの場合には、前記投稿メッセージに含めないようにするとよい。

このようにすれば、ユーザは、投稿メッセージには、再投稿によるメッセージの内容を見なくすることができる。一般的に、再投稿によるメッセージは、再投稿の対象となったメッセージと同一内容を含んでいる。したがって、再投稿のメッセージが含まれることで、同じ内容が表示されるといったことを防ぐことができる。メッセージングサービスとして、例えば、ソーシャルネットワーキングシステムとしてのＴｗｉｔｔｅｒ等とするとよい。Ｔｗｉｔｔｅｒにおいて、再投稿によるメッセージは、リツイートのことである。

（４４）前記生成部は、前記取得したメッセージが再投稿されたメッセージの場合、再投稿された回数を前記投稿メッセージに含めるとよい。

このようにすれば、ユーザは、取得したメッセージの中に、再投稿の対象となっているメッセージある場合、再投稿された回数を確認ことで、そのメッセージがどの程度拡散されているかを認識することができる。一般的に、再投稿の数が大きければ、信頼性の高いメッセージとして評価することができる。

（４５）前記生成部は、前記再投稿された回数の遷移をグラフ表示した画像を前記投稿メッセージに含めるとよい。

このようにすれば、ユーザが、再投稿された回数の遷移がグラフによる表示されることで、どのような拡散の遷移があったかを視覚的に容易に把握することができる。

（４６）前記システムは、車両の状態を取得する装置と通信可能であって、前記制御部は、前記投稿メッセージを前記車両の状態を取得する装置に配信することにしてもよい。

このようにすれば、ユーザは、管理装置が生成して投稿メッセージを、メッセージングサービスに投稿するだけでなく、車両の状態を取得する装置において確認することができる。例えば、需要度の高い情報であれば、車両の状態を取得する装置においても併せて表示されることで、ユーザはより早く情報を得ることができる。

（４７）前記システムは、ユーザのアカウントを取得可能であって、前記制御部は、前記投稿メッセージにユーザのアカウントを識別する情報を含めることにしてもよい。

このようにすれば、ユーザは、投稿メッセージにユーザのアカウントを識別する情報を含めた上で、その投稿メッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。ユーザのアカウントを識別する情報として、メッセージングサービスで扱われている情報とするとよく、例えば、アカウントＩＤ、アカウント名等とするとよい。このようにすると、第三者は、メッセージを投稿するアカウントと、取得したメッセージの投稿者のアカウントが異なっていても、誰からのメッセージであるかと投稿することができる。

（４８）前記ユーザのアカウントは、メッセージの投稿者のアカウントとするよい

このようにすれば、ユーザは、アカウントを識別する情報として、メッセージの投稿者のアカウントを含めた上で、その投稿メッセージをメッセージングサービスへの投稿を通じて第三者と共有することができる。したがって、第三者は、メッセージの投稿者が誰であるかを容易に確認することができる。

（４９）前記ユーザのアカウントは、前記管理装置にログインするユーザのアカウントであってもよい。

このようにすれば、ユーザは、管理装置にログインするユーザのアカウントと、管理装置が送信するアカウントが異なる場合でも、第三者に対して明示することができる。また、管理装置を利用してメッセージを投稿するユーザは、管理装置が投稿したことを知ることができる。

（５０）前記生成部は、前記投稿メッセージとして、交通関連のキーワードに基づくカテゴリーと、事象の発生時刻に関連する情報と、事象が発生している道路名称と、事象が発生している住所と、予め定められたキーワードとの少なくともいずれかを含むとよい。

このようにすれば、投稿メッセージとして、交通関連のキーワードに基づくカテゴリーと、事象の発生時刻に関連する情報と、事象が発生している道路名称と、事象が発生している住所と、予め定められたキーワードとの少なくともいずれかを含めて、メッセージングサービスに投稿することができる。投稿メッセージに、渋滞に関する情報が複数含まれることにより、第三者は、メッセージを見ただけで、どのような事象が生じているのかを把握することができ、かつ、詳細な情報を得ることができる。

（５１）電子機器と、管理装置とを含むシステムであって、前記電子機器は、車両の状態を参照し、投稿情報を生成し、前記投稿情報を前記管理装置に送信する制御を行う制御部と、を備え、前記管理装置は、前記投稿情報を受信し、前記投稿情報から、メッセージングサービスに投稿するメッセージを含むメッセージ情報を生成する生成部と、前記メッセージ情報をメッセージングサービスに投稿する投稿部と、を備えるシステムが提供されるとよい。このようにすると、ユーザが、電子機器及び管理装置を介したメッセージングサービスへの投稿を通じて、車両の状態を、他のユーザと共有することができる。

（５２）管理装置は、制御部を備え、前記制御部は、メッセージングサービスのメッセージから交通関連のキーワードを含むメッセージを取得し、前記取得したメッセージから特定される事象と、事象に関する位置を含む投稿メッセージを生成し、前記投稿メッセージを前記メッセージングサービスに投稿することを特徴とする。

このようにすれば車載用装置と、メッセージングサービスとを中継する管理装置の機能により、メッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。例えば、上述したような、メッセージングサービスへのメッセージの投稿に関する機能を、管理装置に搭載することができる分だけ、車載用装置の構成の簡素化が期待することができる。

（５３）コンピュータに、上記何れかシステムの前記生成部の機能を実現させるためのプログラムが提供されるとよい。このようにすれば、ユーザは、メッセージングサービスへの投稿を通じて車両の状態を他のユーザと共有するためのメッセージを作成できる。

上述した（１）から（５３）に示した発明は、任意に組み合わせることができる。例えば、（１）に示した発明の全て又は一部の構成に、（２）以降の少なくとも１つの発明の少なくとも一部の構成を加える構成とするとよい。特に、（１）に示した発明に、（２）以降の少なくとも１つの発明の少なくとも一部の構成を加えた発明とするとよい。また、（１）から（５３）に示した発明から任意の構成を抽出し、抽出された構成を組み合わせてもよい。本願の出願人は、これらの構成を含む発明について権利を取得する意思を有する。また「～の場合」「～のとき」という記載があったとしても、その場合やそのときに限られる構成として記載はしているものではない。これらはよりよい構成の例を示しているものであって、これらの場合やときでない構成についても権利取得する意思を有する。また順番を伴った記載になっている箇所もこの順番に限らない。一部の箇所を削除したり、順番を入れ替えたりした構成についても開示しているものであり、権利取得する意思を有する。

本発明によれば、例えば、自車両の状態を、メッセージングサービスへの投稿を通じて他のユーザと共有すること、例えば従来技術を改善することができる。

なお、本願の発明の効果はこれに限定されず、本明細書及び図面等に開示される構成の部分から奏する効果についても開示されており、当該効果を奏する構成についても分割出願・補正等により権利取得する意思を有する。例えば本明細書において「～できる」「～可能である」などと記載した箇所などは奏する効果を明示する記載であり、また「～できる」「～可能である」などといった記載がなくとも効果を示す部分が存在する。またこのような記載がなくとも当該構成よって把握される効果が存在する。

第１実施形態におけるシステム全体を説明するための図である。第１実施形態におけるサービスの概要を説明する図である。第１実施形態のおける電子機器の概要を説明する図である。第１実施形態における電子機器の外観を説明する図である。第１実施形態における電子機器の取付部材を説明する図である。第１実施形態における電子機器の機能構成を説明する図である。第１実施形態における電子機器の外観を説明する図である。第１実施形態における電子機器の制御部及び記憶部の構成を説明する図である。第１実施形態における全体の処理を説明する動作フローである。第１実施形態における電子機器の外観を説明する図である。第１実施形態における電子機器における表示画面の一例を説明する図である。第１実施形態における実施例を説明する図である。第１実施形態における電子機器における表示画面の一例を説明する図である。第２実施形態におけるシステム全体を説明するための図である。第２実施形態における電子機器の制御部及び記憶部の構成を説明する図である。第２実施形態における管理装置の機能構成を説明する図である。第２実施形態における全体の処理を説明する動作フローである。第２実施形態における実施例を説明する図である。第２実施形態における実施例を説明する図である。

以下、図面を参照して本発明を実施するための形態について説明する。なお、以下に示す実施形態は、本発明を提供した一つの実施形態であり、以下の記載に基づいて本願発明の内容が限定して解釈されるものではない。なお、以下の説明で、括弧書きを使用している場合があるが、必ずしも、括弧書きした用語とその括弧書きの前に記載した用語とが同じ意味であることを示すものではない。

リアルタイムに端末装置や電子機器に対して情報を配信するサービスが知られている。例えば、サービスにて提供される情報として、発災フィードに含まれる、交通事故、交通渋滞、危険運転（煽り運転、逆走走行）、火災などの内容は、ユーザにとって有益な情報を提供可能である。また、随時情報が配信されることで、リアル感がユーザに対して伝わるといった有益性が感じられる。

また、時事ニュースに関する内容を配信したり、地震情報（震源地や各震度）を、マップ上で表現して配信するなど、様々な手法が知られている。

しかし、配信される情報は、全国レベルでみると、リアルな情報がたくさんあり、有益に一見すると感じるが、市区町村レベルや走行道路レベルだと、情報量が少なくなってしまうという問題があった。例えば、有料の情報配信サービスを利用したとしても、全国レベルの情報を配信する場合はよいが、市区町村レベル、走行道路レベルとなると情報が限られており、ユーザはコスト面で割高に感じてしまったり、必要な情報を手に入れられないという問題があった。

また、時事ニュースに関する内容を受信した場合、一般的には閲覧のみでデータとして使えないという問題があった。

そこで、本明細書において、メッセージングサービスや、ソーシャルネットワーキングサービス（ＳＮＳ）を活用することで、上述した問題を解決することにした。

近年、メッセージングサービスや、ソーシャルネットワーキングサービスといった、ユーザ発信の情報を提供するサービスが知られている。しかし、これのサービスでは様々なメッセージが存在しており、必ずしも有効なメッセージだけがあるとは限らなかった。

特に、車両を運転中に事故や渋滞に遭遇したとしても、運転中にスマートフォン等の装置を操作することは違法であり、迅速に情報を発信するということはできなかった。

また、ユーザが各自発信する内容にはブレがあるために、必ずしも適切な内容が送信されているとは限らなかった。

上述したサービスの知名度や、集客力の良さを利用することで、例えばサービスに対応した製品（例えば、電子機器）をより多くの人に知ってもらえる機会となり、ＳＮＳの利用者の多い若年層の購買欲に期待が持てるといった効果も考えられる。

例えば、メッセージングサービスにおけるメッセージの内容である交通渋滞や事故情報、危険運転の情報は、サービスの特性から、他の情報配信サービスより速く、そして実況っぽい感じが提供できる。このような、サービスを連携することで、ユーザにとって「面白い」と感じるシステムを提供することが可能である。また、情報を即時に配信できることかｒ、実用的にも有効なシステムを提供することが可能である。

メッセージングサービスにおいて利用可能なインタフェース（例えば、ｔｗｉｔｔｅｒＡＰＩ）を利用すれば、サービス上において交通関連のキーワード検索ができる、メッセージ（tweet）を抽出することが可能である。これにより、有料の情報配信サービスや、緊急地震速報のような、緊急度の高い情報を割込みで配信できなくとも、メッセージングサービスを利用したリアルな情報を配信することは可能である。

また、メッセージをそのまま流用することも可能であるが、例えば文中から事象を判定して「事故渋滞の情報」や「あおり運転が報告されました」などにまとめて配信することで、ユーザにとって解りやすいシステムを提供することができる。

また、メッセージングサービスのインタフェース（例えば、ｔｗｉｔｔｅｒＡＰＩ）は、メッセージ（tweet）の自動投稿が可能である。この場合、スマートフォンからではなく、電子機器から直接又は電子機器からサーバを経由してメッセージを投稿したり、再投稿（RT）したりすることで、他の人に有益な情報を提供することもできる。

また、メッセージを投稿するときに、当該メッセージに電子機器の製品名や、製造会社の情報を付加することにより、多くの人に製品を知ってもらえる機会が作れるという効果も期待できる。

メッセージングサービスのインタフェースで利用するキーは、サービスを提供している者から事前に取得しておくことで、メッセージの取得、抽出、投稿（自動投稿）はできる。

また、電子機器は、取得したメッセージに基づく情報を表示することにしてもよい。例えば、電子機器が既に取締り情報等をテロップ表示可能な場合、メッセージ（tweetや、返信メッセージ、例えばインスタコメントの内容）もテロップ表示をすることが可能である。

また、電子機器は、テロップ表示として、電子機器が位置する市区町村に基づいて既に管轄警察署の取締情報を表示している。したがって、表示するメッセージも自車と同じ市区町村に関連するメッセージについて表示させてもよい。

また、電子機器は、住所、緯度経度、道路名称、ICやJCT、SAやPA名など場所が特定できるようなデータであれば、地図上で地点を表示したり、道路を点滅表示したりして識別表示させることも可能である。

また、メッセージ（tweet）やコメントの部分をそのまま引用すると、ユーザにとって解りにくい場合があったり、無断表示として投稿者からクレームになる可能性もある。そこで、文中の内容を自動解析して「事故渋滞の情報です」「逆走走行の危険情報です」などに変換して表示させてもよい。

また、メッセージの情報の時間的な終了を判断するのは難しかったり、ユーザにとって解りにくい部分がある。そこで、発生時間から「Ｘ分前」「Ｘ分経過」とか表示させてもよい。また、経過時間に応じて道路点滅の色も薄くしていくとかして、情報の劣化性も表現してもよい。

また、電子機器が車両で使用されている場合、極力手による操作は避けた方がよい。そこで、音声認識による画面操作で、電子機器が操作を行ったり、投稿をできるようにした方がよい。また、音声入力された音声を認識し、投稿するメッセージである文章の作成をできてもよい。

上述した内容を実現するための実施をするための形態について、以下、図面を参照して説明する。

［１．第１実施形態］
［１．１システムの説明］
［１．１．１システムの概要］
図１は、システム１の全体を説明する図である。システム１は、車両５０に配置可能な電子機器１０と、メッセージングサービスを提供するサービス提供装置３０（サービス提供用のサーバ装置）とがネットワークＮＷを解して接続可能に構成されている。

後述するが、電子機器１０は、サービス提供装置３０とネットワークＮＷを介して直接接続してもよいし、管理装置や、他の端末装置（例えば、スマートフォンやタブレット等の情報処理装置や、カーナビゲーション装置等）を介してサービス提供装置３０と接続してもよい。

［１．１．２メッセージングサービスの説明］
つづいて、本実施形態におけるメッセージングサービスについて説明する。メッセージングサービスは、ユーザと他のユーザとの間でメッセージのやりとりを可能にするサービスである。本実施形態のメッセージングサービスは、特に断りのない限り、ソーシャルネットワーキングシステム（ＳＮＳ）を想定しており、特に、Ｔｗｉｔｔｅｒ（登録商標）を利用したシステムを想定している。メッセージングサービスのうち、ＳＮＳの特徴としては、特定多数又は不特定多数のユーザの間でメッセージがやり取りされることが多く、また、メッセージの送り先（つまり、メッセージを読ませたい相手）を指定していないメッセージも多くやり取りされる。そして、やり取りされているメッセージの中には、ユーザ自身にとって必要な情報を含むメッセージと、そうではないメッセージとが混在しており、後者のメッセージの方がはるかに多いこともよくある。本実施形態は、このようなメッセージングサービスの特徴も考慮してなされたものであるが、ＳＮＳでないメッセージングサービスを排除する趣旨ではない。

メッセージングサービス（サービス）は、ユーザやシステムから投稿されたメッセージを、各ユーザの端末装置に配信可能である。各ユーザの端末装置は、メッセージングサービスから、メッセージを取得し、例えば時系列順に表示する、いわゆるタイムラインを生成して表示することが可能である。また、個別に取得したメッセージを、メッセージ毎に表示装置に表示したり、音声出力装置から音声出力したりしてもよい。

ここでメッセージを投稿するとは、何れかの端末装置や、他のサービスからメッセージングサービスのサーバ装置にメッセージ情報を送信することをいう。メッセージ情報には、メッセージと、メッセージに関する属性とが含まれている。本実施形態のメッセージは、主にテキストであるが、画像（静止画像及び動画像の一方又は両方を含む）、音声も含まれる。また、属性には、例えばメッセージを投稿するアカウントに関する情報（例えば、アカウントを識別するユーザＩＤ、アカウントＩＤや、当該アカウントを使用するユーザのユーザ名、メッセージの投稿日時等）が含まれる。また、メッセージングサービスから端末装置に送信されるメッセージ情報には、それ以外の属性が含まれてもよい。例えば、属性には、後述するようにメッセージに返信したメッセージに関する情報、再投稿に関する情報（例えば、再投稿数、再投稿をしたユーザに関する情報）、評価に関する情報（例えば、評価数、評価をしたユーザに関する情報）等が含まれてもよい。また、前記画像は、画像に関する情報が含まれていればよく、画像自体がメッセージに含まれてもよいが、画像のリンク先を示す情報（例えば、ＵＲＬ）であってもよい。

また、メッセージングサービスがメッセージを配信すると、端末装置がメッセージ情報をメッセージングサービスのサーバ装置から受信する。端末装置は、サーバ装置にメッセージ情報を要求して取得してもよい。また、サーバ装置から定期的に端末装置にメッセージ情報を送信してもよい。

なお、本実施形態のメッセージ情報は、端末装置からメッセージングサービスに投稿する場合と、メッセージングサービスから端末装置に配信する場合について説明するが、メッセージ情報の内容は異なるものであってもよい。

メッセージングサービスの機能について、例えば、図２のタイムラインを一例に説明する。図２のタイムラインは、サービス提供装置３０から取得したメッセージを、時系列順に何れかの端末装置で表示したものである。例えば、タイムラインは、電子機器１０の表示装置で表示してもよいし、携帯端末装置４０の表示装置で表示してもよい。

取得する端末装置は、メッセージングサービスからメッセージを取得する。例えば、図２では、メッセージＭＳ１００、ＭＳ１０２、ＭＳ１０４、ＭＳ１０６の４つのメッセージが取得されている。

端末装置は、サービス提供装置３０から、メッセージ情報を取得する。メッセージ情報には、当該メッセージを投稿したユーザに関する情報として、ユーザ名、アカウントＩＤ、投稿日時、位置情報、ユーザアイコン等が含まれていてもよい。例えば、メッセージＭＳ１０４においては、領域Ｒ１００にユーザ名が、領域Ｒ１０４にアカウントＩＤが、領域Ｒ１０６に投稿日時が、領域Ｒ１０８にメッセージがそれぞれ表示されている。

ここで、ユーザ名に対応するアカウントＩＤは、「＠」以降の文字列をいう。アカウントＩＤは、英数文字、記号等の何れかの文字の組み合わせである。また、アカウントＩＤは、日本語等の２バイト文字が含まれていてもよい。

また、ユーザのアカウントは、サービス提供者が認証を行ったことを示すマーク（例えば、領域Ｒ１３０）を表示してもよい。当該メッセージのユーザが、著名人や、企業の場合、マークが表示されていることにより、なりすましではないことが第三者にとって容易に確認をすることができる。

また、ユーザのアカウントは関連づけることが可能である。例えば、第１のユーザが、第２のユーザを関連づけることにより、第２のユーザのメッセージを取得したり、第２のユーザの情報を取得することができる。このように、特手の関連づけることを、例えば「フォロー」するという。この場合、第２のユーザからみると、第１のユーザは「フォロワー」となる。また、第１のユーザと第２のユーザとは「友達」といってもよい。

また、メッセージは、予め定められた文字数を上限として、テキストの文字列により構成されている。なお、メッセージは、画像、音声、動画を含んでも良い。また、メッセージには「タグ」と呼ばれるものを含んでもよい。例えば、領域Ｒ１２０には、タグとして「＃東名高速」が含まれている。ユーザはタグを利用することで、関連する話題を容易に探し出すことが可能である。

また、メッセージにアカウントＩＤを含むことにより、当該ユーザ宛にメッセージを送信することが可能である。例えば、メッセージＭＳ１００には、アカウントＩＤに関するメッセージとして「＠ｔａｒｏｕ」が含まれている。これにより、メッセージＭＳ１００はアカウントＩＤ「＠ｔａｒｏｕ」に対してメッセージを送信することになる。

また、各メッセージに対して、ユーザが所定の行動を起こすことが可能である。本実施形態では、返信、再投稿、評価の３つの機能を実現している。この３つの機能に対応する操作ボタンに対応して、上記機能について説明する。

（１）返信（領域Ｒ１１０）
メッセージに対して返信を行う。これにより、例えば返信元のメッセージと、返信先のメッセージとは関連づけられることになる。また、本実施形態では、返信元となるメッセージに返信をおこなうと、併せて返信元のメッセージのアカウントＩＤをメッセージの中に含めてメッセージを作成する。返信機能は、例えばリプライ機能やコメント機能と呼ばれるものである。

（２）再投稿（領域Ｒ１１２）
メッセージと同じ内容を再投稿する。この再投稿は、元のメッセージをそのまま投稿してもよいし、自分のメッセージに引用する形式で再投稿してもよい。例えば、図２では、メッセージＭＳ１０６は再投稿されたメッセージである。この場合、元のメッセージがそのまま表示されている。また、領域Ｒ１３２では、当該メッセージが再投稿によるものであることを示す識別表示が行われている。領域Ｒ１３２では、再投稿を示すアイコンと、再投稿をしたユーザのユーザ名とが表示されている。再投稿機能は、例えばリツイート機能や、リポスト機能と呼ばれるものである。

（３）評価（領域Ｒ１１４）
メッセージに対する評価を行う。この評価は、例えば「いいね」といった肯定的な評価であってもよいし、「お気に入り」といった機能であってもよい。また、「Ｇｏｏｄ」「Ｂａｄ」と両方の評価を行えるようにしてもよい。本実施形態の場合、領域Ｒ１１４に表示されている評価機能のアイコンをユーザが選択すると、当該メッセージに評価が加算される。また、再度評価機能のアイコンをユーザが選択すると、当該メッセージの評価が取り消されることにしてもよい。評価機能は、例えばお気に入り機能や、Ｆａｖｏｒｉｔｅ機能と呼ばれるものである。

なお、上述した返信機能、再投稿機能、評価機能に対応付けて表示されるボタンは、アイコンや文字で表示されてもよい。また、例えばメッセージに対するジェスチャ操作（例えば、メッセージをタップする、スワイプする等）により各機能が実行されてもよい。

図２では、各機能を行うことが可能なボタン（アイコン）を表示している。また、各ボタンの横には、実際に行われた人数が表示されている。

［１．２構成］
［１．２．１電子機器の構成］
［１．２．１．１電子機器の概要］
図３は、本発明の車載用装置の一実施形態に係る電子機器１０の概要を説明する図である。電子機器１０は、車両５０に配置される電子機器（車載用装置）であり、運転手その他のユーザに対して各種の情報を提供する。電子機器１０は、レーダー／レーザー探知機の機能を有しており、運転手の安全運転に資する情報を提供する。車両５０は、４輪自動車とするとよいが、４輪自動車に限らず、例えばバイク等の２輪車や４輪以上の大型輸送車等としてもよい。

電子機器１０は、車両５０が所定の目標物と所定の接近関係を有する場合に、ユーザに報知する報知機能を有する。所定の接近関係とは、車両５０が目標物に対して所定の距離以下まで接近している関係をいい、さらに、車両５０の進行方向、又は進路上に目標物が存在し、かつその目標物に対して所定の距離以下まで接近している関係をいうようにしてもよい。目標物として、例えば、車両の速度取締が行われる地点である速度取締地点がある。速度取締地点には、速度測定装置が設置されることがある。電子機器１０は、速度測定装置から発せられる取締波を受信する。取締波は、車両の速度を測定するための電磁波で、測定波、速度測定信号等と称呼されてもよい。速度取締地点は、車両の走行状況（例えば、車両が速度を出しやすいこと）、交通事故の発生状況（例えば、事故の発生数が多い地点）等の状況を勘案して、決定される。速度取締地点の一例は、例えば、車両が走行する路線（道路）のうち、一般道や、直線状の道路、カーブ又はカーブの先の地点等に存在する。速度測定装置としては、固定式、移動式等と呼ばれるもの等、多数存在する。移動式は、例えば、可搬式および車両に搭載される方式がある
電子機器１０は、本体部１０１００と、固定部１０２００と、に大別される。本体部１０１００は、固定部１０２００を用いて所定の設置位置に固定される。本実施形態では、設置位置は、車両５０のダッシュボード５１の上面である。固定部１０２００は、本体部１０１００の下に設けられ、本体部１０１００を所定の設置位置に固定させるための固定部材である。固定部１０２００は、ブラケットとも呼ばれる。

図４は、本体部１０１００の外観構成を示す図である。図４（Ａ）は、本体部１０１００を正面側の右斜め上方向から見た図である。図４（Ｂ）は、本体部１０１００を背面側の左斜め上方向から見た図である。

本体部１０１００は、筐体１０１１を有する。筐体１０１１は、上下よりも左右に長く、かつ厚みが比較的小さい直方体状である。筐体１０１１は、例えば樹脂又はその他の材料で形成されている。筐体１０１１の正面側には、上下よりも左右に長い長方形の開口部が設けられている。本体部１０１００は、この開口部の位置で画像を表示するための表示部１２０及び表示部１２０の表示領域に重ねられたタッチセンサ１５２を有する。本体部１０１００は、その正面側の表示部１２０の左側の位置に、照度センサ窓１２０１及び発光部１８０を有する。発光部１８０は、上下方向を長手方向とした発光領域を有する。筐体１０１１の右側面には、記憶媒体挿入口が設けられている。この記録媒体挿入口を介して、本体部１０１００に対して、記憶媒体１６２が装着される。記憶媒体１６２は、例えばＳＤカードである。ＳＤカードは、例えば、ＳＤメモリカード、ｍｉｎｉＳＤカード及びｍｉｃｒｏＳＤカード等のいずれの形状も含む。

筐体１０１１の背面側には、レンズホルダ１０１２が設けられている。レンズホルダ１０１２は、筐体１０１１の内外を貫通する貫通孔で、レンズ１１１を保持する。レンズ１１１は、集光用のレンズである。レンズ１１１は、本実施形態では、上下よりも左右よりも長い楕円形状で、光の入射面が非球面状であるアスフェリックレンズ（エスフェリックレンズ）と呼ばれるレンズであるが、他の集光用のレンズが用いられてもよい。筐体１０１１の背面側の下端付近であって、筐体１０１１の左右方向の中心付近には、取付部１０１３が設けられている。取付部１０１３は、固定部１０２００が取り付けられる部位である。取付部１０１３は、それぞれが上下に延びている一対の溝部を有する。筐体１０１１の背面側には、さらに、電子機器１０の電源のオン／オフを切り替えるための電源スイッチ１２２１、及び外部の装置を接続するための端子部１７２が設けられている。

図５は、固定部１０２００の外観構成を示す図である。図５（Ａ）は、固定部１０２００を正面側の右斜め上方向から見た図である。図５（Ｂ）は、固定部１０２００を正面側の左斜め上方向から見た図である。

固定部１０２００は、固定部材１０２１を用いて設置位置に固定され、台座部１０２２と、ソケット部１０２３と、ボールスタッド１０２４と、装着部材１０２５とを有する部材である。台座部１０２２は、設置位置（設置面）に固定される部位である。台座部１０２２の底面が、例えば粘着シート又は両面テープ等の固定部材１０２１を用いて設置位置に貼り付けられる。台座部１０２２は、正面側に開口した空間を有するソケット部１０２３を有する。ソケット部１０２３は、ボールスタッド１０２４が有するボール部が装着される。ソケット部１０２３と、ソケット部１０２３に装着されたボールスタッド１０２４とにより、ボールジョイント機構が構成される。ボールスタッド１０２４は、外力を受けて、ソケット部１０２３に装着された状態で、上下、及び左右に姿勢を変化させる。ボールスタッド１０２４のうちの正面側の部位には、装着部材１０２５が設けられている。装着部材１０２５は、本体部１０１００の取付部１０１３に装着される。装着部材１０２５は、正面から見て左右の両側に、正面側に突き出す一対の突出部を有する。この一対の突出部が、本体部１０１００の取付部１０１３の一対の溝部に挿入されることで、本体部１０１００の固定部１０２００への取り付けが完了する。本体部１０１００は外力を受けて、固定部１０２００に装着された状態で、上下左右に姿勢を変化することができる。これにより、ユーザは本体部１０１００を所望する姿勢に固定した状態で、電子機器１０を利用することができる。

図６は、電子機器１０の電気的構成を示すブロック図である。制御部１００は、フロントカメラの各部を制御する。制御部１００は、電子機器１０の各部を制御する。制御部１００は、例えば、プロセッサ１０１、及びメモリ１０２を含むコンピュータである。プロセッサ１０１は、例えば、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）、ＭＰＵ（ＭｉｃｒｏＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）、ＧＰＵ（ＧｒａｐｈｉｃｓＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ－ＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）、及びＦＰＧＡ（ＦｉｅｌｄＰｒｏｇｒａｍｍａｂｌｅＧａｔｅＡｒｒａｙ）の少なくともいずれかを有する。メモリ１０２は、例えば、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）、及びＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）等を有する主記憶装置である。プロセッサ１０１は、メモリ１０２のＲＯＭ又は記憶部１９０から読み出したプログラムをＲＡＭに一時的に記憶させる。また、メモリ１０２のＲＡＭは、プロセッサ１０１に作業領域を提供する。プロセッサ１０１は、プログラムの実行中に生成されるデータをＲＡＭに一時的に記憶させながら演算処理を行うことにより、各種の制御を行う制御部１００は、さらに、時刻を計る計時部１０３を備える。計時部１０３は、例えばリアルタイムクロックである。計時部１０３は、プロセッサ１０１のマザーボードに実装されていてもよいし、プロセッサ１０１に外付けされてもよい。

受光部１１０は、レーザー方式に対応した速度測定装置から、取締波としてのレーザー光を受光するための受光部である。受光部１１０は、レンズ１１１を介して入射した光を受光して、その受光した光に応じた信号を、制御部１００に出力する。受光部１１０は、レーザー光のうちの可視光をカットするフィルタ等の光学部材をさらに有してもよい。受光部１１０が出力する信号は、例えば受光部１１０の受光量に応じて変化する。受光部１１０は、例えば受光素子としてフォトダイオードを備えるが、フォトトランジスタ又はその他の受光素子であってもよい。受光部１１０は、受光素子を２つ以上備えてもよい。受光部１１０は、少なくとも赤外光領域に感度を有するとよい。受光部１１０は、さらに受光素子からのアナログ信号をデジタル信号に変換するＡ／Ｄ変換回路等を有してもよい。

表示部１２０は、画像を表示する。表示部１２０は、例えば３．２インチのカラーＴＦＴ液晶ディスプレイである。液晶ディスプレイは、例えばＩＰＳ（ＩｎＰｌａｎｅＳｗｉｔｃｈｉｎｇ）式である。表示部１２０は、有機ＥＬ（ＥｌｅｃｔｒｏＬｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ又はその他の方式の表示装置でもよい。

音声出力部１３０は、音声を出力する。音声出力部１３０は、例えば音声処理回路及びスピーカを有する。

レーダー受信部１４０は、レーダー方式に対応した速度測定装置から、取締波としてのレーダー波を受信する。レーダー波は、例えば、所定のマイクロ波、所定のステルス取締器が計測する瞬間だけ電波を発射するステルス波、通常レーダー波、Ｋバンド及びＸバンドに対応する新型レーダー波、及びキャンセル告知がある。レーダー受信部１４０は、例えばアンテナ及び受信回路を有する。

無線受信部１４２は、所定の周波数の無線信号を受信する。この所定の周波数の無線信号は、速度取締地点の周辺を伝搬することがあるもので、速度取締地点の存在を示す取締波の一例である。この所定の周波数の無線信号は、例えば、取締無線、カーロケ無線、デジタル無線、特小無線、署活系無線、警察電話、警察活動無線、レッカー無線、ヘリテレ無線、消防ヘリテレ無線、消防無線、救急無線、高速道路無線、警察無線等の周波数に属する無線信号がある。無線受信部１６は、例えばアンテナ及び受信回路を有する。

位置情報取得部１４４は、電子機器１０の位置（より具体的には、現在位置）を示す位置情報を取得する。電子機器１０の位置は、電子機器１０が配置された車両５０の位置、及び車両５０に乗車している運転手その他の人（乗員）の位置と同視することができる。位置情報取得部１４４は、例えば、ＧＮＳＳ（ＧｌｏｂａｌＮａｖｉｇａｔｉｏｎＳａｔｅｌｌｉｔｅＳｙｓｔｅｍ：全球測位衛星システム）の一つであるＧＰＳ（ＧｌｏｂａｌＰｏｓｉｓｉｏｎｉｎｇＳｙｓｔｅｍ）からの信号に基づき、電子機器１０の位置情報（緯度情報、及び経度情報）を取得する。位置情報取得部１７は、ＱＺＳＳ（Ｑｕａｓｉ－ＺｅｎｉｔｈＳａｔｅｌｌｉｔｅＳｙｓｔｅｍ：準天頂衛星システム）として、みちびきを併せて利用してもよい。位置情報取得部１４４は、４Ｇ、５Ｇ通信その他の基地局装置からの信号に基づいて、位置情報を取得してもよい。

通信部１４６は、外部装置と通信する。通信部１４６は、例えば、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）その他の無線ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）通信や近距離無線通信により、外部装置と無線通信する。外部装置は、例えば、スマートフォンやタブレット型コンピュータその他の車両５０内の通信端末である。通信部１４６は、例えば、ＬＴＥ（ＬｏｎｇＴｅｒｍＥｖｏｌｕｔｉｏｎ）、４Ｇ、５Ｇ等の移動通信システムの規格等に準拠した通信を行うための通信回路を有してもよい。

入力部１５０は、ユーザからの情報の入力を受け付ける。入力部１５０は、タッチセンサ１５２と、マイクロホン１５４と、を有する。タッチセンサ１５２は、ユーザの操作の入力を受け付ける。タッチセンサ１５２は、ユーザによりタッチされた位置を検出する。タッチセンサ１５２は、例えば静電容量方式である。マイクロホン１５４は、入射した音を電気信号に変換する。マイクロホン１５４は、例えばコンデンサマイクである。入力部１５０は、これ以外にも、音量調整ボタン、及び作業用ボタン等の物理ボタンを備えてもよい。

センサ部１５５は、各種のセンサを有する。センサ部１５５は、例えば、加速度センサ、ジャイロセンサ、気圧センサ、温度センサ、湿度センサ、及び照度センサの少なくともいずれかを有する。加速度センサは、例えば車両の前後、左右、上下の加速度を検出する３軸の加速度センサである。ジャイロセンサは、電子機器１０の傾きを検出するセンサである。加速度センサ及びジャイロセンサは、例えば、ＧＮＳＳ衛星からの信号が受信できない場合に、自律航法により車両５０の位置を推測するのに使用されてもよい。気圧センサは、気圧を測定する。気圧センサは、例えば、高低差を検知して、高速道と一般道を判定するために用いられる。温度センサは、温度を検知する。湿度センサは、湿度を検知する。照度センサは、照度センサ窓１２０１を介して入射した光に基づいて、電子機器１０の周辺である車室内の明るさを示す照度を検知するセンサである。照度センサは、例えば表示部１２０の表示の輝度の調整に使用される。

装着部１６０は、記録媒体挿入口から挿入された記憶媒体１６２を保持する媒体保持部として機能する。装着部１６０は、記憶媒体１６２にデータを書き込んだり、記憶媒体１６２からデータを読み出したりする。装着部１６０は、記憶媒体１６２を１つだけ保持するものでもよいが、２つ以上の記憶媒体１６２を同時に保持することが可能に構成されてもよい。

電源制御部１７０は、電子機器１０の各部への電力の供給を制御する。電源制御部１７０は、例えば、電源スイッチ１２２１や電源制御回路を有する。電源制御部１７０は、端子部１７２を介して車両５０側から供給された電力を、電子機器１０の各部に供給する。電源制御部２２は、さらに、蓄電手段として、二次電池やボタン電池、電気二重層コンデンサ（スーパーキャパシタとも呼ばれる。）を有してもよい。

端子部１７２は、外部の装置と電気的に接続するための端子である。端子部１７２は、外部の装置から電力の供給を受けるための端子である。端子部１７２は、例えばｍｉｎｉＵＳＢの規格に準拠した端子を有する。端子部１７２は、電源用のコード（例えば、シガープラグコード）の一端側のコネクタが接続される。電源用コードの他端側のコネクタは、例えば車両５０側に設けられた給電用の端子（例えば、シガーソケット）に接続される。

端子部１７２は、車両５０のＯＢＤII（「II」は「２」のローマ数字である。）コネクタに接続可能なＯＢＤIIアダプタが接続されてもよい。ＯＢＤIIコネクタは、故障診断コネクタとも称され、車両のＥＣＵ（ＥｎｇｉｎｅＣｏｎｔｒｏｌＵｎｉｔ）に接続され、所定の期間毎（例えば、０．５秒毎）に各種の車両情報が出力される端子である。端子部１７２が、ＯＢＤIIアダプタを用いてＯＢＤIIコネクタと接続されることで、電子機器１０は、動作用の電力の供給を受けるとともに、車両情報を取得することができる。

車両情報は、車両５０の状態に関する情報である。車両情報は、例えば、車両５０の速度（車速）、エンジン回転数、エンジン負荷率、スロットル度、点火時期、残り燃料の割合、インテークマニホールドの圧力、吸入空気量（ＭＡＦ）、インジェクション開時間、エンジン冷却水の温度（冷却水温度）、エンジンに吸気される空気の温度（吸気温度）、車外の気温（外気温度）、燃料タンクの残り燃料の量（残燃料量）、燃料流量、瞬間燃費、アクセル開度、ウインカー情報（左右のウインカーの動作（ＯＮ／ＯＦＦ））、ブレーキ開度、ハンドルの回転操舵角、ギヤポジション、及びドア開閉状態の情報等の少なくとも１つ以上とするとよい。

端子部１７２に接続される装置として、車両５０側からの給電がなくても、電子機器１０が動作できるように、外付けのバッテリが用いられてもよい。端子部１７２に接続される装置は、例えば、ユーザの安全運転を支援する機能を有する装置であってもよい。このような装置として、例えば、運転手（例えば顔）を撮影して、わき見及び居眠り運転に例示される運転手の状態を検出して報知する機能を有する装置や、車両５０の周辺の障害物を検知して報知する機能を有する装置（例えば、前方車両追突警報システム（ＦＣＷＳ：ＦｏｒｗａｒｄｖｅｈｉｃｌｅＣｏｌｌｉｓｉｏｎＷａｒｎｉｎｇＳｙｓｔｅｍｓ）のための車両検知に使用される装置）がある。端子部１７２に接続される装置は、その他にも、ドライブレコーダに例示される撮影装置、カーナビゲーション装置、ディスプレイ装置等の車載装置としてもよい。

発光部１８０は、所定の色で発光する。発光部１８０は、例えば発光ダイオードを含む。

記憶部１９０は、データを記憶する。記憶部１９０は、例えば、制御部１００が各種の制御を行うためのプログラムを記憶する。制御部１００は、記憶部１９０からプログラムを読み出して実行する。記憶部１９０は、さらに、地図を示す地図データ、目標物の種類やその位置情報、目標物の存在を報知するためのデータ（例えば、効果音やＢＧＭ、音声メッセージ等の音声データ、写真や模式図等の画像データ、等）、電子機器１０がナビゲーション機能を有する場合のルート案内機能を実現するためのデータ、待受画面を表示するためのデータ等を記憶する。目標物は、例えば、速度測定装置（レーザー方式、レーダー方式、ループコイル式、Ｈシステム、ＬＨシステム、光電管式、移動式等）のほか、居眠り運転事故地点、制限速度切替りポイント、取締エリア、検問エリア、駐禁監視エリア、Ｎシステム、交通監視システム、交差点監視ポイント、信号無視抑止システム、警察署、事故多発エリア、車上狙い多発エリア、急／連続カーブ（高速道）、分岐／合流ポイント（高速道）、ＥＴＣレーン事前案内（高速道）、サービスエリア（高速道）、パーキングエリア（高速道）、ハイウェイオアシス（高速道）、スマートインターチェンジ（高速道）、ＰＡ／ＳＡ内ガソリンスタンド（高速道）、トンネル（高速道）、ハイウェイラジオ受信エリア（高速道）、県境告知、道の駅、ビューポイントパーキング等がある。

記憶部１９０には、電子機器１０の製品出荷時に、目標物（例えば、経度・緯度を含む位置情報、目標物の種別情報等）に関する情報が登録されている。制御部１００は、その後に追加される新規な目標物に関する情報を、装着された記憶媒体１６２から取得し、又は通信部１４６を用いて通信により取得し、取得した情報を、記憶部１９０に記憶させる。このように、制御部１００は、新規な目標物に関する情報等についての更新情報を、記憶部１９０に記憶させる機能を有すると尚良い。

なお、記憶部１９０は、例えば、フラッシュメモリ（例えばｅＭＭＣ、ＳＳＤ）に例示される各種の記憶媒体を用いて実現された補助記憶装置とするとよい。記憶部１９０は、光学式記憶媒体、磁気記憶媒体、及び半導体記憶媒体に例示される各種の記憶媒体を用いて実現されてもよい。

［１．２．１．２電子機器の報知機能］
電子機器１０の報知機能は、受光部１１０、レーダー受信部１４０、無線受信部１４２、及び位置情報取得部１４４等を用いて、ユーザに情報を報知する機能である。報知機能は、ＰＯＩ（Ｐｏｉｎｔｏｆｉｎｔｅｒｅｓｔ）と呼ばれる目標物に関する情報を報知する機能である。報知機能は、例えば、以下で説明する機能を有する。報知機能による報知は、表示部１２０への表示、音声出力部１３０による音声の出力、発光部１８０の所定の発光、及びその他の人が知覚可能な方法のいずれかを用いて行われる。

制御部１００は、レーザー警報機能を有する。具体的には、制御部１００は、受光部１１０を用いて、レーザー方式に対応する速度測定装置から、速度測定用のレーザー光を受光したと判定した場合に、警報を発する警報制御を行う。レーザー方式に対応するレーザー光は、特定波長の光で、所定のパルス幅を有するパルスレーザーである。特定波長は、例えば赤外光領域に属し、その波長は例えば８５０ｎｍ、９０５ｎｍ、９５０ｎｍ、又は１９００ｎｍである。パルス幅は、例えば略２０ｎｓ又は略１５ｎｓである。パルス間隔は、例えば、略８０ｍｓである。「略」は、基準となる値と同一又はその値と実質的に同一とみなせる所定範囲内とするとよい。制御部１００は、例えば、レーザー方式に対応するレーザー光が受信されたと判定した場合には、記憶部１９０に記憶されたレーザー方式に対応する速度測定装置の模式図又は写真を表示部１２０に表示させるとともに、記憶部１９０に記憶された音声データを読み出して「レーザー光を受信しました。スピード注意」という音声メッセージを、音声出力部１３０から出力する。

制御部１００は、レーダー警報機能を有する。具体的には、制御部１００は、レーダー受信部１４０によって速度測定装置からのレーダー波を受信したと判定した場合に、警報を発する警報制御を行う。制御部１００は、例えば、速度測定用のレーダー波が受信されたと判定した場合には、記憶部１９０に記憶されたレーダー方式に対応する速度測定装置の模式図又は写真を表示部１２０に表示させるとともに、記憶部１９０に記憶された音声データを読み出して「レーダーです。スピード注意」という音声メッセージを、音声出力部１３０から出力する。

制御部１００は、無線警報機能を有する。具体的には、制御部１００は、無線受信部１４２によって所定の周波数の無線信号を受信したと判定した場合に、警報を発する警報制御を行う。制御部１００は、上述した各種無線信号に対応する周波数をスキャンする。制御部１００は、スキャンした周波数で、無線信号を受信したと判定した場合には、記憶部１９０に無線種別ごとに記憶されたその周波数に対応する無線を受信した旨の模式図又は写真を表示部１２０に表示させるとともに、記憶部１９０に無線種別ごとに記憶された音声データを読み出して、音声出力部１３０からその無線の種別を示す音声を出力する。制御部１００は、例えば、取締無線を受信した場合には、「取締無線です。スピード注意」のような音声メッセージを出力する。

制御部１００は、位置警報機能（一般的には、ＧＰＳ警報と呼ばれる。）を有する。具体的には、制御部１００は、記憶部１９０に記憶された目標物の位置情報と、位置情報取得部１４４が取得した位置情報とに基づいて、警報を発する警報制御を行う。制御部１００は、例えば、目標物の位置情報と電子機器１０の位置情報との距離を算出し、算出した距離が所定の接近距離になった場合に、警報制御を行う。制御部１００は、例えば、高速道路の走行中は、目標物まで２ｋｍに接近した場合に警報制御を行い、そのほか、目標物まで１ｋｍ、５００ｍ、直前、通過と判定した場合に、警報制御を行う。制御部１００は、例えば、トンネル内の速度取締地点については、高速道路の走行中は目標物まで２ｋｍに接近した場合に警報制御を行い、そのほか、目標物まで１ｋｍ、５００ｍと判定した場合に警報制御を行う。制御部１００は、表示部１２０に警報画面を表示し、音声出力部１３０から効果音、ＢＧＭ、音声メッセージ等の音声を出力する。

位置警報機能で警報制御の対象とする目標物としては、速度取締地点のほか、例えば、ネズミ捕りエリア、移動オービスエリア、追尾式取締りエリア、一時停止取締エリア、交差点取締エリア、その他取締エリア、シートベルト検問エリア、飲酒検問エリア、携帯電話検問エリア、その他検問エリア、交差点監視ポイント、信号無視抑制システム、高速道交通警察隊、Ｎシステム、交通監視システム、警察署、事故多発エリア、サービスエリア、パーキングエリア、ハイウェイオアシス、高速道長／連続トンネル、ハイウェイラジオ受信エリア、道の駅、ビューポイントパーキング、駐車場、公衆トイレ等がある。

なお、制御部１００は、上述した複数の報知機能のうち、ユーザにより設定された報知機能のみを動作させてもよい。また、複数の報知機能のそれぞれに又は報知の対象物となる目標物のそれぞれに、電子機器１０の設計段階又はユーザの設定により、優先度が設定されていてもよい。この場合、制御部１００は、優先度の高い報知を優先的に発するようにし、例えば、優先度が低い報知よりも優先度が高い報知を目立たせたり、優先度が低い報知と優先度が高い報知とが競合した場合は、優先度が高い報知のみを行ったりしてもよい。

なお、電子機器１０は、取締波を受信する機能と、取締波を受信したことに応じて報知する報知機能とを有する電子機器であるが、これらの機能を互いに別の電子機器に搭載してもよい。この態様の一例である図７（Ａ）に示す構成では、第１の電子機器１０３００は、取締波を受信する機能と、その受信結果に応じた信号を外部に出力する機能と、を有する。第１の電子機器１０３００は、アンテナ部とも呼ばれる。第２の電子機器１０１００Ａは、第１の電子機器１０３００から出力された信号を取得し、この信号に基づいて、第１の電子機器１０３００で取締波が受信されたことに応じて報知する報知機能を有する。第１の電子機器１０３００と第２の電子機器１０１００Ａとは、例えば有線の通信路（例えば、図７（Ａ）に示すケーブル１０４００）により接続されるが、無線の通信路により接続されてもよい。報知は、例えば、表示、音、及び光の少なくともいずれかによる報知を含まなくてもよい。この態様の一例である図７（Ｂ）に示す構成では、電子機器１０１００Ｂは、表示部を有しない。電子機器１０１００Ｂは、正面側に設けられた放音孔１０５００から音声を出力したり、発光部１０６００を発光させたりして、報知を行う。また、電子機器は、ダッシュボード上とは異なる設置位置として、例えば車両のフロントガラス（例えば、フロントガラスにおける上端付近）、又は車両のルームミラーや車室内の天井等を設置位置とする電子機器としてもよい。この態様の一例である図７（Ｃ）に示す構成では、電子機器１０１００Ｂが、固定部１０２００に代えて、取付部材１０７００を用いてフロントガラスに固定される。取付部材１０７００は、例えば金属製の板状部材を用いて形成されている。また、電子機器は、複数の設置位置の候補の中からユーザが選択したいずれかの設置位置に固定できるように構成されていてもよい。

［１．２．１．３電子機器の制御部・記憶部］
電子機器１０の制御部１００と、記憶部１９０との構成について、図８を参照して説明する。図８は、図６で説明した構成のうち、異なる部分だけを説明する図である。

制御部１００は、更にメッセージ生成部１０４、メッセージ投稿部１０５、メッセージ取得部１０６、メッセージ出力部１０７又はタイミング判定部１０８として機能する。具体的には、制御部１００は、記憶部１９０に記憶されているプログラムを読み出して実行することにより、各機能を実現する。

メッセージ生成部１０４は、サービスに投稿するメッセージを生成する。メッセージを生成する処理については、後述する。そして、生成したメッセージを含む投稿メッセージ情報を生成する。

投稿メッセージ情報には、メッセージの他に、投稿するメッセージに関する情報や属性を含めることができる。例えば、投稿メッセージ情報に含まれる他の情報・属性としては、返信先（リプライ先）となる他のメッセージＩＤを含めることができる。また、投稿メッセージには、位置情報（緯度経度情報や、ランドマーク等の場所情報等）、コンテンツに関する情報（例えば、アップロードされているコンテンツのＩＤ、コンテンツのＵＲＬ）を含めることができる。

メッセージ投稿部１０５は、メッセージ生成部１０４において生成されたメッセージをサービスに投稿する。メッセージ投稿部１０５は、単にメッセージをサービス（サービス内のサーバ装置）に送信してもよいし、投稿メッセージ情報をサービスに送信してもよい。以下、「メッセージを送信する」という場合、単にメッセージをサービスに送信する場合だけでなく、必要に応じてメッセージ情報を送信することを含む。メッセージを投稿することは、メッセージングサービスに対してメッセージが投稿されるように、当該メッセージ情報を出力する処理をいう。メッセージ情報の出力先としては、例えば、メッセージングサービスを提供する装置としたり、メッセージングサービスを提供する装置と電子機器との間に介在する他の装置（例えば、管理装置等の中継装置）としたりするとよい。

メッセージ取得部１０６は、サービス（サービス内のサーバ装置）からメッセージを取得する。具体的には、メッセージ取得部１０６は、例えば取得するメッセージ件数を指定することで、指定した件数分のメッセージをサービスから取得する。なお、サービスからはメッセージ毎に、メッセージと、メッセージ関する情報や属性を含む情報（取得メッセージ情報）を取得する。

取得メッセージ情報には、１又は複数のメッセージが含まれている。また、メッセージ毎に、メッセージに関する情報や属性が含まれていてもよい。メッセージに関する情報や属性は、例えばメッセージを特定するＩＤ（メッセージＩＤ）と、メッセージを投稿したユーザのアカウントＩＤと、メッセージを投稿したユーザのアカウント名、メッセージを投稿した投稿日時、投稿場所等の情報が含まれてもよい。また、メッセージ情報には、返信先（リプライ先）となるメッセージＩＤを含んでもよい。

なお、メッセージ取得部１０６は、条件に応じたメッセージを取得可能である。例えば、メッセージ取得部１０６は、指定されたキーワードに基づくメッセージを取得してもよい。キーワードは、メッセージに含まれる任意の文字や、タグ等であってもよい。また、メッセージに関する属性として、例えば取得したメッセージが返信された回数、再投稿された回数、評価された回数等を含んでもよい。

ここで、メッセージ取得部１０６が、必要に応じた取得先から取得メッセージ情報（メッセージ）を取得することができる。例えば、メッセージ取得部１０６は、サービスから直接必要なメッセージを取得してもよい。また、メッセージ取得部１０６は、一度メッセージ情報記憶領域１９６に記憶した取得メッセージ情報から、必要なメッセージを取得してもよい。

例えば、メッセージ取得部１０６は、サービスから取得する取得メッセージ情報の数（件数）を指定し、メッセージ情報を取得する。このとき、サービスに対して必要なキーワードを指定することができる。例えば、メッセージ取得部１０６は、「事故」というキーワードを指定することで、メッセージに「事故」が含まれるメッセージを取得することができる。また、メッセージ取得部１０６は、「＃事故」というタグを指定することで、「＃事故」というタグが含まれているメッセージをサービスから取得することができる。

また、メッセージ取得部１０６は、単に件数だけ指定した場合、取得可能なメッセージを件数分だけ取得する。そして、メッセージ取得部１０６は、メッセージ情報記憶領域１９６に、取得したメッセージ（取得メッセージ情報）を記憶する。なお、メッセージ情報記憶領域１９６は、取得メッセージ情報を一時的に記憶してもよいし、所定の期間分だけ記憶してもよいし、総て記憶してもよい。

そして、メッセージ取得部１０６は、メッセージ情報記憶領域１９６に記憶している取得メッセージ情報から所定のキーワード（例えば、「事故」）が含まれるメッセージを取得してもよい。

このように、メッセージ取得部１０６がメッセージを取得するという場合は、サービスから直接取得する場合と、メッセージ情報記憶領域１９６に記憶されているメッセージからメッセージを取得する場合とを含むものとし、適宜必要に応じて選択することができる。

なお、この２つの取得先を組み合わせてもよい。例えば、前日以前のメッセージはメッセージ情報記憶領域１９６から取得し、当日のメッセージはサービスから取得してもよい。また、メッセージ取得部１０６は、通信環境の都合等から、サービスからメッセージを取得できない場合は、メッセージ情報記憶領域１９６からメッセージを取得するとしてもよい。

メッセージ出力部１０７は、取得したメッセージを出力する。例えば、取得メッセージ情報に含まれているメッセージと、当該メッセージに関連する情報・属性を表示したり、音声出力したりすることができる。

また、メッセージ出力部１０７は、各メッセージを１つずつ表示してもよいし、時系列にあわらしたタイムラインを表示してもよい。

タイミング判定部１０８は、メッセージをサービスに投稿するタイミングや、メッセージをサービスから取得するタイミングを判定する。例えば、タイミング判定部１０８は、車両の状態に基づいて、メッセージを投稿するタイミングであると判定した場合に、メッセージ生成部１０４にメッセージの生成を促す。また、メッセージ生成部１０４によりメッセージが生成されている場合、ユーザからメッセージが入力されている場合は、メッセージ投稿部１０５にメッセージの投稿を促す。

また、タイミング判定部１０８は、サービスからメッセージを投稿するタイミングや、取得するタイミングを判定する。例えば、メッセージを投稿するタイミングと判定した場合、メッセージ生成部１０４にメッセージを生成することを促す。また、タイミング判定部１０８は、サービスからメッセージを取得するタイミングと判定した場合、メッセージ取得部１０６にサービスからメッセージを取得することを促す。

ここで、タイミング判定部１０８がメッセージを投稿するタイミングと判定するのは、何らかのメッセージを投稿するトリガを検出した場合である。例えば、タイミング判定部１０８は、車両５０の状態が変化したタイミングにトリガを検出したりや、ユーザからの操作入力をトリガとして検出したりしてもよい。また、他の装置（例えばドライブレコーダ等）からトリガを受信してもよい。また、タイミング判定部１０８は、車両５０の状態の変化としては、例えば渋滞になった場合、事故があった場合、あおり運転を受けた場合、取締用レーダーを受信した場合、カーロケ無線を受信した場合等何れかの変化があった場合である。

メッセージ生成部１０４、メッセージ投稿部１０５、メッセージ取得部１０６、メッセージ出力部１０７及びタイミング判定部１０８の更に詳細な処理や、動作については、以下の実施例で詳細に説明する。

記憶部１９０は、アカウント情報記憶領域１９２と、車両情報記憶領域１９４と、メッセージ情報記憶領域１９６と、設定情報記憶領域１９８との領域を確保している。

アカウント情報記憶領域１９２は、ユーザのアカウントに関する情報である。例えば、ユーザのアカウントに関するＩＤ（アカウントＩＤ）、パスワードを記憶する。また、ユーザのアカウントに関する情報として、例えば、認証情報や、アクセストークンを併せて記憶してもよい。

車両情報記憶領域１９４は、電子機器１０が取得した車両５０に関する情報を記憶する。車両情報として記憶されるタイミングは、所定時間毎（例えば、５分毎、１０分毎、１時間毎、１日１回）に記憶される。

メッセージ情報記憶領域１９６は、メッセージ関する情報が記憶される。例えば、メッセージ生成部１０４が生成されたメッセージ（投稿メッセージ情報）や、メッセージ取得部１０６がサービスから取得したメッセージ（取得メッセージ情報）を記憶する。

［１．２．２他の装置］
サービス提供装置３０は、メッセージングサービスを提供する装置であり、例えば、制御部、通信部、記憶部を有している装置である。サービス提供装置３０は、例えばメッセージングサービスを提供する事業者が有している装置である。例えば、ＳＮＳとしてのＴｗｉｔｔｅｒ（登録商標）や、Ｆａｃｅｂｏｏｋ、Ｉｎｓｔａｇｒａｍ、新浪微博、ＴｉｋＴｏｋ等のサービスを提供する事業者が有している装置であってもよいし、ネットワークを介して接続可能なメッセージングサービスを提供する機能を有している装置であってもよい。以下、メッセージングサービスや、ソーシャルネットワーキングサービスを含めて、単にサービスと言う。

携帯端末装置４０は、ユーザが有している情報処理が可能な装置であり、例えば、制御部、通信部、記憶部、表示部等を有している。携帯端末装置４０は、具体的には、スマートフォン、タブレット等の装置である。なお、端末装置であればよいため、例えば車両に備えてあるカーナビゲーション等の装置であってもよい。

電子機器１０は、携帯端末装置４０の通信機能（例えば、テザリング機能）を利用することで、管理装置２０や、サービス提供装置３０と通信を行ってもよい。

［１．３処理の流れ］
続いて、本実施形態における処理の流れについて説明する。

システム１の全体の流れについて説明する。図９は、本実施形態における処理の流れを説明する図である。

まず、制御部１００は、メッセージを投稿するタイミングが否かを判定する（ステップＳ１０２）。ここで、メッセージを投稿するタイミングか否かの判定は、サービスにメッセージを投稿するタイミングであるか、メッセージを投稿する時期かを判定する。これらはタイミング判定部１０８が判定してもよい。

そして、制御部１００は、メッセージを投稿すると判定した場合（ステップＳ１０２；Ｙｅｓ）、メッセージ生成処理を実行する（ステップＳ１０４）。メッセージ生成処理は、例えば、メッセージ生成部１０４が、投稿するメッセージ、投稿メッセージ情報を生成する。生成されたメッセージ（投稿メッセージ情報）は、一時的にメッセージ情報記憶領域１９６に記憶されてもよい。

つづいて、制御部１００は、メッセージ投稿処理を実行する（ステップＳ１０６）。例えば、メッセージ投稿部１０５が、メッセージ生成部１０４が作成したメッセージ（投稿メッセージ情報）をサービスに投稿する。

また、制御部１００は、メッセージをシステムから取得するタイミングであるかを判定する（ステップＳ１１０）。制御部１００は、メッセージを取得するタイミングの場合（ステップＳ１１０；Ｙｅｓ）、メッセージ取得処理を実行する（ステップＳ１１２）。例えば、メッセージ取得部１０６が、サービスから取得メッセージ情報を取得する。そして、制御部１００は、メッセージ出力処理を実行する（ステップＳ１１４）。例えば、メッセージ出力部１０７が、取得メッセージ情報に含まれている１又は複数のメッセージを表示部１２０に表示したり、音声出力部１３０から音声を出力する処理を実行する。

このように、本実施形態の処理を実行することで、電子機器１０からサービスにメッセージを投稿することができる。また、電子機器１０は、サービスからメッセージを取得し、出力することができる。すなわち、サービスを介して、ユーザ間での情報の共有を容易に行うことができる。

［１．４実施例］
このシステムを用いて実現できる実施例について以下説明する。なお、以下の実施例は、本実施形態の実施態様をそれぞれ説明するものである。実施例は、説明の都合上分けて説明しているが、複数の実施例を組み合わせてもよい。

［１．４．１車両の状態に応じてメッセージを投稿する実施例］
本実施例は、電子機器１０が車両の状態からメッセージを投稿するトリガを判定し、サービスにメッセージを投稿する実施例である。ユーザは、車両の状態を、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。他のユーザと共有することの効果として、例えば、安全な運転を支援するユーザ側のメリットや、ＳＮＳ利用者の多い若年層へのアピールや購買欲の向上への期待といった、車載用装置の販売事業者の認知度向上や販売促進といった販売事業者側のメリットを期待することができる。車両の状態とは、車両自体の状態とするとよいが、車両の周辺の状態としてもよい。

車両の状態としては、例えば、交通上の所定の事象に接した状態とするとよく、特に、車両の進行が妨げられる原因となり得る事象とするとよい。このような事象としては、車両の周辺で渋滞していること、事故が起こったこと、工事が行われていること、速度取締が行われていること、悪天候であること、火災、土砂崩れ、冠水その他の災害が発生したこと、及び通行止めその他の交通規制が行われていること、の少なくともいずれかとするとよい。車両の周辺で渋滞していることのように、事象に接したことで車両の進行が妨げられていることは、車両の車両速度に基づいて特定するとよく、位置情報取得部（詳しくは、後述する）が取得した位置情報の変化に基づいて車両速度を特定してもよいが、車両から車速の情報を取得して車両速度を特定するとよい。当該システムが車載用装置に実装されている場合のように車両から情報を取得できる場合は、ＯＢＤII（「II」は「２」のローマ数字である。）コネクタを介して車両速度を取得するとよい。

ここで、車両は特に原動機付きの二輪車又は四輪車とするとよいが、乗用車、トラック、バス等の道路を走行する車両としてもよい。車両の状態は、車両の備えるセンサ等から取得した情報に基づいて取得するとよいが、特に、車両にセンサを備えて取得した情報に基づいて判定するようにしてもよい。

センサとしては、例えば、加速度センサ、ジャイロセンサ、ＧＰＳモジュール等とするとよい。車両の状態を判定することは、センサから取得した情報と予め記憶しておいた情報とを比較して行うとよい。車両の状態がある状態にあるとみなすこととしては、所定の状態そのものにあることのみとしてもよいが、所定の状態に類似する状態にあることも含むと尚良い。車両の周辺の状態としては、例えば、後続車が異様に接近している状態（例えば、後続車があおり運転をしている状態）、他車の危険運転に遭遇した状態、又は逆走の車両がある状態等とするとよい。

以下説明する第１実施例は、車両の状態の一例として車両の進行が妨げられる原因となり得る事象として「渋滞」を検知し、メッセージを投稿する場合について説明する。

本実施例では、制御部１００は、車両５０の状態が渋滞中である場合に、メッセージを投稿するタイミングであると判定する。ここで、車両５０の渋滞中のときにメッセージをサービスに投稿することで、ほぼリアルタイムで他のユーザに対して情報を共有することができる。

ここで、車両５０が渋滞の状態にあると制御部１００が判定する処理としては、例えば以下のようなものが考えられる。

（１）車両５０の速度
制御部１００は、現在の車両５０の速度が判定速度以下であり、判定速度以下で走行している時間が判定時間継続している場合に渋滞していると判定する。

判定速度、判定時間は予め又はユーザにより設定情報として設定情報記憶領域１９８に記憶している。例えば、判定速度として時速１０ｋｍ以下、判定時間を３分間とした場合、車両が時速１０ｋｍ以下の状態が３分以上継続した場合、制御部１００は渋滞していると判定する。

また、判定速度や判定時間は、道路の種類によって変えても良い。例えば、判定速度を一般道の場合は時速１０ｋｍ、高速道路の場合は時速４０ｋｍと記憶してもよい。

（２）車両５０の位置
制御部１００は、現在の車両５０の位置が所定時間同じ場所又は所定の範囲から動かない場合に渋滞していると判定する。例えば、制御部１００は、判定時間経過後であっても、一定範囲に車両５０が含まれている場合には、渋滞していると判定する。また、制御部１００は、車両５０が頻繁に停止している場合は渋滞していると判定してもよい。

（３）外部情報からの判定
例えば、電子機器１０が外の状況を撮影可能な画像データを取得可能な場合、制御部１００は、画像を解析することで渋滞していると判定してもよい。例えば、撮影している画像データは、映像データの変化が緩やかである場合や、所定時間変化がない場合には渋滞していると判定してもよい。また、前車のブレーキランプが点灯しつづけている場合には渋滞していると判定してもよい。

つづいて、メッセージ生成部１０４は、渋滞中であるためのメッセージを生成する。メッセージ生成部１０４は、他のドライバーに役立つようなメッセージを生成することにしてもよい。例えばメッセージ生成部１０４は、「ただいま渋滞中です」という単に渋滞中であることを示すメッセージを生成してもよい。また、メッセージ生成部１０４は、「あー渋滞だ。イライラする。」といった解りやすいメッセージを生成してもよい。このようなメッセージは、サービスを利用している者（ドライバー）に役立つようなメッセージ（記事）を作成して投稿することになる。

また、制御部１００は、ドライバーの感情や動作に応じて、メッセージに含めて送信してもよい。例えば、制御部１００は、車両５０の車両情報から、ブレーキを頻繁に踏んでいることを検出したときには「早く進まないかな」という感情を判定し、メッセージに含めてもよい。また、制御部１００は、車両５０の車両情報から、車線変更を頻繁にしている場合（例えば、ウィンカーの信号が多く検出されている場合）には、「渋滞を抜けたい！」という感情を判定し、メッセージに含めてもよい。

また、制御部１００は、ドライバーの感情や動作に応じて、対応する絵文字を含めてもよい。例えば、制御部１００は、順調に進んでいるときは「笑顔」の顔文字をメッセージに含めてもよい。また、制御部１００は、渋滞しているときは「泣き顔」の顔文字をメッセージに含めてもよい。

また、制御部１００は、渋滞の長さや、渋滞にはまっている時間に応じて絵文字を変化させてもよい。例えば、制御部１００は、渋滞が長いときは車の絵文字を多く含めてもよい。例えば、制御部１００は、渋滞にはまっている時間が５分経過毎に絵文字を１つずつ増やしてもよい。

時間経過とともに、メッセージが投稿されることで、他のユーザはリアルタイムで渋滞の状況を確認することができる。例えば、他のユーザの端末装置で表示されるタイムラインに、定期的に渋滞であることが表示されることで、渋滞中であることがリアルに伝わるだけでなく、どの程度の状態なのかを確認することができる。

また、電子機器１０のユーザが複数同様にメッセージを投稿することで、他のユーザは多くの人が渋滞にはまっていることも確認することができる。これにより、一般の渋滞情報と比較して、実際の車両５０の状態に基づくメッセージであることから、より渋滞が起きていることを把握しやすくなる。

このように、本実施例によれば、自車両の状態を、サービスへの投稿を通じて他のユーザと共有することができる。例えば、車両の状態（例えば、車両の速度から渋滞が発生している等）と共有することができる。

また、安全運転を支援するユーザ側のメリットや、ＳＮＳ利用者の多い若年層へのアピールや、購買欲の向上への期待といった、車載用装置（電子機器の一例）の販売事業者の認知度向上や、販売促進といった販売事業者側のメリットを期待することができる。

また、定期的にメッセージを投稿することにより、アカウントと関連のあるアカウント（例えば、フォロワー、友達）の数を増やすことで、タイムラインにメッセージが表示されるようにアカウントを育成する仕組みが大事であり、このような仕組みを提供することができる。

また、ユーザは、車両の状態として、車両がその車両の進行が妨げられる原因となり得る事象に接したことを示すメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。車両の進行が妨げられる原因となり得る事象については、上述したとおりである。車両が、車両の進行が妨げられる原因となり得る事象に接したと判定したときに投稿する機能を備えるとよい。このようにすると、メッセージングサービスで第三者は、リアルタイムで車両の進行が妨げられる原因となり得る事象に関する情報を受け取ることができる。また、その情報を実際に車両の状態に基づいて生成しているため、ユーザが手入力でメッセージ情報の全部を作成、投稿するのと比べて、簡単に作成、投稿することができる。また、その情報を実際に車両の状態に基づいて生成しているため、ユーザは、より正しい情報を第三者と共有することができる。車両の進行が妨げられる原因となり得る事象として、渋滞は、ユーザが接する機会が比較的多い事象で、その情報の共有をすることは特に価値があるものであるが、ユーザは、このような渋滞に関するメッセージを簡単に作成、投稿することができる。

また、ユーザは、更に、車両の進行が妨げられる原因となり得る事象に関する詳細な情報に基づいて生成したメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。例えば、その事象に関する詳細な情報は、例えば、その事象の発生している状況や、実際にその事象を回避するのにかかった時間等とするとよい。このようにすると、第三者は、単に車両の進行が妨げられる原因となり得る事象が発生していることを知るだけでなく、更に詳細な情報を認識することができる。事象が渋滞である場合は、渋滞に関する渋滞詳細情報に基づいてメッセージを生成するとよく、このようにすると、渋滞に関する詳細な情報を共有することができる。

また、ユーザは、事象詳細情報に基づいた絵文字をメッセージに含めた上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。ここでの絵文字は、メッセージングサービスにおいて利用可能な絵文字とするとよい。また、他の人のメッセージ（つぶやき）に含まれている絵文字を利用するとよい。絵文字を利用することで、感情や状態を表してもよい。また、ユーザが利用した絵文字がメッセージングサービスと、車両側の表示とで同じ絵文字が表示されるようにするとよい。このようにすると、見た目も同一の絵文字が表示されるので、ユーザと第三者とは、メッセージングサービスと、車両側の表示とで同じ絵文字を使用したメッセージを見ることができる。絵文字の外観が異なっていてもよいが、同じ内容を意味する絵文字を表示するとよい。例えば、「笑顔」の絵文字であれば、絵文字を示す文字コードが少なくとも同一とするとよい。事象が渋滞である場合は、第三者は、絵文字を通じて、渋滞の状況を直観的に把握することができる。

また、ユーザは、車両の進行が妨げられる原因となり得る事象の発生範囲の大きさ及び／又はその発生範囲の通過時間に応じて絵文字の数又は内容を変えたメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。例えば、その事象の発生範囲が大きい場合には、多くの絵文字を繰り返し表示するとよい。例えば、その発生範囲の通過時間がかかる場合は、絵文字は１個等とするとよい。例えば、絵文字の内容を変える場合は、その事象の発生範囲に応じてユーザの心境を表現した絵文字を変えるとよい。例えば、その事象の発生範囲が小さい場合は、「笑顔」や「無表情」といった心境を表現する顔文字とし大きい場合には、その事象の発生範囲が大きい場合は、「怒り」や「悲しみ」といった心境を表現する顔文字とするとよい。このようにすると、第三者は、絵文字を見れば車両の進行が妨げられる原因となり得る事象の発生の程度を、容易に判定することができる。事象が渋滞である場合は、渋滞の距離が２ｋｍ、５ｋｍ、８ｋｍ・・・という具合に所定距離増えるごとに、絵文字の数を増やしたり、内容を変えたりするとよい。このようにすると、第三者は、絵文字を見れば、発生している渋滞が長いのか、短いのかを容易に判定することができる。

また、ユーザは、画像を記憶する記憶部に記憶された画像に関する情報をメッセージに含めた上で、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。画像に関する情報は、画像ファイルの形式とするとよい。また、画像に関する情報は、画像ファイルを示すリンク情報（例えばＵＲＬ）としてもよい。このようにすると、第三者は、単なるテキストだけでメッセージを確認するだけでなく、併せて画像ファイルにより表現される画像を確認することができることから、より解りやすく情報を得ることができる。画像に関する情報は、例えば、車両の進行が妨げられる原因となり得る事象の発生の状況を把握するのに役立つ情報とするよい。このようにすると、ユーザは、その発生の状況を正確な内容で第三者と共有しやすくすることができる。画像に関する情報は、記憶部に記憶された画像自体としてもよいが、記憶部に記憶された画像から生成した情報としてもよい。画像から生成した情報としては、その画像の内容を説明する情報としてもよく、例えば、テキスト情報としてもよい。テキスト情報としては、例えば、画像認識して、認識した結果に基づき事象の発生状況を説明したテキスト情報を生成するとよい。

また、ユーザは、車両の運転を支援するための表示画面をキャプチャした画像に関する情報をメッセージに含めた上で、そのメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。車両の運転を支援するための表示画面を表示する装置としては、スマートフォンなどのユーザが携帯する情報処理端末としてもよいが、もっぱら車両の運転を支援するための機能を提供する車載用装置の表示画面とするとよい。車載用装置としては、例えば、撮影及び録画機能を提供するドライブレコーダ、ルート案内等のナビゲーション機能を提供するナビゲーション、及び速度取締地点と所定の接近関係を有することを報知する報知機能を有する探知機（例えば、レーダー探知機、レーザー探知機）等とするとよい。車両の運転を支援するための表示画面においては、地図を表示することも多い。そこで、例えば、車両の運転を支援するための表示画面として地図を含む表示画面をキャプチャして、その地図を含めた画像を含むメッセージを生成するとよい。位置（例えば住所や道路名称）を含む表示画面をキャプチャして、その位置を含めた画像を含むメッセージを生成するとよい。このようにすると、第三者は、メッセージに含まれた画像から、車両の進行が妨げられる原因となり得る事象が発生している付近の地図や、場所を画像からも確認することができるようになる。キャプチャの実行は、ユーザの手入力によって指示されるとよく、例えばワンタッチの操作できるようにするとよい。キャプチャはユーザの明示の指示なしに実行されてもよく、例えば、所定のイベントが発生した場合に実行されたり、定期的に実行されたりするとよい。投稿に用いられる画像は、ユーザが指示してもよいし、その指示無しに選択されてもよい。

また、車両の外を撮影した画像に関する情報をメッセージに含めた上で、そのメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。車両の外としては、車両の前方、後方、及び側方の少なくともいずれかの方向を含むとよいが、特に前方を含むとよい。第三者は、画像に車両の進行が妨げられる原因となり得る事象を撮影した様子が映っていれば、どの程度の状態が発生しているかを視覚的に確認することができる。事象が渋滞である場合は、車両の外として、特に車両の前方を撮影するとよい。このようにすると、第三者は、渋滞の車列等からどの程度の状態が発生しているかを視覚的に確認することができる。ここで撮影装置は、車載用装置に備えられてもよいが、車載用装置とは別の構成であってもよい。例えば、車載用装置に車両の前方を撮影するカメラを備えてもよい。また、車両に備えられているドライブレコーダの画像を利用してもよい。また、ユーザが所有するスマートフォンその他の情報処理装置に備えられたカメラを利用してもよい。

また、ユーザは、位置情報に基づいた地図をメッセージに含めた上で、そのメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。位置情報に基づいた地図は、その位置情報が示す位置の周辺の地図とするよく、例えば、位置を中心とした所定の距離の範囲の地図とするとよい。このようにすると、第三者は、地図を確認することで、具体的にどの位置で車両の進行が妨げられる原因となり得る事象が発生しているかを把握することができる。事象が渋滞である場合は、渋滞が発生している場所周辺の地図の画像が用いられるとよい。このようにすると、第三者は、場所と渋滞の発生状況との関係を理解しやすい。
続いて、以上のような思想に基づく実施例を説明する。

［１．４．２渋滞の詳細メッセージを投稿する実施例］
本実施例は、車両５０が渋滞の状態であるときに、渋滞の詳細をメッセージに含める実施例である。

例えば、第１実施例では、メッセージ生成部１０４は、渋滞をしていることを示すメッセージを生成する場合を説明した。本実施例では、更にメッセージに渋滞に関する詳細な情報（渋滞詳細情報）を示す内容を含める実施例である。

ここで、渋滞詳細情報とは、渋滞の範囲や、渋滞の原因を含めてもよい。例えば、渋滞の開始時刻や開始位置、渋滞を抜けた時刻や、渋滞を抜けた位置、渋滞にはまっていた時間（渋滞の範囲を車両５０が渋滞を通過した時間）、渋滞の長さ（距離）等の情報をメッセージに含めてもよい。

例えば、制御部１００は、上述した方法により車両５０の状態が渋滞していることを検出する。制御部１００は、渋滞の情報として、日時、車両５０の位置（緯度経度情報、ランドマーク情報、携帯電話の基地局情報等）、車両５０のある都道府県、市区町村、町名、車両５０の進行方向（道路の方向）、道路名等を１又は複数取得する。

そして、メッセージ生成部１０４は、取得されている渋滞詳細情報のうち、１又は複数の情報をメッセージに含めてもよい。このとき、メッセージに含める情報はユーザが選択してもよい。

また、渋滞の原因や、位置はタグとしてメッセージに含めてもよい。また、渋滞をしている道路名や、市区町村、ランドマーク名をメッセージに含めてもよい。また、道路名や市区町村、ランドマークをタグとして含めてもよい。

メッセージ生成部１０４が、渋滞詳細情報を作成する場合の動作について説明する。制御部１００は、車両５０の状態が渋滞をしている状態になった位置を第１の位置として取得する。そして、車両５０が渋滞の状態から抜けた位置を第２の位置として取得する。渋滞の状態になった位置とは車両５０が、上述した渋滞の状態となったと判定した開始位置である。また、車両５０が、上述した渋滞の状態から、渋滞ではなくなった状態に遷移したとき、制御部１００は、渋滞を抜けたとして判定する。

これにより、メッセージ生成部１０４は、第１の位置から第２の位置まで渋滞していたメッセージを作成することができる。このとき、メッセージ生成部１０４は、車両５０が渋滞を抜けるのにかかった時間や、渋滞の範囲を示す距離をメッセージに含めてもよい。また、メッセージ生成部１０４は、渋滞が生じている道路（道路名称）、道路の方向（道路において車両が進行する方向）、渋滞が生じてる付近にあるランドマーク名等を含めてもよい。

例えば、車両５０の状態が渋滞している状態になった第１の地点として「南池袋１丁目の交差点付近」、車両５０の状態が渋滞を抜けた状態になった第２の地点として「上池袋の交差点付近」と判定した場合、メッセージ生成部１０４は「南池袋１丁目から上池袋まで渋滞してた」とメッセージを生成してもよい。

また、制御部１００は、渋滞が抜けた後（第２の地点を経過した後）に、「上池袋の交差点付近まで渋滞していいた」とメッセージを生成してもよい。

また、メッセージ生成部１０４は、併せて渋滞が生じている道路名をメッセージに含めたり、タグとして含めたりしてもよい。例えば、渋滞を生じている道路名称が明治通りと取得できれば、「＃明治通り」というタグを上記メッセージに追記してもよい。

また、メッセージ生成部１０４は、渋滞の区間に含まれるランドマーク名を含めてメッセージを生成してもよい。例えば、上記区間の場合、渋滞の区間に池袋駅が含まれるため、メッセージ生成部１０４は、「池袋駅付近で渋滞してた」とメッセージを生成してもよい。

また、メッセージ生成部１０４は、上記渋滞の区間に対応する地図の画像をメッセージに含めてもよい。例えば、メッセージ生成部１０４は、地図の画像データに渋滞の範囲に対応する部分の道路の色を変えてもよい。また、メッセージ生成部１０４は、第１の地点、第２の地点にピンを表示してもよい。

また、メッセージ生成部１０４は、渋滞の原因をメッセージに含めてもよい。例えば、渋滞の第２の地点が工事を行っている場合、工事が原因で渋滞が起きている旨のメッセージを生成してもよい。この場合、第２の地点付近の画像をメッセージに含めてもよいし、ユーザから原因を選択させてもよい。また、制御部１００は、渋滞の原因としてＶＩＣＳ（登録商標）等の他の情報から取得してもよい。

このように、渋滞の詳細な情報を含めたメッセージがサービスに投稿することで、他のユーザとより詳細な情報の共有ができる。とくに、サービスにメッセージと投稿されることから、サービスにおいて関連づけられていないユーザにとっても、渋滞に関する情報を検索しやすくなる。例えば、Ｔｗｉｔｔｅｒのサービスの場合、フォローをしていないユーザであっても、キーワードやタグで検索していたり、リストに登録することで、リアルタイムの渋滞情報を共有することができる。また、渋滞の詳細な情報として、渋滞の長さ、渋滞に係る時間といった実際に車両で走行して得られた情報についても、容易に取得できる。

また、ユーザは、車両の進行が妨げられる原因となり得る事象が発生していることだけでなく、位置情報についても解るメッセージングサービスを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。位置情報は、車両が、車両の進行が妨げられる原因となり得る事象に接した位置を示すようにするとよい。この位置情報は、車両の進行が妨げられる原因となり得る事象が発生している位置またはその周辺を示す。このようにすると、ユーザは、その事象が発生している位置は、車両が現在いる位置であり、正確性の高いメッセージを第三者と共有することができる。また、第三者もメッセージをみたときに、車両の進行が妨げられる原因となり得る事象が発生していること、及びその事象が発生している位置を認識することができる。事象が渋滞である場合は、渋滞に関する内容と、位置情報に基づいた内容とを含めたメッセージを生成することとなる。

また、ユーザは、車両の進行が妨げられる原因となり得る事象の発生原因を含めたメッセージ、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。このようにすると、第三者は、その発生原因を認識することができる。車両の進行が妨げられる原因となり得る事象の発生原因として、例えば「事故」「工事」「土砂崩れ」「冠水」「火災」「災害」といったような発生原因を示す情報をメッセージに含めるとよい。このようにすると、第三者は、発生原因がいつもの理由なのか、普段にはない理由なのか、その事象が解消するのに時間がかかりそうかといったことを判断することができる。事象とその発生原因とが組になっていればよく、例えば、車両の進行が妨げられる原因となり得る事象が「渋滞」で、その発生原因が「事故」としたり、車両の進行が妨げられる原因となり得る事象が「事故」で、その発生原因が「車両同士の衝突」としたりしてもよい。事象が渋滞である場合は、渋滞に関する渋滞詳細情報に基づいてメッセージを生成するとよく、このようにすると、渋滞に関する詳細な情報を共有することができる。第三者は、渋滞の発生原因がいつもの理由なのか、普段にはない理由なのか、渋滞のが解消するのに時間がかかりそうかといったことを判断することができる。発生原因としては、「事故」「工事」「土砂崩れ」「冠水」「火災」「災害」、「車両同士の衝突」等があるが、原因が明らかでなければ、「原因不明」が用いられてもよい。

また、ユーザは、車両の進行が妨げられる原因となり得る事象の範囲を、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。渋滞の範囲は、例えば第１の地点から第２の地点まで発生しているといった範囲とするとよい。第１の地点は、例えば、事象の範囲の開始地点又はその周辺とするとよい。第２の地点は、事象の範囲の終了地点又はその周辺とするとよい。第三者は、その事象が普段も発生している場所かを確認したり、その事象の発生している距離を確認したりすることができる。このようにすると、例えば第三者はその事象が発生している範囲に含まれるルートを迂回するといった判断をすることができる。事象が渋滞である場合は、事象の発生範囲としては、車列の先頭から最後尾までの範囲や、渋滞を構成する車列の長さ等とするとよい。

また、ユーザは、車両の進行が妨げられる原因となり得る事象の発生範囲として、その事象に接したと最初に判定された第１の地点、及びその事象に接した状態を脱したと判定された第２の地点を、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。第三者はメッセージを確認して、その事象が発生している開始地点、及び終了地点に関する第１の地点、及び第２の地点がどこであるかや、その発生範囲がどの程度の長さかを認識することができる。また、このようにすると、例えば第三者は、その事象が発生している範囲を確認できることから、例えばその事象に接するのを回避するルートを選定しやすくなる。事象が渋滞である場合は、車両は、渋滞の発生地点と、どこで渋滞から脱したかを共有することができるので、第三者は、ユーザの渋滞の発生から脱するまでの実際の経験に基づいて情報を確認することができる。

また、ユーザは、車両の進行が妨げられる原因となり得る事象の発生範囲として、その範囲の距離や時間に関する情報を併せたメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。メッセージを確認した第三者は、その事象の発生範囲の長さから、そのまま走行するか、その発生範囲を避けたルートを走行するかを判断しやすくなる。事象が渋滞である場合は、渋滞の発生範囲と、その発生範囲に車両が進入した場合の通過時間を投稿するとよく、このようにすると、第三者は渋滞の発生範囲や通過時間を確認して、ルート選択や移動時間の推定等にこれを利用することができる。

また、ユーザは、車両が走行している道路において、車両の進行が妨げられる原因となり得る事象が発生しているときに、その道路名称を含むメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。メッセージに道路名称が含まれていることから、第三者はその事象が発生している道路がどこであるかを把握することができる。また、道路名称がメッセージに含まれることから、第三者は、いわゆるラジオ等のニュース番組で放送される交通情報に近い感覚で、その事象に関する情報を知ることができる。事象が渋滞である場合は、第三者は、どの道路名称の道路で渋滞が発生しているかを確認でき、車両で移動するときのルート選択や移動時間の推定等にこれを利用することができる。

また、ユーザは、車両が走行している道路名称だけでなく、車両の進行が妨げられる原因となり得る事象が生じている道路の方向を、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。道路の方向は、道路に対して決められた車両が進行すべき方向とするとよく、例えば、上り／下り、東行き／西行き、南行き／北行き、外回り／内回り等とするとよい。このようにすると、第三者は、道路名称だけでなく、道路の方向までメッセージで確認することができる。ユーザは、自分の進行方向により渋滞が影響あるか否かを判定しやすくなる。事象が渋滞である場合は、第三者は、車両の走行状態とともに、どの名称の道路で渋滞が発生しているか、渋滞が発生している道路の方向といったより詳細な情報を確認でき、車両で移動するときのルート選択や移動時間の推定等にこれを利用することができる。

また、ユーザは、メッセージに位置情報に基づいた地図が含まれ、かつその地図が車両の進行が妨げられる原因となり得る事象の詳細な情報に基づいて識別表示された状態で、メッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。第三者は、メッセージを確認したときに、例えばテキスト情報だけでなく、その事象の詳細な情報に基づいて識別表示された地図も併せて確認することができる。位置情報に基づいた地図は、その位置情報が示す位置の周辺の地図とするよく、例えば、位置を中心とした所定の距離の範囲の地図とするとよい。識別表示された状態としては、例えば、事象が発生している場所、事象の発生範囲を識別表示することとするとよい。このようにすると、第三者は、その事象の発生範囲や距離を視覚的に判断することができる事象が渋滞である場合は、第三者は、地図上に渋滞に関する詳細な情報を表現し、その第三者が渋滞に関する詳細な情報を把握しやすくなる。メッセージングサービスとして、例えば、Ｔｗｉｔｔｅｒ等とするとよい。Ｔｗｉｔｔｅｒにおいて、テキスト情報は、各ユーザが投稿するテキスト情報であり、ツイートとも呼ばれる。テキスト情報は、タグを含むとよく、そのタグとしてはハッシュタグとするとよい。地図は、Ｔｗｉｔｔｅｒの機能に搭載された画像ファイルを添付する機能を用いて投稿されるとよい。

また、ユーザは、事象詳細情報に基づいて生成されたタグをメッセージに含めた上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。タグは、例えば、事象詳細情報に含まれる項目を示すテキスト情報とするとよく、例えば、車両の進行が妨げられる原因となり得る事象が発生している位置、及び道路の名称等とするとよい。このようにすると、第三者は、メッセージングサービスにおいて、タグを選択することで、その詳細な情報を容易に検索することができる。メッセージングサービスとして、例えば、Ｔｗｉｔｔｅｒ等とするとよい。Ｔｗｉｔｔｅｒにおいて、タグを含むとよく、そのタグとしてはハッシュタグとするとよい。事象が渋滞である場合は、車両の周辺で発生した渋滞に関する情報をタグに含めて共有するので、タグを見た第三者は、より確実に渋滞に関する情報を受け取りやすくなる。

また、ユーザは、位置情報として、緯度経度情報や、市区町村の名称、ランドマーク名、及び交差点名といった、車両の進行が妨げられる原因となり得る事象が発生している位置を示す具体的な内容をメッセージに含めた上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。第三者は、その事象に関する渋滞を知りたい場合、緯度経度情報や、市区町村の名称、ランドマーク名、及び交差点名の少なくともいずれかを指定して検索することが考えられるため、所望するメッセージに容易にたどり着きやすくなる。

また、ユーザは、位置情報に基づいて生成されたタグをメッセージに含めた上で、そのメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。位置情報に基づいて生成されたタグとして、例えば市区町村名、道路名称、又はランドマーク名といったタグとするとよい。第三者はタグを利用することで、容易に所定の位置情報に関連するメッセージを検索することができる。例えば、同じ地域のメッセージを有する者とコミュニケーションが取りやすくなるといったことも考えられる。事象が渋滞である場合は、渋滞に関するタグを生成するとよい。このようにすると、第三者は、渋滞と位置情報とに関連するメッセージを検索することができる。

また、ユーザは、事象の種類と、事象が発生した時刻に関連する情報と、事象が発生した道路の道路名称と、事象が発生した住所との少なくともいずれかを含むメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。事象が発生した時刻に関連する情報としては、例えば、事象が発生した時刻だけに限らず、例えば事象が発生してから経過した時間を含めるとよい。また、事象が発生した道路名称としては、例えば、国道Ｘ号線のように、番号表記であってもよいし、○○通りといった通り名とするとよい。また、事象が発生した住所は、例えば、都道府県名、市区町村名とするとよいが、町名、番地までも含めてもよい。また、発生した住所に基づく情報として、例えば、施設名・ランドマーク名を含めるとよい。施設名・ランドマーク名としては、例えば、役所（市区町村の役所、警察署、消防署等）、駅、空港、ＰＡ／ＳＡ、公園、遊園地、ショッピングモール、ガソリンスタンド等の施設名を含めるとよい。

また、ユーザは、前記発生した事象の種類、当該事象が発生した時刻に関連する情報、当該事象が発生した道路の道路名称、当該事象が発生した住所をメッセージに含める場合に、タグとしてメッセージに含めた上で、そのメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。とくに、道路名称や住所は、タグを用いた検索に用いられやすいという知見に基づき、これをタグ化してメッセージに含めている。このようにすると、第三者は、メッセージングサービスにおいて扱われるタグを利用して、道路名称及び／又は住所と関連付けてメッセージを表示確認しやすくなる。

［１．４．３渋滞以外の車両の状態を投稿する実施例］
本実施例は、車両の状態として、例えば渋滞以外の状態、例えばあおり運転があった場合や、取締ポイントを通過した場合にメッセージを生成・投稿する実施例である。

例えば、制御部１００は、通信部１４６を経由して接続されたドライブレコーダにより撮影された画像を取得する。そして、制御部１００（タイミング判定部１０８）は、画像を解析することで、あおり運転があったことをトリガとして検出する。そして、メッセージ生成部１０４は、あおり運転があったことを示すメッセージを生成する。

また、制御部１００（タイミング判定部１０８）は、レーダー受信部１４０から取締用のレーダーを受信した場合、取締があったことをトリガとして検出してもよい。メッセージ生成部１０４は、取り締まりが行われていることを示すメッセージを生成する。

なお、それ以外にも、タイミング判定部１０８は、車両５０の状態に応じてトリガを検出してもよい。メッセージ生成部１０４は、トリガに応じたメッセージを生成する。例えば、メッセージ生成部１０４は、取締用無線を受信した場合、パトカーからのカーロケ無線を受信した場合等のとき、その旨を示すメッセージを生成してもよい。

また、制御部１００は、通信部１４６を経由して接続されたドライブレコーダにより撮影された画像を取得し、解析する。そして、画像を解析した結果、取締が行われていることが検出された場合は、その旨を示すメッセージを生成してもよい。

このように、本実施例によれば、渋滞以外の情報についてもサービス（メッセージングサービス）を介して他のユーザと容易に共有することができる。とくに、あおり運転のように「今発生している」状況について、サービスを利用することで、即時に情報を共有することができる。例えば、あおり運転をする自動車がいることが解れば、事前に運転するルートを変えたり、運転を止めること（例えば、施設で休憩をする）で、事前にトラブルを回避することもできる。

また、あおり運転があった場合に、併せてあおり運転をした車両を撮影した画像を含むメッセージを生成し、サービスに投稿してもよい。メッセージを閲覧した他のユーザは、当該車両が来たら避けることで、事前にトラブルを回避することができる。

また、例えば、当て逃げやひき逃げの被害にあった場合に、当該車両の画像を含むメッセージを生成し、サービスに投稿してもよい。サービスで当該画像が共有されることにより、画像に写っている車両を発見したり、他のユーザが通報を行うことで、トラブルを解消することができる。

このようにすれば、車両の外を撮影した画像に関する情報をメッセージに含めた上で、そのメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。車両の外としては、車両の前方、後方、及び側方の少なくともいずれかの方向を含むとよいが、特に前方を含むとよい。第三者は、画像に車両の進行が妨げられる原因となり得る事象を撮影した様子が映っていれば、どの程度の状態が発生しているかを視覚的に確認することができる。事象が渋滞である場合は、車両の外として、特に車両の前方を撮影するとよい。このようにすると、第三者は、渋滞の車列等からどの程度の状態が発生しているかを視覚的に確認することができる。ここで撮影装置は、電子機器に備えられてもよいが、電子機器とは別の構成であってもよい。例えば、電子機器に車両の前方を撮影するカメラを備えてもよい。また、車両に備えられているドライブレコーダの画像を利用してもよい。また、ユーザが所有するスマートフォンその他の情報処理装置に備えられたカメラを利用してもよい。

また、ユーザは、少なくともあおり運転、取り締まり、通行止め又は危険運転といった、発生した事象の種類を示すメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。発生した事象の種類は、発生した事象の種類をカテゴリーとするとよい。

［１．４．４車両の状態を複数組み合わせてメッセージを投稿する実施例］
本実施例は、メッセージ生成部１０４が、渋滞の状態と他の状態とを組み合わせてメッセージを生成する実施例である。

例えば、制御部１００は、ドライブレコーダの画像を解析したり、検出した加速度を解析することで、前方に他の車両が割り込んだと検出した場合は「割り込まれたームムムッ」といったメッセージを更に生成してもよい。また、メッセージ生成部１０４は、そのとき撮影した画像（割り込んだ車両が写っている画像）をメッセージに含めて投稿してもよい。例えば、イライラ運転によって、およそ４７％のドライバーがあおり運転のような行動を取ってしまった経験がある。そこで、あえて状況をメッセージとして投稿することにより、運転者の行動を自制することが可能である。

このように、上述した実施例で説明したように、電子機器１０からメッセージをサービスに適宜投稿することが可能である。交通事故、渋滞、通行止め、危険運転（煽り運転・逆走走行）、火災や水害など、交通情報に関わる事象や、レーダーやレーザー、白バイや覆面パトカーによる交通取締りなど、取締り情報に関わる事象を電子機器１０からサービスに投稿することができる。

なお、第２実施形態で記載しているように、電子機器１０と、サービス（サービス提供装置３０）との間に管理装置２０を含めてもよい。電子機器１０は、投稿のきっかけ（トリガ）を発生させるため、文字データ（投稿情報）と画像データとを管理装置２０に送信する。管理装置２０は、文字データと画像データとに基づく投稿メッセージ情報を生成し、サービスに投稿してもよい。

なお、このとき投稿するメッセージの内容は、サービスを提供する者が決めた範囲内で生成する。例えば、１４０文字以内という制約があれば、１４０字以内で生成する。また、メッセージ投稿部１０５は、サービスを提供する者の規約に合致するようにメッセージを投稿する。例えば、サービス提供者が、投稿の間隔は１０分空けること、同じ内容を投稿しないことと定めている場合、当該ルールにしたがってメッセージを投稿する。

また、メッセージ生成部１０４は、予め定められた定型文でメッセージを投稿してもよい。また、メッセージ生成部１０４は、ユーザからの入力（例えば音声入力）により、任意のメッセージを生成してもよい。

このように、本実施例によれば、車両の状態から複数の状態を判定し、メッセージを生成して投稿することができる。これにより、他のユーザはサービスを介して、複数の情報をリアルタイムに取得することができる。また、１又は複数の車両５０の状態に基づくメッセージを生成していることから、他のユーザにとって必要な情報を投稿しているユーザをフォローすることで、適宜必要な情報を取得することが可能である。

［１．４．５任意のタイミングでメッセージを投稿する実施例］
本実施例は、トリガの検出をユーザー（例えばドライバー）の任意のタイミングで行う場合の実施形態である。

例えば、本体部１０１００に、物理的に動作が可能な操作ボタンを設けてもよい。例えば、図１０に示すように、本体部１０１００に操作ボタン１５０２を設ける。ユーザにより操作ボタン１５０２が選択されると、タイミング判定部１０８は、トリガを検出する。これにより、メッセージ生成部１０４がメッセージを生成し、メッセージ投稿部１０５はサービスにメッセージを投稿する。

このとき、メッセージ生成部１０４は、操作ボタン１５０２が選択されたことにより、予め決められたメッセージを生成して投稿してもよいし、その時点の車両５０の状態に応じたメッセージを生成してもよい。

例えば、ユーザに操作ボタン１５０２が選択されたとき、メッセージ生成部１０４は、車両５０が渋滞中であれば「ただいま渋滞中」といった渋滞を示すメッセージを生成してもよい。これにより、ユーザが操作ボタン１５０２を操作することで、状況に応じたメッセージをサービスに投稿することができる。

また、操作ボタン１５０２に対応付けられた文字がその都度サービスに投稿されてもよい。例えば、操作ボタン１５０２が選択されるごとに、サービスに「危ない運転を見つけた」と投稿されてもよい。また、この場合、制御部１００は、操作ボタン１５０２が選択されたときの車両５０の状態をメッセージに含めて投稿してもよい。例えば、車両５０の現在位置や、外付けされたドライブレコーダの画像がその都度送信されてもよい。

また、機能毎に操作ボタンを設けてもよい。例えば、図１０では、操作ボタン１５０２と、操作ボタン１５０４とを設けている。この場合、操作ボタンごとに投稿するメッセージの種類を変えても良いし、投稿するメッセージの種類を変えても良い。例えば、図１０では、操作ボタン１０５２を選択することで、メッセージ生成部１０４は、渋滞に関する旨のメッセージを生成する。また、操作ボタン１０５４を選択すると、現在ドライブレコーダ等により撮影されている画像を、メッセージに含めて送信する。

また、運転中はメッセージを送信するのが難しいので、上述した操作ボタンを「音声ツイートボタン」「映像ツイートボタン」「写真ツイートボタン」を設けてもよい。これにより、ユーザは簡単な操作で複数のメッセージを切り替えて送信することができる。このような操作ボタンがあると、例えばユーザは事故現場や、火災現場に遭遇したときに、速やかに撮影し、メッセージを投稿することができる。

また、制御部１００は、タッチセンサ１５２から入力されたタッチ操作によりメッセージを生成するトリガとして検出してもよい。例えば、制御部１００は、表示部１２０にソフトウェアボタンを表示する。制御部１００は、タッチセンサ１５２によりソフトウェアボタンがタッチされたことを検出することで、メッセージを生成してもよい。

また、制御部１００は、表示部１２０に１又は複数の候補を表示してもよい。そして、ユーザから選択された候補に応じてメッセージを生成してもよい。

また、制御部１００は、タッチセンサ１５２により所定の操作が検出された場合に、メッセージを生成するトリガとして検出してもよい。例えば、ユーザによりタッチセンサ１５２が３回タップされることで、メッセージを生成するトリガが入力されたと検出してもよい。

また、制御部１００が、ユーザからトリガを受け付けるのは、操作ボタン以外の入力方法であってもよい。例えば、制御部１００は、マイクロホン１５４により音声入力があったことにより、メッセージを生成するトリガが入力されたと検出してもよい。このとき、制御部１００は、単に所定以上の音量を検出した場合にトリガとして検出してもよいし、所定の音声コマンドが入力された場合にトリガとして検出してもよい。

また、制御部１００は、音声入力された場合は、当該音声から認識された文字をメッセージに含めてもよい。また、制御部１００は、音声入力された場合は、入力された音声データ自体を、メッセージに添付して生成してもよい。

また、制御部１００は、ユーザの動作（モーション）を認識してもよい。例えば、ユーザが電子機器１０の前で手を振ることで、メッセージを生成するトリガが入力されたと検出してもよい。

このように、本実施例によれば、ユーザが任意のタイミングでメッセージを投稿することができる。これにより、ユーザが必要と思った情報を、その都度他のユーザにメッセージングサービスを介して共有することができる。

また、上述した実施例では、メッセージを生成するタイミングをタッチ操作だけでなく、音声操作やジェスチャ操作でも入力可能としている。したがって、運転を妨げることなく、即時にメッセージを生成し、サービスに投稿することができる。

また、ユーザは、実際に発生した事象の種類をより正確に特定した上で、その事象の種類を含めたメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。事象の種類の選択肢としては、ユーザが接する可能性が高い事象の選択肢があるとよく、例えば、渋滞、事故、速度取締等とするとよい。例えば、ユーザが任意のタイミングで「事故」に関するメッセージを投稿したいときには、「事故」を選択することで、「事故」と文字が含まれたメッセージを投稿することができる。

また、ユーザは事象を選択するときに、タッチパネルや音声認識において選択することができ、ユーザは簡単な方法で事象を選択することができる。タッチパネル又は音声認識装置は、車両に配置された車載用装置に設けられているとよい。このようにすると、車両内のユーザにとっても操作しやすい。音声認識で選択する構成のもとでは、例えば、ユーザが運転中の場合、音声認識を利用することで、手を離さずに簡単に事象を選択することができる。したがって、ユーザは安全運転に配慮して、装置の操作ができるようになる。

また、ユーザは操作ボタンを選択することで、その操作ボタンに対応した車両の状態に関するメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。また、この操作ボタンは、メッセージを生成し投稿するボタンとは独立して設けられるとよい。このようにすると、ユーザは操作に迷いにくくなる。また、ユーザが必要に応じて他のユーザと共有すべきと判断した情報を、簡単に他のユーザとメッセージングサービスを介して共有しやすくなる。操作ボタンは、表示画面に表示されるソフトボタンとするとよいが、物理ボタンとしてもよい。

また、ユーザは、複数の操作ボタンの各操作ボタンに対応した車両の状態に関するメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。例えば事象毎に操作ボタンを割り当てられていたり、生成するメッセージ毎に操作ボタンが割り当てられていたりするとよい。例えば、第１のボタンには単にテキストでメッセージを生成する機能を割り当て、第２のボタンには、画像付き（例えば、車両の前方を撮影した画像を含む）メッセージを生成する機能を割り当てるとよい。

また、ユーザは、車両の利用中に接する可能性が相対的に高いと考えられる、「事故」や「渋滞」に関するメッセージを容易に作成し、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。

また、ユーザからの音声入力に基づいてメッセージを生成した上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。ユーザからの音声入力は、ユーザが発した音声とするとよい。ユーザが発した音声を認識したことをトリガとして、メッセージを生成するとよい。例えば、ユーザが発した所定のキーワード（例えば、「危ない」や、「混んでる」）に対応付けて事象のメッセージを生成し、投稿してもよい。メッセージは、ユーザが発した所定のキーワード自体を含んでもよいが、そのキーワードから推測される事象を説明したメッセージを生成すると、第三者にとって解りやすい。また、入力されたユーザの音声の音量が所定の音量以上のときにメッセージを生成してもよい。また、入力された音声に基づいて音声認識を行い、音声認識の結果を含めてメッセージを生成してもよい。

また、ユーザは、音声自体をメッセージに含めた上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。ユーザは、音声自体をメッセージに含めることで、より簡単にメッセージを投稿することができる。メッセージングサービスとして、例えば、ソーシャルネットワーキングシステムとしてのＴｗｉｔｔｅｒ等とするとよい。Ｔｗｉｔｔｅｒにおいては、音声メッセージを投稿する機能があるので、これを利用するとよい。

［１．４．６メッセージに所定のキーワードを含めた実施例］
本実施例は、メッセージに所定のキーワードを含めて生成する実施例である。メッセージ生成部１０４は、署名のように、所定のキーワードをメッセージに付けて生成する。ここで、メッセージ生成部１０４は、メッセージに付けるキーワードは、設定情報として記憶部１９０に記憶しておいてもよい。

ここで、所定のキーワードとは、例えばユーザ名や、車両の名前にしてもよい。また、電子機器１０のメーカ名や機種名であってもよい。電子機器１０のメーカ名や機種名の場合、予め記憶部１９０に記憶しておいてもよい。また、電子機器１０のメーカ名や機種名の場合は、予め出荷時に記憶しておいてもよい。また、電子機器１０のメーカ名や機種名の場合は、ユーザが変更できないようにしてもよい。

例えば、メッセージに「＃ユピテルレーダー探知機より送信」と付加してメッセージを生成する。これにより、他のユーザは、メッセージがユピテル製のレーダー探知機から送信されていることを認識することができる。また、上述したメッセージは、１行空けて（空行となるような改行コードを含めて）メッセージを生成してもよい。すなわち、特定のキーワードとして、電子機器１０の製造会社の会社名や、製品名を、他のメッセージ内容と区別できるように表示してもよい。

また、所定のキーワードは、メッセージ毎に付加されてもよいし、所定の間隔毎にメッセージに付加されてもよい。例えば、メッセージ生成部１０４は初回のメッセージを生成するタイミングで所定のキーワードをメッセージに含めてもよいし、回数毎（例えば、５回毎）や、時間（例えば、１時間毎や、朝、昼、晩といった定期的なタイミング）でメッセージに含めてもよい。

また、所定のキーワードはコマンドを含めてもよい。例えば「＜ｌｏｃａｔｉｏｎ＞」というコマンドをキーワードに含める。この場合、メッセージ生成部１０４は、「＜ｌｏｃａｔｉｏｎ＞」を、現在の車両５０の位置（緯度経度情報や、住所、道路名等）に置き換えてメッセージを生成してもよい。

本実施例によれば、所定のキーワードをメッセージに含めてサービスに投稿することができる。したがって、例えば自分の店舗や、営業車の場合会社名をキーワードにすることで、宣伝効果が期待出来る。

また、車両の状態のメッセージがどれであるかを他のユーザに分かるようにしつつ、投稿が行われた車載用装置の製造会社名及び／又は製品名を他のユーザに周知することができる。例えば、ＳＮＳ利用者の多い若年層へのアピールや購買欲の向上への期待といった、車載用装置の販売事業者の認知度向上や販売促進といった販売事業者側のメリットを期待することができる。

このように、ユーザは、車載用装置を通じて、第三者を対象としたアンケートを取ることができる。メッセージングサービスとして、例えば、ソーシャルネットワーキングシステムとしてのＴｗｉｔｔｅｒ等とするとよい。Ｔｗｉｔｔｅｒにおいては、アンケート機能を取るがあるので、これを利用するとよい。アンケート機能は、ダイレクトにメッセージ等を利用して実現されてもよい。アンケート機能を実行して、例えば、ユーザが投稿したメッセージが正しいかどうかを第三者に確認するアンケートを行い、そのメッセージをアンケートで評価できるようにするとよい。アンケート機能によるアンケートの内容は、ユーザが手入力で設定できるようにしてもよいが、その設定なしに決定してもよい。例えば、車両の状態に応じてアンケートの内容を決定するとよい。例えば、渋滞が発生していると判定したときにアンケート機能を実行して、渋滞が発生しているルートを選択した方がよいのか、渋滞を回避したルートを選択した方がよいのかを第三者にアンケートで確認するとよい。

また、予め定められたキーワードをメッセージに含めた上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。予め定められたキーワードとしては、例えば、ユーザがいつもメッセージに含めたいことや、挨拶などを含めたメッセージとするとよい。予め定められたキーワードとしては、例えば、ユーザの店舗の告知や、ユーザのプロフィールのページへのリンク等を含めるとよい。また、予め定められたキーワードとしては、ユーザが所定のタグをいつも付けているときは、そのタグをキーワードとして予め設定するとよい。予め定められたキーワードとしては、ユーザが手入力で指定してもよいが、車載用装置側で判断してユーザの指定なしに挿入してもよい。

また、車両の状態を取得する装置の製造会社名及び／又は製品名をメッセージに含めた上で、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。第三者は、当該製品を利用すれば同じ機能が実現できると考えることから、同じ製品を購入しようとする動機付けとなることが期待できる等、宣伝効果が期待できる。車両の状態を取得する装置としては、上述したような、ドライブレコーダ、ナビゲーション、探知機（例えば、レーダー探知機、レーザー探知機）等とするとよい。メッセージには、車両の状態を取得する装置の製造会社や製品名を毎回挿入するとよい。このようにすると、より高い宣伝効果が期待できる。また、例えば、当該装置の製造会社名及び／又は製品名を利用している事実が明らかとなるので、第三者は当該装置からメッセージが投稿されていることが解り、当該メッセージの信頼性が高いと認識することが期待できる。

また、車両の状態のメッセージがどれであるかを他のユーザに分かるようにしつつ、メッセージングサービスへの投稿を通じて、ユーザにより使用されている装置の製造会社名及び／又は製品名を第三者と共有することができる。例えば、メッセージングサービスとして、ソーシャルネットワーキングシステムとしてのＴｗｉｔｔｅｒ等のＳＮＳ利用者は、若年層や購買層が多く、これらの層へのアピールや購買欲の向上への期待といった、装置の販売事業者の認知度向上や販売促進といった販売事業者側のメリットを期待することができる。

［１．４．７取得したメッセージに応じてメッセージを出力する実施例］
本実施例は、メッセージ取得部１０６が取得した取得メッセージ情報に基づいて、メッセージ出力部１０７がメッセージを出力する実施例である。

メッセージ取得部１０６は、サービスから１又は複数のメッセージが含まれる取得メッセージ情報を取得し、メッセージ情報記憶領域１９６に記憶する。

このとき、メッセージ取得部１０６は、所定のキーワードに基づいてメッセージを取得してもよい。例えば、メッセージ取得部１０６は、キーワードとしていずれかの「地名」と、「事故」という言葉が含まれたメッセージを取得してもよい。また、メッセージ取得部１０６は、「事故渋滞」「交通渋滞」「危険運転」「煽り運転」「単独事故」「多重事故」「逆走走行」「＃事故渋滞」「＃交通渋滞」等の交通に関する情報として、交通情報に関わりそうなメッセージを取得してもよい。すなわち、交通関連のキーワードを取得してもよい。

交通に関する情報（交通関連のキーワード）としては、ユーザが車両での移動中に配慮すべき交通上の事象に関するものとするとよく、特に渋滞に関する情報、又は安全運転に関する情報等とするとよい。例えば「渋滞」「事故」「工事中」といった渋滞に繋がるキーワードや、「取り締まり」「逆走」「あおり運転」といった安全運転に関するキーワード等を含む情報とするとよい。

特に、メッセージングサービスは、ソーシャルネットワーキングサービス（ＳＮＳ）とし、電子機器は、そのソーシャルネットワーキングサービスのメッセージの中から、交通に関する情報を取得する機能を備えるとよい。このようにすれば、ユーザは、ソーシャルネットワーキングサービスで扱われる多くのメッセージの中から、交通に関する情報を受け取ることができる。また、交通に関する情報としては、車両の利用に関連する情報とするとよい。このようにすると、ユーザは、車両の利用に関連する情報を受け取ることができる。車両の利用としては、特に、車両の運転とするとよい。

また、メッセージ取得部１０６は、所定のキーワードが「タグ」として含まれているメッセージを取得してもよい。例えば、「＃事故」「＃東名高速」といったタグが含まれているメッセージを取得してもよい。

例えば、メッセージとは別にそのメッセージに関連するキーワードまたはタグを取得する構成としてもよいが、メッセージングサービスのユーザが、他のユーザと話題を共有したい場合に、そのメッセージ内にその共有するためのキーワードまたはタグをメッセージに含めることがあるから、そのメッセージを取得するとよい。このとき、このタグを利用することで、所定の話題メッセージとは、別にそのメッセージに関連するキーワードまたはタグを取得する構成としてもよいが、所定の話題としては、交通に関する話題とするとよい。メッセージングサービスは、例えば、ソーシャルネットワーキングサービスとしてのＴｗｉｔｔｅｒ（登録商標）等とするとよい。タグは、ハッシュタグとするとよく、ツイートの内容の一部として含められたものを用いるとよい。

他のユーザから投稿されたメッセージを定期的にメッセージングサービスから取得する構成とするとよい。このようにすると、ユーザはあたかも交通情報を受信しているように利用することができる。定期的にメッセージを取得する場合、タグに基づいてメッセージを取得するとよい。例えば、交通に関するタグとして、「＃渋滞」を示すタグとすると、「渋滞」を含むメッセージが定期的に表示されるので、ユーザはあたかも交通情報を受信しているように利用することができる。

また、メッセージ取得部１０６は、位置情報に基づいてメッセージを取得してもよい。例えば、電子機器１０の位置情報を基準とし、所定の範囲の距離に含まれているメッセージを取得してもよい。このとき、メッセージ取得部１０６は、上述したキーワードとともに、位置情報に基づいたメッセージを取得する。

また、メッセージ取得部１０６は、車両の状態に基づいてメッセージを取得してもよい。例えば、電子機器１０は、ＯＢＤＩＩを経由して車両情報を取得する。そして、メッセージ取得部１０６は、車両情報に基づいてキーワードを特定し、当該キーワードが含まれてたメッセージを取得する。例えば、メッセージ取得部１０６は、ＯＢＤＩＩから車両の電圧を取得し、電圧に応じたキーワードを特定する。例えば、特定するキーワードは「電圧が低い」といった状態であってもよいし、「１２．０Ｖ」といった電圧値であってもよい。また、それ以外にも、メッセージ取得部１０６は、油温、ターボ圧、水温といったエンジンに関する情報のキーワードでもよいし、アイドリングストップ時間、走行平均時間といった走行に関する情報のキーワードでもよい。

また、メッセージ取得部１０６は、取得件数に応じて、位置情報から取得する範囲を変更してもよい。メッセージ取得部１０６は、位置情報に基づいてメッセージを取得した場合に、所定の件数になるように位置情報に基づくメッセージの取得の範囲を変更してもよい。例えば、取得メッセージ数を２０件以上とする場合、２０件以上になるまで位置情報に基づくメッセージの取得の範囲を拡げてもよい。例えば、位置情報を現在の取得位置から１ｋｍ、５ｋｍ、１０ｋｍと距離を拡げてもよい。また、隣接市区町村、都道府県内といった地域を広げてもよい。

また、メッセージ取得部１０６は、取得件数が多すぎる場合は、範囲を狭めてもよい。例えば、メッセージ取得部１０６が、メッセージを取得したときに閾値以上（例えば、２０件以上）取得してしまった場合、２０件未満となるように位置情報の取得の範囲を狭めてもよい。

また、メッセージ取得部１０６は、表示されるメッセージの件数が所定の範囲に含まれるよう、メッセージを取得する範囲を変更するとよい。例えば、メッセージを取得する範囲は、対象者の位置を中心として、周辺範囲の距離で表すとよい。また、例えば、メッセージを取得する範囲は、例えばアカウントの年齢層や性別、設置されている装置の自動車の種類、メッセージの属性といった内容とするとよい。

例えば、渋滞に関する情報の場合、車両が位置する近くのメッセージを出力したり、優先的に出力したりするとよい。優先的に出力することは、優先的に出力されるメッセージがユーザに知覚されやすい態様で出力することとするとよく、例えば、優先的に出力する対象のメッセージを出力してそれ以外は出力しないことや、優先的に出力する対象のメッセージを他のメッセージよりも時間的に先に出力すること、優先的に出力する対象のメッセージを他のメッセージよりも目立ちやすい位置に表示すること等とするとよい。また、取得したメッセージ情報の件数が所定の範囲に含まれるように、周辺範囲の大きさを調整するとよい。例えば、メッセージ情報の件数を３０件とした場合、３０件に含まれるように位置情報に基づく範囲を指定するともよい。例えば、制御部は、取得したメッセージの件数が２０件から３０件の範囲を超える場合は、周辺範囲の大きさを小さくする制御をするとよい。また、取得したメッセージの件数が２０件から３０件に満たない場合は、周辺範囲の大きさを大きくする制御をするとよい。

また、周辺範囲の大きさの変更は、単純に中心からの距離としてもよいが、例えば車両の進行方向に応じて変化させてもよい。後者の場合、例えば、車両の進行方向の周辺範囲を広めとしてもよい。例えば、車両が高速道路を北進中の場合、進行方向にあたる北側の範囲を拡大するするともよい。このようにすると、ユーザがこれから進もうとしている方向に関連するメッセージを取得することができる。

また、取得したメッセージを出力するときに、出力態様を変化させてもよい。ユーザは、表示されているメッセージの出力態様の変化により、メッセージが投稿された位置と、ユーザとの位置との関係を確認することができる。例えば、装置の位置から近くの位置から投稿されたメッセージについては色を変えたり、文字の大きさを変えたり、記号を付けたりする表示をするとよい。このようにすると、ユーザは、メッセージの内容が近くで発生している内容であることを確認することができる。また、出力態様を変化させるのと併せて、または出力態様を変化させるのに変えて、メッセージを出力する優先順位を変えるとよい。例えば、電子機器の位置から所定の距離内のメッセージは優先的に出力するとよい。

なお、メッセージ取得部１０６は、キーワードによる検索間隔（メッセージを取得する間隔）が短いと、サービスに負荷がかかったり、サービス提供者の規約に違反することがある。そこで、ある程度メッセージを取得する間隔を空けて取得することが好ましい。メッセージを取得する間隔は、例えばサービス提供者の定めた範囲内であればよい。

そして、メッセージ出力部１０７は、メッセージ取得部１０６が取得したメッセージを出力する。具体的に、メッセージ出力部１０７は、表示部１２０にメッセージを取得する。

例えば、図１１は、表示部１２０に表示される表示画面の一例である。例えば、図１１（Ａ）に示すように、表示画面Ｗ１００の一部の領域Ｒ１００に、メッセージをスクロール表示してもよい。領域Ｒ１００に表示されるメッセージは、通常表示されている表示画面に重畳表示されてもよいし、別の領域で表示されてもよい。また、領域Ｒ１００のメッセージは、横スクロールの表示（例えば、表示画面Ｗ１００の右端から左端にかけて移動表示）をしてもよい。

また、図１１（Ｂ）に示すように、表示画面Ｗ１１０の一部の領域Ｒ１１０にメッセージを表示する領域を設けてもよい。例えば、領域Ｒ１１０は、縦スクロールしてメッセージを表示してもよい。具体的には、領域Ｒ１１０は、新しいメッセージを画面上側に表示し、古いメッセージは下方向にスクロール表示してもよい。

また、メッセージ出力部１０７は、メッセージを出力するときに併せてメッセージの属性に関する表示を行ってもよい。例えば、メッセージ出力部１０７は、メッセージだけではなく、アカウント名、アカウントＩＤだけでなく、評価された数（いいねをされた数、いいね数）、再投稿された数（リツイートされた数）、返信の有無（返信されている数）を表示してもよい。また、メッセージ出力部１０７は、更に公式のアカウントの場合、公式アカウントである旨を併せて表示してもよい。

またメッセージ出力部１０７は、これらを絵文字や記号とともに併せて表示してもよい。例えば、評価数としていいねの数を表示する場合、ハートの絵文字と併せていいねの数を表示してもよい。

図１１（Ｃ）、図１１（Ｄ）は電子機器１０の実際に表示した表示画面の一例である。図１１（Ｃ）では、表示画面に地図が表示されており、下側にメッセージがそのまま表示されている。このメッセージは、表示画面右から左に流れるように表示される。また、メッセージに絵文字がある場合、絵文字を併せて表示してもよい。絵文字を表示することで、ユーザの感情がメッセージとともに表すことができる。例えば、「おこっている顔」を表示することで、イライラしていることを表現してもよい。また「泣いている顔」を表示することで、困っていることを表現してもよい。また、「パトカー」の絵文字を表示することで取締があることを示したり、「工事」の絵文字を表示することで、工事中であることを示してもよい。このようにメッセージに絵文字が含まれていることで、ユーザは視認性のよいメッセージを提供することが可能である。

ここで絵文字は、サービスで利用されているものと同じ絵文字が表示されてもよい。サービスで利用されている絵文字がそのまま表示されることで、ユーザにとってより状況（例えば、投稿者の感情）などが伝わりやすくなる。

図１１（Ｄ）は、例えば、電子機器１０が生成したメッセージを表示している。この場合、サービスから取得したメッセージであることを識別する表示をしてもよい。例えば、メッセージの色を変更することで、サービスから取得したメッセージと、電子機器１０が生成したメッセージとを区別して表示してもよい。また、図１１（Ｄ）に示すように、事象を取得した最初の時刻からの経過時間を併せて表示してもよい。また、図１１（Ｃ）（Ｄ）に示すように表示画面には、例えば車両の速度、現在の時刻、現在の位置に対応する住所、走行中の道路名称が併せて表示してもよい。また、ユーザの設定により他の車両情報が表示されてもよい。

また、メッセージ出力部１０７は、メッセージを繰り返して表示してもよい。例えば、メッセージ情報記憶領域１９６に記憶されている取得したメッセージをテロップ表示（スクロール表示）するときに、繰り返して表示する。例えば、メッセージ出力部１０７は、取得したメッセージが１０件ある場合、古いメッセージの１件目から順次表示し、１０件目を表示した後は、再度１件目から表示してもよい。

また、メッセージ出力部１０７は、表示するメッセージ件数により表示する速さを切り替えてもよい。例えば、多くのメッセージがある場合はスクロール速度を速くし、メッセージが少ない場合はスクロール速度を遅くしてもよい。すなわち、メッセージ出力部１０７は、単位時間あたりの表示する出力数を調整してもよい。

また、メッセージ出力部１０７は、車両の状態に応じてメッセージの表示態様を変えてもよい。例えば、メッセージ出力部１０７は、端子部１７２を経由してＯＢＤＩＩによる車両情報を取得してもよい。例えば、車両情報から車両の速度に応じてメッセージの速さを切り替えるといったことをしてもよい。

また、メッセージ出力部１０７は、直近のメッセージと、過去のメッセージとで表示速度を切り替えてもよい。

また、メッセージ出力部１０７は、メッセージの属性に応じて出力態様（表示態様）を変えてもよい。例えば、メッセージに対する評価や、再投稿数が多い場合は，メッセージの表示速度を遅くし、メッセージに対する評価や、再投稿数が少ない場合は、メッセージの表示速度を速くしてもよい。また、メッセージ出力部１０７は、メッセージの表示速度の変える代わりに、メッセージの色を変えたり、フォントの大きさや種類を変えたりしてもよい。また、メッセージ出力部１０７は、メッセージの属性として、例えばリプライのメッセージ（返信先に自分のアカウントが含まれている場合）は、出力態様を変更してもよい。

このようにすれば、ユーザは、自身宛のメッセージについては、他のメッセージと異なる出力態様で出力されたメッセージを受け取ることができ、自分宛のメッセージを確認しやすくなるようにすることができる。なお、ユーザ宛のメッセージについては、メッセージングサービスから取得したメッセージの中から抽出する機能を備えてもよいが、ユーザ宛のメッセージだけを別に取得する機能を備えてもよい。

ここで、ユーザのアカウント宛のメッセージとは、例えば、メッセージの中で第２のアカウントに関する情報が含まれていること、メッセージに第２のアカウント宛へのメンションが含まれていること、第２のアカウントから投稿したメッセージに対してリプライがあったこと等とするとよい。

ユーザはメッセージの中で自分のアカウントを言及するメッセージを受け取ることができる。また、例えば、メッセージの中でユーザのアカウントを言及するメッセージの出力態様を変える機能を備えるとよい。このようにすると、ユーザは、自分が言及されているメッセージを受け取ることができる。ここで、ユーザのアカウントを言及しているメッセージとは、例えばメッセージの中に自分のアカウントを示す情報（例えば、上述したアカウントを示す情報と同じとするとよく、例えば識別ＩＤ等）が含まれているメッセージとするとよい。また、メッセージングサービスとして、例えばソーシャルネットワークサービスであるＴｗｉｔｔｅｒ等とするとよく、ユーザのアカウントを言及しているメッセージは、当該ユーザに対してメンションがされているメッセージとするとよい。

また、上述の実施例では、ユーザは、メッセージだけでなく、メッセージの属性も確認することができる。メッセージの属性としては、メッセージの重要度の指標となる属性とするとよい。このような属性としては、例えば、位置に関する属性、又はメッセージの評価に関する属性とするとよい。ユーザは、メッセージと併せてメッセージの属性が出力されることで、出力されているメッセージと、メッセージの属性の内容に応じてメッセージの重要度を判定することができる。

また、ユーザは、メッセージに対応した属性として、メッセージが再投稿された回数、メッセージに返信が付けられている回数、及びメッセージが評価された回数のうち、少なくとも１つの属性を、メッセージと併せて受け取ることができる。メッセージと併せてこれらの属性が表示されたり、メッセージと併せてこれらの属性が音声により出力されたりするとよい。このようにすると、ユーザは、メッセージが再投稿された回数、メッセージに返信が付けられている回数、及びメッセージが評価された回数を、メッセージに関する評価として把握することができる。

ここで、メッセージングサービスが、例えばソーシャルネットワークサービスであるＴｗｉｔｔｅｒとするとよい。この場合、メッセージが再投稿された回数は、リツイート数とするとよく、返信が付けられた回数はリプライ数とするとよく、メッセージが評価された回数は「いいね」がついた回数とするとよい。メッセージングサービスが提供するＡＰＩにネットワークを介してアクセスして属性を取得する構成とするとよい。

例えば、メッセージと併せて「Ｘ件リツイートされています」と出力するとよい。このようにすると、ユーザは、メッセージだけでなく、再投稿された回数も把握することができる。例えば、ユーザは、リツイート、リプライ等の回数が多いメッセージほど、多くの人に指示されているメッセージであり、信頼性の高いメッセージであると推測することができる。

また、例えば、メッセージの件数が多い場合に、メッセージをスクロールの表示をする速度を速くするとよい。このようにすると、ユーザは多くのメッセージを確認することができる。また、ユーザは、例えば、スクロールの表示をする速度が速いメッセージを見ることで、投稿数が多いことを把握することができるだけでなく、臨場感（例えば、情報が多く流れているイメージ）を得ることができる。また、取得したメッセージの件数が少ない場合は、スクロールの表示をする速度を遅くするとよい。ユーザは、スクロールの表示をする速度が遅い場合、取得したメッセージの数が少ないことを把握することができるだけでなく、メッセージを確認しやすくなったり、落ち着いている状況を感じることができる。

また、ユーザはメッセージの出力方法により、メッセージの件数がどの程度であるかを認識することができる。例えば、単位時間当たりに取得したメッセージ件数が多い場合は、出力方法として速くメッセージを出力し、単位時間当たりに取得したメッセージ件数が少ない場合は、出力方法として遅くメッセージを出力するとよい。このようにすると、ユーザは、メッセージが速く出力されれば単位時間当たりに多くのメッセージを取得できていることが解る。また、ユーザは、メッセージが遅く出力されれば、単位時間当たりに取得したメッセージは少ないことが解る。また、メッセージの出力方法として、速さを変更する場合は、例えばスクロール速度を切り替えてもよいが、テロップによる表示速度を切り替えるとよい。

また、メッセージ出力部１０７は、メッセージを投稿したアカウントが公式アカウントや、企業アカウントの場合に、表示態様を変化させてもよい。

また、メッセージ出力部１０７は、メッセージの内容や、メッセージに含まれている位置情報が、電子機器１０の位置に近い場合は、表示態様を変化させてもよい。

また、メッセージ出力部１０７は、メッセージを出力するタイミングを、電子機器１０の状態に応じて切り替えてもよい。例えば、メッセージ出力部１０７は、電子機器１０を備えた車両５０が停止しているとき又は低速で移動しているときにメッセージを出力する（メッセージを表示する）ことにしてもよい。

また、メッセージ出力部１０７は、例えば音声出力する場合は、車両５０の車内で音楽やラジオが流れているときは、音声出力を中止してもよい。また、設定により、メッセージ出力部１０７は、車両５０が走行中で騒音が大きい場合等は、通常より大きな音量でメッセージを出力してもよい。

このように本実施例によれば、単にメッセージを取得するだけでなく、必要に応じたメッセージを取得することができる。サービスにおいて、単純に検索を行うと多くのメッセージが抽出されてしまう。そこで、必要に応じたメッセージを取得したり、必要となるメッセージは異なる表示態様で表示できるようにすればよい。

本実施例によれば、ユーザは、メッセージの中から、交通に関するキーワードが含まれるメッセージをメッセージングサービスから受け取ることができる。メッセージングサービスにはユーザとは異なる他のユーザが投稿したメッセージが含まれるが、他のユーザが投稿したメッセージの中から、交通に関するキーワードが含まれるメッセージを取得する機能を備えるとよい。また、交通に関するキーワードを含まないメッセージはメッセージングサービスから取得しない機能を備えるとよい。このようにすると、出力されるメッセージを、交通に関するキーワードを含むメッセージを絞ることができ、ユーザは、交通に関するキーワードを含まないメッセージはメッセージングサービスから受け取らないようにすることができる。

また、メッセージングサービスとして、例えば、ソーシャルネットワーキングシステムとしてのＴｗｉｔｔｅｒ（登録商標）等とするとよい。Ｔｗｉｔｔｅｒにおいて、各ユーザが投稿したメッセージは、ツイートとも呼ばれ、サービスを利用しているユーザにより作成、配信される。ＡＰＩを介して定期的にメッセージングサービスからメッセージを取得する機能を備えるとよい。また、リアルタイムにメッセージを取得するとよい。このようにすると、ユーザは交通に関するキーワードが含まれるメッセージを、メッセージングサービスからリアルタイムに取得することができる。

ユーザは、メッセージングサービスからの交通に関する情報を含むメッセージを電子機器において受け取ることができる。電子機器が、ユーザに向けてメッセージを出力する方法としては、例えば、電子機器が、表示装置や、音声出力装置を備えている場合、表示装置においてメッセージに基づいた交通に関する情報を表示したり、音声出力装置においてメッセージに基づいた交通に関する情報を出力したりしてもよい。

また、本実施例によれば、ユーザが、メッセージの出力態様に応じて、メッセージを投稿したアカウントに関する情報を把握しやすくすることができる。例えば、メッセージの出力先として表示部にメッセージを表示させる機能を備えるとよく、例えば、メッセージの色や、フォントの大きさ、フォントの種類といった表示態様を変化させるとよい。このようにすると、ユーザはアカウントに関する情報を判別しやすく、その情報を把握しやすくなる。具体的には、例えば、ユーザと関連するアカウントの場合、フォントの色を変えて表示させるとよい。また、例えば、メッセージを投稿したアカウントに関連するアカウントの数（フォロー数／フォロワー数）に応じて、メッセージの大きさを変化させたり、メッセージの色を変化させたりするとよい。

また、ユーザは、メッセージを見るときに、併せて、表示された絵文字を見ることができる。また、このとき、ユーザはメッセージングサービスで表示されている絵文字をそのまま電子機器でも見ることができる。絵文字を利用することで、感情や状態を表すともよい。また、ユーザが利用した絵文字がメッセージングサービスと、電子機器とで同じものが表示されることで、ユーザは、よりわかりやすくメッセージを受け取ることができる。制御部は、絵文字をそのまま表示する場合、見た目も同一の絵文字を表示してもよいが、絵文字の外観が異なっていても、同じ内容を意味する絵文字を表示してもよい。例えば、「笑顔」の絵文字であれば、絵文字を示す文字コードが少なくとも同一とするとよい。

［１．４．８取得したメッセージのうち必要なメッセージを出力する実施例］
本実施例は、取得したメッセージのうち、必要に応じてメッセージを非表示とする実施例である。取得したメッセージの中には、無用なデータもたくさん有るため、適切なメッセージを抽出することが好ましい。

例えば、制御部１００（メッセージ出力部１０７）は、キーワードに基づいて取得したメッセージが再投稿メッセージの場合は、１つのみ表示し、後は表示しないようにしてもよい。

例えば、
「＠ＮＥＸ＜火災による通行止め＞東名高速道路下り線１９５．５ＫＰにて車両火災あり吉田ＩＣ～相良牧之原ＩＣ間において通行止め」
というメッセージがあり、当該メッセージの再投稿として、
「ＲＴ＠ＮＥＸ＜火災による通行止め＞東名高速道路下り線１９５．５ＫＰにて車両火災あり吉田ＩＣ～相良牧之原ＩＣ間において通行止め」
が複数あった場合、「ＲＴ」を含むメッセージは非表示としても良い。また、再投稿メッセージが多いということは、重要なメッセージであるとして、メッセージ出力部１０７は、総てのメッセージを表示してもよい。

また、メッセージ出力部１０７は、最初のメッセージに識別表示を行ってもよい。例えば、メッセージ出力部１０７は、最初のメッセージだけ色を変えたり、フォントを代えたりしてもよい。また、メッセージ出力部１０７は、併せて再投稿数を表示してもよい。また、メッセージ出力部１０７は、最初のメッセージ（ＲＴがないメッセージ）を取得できない場合は、取得したメッセージの中で最も古い者だけを表示してもよい。また、メッセージ出力部１０７は、再投稿メッセージのうち、所定のタイミングのものは表示してもよい。例えば、メッセージ出力部１０７が、５分おきには表示したり、取得したメッセージのうち１０個毎には表示することにしてもよい。

また、メッセージ出力部１０７は、評価数が高いメッセージ（いいねの数が多いメッセージ）は優先的に表示することにしてもよい。また、これらのメッセージ文言、属性から機械学習によって学習された学習モデルを利用することで、メッセージの重要度を判定してもよい。

また、メッセージ出力部１０７は、関連性の薄いメッセージは非表示としても良い。このときは、非表示キーワードを予め設定してもよいし、ユーザが登録出来ることとしても良い。例えば「大浴場」「性行為」「試食」といったキーワードを登録し、当該メッセージが含まれているものは非表示としてもよいし、１回のみ表示することにしてもよい。

また、メッセージ出力部１０７は、メッセージに箇条書きが含まれているものは非表示としてもよい。

また、メッセージ出力部１０７は、進行方向にないメッセージは非表示としてもよい。例えば、車両５０が、東名高速を東京から名古屋方面に下り方向に走行しているとする。このとき、メッセージ出力部１０７は、静岡県内を走行中の場合、静岡県、愛知県に関する情報は出力する。また、メッセージ出力部１０７は、神奈川件、東京都に関する情報は出力しないとしてもよい。

このように、サービスには多くのメッセージが含まれていることから単純に抽出すると必要以上に多くのメッセージが出力されてしまうが、本実施例によれば、必要なメッセージを解りやすく表示することができる。また、メッセージングサービスでは、若年層等も気楽に利用出来ることから、友達間のメッセージ等一般的に表示させる必要のないメッセージが含まれる。本実施例では、そのようなメッセージを除外することで、より必要な情報を取得し、出力することができる。

［１．４．９定期的に取得したメッセージから新たなメッセージを生成する実施例］
本実施例は、メッセージ取得部１０６が定期的にメッセージを取得し、新たなメッセージを生成する実施例である。

すなわち、メッセージ取得部１０６が取得したメッセージが、メッセージ情報記憶領域１９６に記憶されている。メッセージ生成部１０４は、当該メッセージ情報記憶領域１９６に記憶されているメッセージから新たなメッセージ（投稿メッセージ）を生成する。

そして、この新たに生成された投稿メッセージは、メッセージ投稿部１０５により、サービスに投稿してもよい。また、このときメッセージ取得部１０６が取得したメッセージのうち、関連するメッセージをまとめてメッセージとして、制御部１００（メッセージ生成部１０４又はメッセージ投稿部１０５）が生成してもよい。

ここで、関連するメッセージとは、制御部１００がメッセージを類似すると判定したメッセージや、サービスにおいて関連付けられているメッセージ（例えば、返信のメッセージ（例えば、リプライのメッセージ）や、再投稿のメッセージ（例えば、リツイートのメッセージ）をいう。

メッセージが類似しているとは、例えば、ある程度同じ文言を含んでいるメッセージをいう。例えば、制御部は、事象の種類（カテゴリーを示すキーワード）、位置（事象の発生時点、道路名称、市区町村）が共通している場合には類似しているメッセージと判定する。また、制御部１００は、複数の文言が含まれていることをスコア化し、点数が高い場合は類似していると判定してもよい。例えば、制御部１００は、メッセージが「渋滞」、「箱崎」というキーワードが共通しており、当該メッセージの投稿時間が違い場合は類似するメッセージと判定する。また、制御部１００は、信頼性の高いアカウントのメッセージと共通する文言が含まれているものは、類似するメッセージと判定する。また、制御部１００は、機械学習によりメッセージが類似するかを判定してもよい。

例えば、制御部１００は、新たに生成したメッセージに、関連するメッセージがまとめて表示されるまとめメッセージが表示できるように、リンクを付してもよい。ユーザはリンクを選択することで、新たなメッセージを作成した元のメッセージが１又は複数確認することができる。このまとめメッセージが表示されるサイトでは、例えば関連するメッセージがスレッドとして表示されてもよい。また、このまとめメッセージが表示できるサイトの２次元コードが併せて表示されてもよい。

また、新たに生成した投稿メッセージは、メッセージ出力部１０７により、出力されてもよい。例えば、表示部１２０に新たなメッセージが表示されたり、音声出力部１３０に音声出力されたりしてもよい。

ここでメッセージ取得部１０６がメッセージを取得する仕組みについて説明する。例えば、メッセージ取得部１０６は、予め決められたキーワードを用いて、サービスから定期的にメッセージを取得する。例えば、メッセージ取得部１０６は、サービスから提供されているメッセージ全体を巡回検索し、キーワードに一致するメッセージを取得してもよい。また、ユーザのアカウントと関連するアカウント（例えば、ユーザのフォロワーや、お気に入りとして登録しているアカウント）のメッセージ（当該ユーザのタイムライン）から、キーワードに一致するメッセージを取得してもよい。

例えば、サービスのＡＰＩ検索に、予め決められたキーワード（カテゴリー）として交通関連のキーワードを設定する。交通関連のキーワードとは、交通情報に関するキーワードや、自動車を運転するときに有効な文言となるキーワードである。具体的には、「交通渋滞」「事故渋滞」「車両通行止め」「速度取締」「危険運転」等のキーワードであり、これらのキーワードを検索キーとして巡回検索させる。

また、キーワード（例えば、「車両通行止め」）を使って、予め登録した道路名称や、ＩＣと一致した文字列を使って文章を組み立ててもよい。すなわち、制御部１００は、新たな投稿メッセージを生成する。

そして、メッセージ生成部１０４は、メッセージから事象を取得し、事象を含むメッセージを生成する。

また、メッセージ生成部１０４は、新たなメッセージには、何れかの地域に関連する語句が含まれることが好ましい。例えば、事象が発生している市区町村名、交差点名、道路名、ＩＣやＳＡ／ＰＡの名称、発生している区間といった地域に関連する語句が１又は複数含まれることが好ましい。

これらのキーワードに対応するカテゴリーは各事象の種類を示しており、予め定められていてもよいし、ユーザが追加してもよい。また、カテゴリーは、事象を新たに追加してもよい。例えば、ニュースで「歩行者妨害」が話題になっている場合は、「歩行者妨害」の事象の種類を、新たなカテゴリーとして追加してもよい。

この場合のメッセージのフォーマットの一例を、図１２（Ａ）に示す。本実施例により生成されるメッセージの一例は、例えば、「カテゴリー」「時刻」「道路名称」「住所」、「メンション」、「ハッシュタグ」、「署名」が含まれる。

また、本実施例の制御部１００の一例を図１２（Ｂ）に、記憶部１９０の構成の一例として図（Ｃ）に示す。図１２の構成は、図８（Ａ）及び図８（Ｂ）で示した構成に追加されるものである。

メッセージ制御部１０９は、取得したメッセージ等から新たなメッセージに生成したり、加工したりする。また、このとき、記憶部１９０に記憶された辞書データベース（ＤＢ）１９９を利用して、メッセージ制御部１０９は、メッセージを生成する。

本実施例では、ユーザがカテゴリーを選択したり、入力したりすることで、メッセージ制御部１０９は、サービスから取得したメッセージに基づいて、新たなメッセージを生成する。

ここで、ユーザは、カテゴリーを音声入力したり、タッチ操作により選択したりして入力する。また、ユーザは、操作ボタンを操作することにより、カテゴリーを入力してもよい。これは、車載用の電子機器１０の場合、スマフォのように文字を打ち込むことができない。そこで、カテゴリーを声やタッチ操作で選ぶことで、メッセージ（例えば、ｔｗｅｅｔの記事）を自動で構成させていくことになる。また、カテゴリー以外の残りのメッセージは、電子機器１０が取得している位置情報（例えば、ＧＰＳによるＧＰＳ情報）や、地図情報を使って、それぞれ区切られたフレームの内容を自動生成していくことができる。

また、例えばユーザが投稿しやすいように、待ち受け画面に投稿用の待ち受け画面を設けてもよい。例えば、投稿用の待ち受け画面をスクリーンショットすることで、投稿画像として投稿することができる。以下、図１２（Ａ）で示した各項目について説明する。

（１）カテゴリーの作成
投稿するカテゴリーは、交通に関する語句であることが好ましい。例えば「渋滞」「逆走」「あおり」「取締り」等、音声認識しやすいいワードや、メッセージングサービスでよく使われる検索ワードをリストアップしておくことが好ましい。また、カテゴリーは、上述したキーワードと一致してもよい。

また、音声認識をする場合、音声認識用の登録ワードはスコア値が出やすいワードも登録しておいてもよい。

例えば、「渋滞」であれば「ジュウタイ」の他にも「ジュータイ」を登録しておいてもよい。同様に、「通行止め」であれば「ツウコウドメ」の他にも「ツーコードメ」、「逆走」であれば「ギャクソウ」の他にも「ギャクソー」、「暴走」であれば「ボーソー」も登録しておく。これらを、図１２（Ｃ）で示した記憶部１９０に記憶される辞書ＤＢ１９８のカテゴリー辞書１９８２に記憶する。

また、カテゴリーに対応したキーワードを付加しても良い。この場合、巡回しているキーワードや、メッセージに対応するキーワードを抽出してキーワードにする。この場合、キーワードは目立つように括弧で囲んでもよいし、後で識別表示できるようなコマンド（例えば、ｈｔｍｌタグ）で囲んでもよい。

（２）時刻
時刻は、電子機器１０において管理している時刻を使用する。このとき、例えばＧＰＳの年月日情報や、電子機器１０の計時部１０３が管理している時刻を使用し、自動生成する。

（３）道路名称
道路名称は、例えば、道路辞書１９８８を参照して自動生成する。道路辞書１９８８は、道路リンクデータと、緯度経度と、道路名とが対応付けて記憶している。制御部１００は、取得した位置情報（緯度経度情報）に基づき、現在車両５０が走行している道路名称を使用する。道路名称は自動生成されてもよい。

（４）住所
住所は、例えば、住所辞書１９８６を参照して自動生成する。住所辞書１９８６は、地図の行政界ポリゴンと、緯度経度情報と、市区町村名や、町名とを記憶する。そして、制御部１００は、取得した位置情報（緯度経度情報）に基づき、現在車両５０が走行している住所を使用する。住所は自動生成されてもよい。

（５）メンション
メンションは、例えば、投稿したユーザが誰なのかが解るように、ユーザアカウントをメッセージに含める。すなわち、メッセージングサービスにおいてユーザアカウントに対するリンク（メンションと呼ばれることがある）が貼られることになる。このユーザアカウントについては、アカウント情報記憶領域１９２に記憶されているアカウント情報を使用すればよい。

また、ユーザアカウントに対するリンクが貼られることで、第三者がユーザのプロフィールページを見ることができる。これにより、第三者と、投稿したユーザとの間で信頼関係の構築に繋がる。

また、メッセージを投稿する人は、電子機器１０を使用しているユーザのアカウントでもよいし、メッセージを管理装置等経由して投稿する場合は、管理装置に対応付けられたアカウントでもよい。

また、ユーザに対してメッセージが投稿されたことを示すために、ユーザにたいするメンションを含めることとして説明したが、投稿したメッセージをダイレクトメッセージやメールで送信してもよい。

（６）ハッシュタグ
市区町村名や道路名称をハッシュタグとしてメッセージに含める。例えば、ハッシュタグは、市区町村名や道路名称の文字列に特定文字（列）を付加しても良い。例えば、特定文字「＃」と、道路名称「国道１号線」とを組み合わせることで、ハッシュタグ「＃国道１号線」がメッセージに付加される。ハッシュタグは自動生成されてもよい。なお、ハッシュタグは、タグの一例である。

（７）署名
任意の文字列を署名として付加できる。例えば、電子機器１０の製造会社の名称を予め登録しておくことで、電子機器１０の製造会社の技術力のアピールにもなる。また、ユーザが任意に作成した文字列を署名として毎回付加しても良い。

このように、メッセージを巡回し、まとめて記載することで、単にメッセージが表示されるのと比較し、解りやすいメッセージが新たに生成される。

なお、上述した（１）～（７）の項目は、それぞれユーザがメッセージに含まれるものを選択できるようにしてもよい。例えば、（６）についてメッセージに含めないとしてもよい。また、メッセージとして生成する順番を入れ替えてもよい。

また、メッセージ生成部１０４は、複数の関連するメッセージがある場合は、件数を含めてもよい。例えば、メッセージ生成部１０４は「○○の事故に関して他１０件メッセージがあります」といったことを表示してもよい。

また、この件数を表示した場合、この件数はまとめメッセージの件数であってもよい。
この場合、ユーザがメッセージに含まれている件数を選択したり、当該メッセージに含まれているリンクを選択したりすると、まとめメッセージを確認できるページを表示してもよい。

また、複数のメッセージは、事象毎にまとめたり、地域毎にまとめたりしてもよい。例えば、「事故に関するメッセージは○件あります」とメッセージを生成したり、「名古屋駅周辺でメッセージが○件あります」といったメッセージを生成したりしてもよい。また、事象が同一のメッセージをまとめてもよい。例えば「中央道談合坂ＳＡで渋滞に関するメッセージが○件あります」といったメッセージを生成してもよい。

また、新たに生成したメッセージには、取得したメッセージの一部を含めてもよい。例えば、最も新しいメッセージを含めたり、信頼性の高いアカウントから投稿されたメッセージや、信頼性の高いメッセージの一部を含めたりしてもよい。アカウントやメッセージの信頼性が高いか否かは別の実施例で説明する。

このように、本実施例では、メッセージをそのまま取得せずに、必要に応じた状態に加工して表示することができる。とくに、メッセージングサービスには多くのメッセージが投稿されており、必要なメッセージと不要なメッセージとが存在している。また、一見すると必要なメッセージでも、例えば単に再投稿のメッセージ（リツイート）であって、必要な情報は一部の場合がある。そのような場合でも、新たなメッセージを生成することで、情報の価値の高いメッセージを投稿することや、表示することができる。

また、ユーザは、交通関連のキーワードとして「渋滞」「事故」又は「逆走」に基づいて、メッセージングサービスにメッセージを投稿し、そのメッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。そして、新たな投稿メッセージとして、渋滞、事故、又は逆走に関するメッセージを生成することができる。これらのキーワードは、第三者にとっても必要性が高いキーワードと考えられ、ユーザは、第三者にとって必要性の高いメッセージを投稿しやすくすることができる。

また、ユーザにとっては、電子機器において、関連するメッセージが複数表示されることがなく、まとめて１つの投稿メッセージとして確認ことができる。例えば、メッセージングサービスにおいて分散しているメッセージを、まとめて投稿メッセージを生成し、投稿するとよい。このようにすると第三者も、当該投稿メッセージを参照することで、必要な情報が含まれる投稿メッセージに接しやすくなる。

また、ユーザは、投稿メッセージにユーザのアカウントを識別する情報を含めた上で、その投稿メッセージをメッセージングサービスへの投稿を通じて他のユーザと共有することができる。ユーザのアカウントを識別する情報として、メッセージングサービスで扱われている情報とするとよく、例えば、アカウントＩＤ、アカウント名等とするとよい。このようにすると、第三者は、メッセージを投稿するアカウントと、取得したメッセージの投稿者のアカウントが異なっていても、誰からのメッセージであるかと投稿することができる。

また、ユーザは、アカウントを識別する情報として、メッセージの投稿者のアカウントを含めた上で、その投稿メッセージをメッセージングサービスへの投稿を通じて第三者と共有することができる。したがって、第三者は、メッセージの投稿者が誰であるかを容易に確認することができる。
また、ユーザのアカウントは、管理装置にログインするユーザのアカウントであってもよい。
このようにすれば、ユーザは、管理装置にログインするユーザのアカウントと、管理装置が送信するアカウントが異なる場合でも、第三者に対して明示することができる。また、管理装置を利用してメッセージを投稿するユーザは、管理装置が投稿したことを知ることができる。

［１．４．１０メッセージに画像を追加する実施例］
上述した実施例に加えて本実施例では画像を投稿する。すなわち、メッセージ制御部１０９は、生成するメッセージに画像を添付する。そして、メッセージ制御部１０９が生成したメッセージをメッセージ投稿部１０５がサービスに投稿することで、画像付きメッセージを投稿することができる。本実施例は、メッセージ制御部１０９が生成したメッセージを、メッセージ投稿部１０５がサービスに投稿するときに特に有効である。

投稿する画像としては、例えば電子機器１０にドライブレコーダが接続されている場合、ドライブレコーダから画像を取得すればよい。また、電子機器１０に撮像装置が設けられている場合、撮像装置から画像を取得すればよい。また、電子機器１０が他の装置、例えばユーザのスマートフォン等の端末装置が接続可能な場合、当該端末装置から画像を取得してもよい。また、電子機器１０の表示部１２０の表示画面をキャプチャした画像であってもよい。また、電子機器１０が取得可能な地図情報（例えば、現在位置を含む地図）を示す画像であってもよい。

ここで、電子機器１０の表示部１２０に表示されている画面は、車両の運転を支援するための表示画面であってもよい。例えば、表示画面には、交通規制（規制速度、道路標識の内容）が含まれてもよい。また、表示画面には、車両の情報（例えば、ＯＢＤＩＩにより取得した車両情報）が含まれてもよい。また、表示画面には、交通取締の場所、交通取締の内容が含まれてもよい。また、表示画面には、これらの情報が組み合わせられて表示されてもよい。例えば、表示画面に、現在位置を含む地図と、交通規制に関する情報、車両の情報（例えば、車両の速度）が併せて含まれてもよい。

また、上述した画像に、電子機器１０は情報を付加した画像であってもよい。例えば、電子機器１０が取得した現在の位置を示す情報（例えば、市区町村を含む町名）、道路名称、車両５０の状態、日時を１又は複数画像に含めてもよい。

ここで、サービスにおいて、画像の大きさに制限がある場合、制限内に収まるように画像のサイズや解像度を変換してもよい。例えば、横サイズが最大６００ピクセル、縦サイズは無制限、縦横比は１６：９、拡張子がＰＮＧ、ＪＰＧ、ＧＩＦの画像形式、ファイルサイズが５ＭＢ以下になるように、画像を変換する。

このようにすれば、ユーザは、車両の運転を支援するための表示画面をキャプチャした画像に関する情報をメッセージに含めた上で、そのメッセージを、メッセージングサービスへの投稿を通じて他のユーザと共有することができる。車両の運転を支援するための表示画面を表示する装置としては、スマートフォンなどのユーザが携帯する情報処理端末としてもよいが、もっぱら車両の運転を支援するための機能を提供する電子機器の表示画面とするとよい。

電子機器としては、例えば、撮影及び録画機能を提供するドライブレコーダ、ルート案内等のナビゲーション機能を提供するナビゲーション、及び速度取締地点と所定の接近関係を有することを報知する報知機能を有する探知機（例えば、レーダー探知機、レーザー探知機）等とするとよい。車両の運転を支援するための表示画面においては、地図を表示することも多い。そこで、例えば、車両の運転を支援するための表示画面として地図を含む表示画面をキャプチャして、その地図を含めた画像を含むメッセージを生成するとよい。位置（例えば住所や道路名称）を含む表示画面をキャプチャして、その位置を含めた画像を含むメッセージを生成するとよい。このようにすると、第三者は、メッセージに含まれた画像から、車両の進行が妨げられる原因となり得る事象が発生している付近の地図や、場所を画像からも確認することができるようになる。キャプチャの実行は、ユーザの手入力によって指示されるとよく、例えばワンタッチの操作できるようにするとよい。キャプチャはユーザの明示の指示なしに実行されてもよく、例えば、所定のイベントが発生した場合に実行されたり、定期的に実行されたりするとよい。投稿に用いられる画像は、ユーザが指示してもよいし、その指示無しに選択されてもよい。

また、画像を投稿する場合、電子機器１０の待ち受け画面を「投稿」が可能な投稿待ち受け状態にしてもよい。例えば、電子機器１０が、音声認識の起動フレーズなしで、即画像を含むメッセージを投稿できるような環境を提供する。

なお、メッセージ投稿部１０５は、サービスに投稿する場合、サービスの制約内の条件でメッセージを投稿してもよい。例えば、サービスに投稿するＡＰＩのアクセスキーの使用が、取得するメッセージの２００を確認する処理と併せる場合、投稿間隔を１０分以上とするというように、サービスの制約に併せて投稿してもよい。また、メッセージ投稿部１０５は、同じメッセージ（データ）を連続して送らないといった制約を設けてもよい。

このように、本実施例によれば、メッセージに画像を含めて投稿することができる。一般的にサービスのメッセージを表示する画面（タイムライン）には、画像を含めて表示される。したがって、他のユーザは共有されたメッセージをみるとき、文字だけより画像が含まれているメッセージの方が、他のユーザに対してより訴求性の高いメッセージを生成し、投稿することができる。

なお、画像を投稿する場合、画像のリンク先を含む情報をメッセージに含めて投稿する場合があるが、このリンク先を示す情報を含めたとしても、サービスにおける規約内に文字数を含めるようにしてもよい。例えば、リンク先を示す情報を含めて１４０字以内になるようにメッセージを作成してもよい。

［１．４．１１取得したメッセージを解りやすく変換して出力する実施例］
本実施例は、メッセージ出力部１０７がメッセージを出力するときに、取得したメッセージそのものではなく、ユーザにとって解りやすいメッセージに変換して出力するものである。

すなわち、制御部１００が、新たに取得メッセージ情報にもとづき、新たなメッセージを生成し、出力する。

例えば、メッセージ出力部１０７は、メッセージをそのまま流用出来ない可能性があるため、その場合メッセージ中から事象を判定してメッセージを表示部１２０に表示する。

例えば、メッセージ出力部１０７は、「事故」に関するメッセージであれば「事故渋滞の情報」と表示する。また、メッセージ出力部１０７は、「あおり運転」に関するメッセージであれば「あおり運転が報告されました」とメッセージを表示する。このように、文中の内容を自動解析して、変換したメッセージを出力してもよい。これは、メッセージの部分をそのまま引用すると、クレームにある可能性もあるため、表現を変えて出力することができる。また、そのままのメッセージを表示すると、色々な表現を含むため独自の文言を作成し、出力してもよい。

また、関連するメッセージを１つのメッセージにまとめてもよい。例えば、同じ地域で同じ事故に関するメッセージは、１つのメッセージにまとめてもよい。また、メッセージに対して関連付いたメッセージ（例えば、返信されたメッセージ）であれば、１つのメッセージにまとめてもよい。

これらのメッセージをまとめメッセージとして管理してもよい。まとめメッセージは１つのスレッドとして表示することが可能である。まとめメッセージは、例えば、１つの関連する話題であり、１つの事象（例えば、事故や渋滞）に関するメッセージをまとめていてもよい。

また、ワードリスト列と、配列文言との対応関係リストを持っておき、メッセージ内の文字列がマッチしたら置き換えたメッセージを表示してもよい。

また、置き換えたメッセージは、メッセージ投稿部１０５により、サービスに投稿してもよい。このとき、更に投稿するメッセージには、投稿するユーザのアカウントに関する情報（例えば、アカウント名や、アカウントＩＤ）を含めてもよい。

例えば、図１２（Ｄ）に示すように、検索ワード、経過時間、住所、道路名称、詳細情報やアカウント、ハッシュタグ等を新たに生成し、メッセージ出力部１０７が表示部１２０にメッセージを出力してもよい。

このとき、電子機器１０は、既存の取締情報に併せて、上述したメッセージも表示してもよい。例えば、既存の取締情報がテロップ表示されているときに、上述したメッセージを連続して表示したり、交互に表したりしてもよい。

また、市区町村が解るため、メッセージ出力部１０７は、既存の取締情報と同様に、同じ市区町村の内容だけを表示してもよい。

また、メッセージ出力部１０７は、メッセージを単に表示するだけでなく、異なる表示と組み合わせてもよい。例えば、メッセージ出力部１０７は、住所、緯度経度、道路名称、ＩＣ・ＪＣＴ・ＳＡ・ＰＡ名、ランドマーク名等の場所が特定できるような情報が含まれている場合、地図上の場所や道路を点滅させたり、色を変えたり、ピン表示をしたりしてもよい。

また、メッセージ出力部１０７は、経過時間を合わせて出力してもよい。経過時間は、メッセージが投稿された日時から経過した時間を表示してもよい。また経過時間は、メッセージの事象の発生時刻を特定し、発生時刻からの経過からであってもよい。例えば、メッセージに「１５：１０事故発生」と含まれていれば、「１５：１０」を発生時刻としてもよい。

また、メッセージ出力部１０７は、経過時間に応じて表示態様を変化させてもよい。例えば、発生時間やメッセージ投稿時間から「Ｘ分前」「Ｘ分経過」と表示するだけでなく、道路の点滅の色を薄くしていったり、輝度を変えたりすることで、情報の劣化性を表現してもよい。また、表示されるメッセージの時間を特定範囲のものに限定してもよい。例えば、発生時刻や投稿時刻から１０時間までのメッセージを表示対象としてもよい。

また、メッセージの内容（事案）が過去のものへの言及である場合は、表示対象としなくてもよい。メッセージの内容（事案）が、事案の発生時点のものであるのか、事案の終了時点であるものかを判定してもよい。この場合、メッセージ出力部１０７は、メッセージの内容と、投稿日時とを併せて判定してもよい。

例えば、「昨日の天満橋の事故渋滞は酷かった」というメッセージが、今日投稿されている場合、メッセージ出力部１０７は、メッセージの投稿日が今日であれば、そのまま表示対象としてもよい。この場合、投稿日時をはっきりと表示させておいて、所定時間（例えば１０時間）は、表示対象とするとしてもよい。

また、メッセージの内容（事案）が過去のものであれば表示対象から除外してもよい。この場合「昨日の天満橋の事故渋滞は酷かった」というメッセージは「昨日」というキーワードがあるため表示対象から除外する。

また、一つの情報から関連するメッセージを取得し、事案の発生日時を特定してもよい。例えば、「天満橋の事故渋滞はひどかった」というメッセージの場合、当該メッセージに含まれる「天満橋」「事故渋滞」というキーワードに基づいてサービスから新たにメッセージを取得する。このとき、取得されたメッセージの内容や、投稿日時が過去のものであれば、当該メッセージを表示対象から除外してもよい。

また、キーワードに基づいて事案の発生日時を特定する為に検索する対象は、異なるサービスや、ニュースサイト、気象情報、渋滞情報（ＶＩＣＳ情報）等の情報を検索してもよい。

また、メッセージ出力部１０７は、メッセージの内容を解析して表示対象とするかを判定してもよい。例えば、メッセージの表現が「通れない」ではなく、「通れなかった」という表現の場合は、表示対象から除外してもよい。

ここで、メッセージ取得部１０６は、例えば、サービスのＡＰＩを使用して、検索ワードから関連するメッセージを取得する。メッセージ取得部１０６は、取得したメッセージを所定の形式（例えば、ＣＳＶ形式）で記憶部１９０に記憶する。

続いて、検索に引っかかりそうな語録（キーワード）を考えて、的確なメッセージを検索する。具体的には、キーワードを予め記憶部１９０に記憶し、当該キーワードで検索を行う。メッセージ出力部１０７は、キーワードを含むメッセージから表示用のメッセージを作成する。

具体的な例を説明する。例えば、メッセージングサービスとしてＴｗｉｔｔｅｒの場合、抽出元のtweets.jsonから、created_at、user.location、user.name、user.name、user.screen_name、user.followers_count、textなどをＣＳＶ形式で出力する。そして、メッセージ出力部１０７は、出力されたＣＳＶファイルから、「日時」「twitterネーム」「アカウント」「発生場所」「tweet」にあてはまるデータを抽出と解析をして、表示用のメッセージを作成する。これにより、電子機器１０で既存の公開取締情報のデータと同様の取扱いができ、同じように表示することができる。

ここでメッセージ出力部１０７は、メッセージを以下の方法で解析する。まず、住所データの解析として、メッセージ出力部１０７は、メッセージから都道府県（４７件）の確認、市区町村（１７１８件）の確認を行う。また、メッセージ出力部１０７は、町字がある可能性があることから、終端記号として「待ち」であれば、市区町村の名称として採用する。ここで、図１２（Ｃ）で示した、住所辞書１９９６を使用してもよい。

道路データの解析は、メッセージの中に、全国の道路名称が含まれているかを判定する。ここで、図１２（Ｃ）で示した、道路辞書１９９８を使用してもよい。

よく使用する文字列は、予め辞書として登録してもよい。メッセージ出力部１０７は、例えば、「事故渋滞」であれば、「単独事故、多重事故、人身事故、衝突事故、トラック事故、バイク事故等」の文字列が含まれればメッセージを採用してもよい。また、図１２（Ｃ）で示したワード辞書１９９４を使用してもよい。

なお、メッセージ出力部１０７は、例えば図１２のメッセージ制御部１０９を利用してメッセージを解析し、図１２（Ｄ）の形でメッセージを出力してもよい。

また、メッセージ出力部１０７は、関連する情報を表示してもよい。例えば、ニュースサイトから取得したニュース情報や、天気予報の情報等を併せてメッセージとして出力してもよい。

本実施例によれば、取得したメッセージに基づいて所定のフォーマットのメッセージに変換し、投稿することができる。これにより、他のユーザはサービスにおいてメッセージを確認した場合に、決まったフォーマットで出力されていることから、容易に情報を取得することができる。

また、ユーザは、取得したメッセージに変えて、住所、又は道路名称が含まれるメッセージを受け取ることができる。例えば、メッセージングサービスの各ユーザは、さまざまな内容でメッセージを投稿する。ユーザは、メッセージングサービスに投稿されたメッセージをそのままではなく、必要な情報が解りやすい出力にて確認することができる。ここで、住所は、市区町村名と町名との組み合わせとしてもよいが、都道府県名と市区町村名とするとよい。また、住所は、交差点名、施設名、又はランドマーク名といった、何れかの地域を表すものとするとよい。また、住所は、緯度経度情報や、マップコードのように、地域や地点を示す情報とするとよい。また、道路名称は、国道Ｘ号線、県道Ｘ号線といった名称や、明治通り、靖国通りといった道路名称、中央道、東名高速、首都高速といった自動車道の名称とするとよい。

また、ユーザは交通に関する情報が含まれるメッセージを受け取ることができる。ここで、例えば、交通に関する情報として「渋滞」「交通渋滞」「事故渋滞」「工事渋滞」といった渋滞に関する情報、「工事」「事故」「閉鎖」といった渋滞に関連する情報、「あおり運転」「危険運転」「取り締まり」「パトカー」といった安全運転に関する情報を含むとよい。また、交通に関する情報は、交通に影響を及ぼす内容とするとよく、「豪雨」「冠水」「火災」「地震」といった災害に関する情報を含むとよい。

また、ユーザはメッセージが投稿されてから経過した時間を確認することができる。したがって、ユーザはメッセージとともに、当該メッセージがいつ投稿されたか、どの程度過去のメッセージであるかを確認することができる。例えば、メッセージが例えば渋滞等の交通に関する事象を示す場合、その事象とともに、経過した時間を表示するとよい。このようにするとユーザは、交通に関する事象が発生していることを知ると共に、その事象がいつ発生したのか、事象が発生したと投稿されてからどの程度時間が経過しているのかを併せて確認することができる。

ここで、メッセージが投稿されてから経過した時間は、例えば、メッセージが投稿された日時を取得可能な場合、メッセージが投稿された日時と、現在との差から求めるとよい。また、例えば、メッセージに時間を示すキーワード（例えば、「昨日」「昨夜」や、「今日」「さっき」）から、経過した時間を求めるとよい。また、制御部は、メッセージを解析し、例えば、過去の文章（例えば、過去形の文章と判定された場合）には、過去の情報であることを出力するとよい。また、経過した時間は、例えば、具体的にＸ分前、Ｘ時間前といった経過時間でとしてもよいが、概ねの情報（例えば、「昨日」や、「以前に」）といった情報であってもよい。また、投稿されてから経過した時間により、メッセージの出力態様を変えるとよい。例えば、メッセージを表示する場合、出力用メッセージに含まれたメッセージが投稿されてから経過時間に基づいて、出力態様を変えるとよく、例えば、経過した時間が長いほど表示を薄くしたり、文字の大きさを小さくしたりといった表示の態様を変更するとよい。

［１．４．１２取得したメッセージの信頼性を判定する実施例］
本実施例は、メッセージ取得部１０６により取得したメッセージについて、制御部１００が信頼性のある内容かを判定する実施例である。制御部１００は、メッセージから取得可能な情報や、投稿者のアカウントの情報に基づいてメッセージの信頼度や、アカウントの信頼度を算出してもよい。そして、制御部１００は、算出した信頼度から、メッセージの信頼性や、アカウントの信頼性を判定してもよい。

例えば、メッセージ取得部１０６が取得したメッセージには、誤報やデマ関連のメッセージも含まれている。これらのフェイク情報については、例えば制御部１００は、メッセージを投稿した投稿者のアカウント情報を参考に判定してもよい。

例えば、制御部１００は、投稿したアカウントが企業アカウントの場合は、信頼性の高いメッセージと判定する。また、投稿したアカウントが、インフルエンサーであるアカウント（例えば、アカウントに関連付けられたアカウント（フォロワー数）が３０００以上等）であれば、信頼できるメッセージと判定する。

これらの信頼性の高いアカウントをリスト化し、記憶部１９０に記憶してもよい。制御部１００は、これらの信頼性の高いアカウントから投稿されたメッセージであれば有力情報であると判定する。メッセージ出力部１０７は、信頼性の高いアカウントであれば、メッセージを表示する。

また、メッセージ出力部１０７は、メッセージの信頼度に応じて出力する態様を変えてもよい。例えば、メッセージ出力部１０７は、信頼性が高いメッセージの場合は青色でメッセージを表示し、信頼性が低いメッセージの場合は黄色でメッセージを表示してもよい。また、その他にもメッセージ出力部１０７は、メッセージの信頼度に応じて、文字の濃さを変更したり、大きさを変更したり、スクロール速度を変更したりしてもよい。

また、アカウントが公式アカウントであれば、制御部１００は、信頼性高いアカウントと判定してもよい。また、この場合メッセージ出力部１０７は、公式アカウントであることを併せて出力してもよい。

また、制御部１００は、アカウントのアクティビティが相対的に低いアカウントからメッセージが投稿された場合は、信頼性の高いメッセージと判定してもよい。例えば、アクティビティが相対的に低いアカウントのメッセージから、急に事故等の情報が取得できた場合、アクティビティが高い人の情報よりも角度が高い情報として判定してもよい。

また、制御部１００は、メッセージに位置情報が付加されているメッセージは信頼度が高いと判定してもよい。また、制御部１００は、メッセージに所定のキーワードが付加されているメッセージは信頼度が高いと判定してもよい。例えば、制御部１００は、電子機器１０が出力したことをしめす署名が付加されたメッセージは信頼度が高いと判定してもよい。

このように、本実施例によれば、信頼性の高いメッセージに基づいて処理を実行することができる。サービスにおいては、様々なメッセージが含まれているため、必ずしも信頼性が高いとはいえない。しかし、本実施例によれば、アカウントに基づく信頼性や、投稿されたメッセージの信頼性を判定し、信頼性が高いと判定されたものに限定して処理を行うことができる。

また、単にメッセージを投稿したアカウントと関連付いているアカウントの数（フォロワー数）を取得し、出力してもよい。また、メッセージを投稿したアカウントと関連付いているアカウントの数として、フォロー数を取得し、出力してもよい。メッセージングサービスとしては、Ｔｗｉｔｔｅｒ等のソーシャルネットワーキングサービスとするとよい。このようにすると、ユーザは、第１のアカウントのフォロワー数や、フォロー数を受け取ることができる。

また、ユーザは、投稿したユーザのアカウントと関連付いているアカウント数が多い場合は、信頼性の高いアカウントではないかと判断することができる。例えば、メッセージングサービスが、Ｔｗｉｔｔｅｒ等のソーシャルネットワーキングサービスのとき、例えば、メッセージを投稿したアカウントのフォロワー数が所定の数より多いアカウントの場合は、ユーザは信頼性の高いアカウントから投稿されたメッセージであると判断することができる。また、ユーザは、例えば第１のアカウントがインフルエンサー等のアカウントと判断できた場合は、信頼性が高いアカウントから投稿されたメッセージと判断してもよい。

このようにすれば、ユーザは、投稿されたメッセージと共に、メッセージを投稿したアカウントのフォロワー数又はフォロー数を受け取ることができる。例えば、メッセージを投稿したアカウントの影響力（例えば、多くのフォロワー数がいるインフルエンサーのアカウント等）に基づいて、ユーザはメッセージやアカウントの信頼性を判定することができる。また、アカウントのフォロー数やフォロワー数に基づいてアカウントや、当該アカウントが投稿したメッセージの信頼性を判定し、その旨を出力する機能を有するとよい。例えば、フォロワー数の方がフォロー数より所定の割合以上多い場合は、信頼性の高いアカウントと判定するとよい。
このようにすれば、ユーザは、メッセージを投稿したアカウントが、設定された企業アカウントであるか、又はメッセージングサービスが認証した公式のアカウントであるかを知ることができる。ユーザは、個人が所有するアカウントと比較して、企業アカウントの法が信頼性の高いメッセージと判定することができる。このようにすると、メッセージを投稿したアカウントが企業アカウントや、予め設定された企業アカウントである旨が出力されることで、ユーザは信頼性の高いメッセージと判定することができる。例えば、ユーザが予め企業アカウントを設定できる機能を備えるとよく、このようにすると、メッセージを投稿したユーザが企業アカウントであることを知ることができる。ここで、企業アカウントとは、企業がプロモーションや、広報活動を目的として所有するアカウントとするとよく、当該企業が公式に運用したり、１又は複数を社員が企業名で運用をしたりしているアカウントとするとよい。また、企業アカウントは、民間企業のアカウントとしてもよいが、団体のアカウントとして、国、地方公共団体の役所、機関や、財団法人、医療法人、学校法人、ＮＰＯ法人等といった団体のアカウント、法人のアカウントとするとよい。

例えば、特定のアカウント（例えば、ＮＥＸＣＯ）を信頼できるアカウントとしてユーザが登録可能なＤＢ（Data Base）を、自装置の内部又は外部に持っているとよい。また、例えば、アカウント情報のプロフィールを解析することで、企業アカウントであることを特定するとよい。

また、メッセージングサービスが、例えば、認証した公式アカウント（例えば、当該アカウントに公式バッジが表示されているアカウント）の場合、異なる出力態様とするとよい。このようにすると、ユーザは、投稿者のアカウントが公式アカウントである場合には、信頼性が高いと判断している場合に、公式アカウントを知ることで、メッセージの信頼性の判定に利用できる。

また、ユーザは信頼性が高いメッセージを優先的に確認することができる。例えば、メッセージングサービスに投稿されているメッセージには、正しい情報と、誤った情報とが混在している。また、例えば、メッセージングサービスに投稿されているメッセージは、事実だけを含めているメッセージと、投稿したユーザの感想や、関係のないメッセージが混在している。このように、メッセージングサービスに投稿されているメッセージには、交通に関連しないメッセージ、事実に反するメッセージといった信頼性の低いメッセージや、事実ではあるが事象が発生してから時間が経過してしまった内容のメッセージ等のいわゆるノイズとなるメッセージが含まれていることがある。メッセージの信頼性を判定することで、ノイズとなるメッセージの出力を抑制したり、ノイズでないメッセージの優先度を高くしたりすることができる。このようにすれば、ユーザは、ユーザにとって必要となるノイズ以外のメッセージを優先的に確認することができる。

［１．４．１３投稿したメッセージからユーザの評価を行う実施例］
本実施例は、投稿したメッセージからユーザ（ドライバー）の評価を行う実施例である。制御部１００は、ユーザが投稿したメッセージの数や、メッセージしたタイミングにより、メンタルサイクル（心理状況）を判定する。

例えば、メッセージ投稿部１０５が投稿したメッセージをメッセージ情報記憶領域１９６に記憶する。そして、制御部１００は、メッセージを解析し、交通事故や危険運転の可能性を判定したり、運転の評価を行う。すなわち、本実施形態において投稿されるメッセージは、交通関連の内容が多いことから、交通事故や危険運転の多い時期のサイクルを判定することができる。例えば、量的な変化を時系列に改正し、例えば、運転からＸ分後にリスクがあると判定したり、道路（例えば、高速道路、一般道）毎にリスクを判定してもよい。具体的には、制御部１００は、「イライラ」と含まれているメッセージを抽出する。当該メッセージが、高速道路を走行中に多い場合、高速道路での運転の注意を促す報知を行ってもよい。これにより、ユーザに対して事故防止のきっかけとなる。

また、制御部１００は、メッセージの投稿した時刻に基づき、活動周期からユーザの活動パターンを評価してもよい。例えば、制御部１００は、６時から２１時までのメッセージが多ければ、ユーザが当該時間に活動していることがわかる。また、昼間に投稿されたメッセージが多い場合、制御部１００は昼休憩であると判定してもよい。

なお、本実施例において、制御部１００はメッセージ投稿部１０５が投稿したメッセージを解析しているが、例えばメッセージ取得部１０６が取得したメッセージを解析してもよい。この場合、電子機器１０に記憶されているアカウント情報のアカウントのメッセージを解析してもよいし、他人のアカウントに基づいて解析してもよい。

本実施例によれば、サービスに投稿したメッセージに基づいて、ユーザの心理状態や、安全運転を行っているか等、さまざまな評価を行うことができる。例えば、評価対象を複数にすることにより、例えば安全運転ランキング等を行うこともできる。ユーザも、投稿内容から気楽に運転傾向等を分析することができる。

［１．４．１４メッセージの出力と併せて音声認識を行う実施例］
本実施例は、メッセージの表示と併せて音声認識を組み合わせる実施例である。例えば、電子機器１０からメッセージを投稿する場合、自動的にメッセージを作成する場合の他に、任意のメッセージを入力可能とする。また、電子機器１０にメッセージを出力する場合、メッセージを表示するだけでなく、音声として出力可能とする。

この場合、メッセージ投稿部１０５は、ユーザは電子機器１０のソフトウェアキーボードから入力されたメッセージや、選択リストから選択された文言に基づいて生成されたメッセージを投稿する。

更にメッセージ投稿部１０５は、音声認識により投稿するメッセージを生成してもよい。例えば、制御部１００は、音声として入力された言葉を音声認識して文字列に変換し、メッセージを生成してもよい。また、制御部１００は、表示部１２０に「事故」「渋滞」「危険運転」「災害」のカテゴリーを表示し、画面上の文言リストから選んでメッセージを作成しても良い。このとき、制御部１００は、ユーザから入力された音声によりカテゴリーを選択してもよい。また、制御部１００は、このときメッセージが「交差点で渋滞しています」と認識された場合「渋滞」というキーワードから「渋滞」のカテゴリーを選択してもよい。

また、メッセージ投稿部１０５は、上述した文言リストにないカテゴリーになりうる言葉が音声入力された場合、当該音声入力された言葉を音声認識し、カテゴリーとして新たに選択してもよい。

また、画面遷移等を音声操作でおこなってもよい。例えば、メッセージ出力部１０７がメッセージを出力中に、ユーザから音声入力として「次のメッセージ」と入力された場合は、現在のメッセージの出力を中断して、次のメッセージを出力してもよい。

また、音声メッセージを出力中又は出力した直後に、今のメッセージの続報の報知を希望するか否かを、ユーザの音声入力により入力してもよい。

また、メッセージ出力部１０７は、メッセージを表示（例えばテロップによる表示）を行うのと併せて音声で出力してもよい。メッセージを表示するか、音声出力するかは、ユーザが選択可能としてもよい。また、メッセージ出力部１０７は、メッセージの内容に応じて、メッセージを表示するか、音声出力するかを切り替えてもよい。

また、メッセージ出力部１０７は、メッセージを音声出力するときに、投稿カテゴリーをその都度音声出力してもよい。

また、音声認識は、他の装置によって行われてもよい。例えば、電子機器１０が、スマートフォン等と接続可能な場合、スマートフォンにより音声を入力し、音声を認識する。そして、スマートフォンから音声認識の結果を、電子機器１０に送信してもよい。

このように、本実施例によれば、電子機器１０において表示するだけでなく、音声による出力や、音声認識による操作も行うことができる。とくに電子機器１０が車載用装置でドライバーが使用する場合は、操作ができる画面が限られる。そこで、音声認識を利用することで、ユーザであるドライバーは手をはなすことなく操作が可能であり、安全運転に資することとなる。

また、ユーザはメッセージを音声にて確認することができる。ユーザは、音声でメッセージを確認できることから、例えば運転中であっても、電子機器を注視することなく、メッセージを確認することができる。したがって、ユーザは安全にメッセージを確認することができる。上述した出力態様や出力方法を変更することは、音声部から出力する音声の大きさを変える、声色を変える、又は音声を出力する速度を変えるといった方法とするとよい。また、音声を出力する方法は、例えば、警告音や、音楽を出力するといった方法とするとよい。

［１．４．１５詳細なメッセージや関連するメッセージを出力する実施例］
本実施例は、メッセージ出力部１０７が、更に詳細なメッセージや、関連するメッセージを表示させる方法における実施例である。

例えば、メッセージ出力部１０７がメッセージを出力したときに、まとめたメッセージを出力する。例えば、ハッシュタグに「＃中央道」と含まれた事故のメッセージの場合、制御部１００は、「中央道事故Ｘ件」のようにまとめてメッセージを出力してもよい。

この場合、制御部１００は、併せてハッシュタグ「＃中央道」を表示する。ユーザがハッシュタグを選択すると、メッセージ出力部１０７は、まとまる前のメッセージを順次表示してもよい。

また、制御部１００は、メッセージ自体が選択された場合に、まとめたメッセージの元になっているメッセージを切り替えて表示してもよい。

また、制御部１００は、表示部１２０の表示領域が限られている（狭い）場合、他の装置で表示できるようにしてもよい。例えば、制御部１００は、まとめて表示する画面に誘導する情報を含めた２次元コードを表示してもよい。ユーザは、例えばスマートフォン等の端末装置において、この２次元コードを読み込むことにより、メッセージの詳細を表示してもよい。

また、２次元コードには、まとめメッセージを一覧表示するリンクを含めてもよい。まとめメッセージは、例えば所定のメッセージに対する返信メッセージ（リプライ）がまとめられているメッセージである。このまとめメッセージが一覧で表示できるＵＲＬを２次元コードに含めておく。

スマートフォン等の端末装置において、この２次元コードを読み込むことにより、まとめメッセージを端末装置で一覧表示することができる。

また、まとめメッセージ新たなメッセージが追加された場合、電子機器１０はメッセージが追加されたことを表示してもよい。例えば、メッセージ取得部１０６が取得したメッセージがまとめツイートの１つである場合、新たなメッセージが追加したことを表示部１２０に表示してもよい。また、このとき併せて２次元コードを表示してもよい。

本実施例によれば、まとめメッセージとして関連するメッセージをまとめることが可能である。メッセージングサービスは、例えば返信（リプライ）機能を利用することで、メッセージをまとめることが可能である。本実施例は、返信（リプライ）機能を活用することで、関連するメッセージをまとめることが可能である。

また、ユーザに、関連するメッセージを表示させたい場合にはリンクを選択することで、その関連するメッセージを見ることができる。リンクが選択されると、関連するメッセージを一覧で表示するようにするとよい。また、関連するメッセージをスレッド表示にするとよい。このようにすると、ユーザは、閲覧性の高い状態でメッセージを見ることができる。

また、ユーザは、例えばスマートフォン等の端末装置において、２次元コードを読み込むことにより、リンクに関連付けられている、関連するメッセージを確認ことができる。例えば、２次元コードに含まれているリンクから、関連メッセージを一覧表示するサイトにジャンプして、端末装置に表示させるようにするとよい。なお、２次元コード以外の、情報を符号化した符号化画像を用いることとしてもよい。

また、ユーザは、投稿メッセージを参照することで、取得したメッセージの内容を確認することができる。このとき、取得したメッセージに含まれる全ての内容を含めてもよいが、一部の内容だけを含めるとい。ユーザは、投稿メッセージに取得したメッセージが含まれることから、投稿したユーザがどのような内容でメッセージを投稿したかを容易に確認することができる。

また、ユーザは関連するメッセージは集約された状態で確認することができる。関連するメッセージとは、例えば、メッセージングサービスで、１のメッセージに対して他のメッセージが何らかの関連を持っているものとするとよい。例えば、メッセージングサービスとしてソーシャルネットワーキングサービスのＴｗｉｔｔｅｒ等とするとく、この場合、返信（リプライ）、再投稿（リツイート）等であってもよい。関連するメッセージが集約されることで、ユーザは似たようなメッセージを何度も確認しなくてよい。例えば、再投稿メッセージの場合は、再投稿された分、同じようなメッセージが出力されてしまう。そこで、例えば、再投稿元となるメッセージを１回だけ出力するようにすると、ユーザは関連するメッセージのうち１つだけを確認することができる。

また、ここで集約して出力するとは、複数のメッセージをまとめて出力してもよいことをいう。まとめて出力することは、例えば、代表となる１つのメッセージだけを表示することとするとよい。また、代表となる１つのメッセージとして、最初に投稿されたメッセージを選択してもよいが、新たにメッセージを生成し、出力するとよい。

また、ユーザは１つのメッセージに対して返信が行われているメッセージは集約した状態で確認することができる。例えば、あるメッセージに返信（例えばリプライ）されたメッセージは、返信元のメッセージのみを出力してもよいが、返信（例えばリプライ）されたメッセージを表示しないようにするとよい。メッセージングサービスの利用方法として、例えば、返信があったメッセージは、返信元のメッセージの方が、重要な情報を含むことが多い。したがって、返信したがって、返信元のメッセージを出力するとよい。また、１つのメッセージに対してスレッドのようにメッセージが返信されている場合でも、関連するメッセージとして集約するとよい。

また、ユーザは、再投稿されているメッセージは集約して受け取ることができる。例えば１つのメッセージに対する再投稿メッセージ（例えばリツイート）として、再投稿元（例えばリツイート元）のメッセージのみを出力するとよく、この場合、再投稿したメッセージ（例えばリツイート）は表示されないようにすることができる。一般的に、再投稿（例えばリツイート）されたメッセージは、再投稿元（例えばリツイート元）のメッセージとほぼ同内容のため、再投稿元（例えばリツイート元）のメッセージを表示するとよい。

また、ユーザは、集約元となるメッセージの一部又は全部を受け取ることができる。例えば集約したメッセージのうち集約元となったメッセージ全部（例えば、そのまま）出力するとよいが、集約元となるメッセージの一部の文言をメッセージに含めて出力してもよい。ユーザは、例えば、メッセージが集約された場合に、集約元のメッセージがそのまま出力されたり、一部が出力されたりすると、どのようなメッセージが集約されたかを確認することができる。

また、ユーザはメッセージを集約したメッセージの件数を併せて確認することができる。例えば、メッセージが再投稿（例えば、リツイート）された件数や、返信がされている件数（例えば、リプライされた件数）をメッセージと併せて出力するとよい。ユーザは、メッセージと、集約したメッセージの件数を確認することで、より大きな反応があるメッセージであることを認識することができる。例えば、ユーザは、大きな反応があるメッセージの場合は、重要なメッセージや、信頼性が高いメッセージであると、認識することができる。

また、ユーザは、メッセージの出力態様に応じて、当該メッセージの再投稿回数がどの程度であるかを認識することができる。制御部は、例えば、メッセージの再投稿回数（リプライ数）が多い場合には、メッセージのフォントの種類、又は大きさを変更したり、文字の色を変更したりするとよい。また、メッセージの再投稿回数（リプライ数）に応じて、メッセージの出力態様を徐々に変化させるとよい。このようにすると、ユーザは、当該メッセージがどの程度再投稿されているのかを確認することができる。例えば、再投稿回数が多くなると、文字の色が白から赤色に変化する構成とするとよく、この場合、ユーザは、文字の色が赤色に近い程再投稿回数が多い（リプライ数が多い）と認識することができる。

また、ユーザは、メッセージの大きさによって、メッセージの再投稿回数がどの程度であるかを認識することができる。例えば、メッセージと併せて再投稿回数を表示するとよく、メッセージの大きさとして、文字の大きさ、又は表示領域の大きさにより、再投稿回数が多いか、少ないかを表示しもよい。また、ユーザは、再投稿回数が多いメッセージは、多くの人に拡散されているメッセージであり、重要なメッセージとして認識することができる。したがって、再投稿回数が多い重要なメッセージほど、メッセージが大きく表示されることで、ユーザはメッセージの重要性を直感的に把握することができる。

また、ユーザは２次元コードを利用して、集約されたメッセージを確認することができる。例えば、ユーザは別の端末装置（スマートフォンや、タブレット等）に２次元コードを読み取らせる。端末装置は、２次元コードに示された情報（例えば、ＵＲＬ等）に基づいて、集約されたメッセージを表示する。ここで２次元コードには、例えば集約されたメッセージを一覧表示するＵＲＬ等が含まれているとよい。また、集約されたメッセージを、例えば１つずつ順次表示してもよいが、スレッド状に表示するとてもよい。なお、２次元コード以外の、情報を符号化した符号化画像を用いることとしてもよい。

［１．４．１６メッセージの出力方法を切り替える実施例］
本実施例は、メッセージの出力するときの出力方法を切り替える実施例である。

メッセージ出力部１０７は、メッセージに含まれるハッシュタグにより出力する方法を切り替える。取得するメッセージには、事案を区別するための対象種別のハッシュタグや、事案が生じている地名がハッシュタグに含まれている場合がある。ここで、地名等はハッシュタグのみに含まれているものを対象としてもよい。

例えば、現在の道路状況を知らせるメッセージには、場所を示す言葉をハッシュタグにすることが多い。

メッセージＡ：「＃事故渋滞＃阪神高速＃守口線」
メッセージＢ：「＃大阪＃臨海＃事故渋滞＃府道２９号南向き
＃高石大橋付近」
メッセージＣ：「＃松本市＃事故渋滞＃なんて日だ」
メッセージＤ：「＃アクアライン＃事故渋滞」
メッセージＥ：「＃姫路バイパス＃事故渋滞＃祝日って忘れていた人
＃祝日の土曜日」
このようなメッセージに対して、制御部１００は、同一のキーワードに対して、ハッシュタグあり検索と、ハッシュタグなし検索を実行する。そして、ハッシュタグがあるメッセージに基づく情報と、ハッシュタグがないメッセージに基づく情報とは異なる報知態様で出力してもよい。

また、メッセージ出力部１０７がメッセージを出力する対象（報知対象）とする投稿日時の範囲を、種類毎（例えばハッシュタグ毎）に異なるものとしてもよい。この投稿知事の範囲は、種類毎に設定できるようにしてもよい。例えば、「＃事故渋滞」の場合は１日と、「＃取締」については７日と、取得するメッセージの範囲を設定してもよい。

また、メッセージの投稿者が、電子機器１０のユーザと関連のあるアカウント（フォローしている人のメッセージ）は、メッセージ出力部１０７は、異なる態様で出力してもよい。例えば、読み上げする音声（ＴＴＳ）の声質を変えてもよいし、読み上げる速度を変えてもよいし、音量を変えてもよい。

また、発光部１８０を利用して報知をする場合、メッセージ出力部１０７は、発行するＬＥＤの色や発光パターンを変更してもよい。

これにより、ユーザが運転中であっても、単なる事故等のメッセージなのか、フォローしている人のメッセージなのかを容易に判別することができる。また、ユーザは事故等の情報を容易に注目することができる。

また、メッセージ出力部１０７は、自分のメッセージに対するアクション（例えば、返信（返信ツイート）や、再投稿（リツイート）、評価（いいね））と、それ以外のアクションとは異なる態様で出力してもよい。

また、メッセージ出力部１０７は、更に自分のメッセージに対するアクションの場合は、音楽を流す（所定の音声ファイルを再生する）ことをしてもよい。この場合、メッセージ出力部１０７は、単なるメッセージを出力する場合は、音楽を流すことをしなくてもよい。

本実施例によれば、メッセージに含まれているタグや、アクションに応じて必要な報知をすることができる。メッセージングサービスには多くのメッセージが投稿されており、単純に表示しているだけでは見落とす可能性が高い。そこで、例えば自分宛のアクションの場合は異なる報知を行うことで、自分宛のアクションを見落とすことを無くすことができる。また、メッセージングサービスにおけるハッシュタグを活用することで、サービスから迅速に情報を取得することができる。とくに、ハッシュタグは関連するメッセージが含まれている可能性が高いため、ハッシュタグを有効に活用することで、効果的な報知を行うことができる。

本実施例によれば、ユーザは、メッセージを投稿したユーザのアカウントが、自分自身のアカウントと関連付けられているかどうかの情報を受け取ることができる。メッセージングサービスが、Ｔｗｉｔｔｅｒ等のソーシャルネットワーキングサービスとするとよい。このようにすると、ユーザは、メッセージを投稿したユーザをフォローしているのか、当該ユーザからフォローされているのかといった情報を知ることをできる。関連付けられているかどうかの情報として、友達のアカウントであることや、知り合いのアカウントであることを特定可能な情報とするとよい。このようにすると、ユーザは、自分の第２のアカウントと第１のアカウントが関連付いている場合は、全く関係のないアカウントからの投稿ではないことが解る。したがって、ユーザは信頼性の高いアカウントをフォローすることができる。そのとき、ユーザは、第２のメッセージを投稿したアカウントがフォローしているアカウントであれば、信頼性の高いアカウントから投稿されたメッセージであると判断することができる。

また、例えば、メッセージの出力先として音声出力部から音声を出力するとよく、例えば音声の音量、声色、出力速度といった出力態様を変化させるとよい。このようにすると、ユーザはアカウントの情報を把握しやすくなる。具体的には、例えば、ユーザと関連しないアカウントの場合は、男性の声でメッセージを出力し、例えば、ユーザと関連するアカウントの場合は、女性の声でメッセージを出力するといった構成にするとよい。

また、投稿されたメッセージにおいて、メッセージの投稿者が運転中である場合は、その旨を出力してもよい。ユーザはメッセージを受け取るときに、運転中に投稿されたメッセージであることを確認することができる。例えば、このメッセージは渋滞に関するメッセージとするとよい。実際に運転している者が発信したメッセージは信頼性が高いと判断する場合、ユーザは表示されている渋滞に関するメッセージの中から、信頼性の高いメッセージを確認することができる。

また、ユーザはメッセージの出力方法によって、取得したメッセージの件数がどの程度であるかを認識することができる。例えば、取得したメッセージをスクロール表示しているときは、スクロール表示する速度を切り替えるとよい。また、例えば、取得したメッセージを所定の領域に表示する場合に、前記メッセージの件数に応じてフォントの大きさを変えたり、表示する領域の大きさを変えたりするとよい。また、取得したメッセージを音声出力するときは、音声の出力速度を取得したメッセージ件数に応じて変えるとよい。このように、メッセージ件数に応じて、メッセージの出力方法が変わるため、ユーザは取得したメッセージを見たり、聞いたりするときに、取得したメッセージ件数が多いか少ないかの程度も認識することができる。

また、ユーザは発光部の発光パターンによって、メッセージの再投稿回数がどの程度であるかを認識することができる。これは、装置に発光部を設けているときに、再投稿回数に応じて発光部の発光方法が変化することになる。例えば、発光方法としては、点滅回数を変化させたり、輝度を変化させたり、色を変化させたりするとよい。例えば、再投稿回数が多いメッセージの場合は、発光の頻度を高くするとよい。このようにすると、ユーザに注意喚起をすることができる。また、ユーザは発光部の発光パターンによってメッセージの再投稿回数の目安を認識することができる。例えば表示されているメッセージのうち、再投稿回数が多いメッセージを表示した場合に、再投稿回数が多い旨を示す発光パターンを出力するとよい。このようにすると、ユーザは、わざわざメッセージを読むことなく、再投稿回数が多いメッセージであるか否かを認識することができる。

［１．４．１７取得したメッセージが再投稿メッセージの場合の実施例］
本実施例は、事故等の情報として、メッセージは少なくとも原文の一部を用いてそのまま出力し、再投稿はそのまま出力しない実施例である。

メッセージ出力部１０７は、取得したメッセージ情報が再投稿によるメッセージの場合、そのまま出力してもよいし、メッセージを一部のみ出力してもよい。また、メッセージ出力部１０７は、取得したメッセージが他のユーザのメッセージを引用して含んでいる場合、引用部分はメッセージを出力しなかったり、一部省略してメッセージを出力したり、所定文言に置き換えてメッセージを出力してもよい。

また、メッセージ出力部１０７は、再投稿（リツイート）の種類に応じてメッセージの出力方法を切り替えてもよい。例えば、事故等のメッセージに対する再投稿があったとき、制御部１００は、再投稿数を所定の方法で集計した数とともにメッセージを出力してもよい。また、制御部１００は、集計は一定時間間隔毎に集計してもよい。

例えば、メッセージ出力部１０７は、
「「矢作橋で事故みたい。大渋滞で遅刻だよ」のメッセージがあります」
「さきほどの「矢作橋で事故」のメッセージが、この５分間で３回再投稿されています」と出力してもよい。

また、更に５分後に、メッセージ出力部１０７は、
「さきほどの「矢作橋で事故」のメッセージが、この１０分間で３０回再投稿されています」
と定期的にメッセージを出力してもよい。

また、同一のキーワード（例えば、地名等の固有名詞）が含まれるメッセージが所定の時間範囲内にあるときは、関連メッセージとしてメッセージを出力（報知）してもよい。

例えば、上述した報知の後に、メッセージ出力部１０７は、
「１２分前の「矢作橋で事故」の関連ツイートがありました。「矢作橋に救急車来たけど現場まで入れず困ってる」
とメッセージを出力してもよい。

また、同一のキーワード（例えば、地名等の固有名詞）が含まれる新規のメッセージ一定時間範囲内に所定数以上あるときには、メッセージ出力部１０７は、関連ツイートとしてその数を出力（報知）してもよい。

このとき、メッセージの再投稿や引用の元となったメッセージの出力を行うか否かをユーザが選択してもよい。

例えば、ユーザがメッセージを音声出力すると指示をした場合、メッセージ出力部１０７は、ユーザからの読み上げ指示があったと判定し、メッセージを音声出力してもよい。

例えば、制御部１００は「５分前の「矢作橋で事故」の関連メッセージが１２件あります。読み上げますか？」と音声出力部１３０から出力する。ユーザが「読み上げる」ことを音声操作や、タッチ操作で入力すると、音声出力部は関連メッセージを読み上げる。

また、メッセージ出力部１０７は、再投稿メッセージや関連メッセージ等の回数の時間的遷移を種類別・累計などのグラフ等で表示してもよい。メッセージ出力部１０７は、このグラフをメッセージの読み上げ時に表示してもよい。また、メッセージ出力部１０７は、メッセージを表示する場合は、表示するメッセージと併せてグラフ等を表示してもよい。

また、メッセージ出力部１０７は、再投稿メッセージや、関連メッセージの回数が多いほど目立つように出力（報知）してもよい。

例えば、メッセージ出力部１０７は、表示するメッセージの文字サイズを拡大して表示したり、発光部１８０の発光の頻度をあげていったりしてもよい。また、メッセージ出力部１０７は、発光部１８０のＬＥＤの色を青→黄色→赤と遷移させたり、音声出力部１３０から出力される音を「ぽーん」から「ピロリロピロリロ」に変更してもよい。

さらに、投稿されたメッセージや、メッセージに含まれている事案が発生した場所が解る場合、上述した報知の制御と併せて、その場所への接近状態も加味して、目立つ報知とするとよい。

このように、本実施例によれば、取得したメッセージがリプライ（再投稿）の場合は、まとめてメッセージを出力してもよい。とくに、サービスにおいては、再投稿（リツイート）が多いメッセージは重要度が高いと判定してもよい。また、再投稿の回数などを含めて出力することで、他のユーザからどの程度重要なメッセージであるかを認識させてもよい。

また、ユーザは、投稿メッセージには、再投稿によるメッセージの内容を見なくすることができる。一般的に、再投稿によるメッセージは、再投稿の対象となったメッセージと同一内容を含んでいる。したがって、再投稿のメッセージが含まれることで、同じ内容が表示されるといったことを防ぐことができる。メッセージングサービスとして、例えば、ソーシャルネットワーキングシステムとしてのＴｗｉｔｔｅｒ等とするとよい。Ｔｗｉｔｔｅｒにおいて、再投稿によるメッセージは、リツイートのことである。

また、ユーザは、取得したメッセージの中に、再投稿の対象となっているメッセージある場合、再投稿された回数を確認ことで、そのメッセージがどの程度拡散されているかを認識することができる。一般的に、再投稿の数が大きければ、信頼性の高いメッセージとして評価することができる。

また、ユーザが、再投稿された回数の遷移がグラフによる表示されることで、どのような拡散の遷移があったかを視覚的に容易に把握することができる。

また、ユーザは、再投稿メッセージを受け取らないようにすることができ、その分だけ、重複した内容のメッセージの受け取りを減らすことにしてもよい。例えば、再投稿メッセージ以外のメッセージを取得する機能を備えるとよい。このようにすると、再投稿メッセージ以外のメッセージをユーザが確認できないといった事態を抑制することができる。例えば、ある投稿メッセージの再投稿メッセージが複数行われた場合、再投稿メッセージは出力されないから、ユーザは重複した内容のメッセージを受け取ることを抑制することができる。また、メッセージの再投稿が様々なユーザにより行われると、同じメッセージが繰り返し再出力されてしまう。ユーザは、このような同じ再投稿メッセージが繰り返し確認しなければならないといった状態を避けることができる。

メッセージングサービスとして、例えばソーシャルネットワークサービスであるＴｗｉｔｔｅｒ等とするとよく、再投稿メッセージはリツイートのメッセージとするとよい。また、メッセージに「ＲＴ」等の特定の文字列が含まれているメッセージをリツイートのメッセージとするとよい。また、例えば、再投稿メッセージは、引用リツイートを含むとよい。例えば、「ＲＴ」に続くメッセージ以外にも他のメッセージが含まれていたり、「ＱＴ」が含まれているメッセージを引用リツイートと判定するとよい。また、例えば、当該メッセージとして出力しない部分は、「ＲＴ」に続くメッセージ部分をメッセージとして出力しない構成とするとよい。

［１．４．１８新たに出力したメッセージを出力する実施例］
本実施例は、前回まで出力済のメッセージを除いた新しいメッセージを出力する実施例である。

例えば、制御部１００は、一定時間間隔（例えば１日１回）、ユーザが登録したキーワードでサービスにおいて取得したメッセージのうち、前回までに出力報知済みの検索結果を除いた新しいメッセージを出力してもよい。

また、制御部１００は、例えば電子機器１０の電源投入時に、前回から今回までの間に新しく取得したメッセージを出力してもよい。例えば、電源投入時に、制御部１００は、新しいメッセージを音声として出力しても（読み上げても）よい。

また、制御部１００は、メッセージを出力する前に枕詞を出力してもよい。例えば、「登録キーワード「工事渋滞」での、今日の新しいメッセージを読み上げます」と、先に出力してもよい。

本実施例によれば、予め定められたキーワードに基づいて、一定間隔で報知することができる。したがって、車両を最初に使ったとき等に、交通関連の情報を配信したり、一般のニュースに関する情報等を配信したりしてもよい。

［１．４．１９アカウントに対する処理を行う実施例］
本実施例は、メッセージを出力するときに、出力するメッセージの投稿者（アカウント）に応じて、付加的なメッセージを出力したり、アカウントに対する処理を行う実施例である。

例えば、出力するメッセージを投稿したアカウントと、電子機器１０のユーザのアカウントが関連付けられていない場合（例えば、ユーザのアカウントでフォローしていないアカウントの場合）、当該アカウントのプロフィールの文言を音声出力してもよい。

また、制御部１００は、メッセージ出力部１０７がメッセージを出力中や、メッセージを出力後に、メッセージを投稿したアカウントと、ユーザのアカウントを関連付ける（フォローする）ことを指示入力したり、自動で関連付けたりする（フォローする）ことにしてもよい。

これにより、例えば、電子機器１０において、取得したメッセージが音声出力されるとき、制御部１００は、当該メッセージを投稿したアカウントを、電子機器１０を利用しているユーザのアカウントがフォローしている（関連付いている）かを判定する。そして、制御部１００は、ユーザのアカウントをフォローしていないと判定した場合、メッセージを音声出力中又は音声出力後に、ユーザにアカウントをフォローしていない旨を報知したり、フォローしていないユーザのプロフィールを音声で出力したりしてもよい。また、制御部１００は、当該フォローしていないユーザをフォローするか確認したり、自動的にフォローしたりしてもよい。また、それ以外にも、例えば制御部１００は、当該フォローしていないユーザをリストに追加したりしてもよい。

また、ユーザの設定により関連付け（フォロー）の仕方を変更してもよい。例えば、通常のフォローでは、趣味などの今後もメッセージを取得対象としたい人に選択することがおおい。したがって、一度フォローをすると、フォローを外すことは少ない。一方、事故などのニュース情報に感心がある期間が駆られている。

そこで、制御部１００は、関連するアカウントと抽出し、グループ（例えば、フォローグループやリスト）に一時的に登録することにしてもよい。

すなわち、サービスで提供している関連付け（フォロー）の機能の他に、記憶部１９０で関連するアカウントに関する情報を記憶してもよい。

本実施例によれば、ユーザは、メッセージを投稿した第１のアカウントに関する情報を受け取ることができる。第１のアカウントに関する情報としては、メッセージングサービスで扱われている情報とするとよく、例えば、アカウント名、アカウントＩＤといったアカウントを識別できる情報、アカウントに関連付けられた画像、アカウントの詳細情報、及びアカウントのプロフィール情報の少なくともいずれかとするとよい。このようにすると、ユーザは誰がメッセージを投稿したか、又はアカウントの持ち主に関する情報を把握することができる。

また、ユーザは、メッセージを投稿したアカウントが自分のアカウントと関連付けられていないアカウントの場合には、メッセージを投稿したアカウントに関する情報を受け取ることができる。ユーザのアカウントと、メッセージを投稿したアカウントが関連付けられていないとは、例えば、ソーシャルネットワークサービスにおいて友達関係になっていない場合や、フォロー関係になっていない場合とするとよい。メッセージを投稿したアカウントが関連付けられていないため、ユーザは当該アカウントに関する情報を得ることができる。このようにすると、どのようなユーザから投稿されたメッセージであるかをユーザは確認することができる。ここで、アカウントに関する情報としては、例えば、メッセージを投稿したユーザの居住地、誕生日、趣味等とするとよい。

また、ユーザは、メッセージを投稿したアカウントに関する情報として、プロフィールに関する情報、フォロワー数に関する情報、及びフォロー数に関する情報等を１又は複数受け取り、第１のアカウントに関する情報を把握することができる。

例えば、メッセージを投稿したユーザのプロフィール（例えば、居住地域、趣味、好きなもの）といったことを併せて出力するとよい。また、フォロワー数に関する情報や、フォロー数に関する情報を、それぞれ出力してもよいし、併せて複数の情報を出力するとよい。このようにすると、ユーザは、メッセージを投稿したアカウントに関する情報を取得することができる。

また、ユーザは、メッセージを投稿したユーザのアカウントが関連付けられていない場合に、メッセージを投稿した第１のアカウントを関連付ける又は関連付けることをレコメンドする情報を受け取ることができる。ユーザは、この情報に基づいて関連付けるかどうかを判断したり、関連付けたりすることができる。例えば、ユーザは、メッセージをみたときに、有益なメッセージを投稿しているユーザと判定した場合、容易にフォローすることができる。例えば、ソーシャルネットワークサービスとしてＴｗｉｔｔｅｒ等とするとよく、ユーザが第２のアカウントをフォローしていない場合は、フォローできるようにレコメンドするとよい。また、例えば、ユーザが第２のアカウントをフォローしていない場合は、自動的にフォローするようにするとよい。また、ユーザがフォローしたアカウントが投稿したメッセージを優先的に取得したり、出力態様を変化させたりする機能を備えるとよい。

このようにすれば、ユーザは、メッセージを投稿したアカウントが、特定の条件に一致したアカウントであることを確認することができる。ここで、特定の条件としては、例えば、ユーザは所定のキーワードを入力している場合に、当該キーワードがメッセージを投稿したアカウントのプロフィール情報に含まれていることとするとよい。特定の条件としては、例えば、アカウントの属性として、関連するアカウントに関する属性の値（具体的には、フォロワー数／フォロー数等）が所定の閾値以上であることとするとよい。また、特定の条件としては、例えば、アカウントが、メッセージングサービスが認定したアカウントであるとしてもよい。ユーザは、特定の条件に一致したことを知ることで、例えば当該アカウントを関連付けるか（例えばフォローするか）を判定することができる。また、ユーザは特定の条件に一致したことを知ることで、当該メッセージの信頼性が高いか否かを判定することができる。

［１．４．２０複数のアカウント情報を有する場合の実施例］
本実施例は、電子機器１０を使用するユーザのアカウントが複数ある場合の実施例である。アカウント情報記憶領域１９２には、ユーザに関するアカウント情報が１又は複数記憶することができる。

例えば、メッセージ出力部１０７は、サービスからメッセージを取得した場合、取得したアカウントに応じて出力する態様を異なって出力してもよい。例えば、メッセージ出力部１０７がメッセージを表示する場合、アカウントに対応付けて、メッセージを表示する色（文字色、背景色）、メッセージのフォント、テロップ表示の速度等を切り替えて表示してもよい。また、メッセージ出力部１０７が、メッセージを音声出力する場合、音声出力する声色を異ならせてもよい。これにより、ユーザは、どのアカウントからメッセージが取得されたのかを容易に判別することができる。

また、メッセージ取得部１０６が、複数のアカウントでメッセージを取得した場合、重複したメッセージは出力対象としないことにしてもよい。また、メッセージ出力部１０７はアカウントが異なっていてもメッセージが同じものは出力対象としなくてもよい。また、メッセージ出力部１０７は、アカウントが異なっていてもメッセージに含まれる文字列が同一又は略同一の場合、当該メッセージを出力対象としなくてもよい。

例えば、異なるアカウントであっても、同じユーザのアカウントをフォローしている場合がある。電子機器１０は、それぞれを報知してしまうと、ユーザはうっとうしいと感じてしまう。そこで、重複するメッセージは、１つだけ出力し、他のメッセージは出力対象としないようにしてもよい。

また、メッセージ投稿部１０５は、予め定められた少なくとも１つのアカウントから投稿してもよい。

このようにすれば、ユーザは、メッセージングサービスにログインする情報を、電子機器自体に記憶させておくることができる。例えばユーザは、ログイン情報が自分が所有する電子機器自体に記憶されていることから、ログイン情報の流出等を心配せずにメッセージングサービスを利用することができる。また、例えば、メッセージングサービスを利用するときに、ユーザはログイン情報を入力する手間を減らすことができる。

また、ユーザはログイン情報を電子機器に複数記憶させておき、ログイン情報を切り替えてメッセージングサービスからメッセージを受け取ることができる。このように、複数のログイン情報を記憶可能なことから、ユーザは、例えば、ログイン情報として、通常使用しているプライベートのアカウントと、電子機器で交通に関する情報を収集する目的で使用しているアカウントを２つ記憶するといった使い方ができる。また、制御部は、複数記憶されたログイン情報を、併せて使用してもよいが、切り替えて使用する機能を備えるとよい。制御部は、例えば、例えば、ユーザが切り替えて第１のログイン情報に基づいてログインして取得したメッセージだけを出力したり、第２のログイン情報に基づいてログインして取得したメッセージだけを出力したりするとよい。また、ユーザは、両方使用する場合は、第１のログイン情報及び第２のログイン情報に基づいてログインし、両方から取得したメッセージを併せて出力するとよい。

また、ユーザは複数の異なるアカウントに基づいてメッセージが取得された場合であっても、各アカウントから取得したメッセージのうち、重複したメッセージについては１つのメッセージのみを受け取ることができる。例えば、ユーザが、異なるアカウントから取得したメッセージを併せて出力する場合、それぞれのユーザのアカウントが同一の他のユーザのアカウントをフォローしていると、重複したメッセージを受け取ってしまうことがある。そこで、制御部は、重複したメッセージをそれぞれ出力せずに、１つの表示にするとよく、このようにすると、ユーザは同じメッセージを繰り返し受け取ることを避けることができる。また、重複したメッセージが出力されないことから、制御部は、例えば、その分他のメッセージを出力するとよいできる。また、制御部は、例えば重複したメッセージを１つにまとめた場合に、当該メッセージの表示態様を変化させるとよい。

［１．４．２１サービスの投稿条件に応じた投稿を行う実施例］
本実施例は、サービスの投稿情報に応じてメッセージ投稿部１０５がサービスにメッセージを投稿する実施例である。

例えば、サービス事業者からサービスを利用するにあたり規約が示されている。メッセージ投稿部１０５は、当該規約に沿ったようにメッセージを投稿する。例えば、サービスが投稿間隔を１０分空けてる規約の場合、１０分間空けてからメッセージ投稿部１０５はメッセージを投稿する。

また、メッセージ取得部１０６も、サービスの規約に沿ったようにメッセージを取得してもよい。例えば、１０分間で１０回の場合、その回数以上細かい間隔でメッセージを取得することは避け、当該回数内に収まるようにメッセージを取得すればよい。

本実施例によれば、サービス側からシステムを利用する制約が課された場合でも、当該制約に従って運用を行うことができる。

［１．４．２２表示部の大きさに応じてメッセージの表示態様を変化する実施例］
本実施例は、表示部の大きさに応じてメッセージの表示態様が変化する実施例である。

メッセージ出力部１０７がメッセージを表示部や表示装置に出力する場合に、表示部の大きさや解像度に応じてメッセージの表示態様を変化してもよい。

例えば、メッセージ出力部１０７は、横解像度の方が広い表示部１２０や、表示装置の場合、メッセージを横方向にスクロール表示を行ってもよい。また、メッセージ出力部１０７は、縦解像度の方が広い表示部１２０や、表示装置の場合、メッセージを縦方向にスクロール表示を行ってもよい。

また、表示部１２０や、表示装置の解像度に応じて、メッセージの配置を変更してもよい。メッセージ出力部１０７は、表示装置の種類に応じてメッセージの表示する方向、メッセージの配置、スクロール方向を変更してもよい。例えば電子機器１０の表示部１２０に表示する場合は、大きさが限られているが、ユーザの所有する携帯端末装置（スマートフォン）の方が表示部の大きさが大きい場合、メッセージ数を多めに表示してもよいし、カーナビゲーション装置の表示部の大きさが大きい場合、メッセージのスクロール方向を変更してもよい。

［１．４．２３他の装置と連携する実施例］
本実施例は、他の装置から送信された走行履歴等からメッセージの信頼性を評価したり、場所を推定したりする実施例である。

例えば、電子機器１０は、車両情報の１つとして走行履歴を示した走行履歴情報を送信する。送信先としては、例えば、走行履歴情報を管理可能なサーバ装置に送信する。また、電子機器１０は、必要に応じて他の電子機器１０に送信してもよい。

制御部１００は、通信部１４６を介して、他の装置における走行履歴情報を受信する。走行履歴情報は、例えばＧＰＳログ等であればよい。また、走行履歴情報には、日時、車両５０の走行速度、緯度経度情報、移動距離、住所、市区町村名、道路名称等が必要に応じて含まれている。

また、電子機器１０は、走行履歴情報を必要に応じてサーバ装置に送信する。電子機器１０は、定期的に（例えば１時間毎等）サーバ装置に送信してもよいし、電源投入時に送信してもよい。また、電子機器１０は、走行履歴情報に記憶されたサイズが所定のサイズとなったタイミングで送信してもよい。また、電子機器１０は、例えば車両５０の異常を検知したタイミングや、事故を検知したタイミングで送信してもよい。

制御部１００は、走行履歴情報から、メッセージの信頼性を判定してもよい。例えば、メッセージから「名古屋駅で渋滞が発生している」というメッセージに対して、名古屋駅周辺を含む走行履歴情報を取得する。ここで、名古屋駅周辺を含む走行履歴情報から、本当に渋滞しているか否かを判定する。

また、制御部１００は、走行履歴情報から渋滞を検出してもよいし、事故を検出してもよい。この場合、メッセージ生成部１０４は、「渋滞が発生しているようです」というメッセージを生成してもよい。

また、事故や渋滞の情報等特に即時性が要求されるものについては、制御部１００は、詳細を尋ねるメッセージを自動的にユーザに対して送信してもよい。ユーザに対して送信するメッセージは、１対１で通信可能な直接のメッセージ（例えば、ダイレクトメッセージ）であってもよい。

そして、電子機器１０は、返信されたメッセージの内容に応じて処理を行ってもよい。例えば、ユーザが更に語句を付け加える処理を実行してもよいし、信頼性を高める取った処理を実行してもよい。

また、直接のメッセージは、予めテンプレートを記憶しておき、そのテンプレートを本文として元のメッセージへの返信ツイートとしてメッセージを投稿してもよい。

［１．４．２４アンケート機能を実現する実施例］
本実施例は、サービスにおいて提供されているアンケート機能を利用する実施例である。

例えば、メッセージ生成部１０４は、サービスにおいて提供されているアンケート機能を利用するメッセージを生成する。メッセージ投稿部１０５は、アンケート機能を利用するメッセージをサービスに投稿する。

これにより、例えばとりまとめた情報が正しいか否かをメッセージサービスのアンケート機能を利用して集計することが可能である。サービスのアンケート機能は、例えばＴｗｉｔｔｅｒにおけるアンケート機能等を利用してもよい。

例えば、図１３は、アンケートを含むメッセージを表示した表示画面Ｗ１５０を示す一例である。表示画面Ｗ１５０は、メッセージを表示する領域Ｒ１５０と、アンケートの対象となる引用したメッセージＲ１５２と、アンケートを回答可能な領域Ｒ１５４とが表示されている。また、サービスが提供する機能として、投票件数と、アンケートの残り時間とが表示されている。

このように、アンケートを利用することで、ユーザは投稿したメッセージが適切であったか否かを評価することができる。

また、アンケート結果をリアルタイムにグラフ化して出力してもよい。例えば、メッセージ取得部１０６は、定期的にアンケートの投票件数を取得する。そして、アンケートの投票件数を折れ線グラフや、棒グラフ、円グラフ等を生成し、表示部１２０に表示する。また、制御部１００は、グラフ化した結果を含むメッセージを再度サービスに投稿してもよい。

また、アンケート結果は、外部サーバ装置で集計し、電子機器１０に配信してもよい。例えば外部のサーバ装置は、サービスからアンケートの回答件数を所定時間毎に取得する。そして、外部のサーバ装置は、アンケートの回答件数に基づいて、アンケートの結果を集計してもよい。電子機器１０は、外部サーバ装置からアンケートの結果を受信したら、表示部１２０に結果を表示してもよい。

また、外部サーバ装置は、当該アンケートのメッセージの再投稿の状況（リツイートの件数）に応じて、とりまとめた情報（例えばアンケートの集計結果）を電子機器１０に送信してもよい。

また、外部サーバ装置は、再投稿の状況に替えて、アンケートをサービスで行ってからアンケートの状況に基づき、集計した結果を電子機器１０に送信してもよい。例えば、外部サーバ装置は、アンケートの回答が目標値に到達した場合や、一定数集まった場合に、電子機器１０にアンケートの集計結果を送信してもよい。

また、外部サーバ装置又は電子機器１０は、アンケートの時間は、アンケートの回収件数に応じて可変することにしてもよい。例えば、回答件数が足りない場合、再度アンケートを含むメッセージをサービスに投稿してもよい。

また、外部サーバ装置又は電子機器１０は、アンケートの集計をするための回答件数が集まった場合（設定された回答件数に到達した場合）、アンケートのツイートを削除してもよい。

この場合、外部サーバ装置又は電子機器１０は、アンケートの結果に基づいたメッセージをサービスに送信してもよい。例えば、外部サーバ装置又は電子機器１０は、アンケートの結果を示すスクリーンショットの画像をサービスに投稿してもよい。また、外部サーバ装置又は電子機器１０は、アンケートの結果を示す数値を、サービスに投稿してもよい。

なお、アンケートは、公開のメッセージで行わなくても、それぞれのユーザへの個別メッセージ（例えば、ダイレクトメッセージ）で実現してもよい。

［１．４．２５トレンドを利用した実施例］
本実施例は、サービスにおけるトレンドを利用した実施例である。トレンドは、サービスにおいて、多くのメッセージに含まれている語句をいう。ここで、制御部１００は、トレンドランキングに入っている語句に、メッセージとして出力すべきものがある場合、メッセージ出力部１０７は、トレンドランキングに入っている語句に基づいてメッセージを出力する。ここで、メッセージ出力部１０７は、トレンドランキングに含まれている語句に基づいて取得したメッセージと、その他のメッセージとを区別して表示してもよい。例えば、区別する情報を付加して表示してもよいし、メッセージの色やフォントを変えても良い。また、メッセージ出力部１０７は、メッセージを音声出力する場合は、声色を替えたりしてもよい。

このようにすれば、ユーザはメッセージングサービスにおいてトレンドとなっている言葉を含むメッセージを受け取ることができる。例えば、取得するメッセージを、トレンドとして抽出可能な言葉を交通に関する情報と併せてＡＮＤ検索して取得してもよいし、ＯＲ検索して取得してもよい。例えば、交通に関する情報の中からトレンドとなっているメッセージだけを取得してもよいが、交通に関する情報と併せてトレンドとなっている言葉を含むメッセージを取得してもよい。また、トレンドとなっている言葉を含むメッセージを表示する場合は、当該メッセージの出力態様を変化させるとよい。また、トレンドとなっている言葉は、メッセージ中の一部に含まれていてもよいが、タグとして含まれていてもよい。

［１．４．２６関連する場所を検索する実施例］
本実施例は、メッセージに含まれる文字列から、付加情報を追加したメッセージを表示したり、サービスに投稿する実施例である。

例えば、制御部１００は、取得したメッセージから、事故や渋滞のメッセージを判定する。そして、制御部１００は、当該メッセージに含まれている場所の緯度経度情報を取得する。

制御部１００は、取得した緯度経度情報から、周辺の地域情報を取得する。そして、当地域のトレンドとなっている語句を取得して、メッセージに付加してもよい。また、制御部１００は、緯度経度情報から、周辺のメッセージや、地域情報を取得し、メッセージの制度を上げてもよい。例えば、制御部１００は、「渋滞」が含まれているメッセージに緯度経度情報が含まれている。このとき、メッセージ取得部１０６は、当該緯度経度情報の周辺で投稿されたメッセージを取得する。そして、制御部１００は、当該緯度経度情報の周辺で投稿された他のメッセージから「渋滞」に関するメッセージを取得できた場合、最初のメッセージの信頼性は高いと判定できる。

また、制御部１００は、サービスから関連する情報を検索してもよい。例えば、取得した緯度経度情報から、周辺の施設やイベントが含まれるメッセージを取得したり、店舗の情報を取得したりする。例えば、ユーザが「渋滞」にはまるのであれば、渋滞を避けるために店舗に立ち寄ったり、イベントを楽しんだりすることができる情報を提供することができる。

本実施例によれば、メッセージを取得したときに、当該メッセージが投稿された内容又はメッセージに含まれている位置情報に基づいて周辺の地域情報を取得する。そして、周辺の地域情報が含まれるメッセージを抽出することができる。これにより、メッセージの信頼度を他のメッセージに基づいて評価することができる。また、ユーザに対して、ユーザが渋滞にはまっているとき、付加的な情報を更に提供することができる。

［１．４．２７ＲＳＳを利用した実施例］
電子機器１０において、ネット上のＲＳＳフィードを登録しておき、ＲＳＳフィードで配信される情報を、テロップ表示する機能がある。

上述したサービスについて、ＲＳＳフィードとしてもよい。すなわち、メッセージ取得部１０６は、ＲＳＳフィードに基づいてメッセージを取得してもよい。

このＲＳＳフィードは、電子機器１０で登録してもよいし、他の装置で登録してもよい。例えば、ＲＳＳフィードは、専用のアプリケーションを利用して登録できるようにしてもよいし、Ｗｅｂサイト上のサイトに登録した情報を取得するようにしてもよい。また、ＲＳＳフィードは、ユーザのブラウザを利用して登録してもよい。例えば、ブラウザのFollowボタン等が押されて登録されている情報を取得してもよい。

例えば、外部のサーバ装置や、電子機器１０、他のブラウザを搭載した装置で、ユーザのブラウザに登録されているＲＳＳのアドレス情報を取得する。そのアドレスの情報（ＲＳＳフィード）が更新されたときに、その情報を要約等して電子機器１０に配信したり、表示したりするとよい。

また、ＲＳＳに交通関連の情報が含まれるか判定（フィルター等）して、交通関連の情報が含まれるものを集約して電子機器１０に配信するようにしてもよい。

［１．４．２８メッセージの出力先をサービスにする実施例］
本実施例は、メッセージの出力先として、他の装置（サーバ装置）等に行う実施例である。

例えば、上述したメッセージ出力部１０７は、制御部１００（例えば、メッセージ制御部１０９）により生成したメッセージを出力する。メッセージ出力部１０７は、表示部１２０によるメッセージの表示、音声出力部１３０による音声出力、発光部１８０によるＬＥＤの点灯等を出力先としている。メッセージ出力部１０７は、上述した出力先以外に、他の装置、サービスに出力してもよい。

例えば、メッセージ出力部１０７は、取得したメッセージに基づいて作成したメッセージを表示部１２０に表示するとともに、サービスに出力してもよい。メッセージ出力部１０７がメッセージをサービスに出力するとは、例えばメッセージ投稿部１０５を介してサービスにメッセージを投稿することをいう。

ここで、メッセージ出力部１０７は、電子機器１０においてメッセージを出力せずに、サービスだけにメッセージを出力（投稿）してもよいし、電子機器１０においてメッセージを出力するのと併せて、サービスにメッセージを出力（投稿）してもよい。また、メッセージ出力部１０７は、メッセージの重要度や、信頼度に応じて出力先を切り替えてもよい。例えば、メッセージ制御部１０９が、メッセージ取得部１０６が取得したメッセージに基づいて、まとめたメッセージを作成としたとする。このとき、元のメッセージに対して評価が高かったり、再投稿の数が多い場合は、制御部１００は、メッセージが重要であると判定してもよい。

制御部１００（メッセージ出力部１０７、メッセージ投稿部１０５）は、メッセージの重要度が高いと判定した場合は、生成したメッセージをサービスに投稿する。また、メッセージ投稿部１０５は、このとき元のメッセージに返信する形でメッセージを投稿してもよいし、引用する形（引用リツイート）でメッセージを投稿してもよい。

［１．４．２９ブックマーク機能を利用する実施例］
本実施例は、サービスが有するブックマーク機能を利用する実施例である。電子機器１０等やスマートフォンのTwitterクライアントアプリで、メッセージが車内で読み上げられているとき音声認識で「ブックマーク」を認識したら、そのメッセージをブックマークとして保存する。

この保存場所をＴｗｉｔｔｅｒのブックマーク（Ｔｗｉｔｔｅｒにおけるサーバー上）とするか、電子機器１０等の機器内部のみとするかをユーザが選択可能にしてもよい。

ここで、ユーザが選択する機能は、予め設定画面で設定しておきその設定内容に応じて決定してもよい。また、音声認識の言葉を変えるなどして保存先を指定してもよい。

これは、渋滞等の情報は、一時的な情報であることが多いので、ブックマークしておきたい期間が、自分が興味ある分野のつぶやき等とは異なり短いことが多い。

このような渋滞のメッセージ（ツイート）と、興味分野のメッセージ（ツイート）を混ぜずに、渋滞のツイートは電子機器１０に記憶するようにするとよい。このように、本実施例では、メッセージの保存場所を物理的に（場所的に、空間的に）異なる場所とする機能を備えるとよい。

あるいは、制御部１００は、保存期間に関する情報を音声認識したときには、その期間保存した後、削除する処理を行うようにしてもよい。

例えば、制御部１００は、「このメッセージしばらく保存」「このメッセージは大事に保存」とで保存期間を変える。前者は１週間後に削除するが、後者は削除しないとしてもよい。また、制御部１００は、期間を具体的に指定された場合にはその期間経過後に削除する。「このツイートを一週間保存」と認識されたツイートについては１週間保存する。保存期間が指定されなかったツイートについては、サービス側のブックマーク機能で保存させる処理を行うようにするとよい。

また、ブックマークに保存する種類を変更できるようにしてもよい。例えば、メッセージの重要度に応じて、保存する期間を変えられるものとしてもよい。

このように、ユーザは、音声入力により出力されているメッセージをブックマークとして保存することができる。例えば、出力されているメッセージを再度確認したい場合や、後で利用したい場合に、ユーザがブックマークに保存する内容を示す命令を音声で発すると、当該メッセージがブックマークに保存するようにするとよい。また、ユーザが音声により登録操作ができることから、例えばユーザが運転中のように操作が行えない環境であっても、出力されているメッセージをブックマークとして保存することができる。ブックマークとは、メッセージをお気に入り等の情報として保存することをいうとよい。メッセージはブックマークとして保存される場所は例えば装置とするとよいが、メッセージングサービス上であってもよい。また、メッセージは、装置と接続された他の装置にブックマークとして保存されてもよい。また、ブックマークとして保存されるものは、メッセージ（例えばメッセージ情報）自体が保存されてもよいが、メッセージを特定する識別情報（例えば、メッセージＩＤ、メッセージを示すＵＲＬ等）が保存されてもよい。

［１．４．３０音声会議を利用した実施例］
本実施例は、音声会議を利用した実施例である。例えば、制御部１００は、音声会議を提供するサービスに対して、一連の場所的・時間的接着性のあるメッセージ（ツイート）のクラスタを生成する。

そして、制御部１００は、当該クラスタ内のユーザへスペース等の会議室（好ましくは音声会議室を提供する）への招待のメッセージ（リンク情報）等を送信する。そして、会議室を提供したサービス、メッセージングサービスを提供するサービス、外部サーバ装置の何れかにおいて、この会議室（音声会議室）中でのやりとりの内容を文字に起こし、その文章内容や音声の感情認識等によって、もとのメッセージを配信対象とするか決定したり、あるいは、配信したツイートに関心があるユーザへこの会議室のアドレスを通知する処理を行うとよい。これにより、ユーザは運転しながら状況を音声で確認できる。

［１．４．３０電子機器について］
本実施例は、電子機器１０の装置の実現方法を説明する実施例である。例えば、電子機器１０は、図１に示すような車載用の装置として説明したが、他の装置であってもよい。電子機器１０は、例えば、ドライブレコーダーのような機器であってもよい。また、電子機器１０は、例えば、ルームミラーに取り付けて使用されるドライブレコーダであるミラー一体型ドラレコの中味の基板と液晶の組み合わせで実現してもよい。

また、電子機器１０は、スマートフォンに、図８の制御部で実現している機能を実現可能なアプリケーションをインストールしてもよい。また、電子機器１０は、カーナビゲーション装置で実現してもよい。

［１．５実施例の組み合わせについて］
上述した実施例は、説明の都合上、機能毎に説明しているが、それぞれの実施例を組み合わせてよいことは勿論である。また、実施例は複数の実施例を組み合わせたり、開示されている範囲を適宜組み合わせて適用可能なことは勿論である。

また、上述した実施例は、第２実施形態においても適用可能である。第２実施形態では、上述した電子機器１０の動作を、必要に応じて管理装置２０に置き換える。現在開示されてている処理を、電子機器１０で実現するか、管理装置２０で実現するかは、いわゆる当業者であれば容易に実現可能である。

また、電子機器１０と、管理装置２０とを併せてメッセージ処理システムと構成してもよい。この場合、上述した電子機器１０の処理が、メッセージ処理システムの処理として実現可能である。

［２．第２実施形態］
つづいて、第２実施形態について説明する。第２実施形態は、システム１において、管理装置を備える実施形態である。

［２．１システム概要］
第２実施形態のシステム２の一例を、図１４に示す。システム２は、第１実施形態のシステム１の構成に加えて、管理装置２０を更に備えている。また、図１４のシステム２は、ユーザのスマートフォン等である携帯端末装置４０が示されている。

電子機器１０は、ネットワークＮＷに直接接続してもよいし、携帯端末装置４０を介して接続してもよい。携帯端末装置４０は、例えばテザリング機能を有する装置であり、ネットワークＮＷに接続するときのアクセスポイントとして機能する。

第１実施形態とことなり、本実施形態では、メッセージの生成、メッセージの投稿、メッセージの取得を管理装置２０で実行する。電子機器１０は、トリガに基づいて車両５０の車両状態や、ユーザ（ドライバー）からの入力に応じて、投稿情報を生成する。

そして、電子機器１０は、管理装置２０に投稿情報を送信する。管理装置２０は、投稿情報に基づいてメッセージを生成する。

また、管理装置２０は、サービス提供装置３０からメッセージを取得する。そして、必要に応じて、メッセージを電子機器１０に送信（配信）する。また、取得したメッセージから新たなメッセージを生成し、サービス提供装置３０にメッセージを送信する。これにより、管理装置２０は、新たなメッセージをサービスに投稿することができる。

［２．２機能構成］
つづいて、第２実施形態における機能構成を説明する。第１実施形態と概ね構成は同じであるが、第１実施形態から変更された点を中心に説明する。

［２．２．１電子機器］
電子機器１０の構成は、第１実施形態と略同一である。本実施形態の電子機器１０は、図８で説明した制御部１００、記憶部１９０を図１５に置き換えている。

図１５（Ａ）に示すように、制御部１００は、投稿情報生成部１０４ａと、メッセージ出力部１０７と機能する。投稿情報生成部１０４ａは、第１実施形態のメッセージ生成部１０４がメッセージを生成していた代わりに、投稿情報を生成する。投稿情報は、管理装置２０がメッセージを生成するために必要な情報が含まれている。

また、図１５（Ｂ）に示すように、記憶部１９０は、アカウント情報記憶領域１９２と、車両情報記憶領域１９４と、メッセージ情報記憶領域１９６と、投稿情報記憶領域１９７と、設定情報記憶領域１９８との領域を確保している。

ここで、メッセージ情報記憶領域１９６は、管理装置２０が配信し、電子機器１０が受信したメッセージ情報が記憶する。また、投稿情報記憶領域１９７は、投稿情報生成部１０４ａが生成した投稿情報を記憶する。

［２．２．２管理装置］
管理装置２０の構成について、図１６を参照して説明する。

制御部２００は、管理装置２０の全体を制御するための機能部である。制御部２００は、記憶部２２０に記憶されている各種プログラムを読み出して実行することにより各種機能を実現しており、例えば１又は複数の演算装置で実現される。例えば、ＣＰＵ（Central Processing Unit）や、ＳｏＣ（System on a Chip）により実現される。

制御部２００は、記憶部２２０に記憶されているプログラムを実行することにより、メッセージ生成部２０２、メッセージ投稿部２０４、メッセージ取得部２０６、タイミング判定部２０８として機能してもよい。

メッセージ生成部２０２は、電子機器１０から受信した投稿情報に基づいてメッセージを生成する。電子機器１０から受信した投稿情報は、一度投稿情報記憶領域２２８に記憶されている。したがって、メッセージ生成部２０２は、投稿情報記憶領域２２８から投稿情報を読みだし、メッセージと、メッセージを含む投稿メッセージ情報を生成する。そして、メッセージ生成部２０２は、生成したメッセージ（投稿メッセージ情報）を送信情報記憶領域２２６に記憶する。

メッセージ生成部２０２は、第１実施形態におけるメッセージ生成部１０４の処理又は処理の一部を実行する。

メッセージ投稿部２０４は、メッセージ生成部２０２が生成したメッセージ（投稿メッセージ情報）を、サービス提供装置３０に送信する。すなわち、メッセージ投稿部２０４は、メッセージをメッセージングサービスに投稿する。なお、メッセージ投稿部２０４は、予めアカウント情報記憶領域２２２に記憶されているアカウント情報に基づいて、メッセージングサービスにログインする。これにより、メッセージ投稿部２０４は、ログインしたアカウントで、メッセージングサービスにメッセージを投稿することになる。

メッセージ投稿部２０４は、第１実施形態におけるメッセージ投稿部１０５の処理又は処理の一部を実行する。

メッセージ取得部２０６は、サービス提供装置３０が配信した取得メッセージ情報を取得する。すなわち、メッセージ取得部２０６は、メッセージングサービスからメッセージを取得する。そして、メッセージ取得部２０６は、取得した取得メッセージ情報をメッセージ情報記憶領域２２４に記憶する。

メッセージ取得部２０６は、第１実施形態におけるメッセージ取得部１０６の処理又は処理の一部を実行する。

タイミング判定部２０８は、メッセージをサービスに投稿するタイミングや、メッセージをサービスから取得するタイミングを判定する。

タイミング判定部２０８は、第１実施形態におけるタイミング判定部１０８の処理又は処理の一部を実行する。

メッセージ制御部２０９は、取得したメッセージ（取得メッセージ情報）に対して各種処理を行う。例えば、特定のキーワードの含むメッセージだけを抽出したり、特定のタグを含むメッセージだけを抽出したりする。

なお、メッセージ制御部２０９は、メッセージ取得部２０６が取得した取得メッセージ情報（メッセージ）に対して処理を行うように制御してもよい。また、メッセージ取得部２０６がサービス提供装置３０からキーワードやタグといった情報を含むメッセージのみを取得するように制御してもよい。

メッセージ制御部２０９は、第１実施形態におけるメッセージ制御部１０９の処理又は処理の一部、メッセージ出力部１０７の処理の一部を実行する。

記憶部２２０は、管理装置２０の動作に必要な各種プログラムや、各種データが記憶されている機能部である。記憶部２２０は、例えば、半導体メモリや、ＨＤＤ（Hard Disk Drive）等により構成されている。

また、記憶部２２０は、メッセージングサービスにログインするためのアカウント情報を記憶するアカウント情報記憶領域２２２と、メッセージ取得部２０６がサービス提供装置３０から取得した取得メッセージ情報を記憶するメッセージ情報記憶領域２２４と、メッセージ生成部２０２により生成された投稿メッセージ情報を記憶する送信情報記憶領域２２６と、電子機器１０から受信した投稿情報を記憶する投稿情報記憶領域２２８とを確保している。

なお、アカウント情報は、電子機器１０に記憶されている場合、管理装置２０に記憶しなくてもよい。セキュリティの都合から、管理装置２０で記憶していることが好ましい。

操作部２４０は、ユーザや管理者の操作入力を受け付ける。例えば、キーボードやマウス、タッチパネル等の操作装置で構成される。また、表示部２４５は、管理装置２０の各種情報等を表示する表示装置である。操作部２４０、表示部２４５は、必要に応じて備えればよく、例えばＵＳＢ等により接続される外部装置であってもよいし、外部から遠隔操作を行う端末装置であってもよい。

通信部２５０は、ネットワークＮＷを介して他の装置と通信を行う。本実施形態では、電子機器１０や、サービス提供装置３０と通信を行う。また、通信部２５０を介して他の装置と通信を行ってもよい。また、通信部２５０は、例えばネットワークに接続するＬＡＮインタフェース等により構成される。

［２．３処理の流れ］
以下、本実施形態の処理の流れを説明する。本実施形態は、第１実施形態において説明した電子機器１０の機能のうち、一部の機能を管理装置２０が実行する実施形態である。第１実施形態において、例えば図９で説明した処理を、一部の機能を管理装置２０で実現すればよい。すなわち、第１実施形態では、電子機器１０のみで実現していた処理を、第２実施形態では、管理装置２０を経由して実現すればよい。

具体的には、サービスからのメッセージの取得、サービスへのメッセージの投稿を管理装置２０が実行する。電子機器１０は、メッセージを生成するために必要な情報を管理装置２０に送信する。また、電子機器１０は、管理装置２０からメッセージを取得し、メッセージを出力する。

すなわち、第１実施形態において説明した電子機器１０の機能を、必要におうじて第２実施形態の電子機器１０と、管理装置２０とに分散している実施形態である。

例えば、第２実施形態の処理を図１７を参照して説明する。まず、電子機器１０は、投稿情報生成処理を実行する（Ｓ１１００）。電子機器１０は、投稿情報生成処理が実行すると、車両５０の状態や、ユーザからの入力等により投稿情報を生成する。

電子機器１０は、生成した投稿情報を管理装置２０に送信する（Ｓ１１０２）。管理装置２０は、投稿情報を受信すると、投稿情報に基づいてメッセージを生成する。

ここで投稿情報には、車両５０の状態や、ユーザから入力された情報等のメッセージを生成するために必要な情報が含まれている。管理装置２０は、例えば、投稿情報に含まれている車両５０の移動速度、移動距離、位置情報に応じて車両５０の状態が渋滞であると判定する。そして、管理装置２０は、投稿情報から渋滞である旨のメッセージを生成する。

また、管理装置２０は、投稿情報に位置情報が含まれていれば、位置情報から地図の画像を生成してもよい。また、管理装置２０は、投稿情報に画像（例えば、電子機器１０の表示部１２０の表示画面のキャプチャ画像）が含まれていれば、画像を含むメッセージを生成してもよい。

また、管理装置２０は、メッセージ情報記憶領域２２４に記憶されているメッセージ情報から新たなメッセージを生成してもよい。

管理装置２０は、メッセージ投稿処理を実行する（Ｓ１３００）。具体的には、管理装置２０は、生成した投稿メッセージ情報をサービス提供装置３０に送信する。これにより、管理装置２０を経由して、メッセージがサービスに投稿される。

また、管理装置２０は、所定のタイミングでメッセージ制御処理を実行する（Ｓ１４００）。メッセージ制御処理は、取得メッセージ情報に基づいて新たなメッセージを生成したり、サービスからメッセージを取得するメッセージ取得処理を実行する（Ｓ１４５０）。

管理装置２０は、メッセージ取得処理を実行すると、サービス提供装置３０に取得メッセージ情報を要求する（Ｓ１４５２）。そして、サービス提供装置３０から取得メッセージ情報応答により、取得メッセージ情報を受信する（Ｓ１４５４）。

管理装置２０は、取得メッセージ情報に基づいて、メッセージ情報を電子機器１０に送信する（Ｓ１４６０）。電子機器１０は、メッセージ出力処理を実行する（Ｓ１５００）。メッセージ出力処理は、管理装置２０から受信したメッセージ情報に含まれるメッセージを表示部１２０に表示したり、音声出力部１３０から音声を出力したりする。

［２．４実施例］
本実施形態の実施例は、第１実施形態において説明した実施例をそのまま適用可能である。すなわち、電子機器１０で行っていた処理のうち、メッセージの生成、メッセージの投稿、メッセージの取得、メッセージの制御について、適宜管理装置２０で実現すればよい。例えば、第１実施形態において、電子機器１０がメッセージを生成した内容は、そのまま管理装置２０で実現可能である。

また、第２実施形態においても、メッセージの生成は電子機器１０で実行してもよい。この場合、投稿情報に、実際に投稿するメッセージをテキストで含めればよい。そして、管理装置２０は、実際にメッセージに投稿する形式の投稿メッセージ情報を生成すればよい。

このように、第１実施形態において記載した実施例を第２実施形態に適用できるが、以下、便宜的に第２実施形態における実施例について説明する。なお、以下の実施例を第１実施形態に適用し、電子機器１０で実現してもよいことは勿論である。

［２．４．１メッセージを生成して投稿する実施例］
本実施例は、電子機器１０から任意のタイミングでメッセージをサービスに投稿する実施例である。

例えば、電子機器１０の表示部１２０に、「事故」「渋滞」「危険運転」「災害」のカテゴリーがあって、表示画面に表示される文言リストからユーザが選ぶと、メッセージ生成部１０４はメッセージを生成する。

例えば、「渋滞」の文言リストから「交差点で渋滞してまーす」を選択する。なお、メッセージには渋滞を示す複数の車が並んだ絵文字が含まれていてもよい。また、住所や道路名称に基づくタグを併せてメッセージに付加しても良い。

このとき、日時、住所、道路名称、メッセージを含めた投稿情報を電子機器１０から管理装置２０に送信する。なお、アカウント情報は電子機器１０に既に保有している場合、既にサービスにおいてログイン認証が行われていてもよいし、その都度サービスにおいて認証をしてもよい。

管理装置２０は、投稿情報に含まれている内容に基づいてメッセージを生成する。例えば、図１８（Ａ）は、生成したメッセージの一例を示している。また、このとき、電子機器１０から画像データが含まれていれば、画像データをメッセージに含ませてもよい。ここで、画像データがメッセージに含まれるとは、画像データ自体をメッセージに含めてもよいし、メッセージがアップロードされているＵＲＬがメッセージに含まれてもよい。

管理装置２０は、サービスのインタフェースを利用して、サービスにおいてメッセージを投稿する。例えば、サービスがＴｗｉｔｔｅｒの場合、ＴｗｉｔｔｅｒＡＰＩを使用してメッセージをｔｗｅｅｔする。

図１８（Ｂ）は、実施に投稿された状態を示す一例である。この場合、メッセージを投稿したアカウントは、管理装置２０が有しているアカウント（すなわち、電子機器１０のアカウントに関係なく、システムで使用する投稿用のアカウント）でもよいし、電子機器１０のユーザのアカウントでもよい。

また、管理装置２０が有しているアカウントでメッセージを投稿している場合、元のメッセージを投稿したユーザを示すアカウントのメンションがメッセージに含まれてもよい。これにより、誰からの情報に基づく情報であるかを他のユーザが確認することができる。

また、管理装置２０が有しているアカウントでメッセージを投稿することで、他のユーザは当該アカウントのメッセージを取得すると、交通情報を含む情報を取得することができる。

なお、画像データを含む場合について、具体的な動作について以下説明する。まず、電子機器１０は、投稿情報に投稿するメッセージを文言データとしてテキストファイル（例えば、「20100428010101.txt」）を生成する。電子機器１０は、文言データであるテキストファイルを、管理装置２０に送信（アップロード）する。

また、投稿する画像（例えば、「20210428010101.jpg」）データを生成する。投稿する画像データは、拡張子形式をＰＮＧ、ＪＰＧ、ＧＩＦの何れかにして、管理装置２０に送信（アップロード）する。

管理装置２０は、投稿サーバとして機能している。例えば、管理装置２０は、ＰＨＰ等で組まれた投稿ソフトがインストールされている。そして、投稿データ（投稿情報）のあるフォルダを巡回していき、文言データ（テキストデータ）、画像データをサービスに投稿する。このとき、管理装置２０は、ｔｗｉｔｔｅｒＡＰＩのアクセスキー認証を受ける必要がある。また、管理装置２０は、投稿するときは、ＨＴＴＰ応答ステータスコードを利用してもよい。

また、管理装置２０は、その他の情報に基づいて画像を生成してもよい。例えば、投稿情報に、緯度経度情報が含まれている場合、緯度経度情報に基づく地図の画像データを生成してもよい。地図の画像データを管理装置２０で生成することで、常に最新の地図にもとづく画像を生成することができる。

［２．４．２取得したメッセージをサービスや電子機器に配信する］
本実施例は、管理装置２０が取得したメッセージから新たなメッセージを生成し、電子機器１０がテロップ表示したり、サービスに投稿したりすることができるようにする実施例である。

例えば、管理装置２０は、サービスのインタフェース（例えば、ＴｗｉｔｔｅｒＡＰＩ）を使用して、検索ワードから関連するメッセージ（Ｔｗｅｅｔ情報）を取得する。そして、管理装置２０は、取得したメッセージを一度ＣＳＶで記憶する。ここで、検索ワードであるキーワードは、交通関連のキーワードであることが好ましい。

例えば、図１９は、記憶されたＣＳＶの情報の一例を示す図である。管理装置２０は、例えば、１番上にあるメッセージから、事故に関するキーワードを抽出する。このメッセージから「事故」であること、「佐世保市大塔町」で事故が起こっていることが解る。そこで、配信するメッセージ（例えば、サービスに投稿する投稿メッセージ）として、「＜事故渋滞＞１時間前佐世保市大塔町トラック事故」というメッセージが生成される。管理装置２０は、この生成したメッセージを、電子機器１０に配信してもよい。電子機器１０はメッセージを取得するとテロップ表示を行うことができる。また、管理装置２０は、この生成したメッセージをサービスに投稿してもよい。また、サービスに投稿する場合は、当該メッセージの投稿者（ここでは、＠ｙａｋｙｕ）のアカウントをメッセージに含めてメッセージをサービスに投稿してもよい。

また、図１９の上から２件目は事故が発生したことを示すメッセージである。それに対して、３件目と、４件目とは、２件目のメッセージを再投稿（ＲＴ）したものである。この場合、管理装置２０は、２件目のメッセージに基づいて、配信するメッセージを生成してもよい。すなわち、管理装置２０は、２件目から４件目のメッセージは、関連するメッセージと判定してもよい。

例えば、管理装置２０は「＜事故渋滞＞３０分前中国道下り宝塚インター付近事故」というメッセージを生成し、電子機器１０に配信する。また、併せてサービスに当該メッセージをサービスに投稿する。

なお、このとき、管理装置２０は、電子機器１０にメッセージの配信の有無を判定してもよい。例えば、図１９の上から２件目のメッセージは、再投稿もされているメッセージであり重要度が高い。したがって、電子機器１０に配信し、サービスにメッセージを投稿する。しかし、図１９の１件目は、他のユーザから再投稿等はされていない。この場合は、例えばメッセージをサービスには投稿するが、電子機器１０には配信しないとしてもよい。

このように、本実施例によれば、管理装置２０は、取得したメッセージに基づいて再度投稿メッセージを生成し、サービスに投稿することができる。また、管理装置２０は、投稿メッセージを併せて電子機器１０に配信し、電子機器１０は受信した投稿メッセージを出力することができる。

本実施例においても、例えばメッセージをまとめる方法や、メッセージの信頼性を判定する方法については、第１実施形態に記載した実施例を適用すればよい。

［３．変形例］
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も特許請求の範囲に含まれる。

また、実施形態において各装置で動作するプログラムは、上述した実施形態の機能を実現するように、ＣＰＵ等を制御するプログラム（コンピュータを機能させるプログラム）である。そして、これら装置で取り扱われる情報は、その処理時に一時的に一時記憶装置（例えば、ＲＡＭ）に蓄積され、その後、各種ＲＯＭやＨＤＤの記憶装置に格納され、必要に応じてＣＰＵによって読み出し、修正・書き込みが行われる。

ここで、プログラムを格納する記録媒体としては、半導体媒体（例えば、ＲＯＭや、不揮発性のメモリカード等）、光記録媒体・光磁気記録媒体（例えば、ＤＶＤ（Digital Versatile Disc）、ＭＯ（Magneto Optical Disc）、ＣＤ（Compact Disc）、ＢＤ等）、磁気記録媒体（例えば、磁気テープ、フレキシブルディスク等）等の何れであってもよい。また、ロードしたプログラムを実行することにより、上述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、オペレーティングシステムあるいは他のアプリケーションプログラム等と共同して処理することにより、本発明の機能が実現される場合もある。

また、市場に流通させる場合には、可搬型の記録媒体にプログラムを格納して流通させたり、インターネット等のネットワークを介して接続されたサーバコンピュータに転送したりすることができる。この場合、サーバの記憶装置も本発明に含まれるのは勿論である。

また、上述した実施形態では、主にサービス（メッセージングサービス）として、ＳＮＳ、特にＴｗｉｔｔｅｒを主な例に説明したが、他のサービスにおいても適用可能である。例えば、サービスは、ＳＮＳとしてのＦａｃｅｂｏｏｋ、Ｉｎｓｔａｇｒａｍ、新浪微博、ＴｉｋＴｏｋ等としてもよい。Ｉｎｓｔａｇｒａｍの場合、適切なメッセージを取得するのと併せて、コメントの内容を取得してもよい。また、Ｉｎｓｔａｇｒａｍにおいても、「＃交通渋滞」「＃事故渋滞」の投稿ＵＲＬページから抽出してもよい。

上述した電子機器は、主に利用者が車両に乗車中に利用される機器である。例えば、電子機器は、車載用装置のみならず、スマートフォン、タブレット等の移動可能な装置にアプリケーションをインストールし、実行することで同様の機能が実現できる。

また、上述した第１実施形態、第２実施形態と説明したように、電子機器１０や、管理装置２０は単体で実行することも可能であるし、一部の機能を分散することも可能である。また、管理装置２０は、更に他のサーバ装置や、クラウドサービスを利用することも可能である。すなわちシステム全体として、制御部が実行する機能を実現すればよいし、記憶部に記憶する機能が何れかに記憶されていればよい。

なお、本発明の範囲は、明細書に明示的に説明された構成や限定されるものではなく、本明細書に開示される本発明の様々な側面の組み合わせをも、その範囲に含むものである。本発明のうち、特許を受けようとする構成を、添付の特許請求の範囲に特定したが、現在の処は特許請求の範囲に特定されていない構成であっても、本明細書に開示される構成を、将来的に特許請求の範囲とする意思を有する。

本願発明は上述した実施の形態に記載の構成に限定されない。上述した各実施の形態や変形例の構成要素は任意に選択して組み合わせて構成するとよい。また各実施の形態や変形例の任意の構成要素と、発明を解決するための手段に記載の任意の構成要素又は発明を解決するための手段に記載の任意の構成要素を具体化した構成要素とは任意に組み合わせて構成するとよい。これらについても本願の補正又は分割出願等において権利取得する意思を有する。「～の場合」「～のとき」という記載があったとしてもその場合やそのときに限られる構成として記載はしているものではない。これらの場合やときでない構成についても開示しているものであり、権利取得する意思を有する。また順番を伴った記載になっている箇所もこの順番に限らない。一部の箇所を削除したり、順番を入れ替えた構成についても開示しているものであり、権利取得する意思を有する。

また、意匠登録出願への変更により、全体意匠又は部分意匠について権利取得する意思を有する。図面は本装置の全体を実線で描画しているが、全体意匠のみならず当該装置の一部の部分に対して請求する部分意匠も包含した図面である。例えば当該装置の一部の部材を部分意匠とすることはもちろんのこと、部材と関係なく当該装置の一部の部分を部分意匠として包含した図面である。当該装置の一部の部分としては、装置の一部の部材としても良いし、その部材の部分としても良い。全体意匠はもちろんのこと、図面の実線部分のうち任意の部分を破線部分とした部分意匠を、権利化する意思を有する。また、装置の筐体の内部のモジュール・部材・部品等についても、図面に表示されているものは、いずれも独立して取引の対象となるものであって、同様に、意匠登録出願への変更を行って権利化を行う意思を有するものである。

１システム
１０電子機器
１００制御部
１０１プロセッサ；１０２メモリ；１０３計時部
１０４メッセージ生成部；１０５メッセージ投稿部
１０６メッセージ取得部；１０７メッセージ出力部
１０８タイミング判定部；１０９メッセージ制御部
１１０受光部
１２０表示部
１３０音声出力部
１４０レーザー受信部
１４２無線受信部
１４４位置情報取得部
１４６通信部
１５０入力部
１５２タッチセンサ
１５４マイクロホン
１５５センサ部
１６０装着部
１６２記憶媒体
１７０電源制御部
１７２端子部
１８０発光部
１９０記憶部
１９２アカウント情報記憶領域；１９４車両情報記憶領域
１９６メッセージ情報記憶領域；１９８設定情報記憶領域
２０管理装置
２００制御部
２０２メッセージ生成部；２０４メッセージ投稿部
２０６メッセージ取得部；２０８タイミング判定部
２０９メッセージ制御部
２２０記憶部
２２２アカウント情報記憶領域；２２４メッセージ情報記憶領域
２２６送信情報記憶領域；２２８投稿情報記憶領域
２４０操作部
２４５表示部
２５０通信部

Claims

車両の状態に基づいて、メッセージングサービスに投稿するメッセージを含むメッセージ情報を生成する生成部と、
前記メッセージ情報をメッセージングサービスに投稿する投稿部と、
を備えることを特徴とするシステム。
前記生成部は、前記車両の状態として、前記車両が前記車両の進行が妨げられる原因となり得る事象に接したと判定した場合に、前記事象に接したことを示す前記メッセージ情報を生成することを特徴とする請求項１に記載のシステム。
位置情報を取得する位置情報取得部を備え、
前記生成部は、前記メッセージに、前記事象に関する内容と、前記位置情報に基づいた内容とを含めることを特徴とする請求項２に記載のシステム。
前記生成部は、前記事象に関する事象詳細情報を取得し、
前記メッセージ情報に含まれるメッセージは、前記事象詳細情報に基づいて生成することを特徴とする請求項３に記載のシステム。
前記事象詳細情報には、前記事象の発生原因となることを示す内容が含まれることを特徴とする請求項４に記載のシステム。
前記事象詳細情報には、前記事象の発生範囲を示す内容が含まれることを特徴とする請求項４又は５に記載のシステム。
前記発生範囲は、前記車両の状態が前記事象に接したと最初に判定された第１の地点及び／又は前記車両の状態が前記事象に接した状態を脱したと判定された第２の地点を示す内容を含むことを特徴とする請求項６に記載のシステム。
前記事象詳細情報は、前記事象の発生範囲の距離及び／又は前記事象の発生範囲の通過時間を示す内容を含むことを特徴とする請求項４から７の何れか一項に記載のシステム。
前記事象詳細情報は、前記車両の状態が前記事象に接していることを示す状態であるとき、当該車両が走行している道路名称を含むことを特徴とする請求項４から８の何れか一項に記載のシステム。
前記事象詳細情報は、前記車両の状態として走行状態と、前記道路名称とから、前記事象が生じている当該道路の方向を含めることを特徴とする請求項９に記載のシステム。
前記生成部は、前記位置情報に基づいた地図を前記メッセージに含め、
前記地図は、前記事象詳細情報に基づいて識別表示がされることを特徴とする請求項４から１０の何れか一項に記載のシステム。
前記生成部は、前記事象詳細情報に基づいてタグを生成し、当該タグを前記メッセージに含めることを特徴とする請求項４から１１の何れか一項に記載のシステム。
前記生成部は、前記位置情報に基づいた内容として、緯度経度情報、市区町村の名称、ランドマーク名、及び交差点名の少なくとも１つを前記メッセージに含めることを特徴とする請求項４から１１の何れか一項に記載のシステム。
前記生成部は、前記事象詳細情報に基づいて絵文字を前記メッセージに含めることを特徴とする請求項４から１３の何れか一項に記載のシステム。
前記生成部は、前記事象の発生範囲の大きさ及び／又は前記発生範囲の通過時間に応じて、前記絵文字の数又は内容を変えて前記メッセージに含めることを特徴とする請求項１４に記載のシステム。
前記生成部は、画像を記憶する記憶部に記憶された前記画像に関する情報を前記メッセージに含めることを特徴とする請求項１から１５の何れか一項に記載のシステム。
前記画像は、前記車両の運転を支援するための表示画面をキャプチャしたキャプチャ画像であることを特徴とする請求項１６に記載のシステム。
前記画像は、車両の外を撮影する撮影装置が撮影した画像であることを特徴とする請求項１７に記載のシステム。
前記画像は、前記位置情報に基づいた地図であることを特徴とする請求項１８に記載のシステム。
前記生成部は、前記位置情報に基づいてタグを生成し、当該タグを前記メッセージに含めることを特徴とする請求項３から１９の何れか一項に記載のシステム。
前記生成部は、前記車両の状態として、少なくとも前記車両が渋滞に接したことを示す前記メッセージ情報を生成する請求項１から２０の何れか一項に記載のシステム。
前記生成部は、前記車両の状態から、車両又は車両の周辺に発生した事象の種類として、少なくともあおり運転、取り締まり、通行止め又は危険運転があったことを判定した場合に、当該発生した事象の種類を示す前記メッセージ情報を生成することを特徴とする請求項１から２１の何れか一項に記載のシステム。
前記生成部は、前記発生した事象の種類と、当該事象が発生した時刻に関連する情報と、当該事象が発生した道路の道路名称と、当該事象が発生した住所との少なくともいずれかを含むメッセージを生成することを特徴とする請求項２２に記載のシステム。
前記生成部は、前記発生した事象の種類、当該事象が発生した時刻に関連する情報、当該事象が発生した道路の道路名称、当該事象が発生した住所をメッセージに含める場合に、タグとして前記メッセージに含めることを特徴とする請求項２３に記載のシステム。
ユーザの選択により前記事象の種類を選択する選択部を更に備え、
前記生成部は、前記選択部により選択された事象の種類を示す前記メッセージ情報を生成することを特徴とする請求項１から２４の何れか一項に記載のシステム。
前記選択部は、タッチパネル又は音声認識装置を有することを特徴とする請求項２５に記載のシステム。
前記車両の状態に関するメッセージに対応した操作ボタンを更に設け、
前記生成部は、ユーザにより前記操作ボタンにより操作があったことを検出して、前記メッセージを生成することを特徴とする請求項１から２６の何れか一項に記載のシステム。
前記操作ボタンは、複数設けられており、
前記生成部は、前記ユーザにより操作された前記操作ボタンに対応したメッセージを生成することを特徴とする請求項２７に記載のシステム。
前記操作ボタンは、少なくとも事故を示すボタン、渋滞を示すボタンの何れかを設けていることを特徴とする請求項２８に記載のシステム。
ユーザからの音声入力を受け付ける音声入力部を更に備え、
前記生成部は、前記音声入力部から音声入力があったときに、前記メッセージを生成することを特徴とする請求項１から２９の何れか一項に記載のシステム。
前記生成部は、前記音声入力された音声データを前記メッセージ情報に含めることを特徴とする請求項３０に記載のシステム。
前記生成部は、アンケート機能を実行するための前記メッセージを生成することを特徴とする請求項１から３１の何れか一項に記載のシステム。
前記生成部は、予め定められたキーワードを前記メッセージに含めることを特徴とする請求項１から３２の何れか一項に記載のシステム。
前記キーワードは、前記車両の状態を取得する装置の製造会社名及び／又は製品名であることを特徴とする請求項３３に記載のシステム。
前記生成部は、前記車両の状態を取得する装置の製造会社名及び／又は製品名のキーワードを含める場合は、前記車両の状態と区別可能にして前記メッセージに含めることを特徴とする請求項３４に記載のシステム。
メッセージングサービスのメッセージから交通関連のキーワードを含むメッセージを取得する取得部を更に備え、
前記生成部は、前記取得したメッセージに基づいて投稿するメッセージを生成する
ことを特徴とする請求項１から３５の何れか一項に記載のシステム。
前記生成部は、前記取得したメッセージから特定される事象と、事象に関する位置を含む前記投稿するメッセージを生成することを特徴とする請求項３５に記載のシステム。
前記交通関連のキーワードは、渋滞、事故又は逆走に関する１又は複数の何れかであることを特徴とする請求項３６又は３７に記載のシステム。
前記生成部は、前記取得したメッセージから関連するメッセージを判定し、関連するメッセージをまとめて１つの前記投稿するメッセージを生成することを特徴とする請求項３６から３８の何れか一項に記載のシステム。
前記生成部は、前記関連するメッセージを表示可能なリンクに関する情報を前記投稿するメッセージに含めることを特徴とする請求項１から３９の何れか一項に記載のシステム。
前記生成部は、前記リンクに対応した２次元コードを示す画像を前記投稿するメッセージに含めることを特徴とする請求項４０に記載のシステム。
前記生成部は、前記投稿するメッセージに、前記取得したメッセージに含まれている内容を一部又は全部含めることを特徴とする請求項３６から４１の何れか一項に記載のシステム。
前記生成部は、前記取得したメッセージが、再投稿によるメッセージの場合には、前記投稿するメッセージに含めないようにする請求項３６から４２の何れか一項に記載のシステム。
前記生成部は、前記取得したメッセージが再投稿されたメッセージの場合、再投稿された回数を前記投稿するメッセージに含めることを特徴とする請求項３６から４３の何れか一項に記載のシステム。
前記生成部は、前記再投稿された回数の遷移をグラフ表示した画像を前記投稿するメッセージに含めることを特徴とする請求項４４に記載のシステム。
前記システムは、車両の状態を取得する装置と通信可能であって、
前記制御部は、前記投稿するメッセージを前記車両の状態を取得する装置に配信することを特徴とする請求項３６から４５の何れか一項に記載のシステム。
前記システムは、ユーザのアカウントを取得可能であって、
前記制御部は、前記投稿するメッセージにユーザのアカウントを識別する情報を含めることを特徴とする請求項３６から４６の何れか一項に記載のシステム。
前記ユーザのアカウントは、メッセージの投稿者のアカウントであることを特徴とする請求項４７に記載のシステム。
前記ユーザのアカウントは、管理装置にログインするユーザのアカウントであることを特徴とする請求項４７に記載のシステム。
前記生成部は、前記投稿メッセージとして、交通関連のキーワードに基づくカテゴリーと、事象の発生時刻に関連する情報と、事象が発生している道路名称と、事象が発生している住所と、予め定められたキーワードとの少なくともいずれかを含むことを特徴とする請求項３６から４９の何れか一項に記載のシステム。
電子機器と、管理装置とを含むシステムであって、
前記電子機器は、
車両の状態を参照し、投稿情報を生成し、前記投稿情報を前記管理装置に送信する制御を行う制御部と、
を備え、
前記管理装置は、
前記投稿情報を受信し、
前記投稿情報から、メッセージングサービスに投稿するメッセージを含むメッセージ情報を生成する生成部と、
前記メッセージ情報をメッセージングサービスに投稿する投稿部と、
を備えるシステム。
制御部を備え、
前記制御部は、
メッセージングサービスのメッセージから交通関連のキーワードを含むメッセージを取得し、
前記取得したメッセージから特定される事象と、事象に関する位置を含む投稿メッセージを生成し、
前記投稿メッセージを前記メッセージングサービスに投稿する、
ことを特徴とする管理装置。
コンピュータに、請求項１から５０の何れか一項に記載のシステムの前記生成部の機能を実現させるためのプログラム。