特許 6891377 絵記号を利用したログインシステム、絵記号管理サーバ、絵記号管理方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】6891377

(24)【登録日】2021年5月31日

(45)【発行日】2021年6月18日

(54)【発明の名称】絵記号を利用したログインシステム、絵記号管理サーバ、絵記号管理方法

(51)【国際特許分類】

   G06F 21/36 20130101AFI20210607BHJP

   G06F 21/31 20130101ALI20210607BHJP

【ＦＩ】

   G06F21/36

   G06F21/31

【請求項の数】7

【全頁数】24

(21)【出願番号】特願2017-87899(P2017-87899)

(22)【出願日】2017年4月27日

(62)【分割の表示】特願2016-223651(P2016-223651)の分割

【原出願日】2016年11月16日

(65)【公開番号】特開2018-60506(P2018-60506A)

(43)【公開日】2018年4月12日

【審査請求日】2019年11月5日

(31)【優先権主張番号】特願2016-194696(P2016-194696)

(32)【優先日】2016年9月30日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】302064762

【氏名又は名称】株式会社日本総合研究所

(74)【代理人】

【識別番号】100144048

【弁理士】

【氏名又は名称】坂本 智弘

(74)【代理人】

【識別番号】100186679

【弁理士】

【氏名又は名称】矢田 歩

(74)【代理人】

【識別番号】100189186

【弁理士】

【氏名又は名称】大石 敏弘

(72)【発明者】

【氏名】山谷 奈央

【審査官】 平井 誠

(56)【参考文献】

【文献】 米国特許出願公開第２０１６／００７８２１８（ＵＳ，Ａ１）

【文献】 特開２０１０−２２４８６７（ＪＰ，Ａ）

【文献】 特開２０１３−１２０４６６（ＪＰ，Ａ）

【文献】 特開２０１４−０２６５９７（ＪＰ，Ａ）

【文献】 特開２０１１−１６４９１５（ＪＰ，Ａ）

【文献】 特開２０１４−１０２５３２（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ２１／３０−４６

(57)【特許請求の範囲】

【請求項1】

ネットワークを介して商品又はサービスを提供する事業者のログインシステムであって、
ログイン画面を制御し、前記ログインシステムへの認証情報としてのテキスト若しくは絵記号又はその組み合わせを受け付けるログイン画面制御手段と、
前記ログイン画面制御手段は、テキストによる通常の認証を行うテキスト認証手段と、絵記号又はその組合せによる認証を行う絵記号認証手段とを、備え、
前記ログイン画面において、ログインＩＤ及び／又はパスワードの入力枠にテキストが入力された場合は当該テキストをそのまま認証情報として使用し、前記ログインＩＤ及び／又は前記パスワードの入力枠に絵記号がドラッグ・アンド・ドロップされた場合は当該絵記号を認証情報として使用することを特徴とするログインシステム。

【請求項2】

前記テキスト認証手段及び前記絵記号認証手段は、前記ログインＩＤ及び前記パスワードそれぞれに対して選択可能又は併用可能に制御することを特徴とする請求項１に記載のログインシステム。

【請求項3】

前記ログイン画面は、ＷＥＢブラウザ上に、絵記号によるログインのための絵記号リストを含むツールバーを備えることを特徴とする請求項１又は２に記載のログインシステム。

【請求項4】

ネットワークを介して商品又はサービスを提供する事業者のシステムである事業者システムと、ユーザが登録した絵記号を管理する絵記号管理サーバとが接続されたログインシステムであって、
前記絵記号管理サーバは、
前記ユーザの端末から受け付けた絵記号を登録する絵記号登録手段と、
前記登録された絵記号又はその組み合わせを、前記事業者システムにログインするためのログインＩＤ及びパスワードに対応させて、又はログインＩＤとパスワードの代わりの認証手段として、格納するログイン絵記号登録テーブルと、
ログイン画面を制御し、前記事業者システムへの前記認証手段としてのテキスト若しくは絵記号又はその組み合わせを受け付けるログイン画面制御手段と、
前記ログイン画面制御手段において、ログインＩＤ及び／又はパスワードの入力枠にテキストが入力された場合は当該テキストをそのまま認証情報として使用し、
前記ログイン画面制御手段において、前記ログインＩＤ及び／又は前記パスワードの入力枠に絵記号がドラッグ・アンド・ドロップされた場合は前記ログイン絵記号登録テーブルに格納された絵記号又はその組み合わせと、前記ログイン画面制御手段が受け付けた絵記号又はその組み合わせとを比較し、正規ユーザか否かを判定する絵記号判定手段と、
を備えることを特徴とするログインシステム。

【請求項5】

前記ログイン画面にテキスト若しくは絵記号又はその組み合わせを入力することによって、当該絵記号又はその組み合わせにあらかじめ対応づけられた事業者システムのＷＥＢベージを起動し、ログインを完了させることを特徴とする請求項４に記載のログインシステム。

【請求項6】

ネットワークを介して商品又はサービスを提供する事業者のシステムにおけるログイン方法であって、
前記事業者のシステムへの認証情報としてのテキスト若しくは絵記号又はその組み合わせを受け付けるログイン画面制御ステップと、
前記ログイン画面制御ステップにおいて、ログインＩＤ及び／又はパスワードの入力枠にテキストが入力された場合は当該テキストをそのまま認証情報として使用し、前記ログインＩＤ及び／又は前記パスワードの入力枠に絵記号がドラッグ・アンド・ドロップされた場合は当該絵記号を認証情報として使用するステップと、
を実行することを特徴とするログイン方法。

【請求項7】

請求項６に記載の各ステップをコンピュータに実行させることを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ＳＮＳを利用したネット商取引をサポートするシステムに関する。特にＳＮＳの絵記号を用いて顧客をサポートするシステムに関する。

【背景技術】

【0002】

近年、ＳＮＳ（Social Networking Service）の普及が目覚ましい。ＳＮＳは、単に情報発信や情報共有などのコミュニケーションツールとしてだけでなく、様々な利用方法が出現している。例えば、災害時の情報センターとしての機能や大衆から資金調達を募るクラウドファンディングなどの利用方法もある。出願人においても、ＳＮＳのシステムと金融機関のシステムを連携させ、ユーザがＳＮＳから金融取引を行える方法を提案している。例えば、特許文献１では、ＳＮＳのシステムから自然言語のメッセージを使って、銀行振込などの金融取引を行えるシステムを提案している。また、特許文献２では、ＳＮＳのシステムからイベントの登録と参加者を募り、イベントの参加費の支払を金融機関のシステムが受け付け、参加者が支払を実行すると、その支払情報を金融機関の公式シンボルとともにイベント主催者のユーザに通知するシステムを提案している。また、特許文献３では、ＳＮＳの絵記号を利用した新たな商品購入システムを提案している。

【先行技術文献】

【特許文献】

【0003】

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

【特許文献2】特開２０１５−１９７７２０号公報

【特許文献3】特願２０１６−１３３４７７号公報

【発明の概要】

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

【0004】

本発明では、絵記号を利用したログインシステム提供することを目的とする。

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

【0005】

上記課題を解決するため、本発明は、以下のような解決手段を提供する。

【0006】

（１）ネットワークを介して商品又はサービスを提供する事業者のシステムである事業者システムと、ユーザが登録した絵記号を管理する絵記号管理サーバとが接続されたログインシステムであって、前記事業者システムは、ログイン画面を制御するログイン画面制御手段と、前記ログイン画面から入力された絵記号又はその組み合わせを前記絵記号管理サーバに送信する絵記号認証手段を備え、前記絵記号管理サーバは、前記ユーザの端末から受け付けた絵記号を登録する絵記号登録手段と、前記登録された絵記号又はその組み合わせを、前記事業者システムにログインするためのログインＩＤ及びパスワードに対応させて、又はログインＩＤとパスワードの代わりの認証手段として、格納するログイン絵記号登録テーブルと、前記ログイン絵記号登録テーブルに格納された絵記号又はその組み合わせと、前記ログイン画面から入力された絵記号又はその組み合わせとを比較し、正規ユーザか否かを判定する絵記号判定手段と、を備えることを特徴とする。

【0007】

（２）上記（１）の構成において、前記ログイン画面制御手段は、テキスト情報による通常の認証を行うテキスト認証手段と、絵記号又はその組合せによる認証を行う絵記号認証手段とを選択可能又は併用可能に制御することを特徴とする。

【0008】

（３）上記（１）又は（２）の構成において、前記ログイン画面は、ＷＥＢブラウザ上に、絵記号によるログインのための絵記号リストを含むツールバーを備えることを特徴とする。

【0009】

（４）ネットワークを介して商品又はサービスを提供する事業者のシステムである事業者システムと、ユーザが登録した絵記号を管理する絵記号管理サーバとが接続されたログインシステムであって、前記絵記号管理サーバは、前記ユーザの端末から受け付けた絵記号を登録する絵記号登録手段と、前記登録された絵記号又はその組み合わせを、前記事業者システムにログインするためのログインＩＤ及びパスワードに対応させて、又はログインＩＤとパスワードの代わりの認証手段として、格納するログイン絵記号登録テーブルと、前記事業者システムへの前記認証手段としての絵記号又はその組み合わせを受け付ける絵記号受付ダイアログと、前記ログイン絵記号登録テーブルに格納された絵記号又はその組み合わせと、前記絵記号受付ダイアログが受け付けた絵記号又はその組み合わせとを比較し、正規ユーザか否かを判定する絵記号判定手段と、を備えることを特徴とする。

【0010】

（５）上記（４）の構成において、前記絵記号受付ダイアログに絵記号又はその組み合わせを入力することによって、当該絵記号又はその組み合わせにあらかじめ対応づけられた事業者システムのＷＥＢベージを起動し、ログインを完了させることを特徴とする。

【0011】

（６）ネットワークを介して商品又はサービスを提供する事業者のシステムである事業者システムと、ユーザが登録した絵記号を管理する絵記号管理サーバとが接続されたシステムにおけるログイン方法であって、前記事業者システムにおいて、ログイン画面から入力された絵記号又はその組み合わせを前記絵記号管理サーバに送信するステップと、前記絵記号管理サーバにおいて、前記ユーザの端末から受け付けた絵記号を登録するステップと、前記登録された絵記号又はその組み合わせを、前記事業者システムにログインするためのログインＩＤ及びパスワードに対応させて、又はログインＩＤとパスワードの代わりの認証手段として、ログイン絵記号登録テーブルに格納するステップと、前記ログイン絵記号登録テーブルに格納された絵記号又はその組み合わせと、前記ログイン画面から入力された絵記号又はその組み合わせとを比較し、正規ユーザか否かを判定するステップと、を含むことを特徴とする。

【0012】

（７）ネットワークを介して商品又はサービスを提供する事業者のシステムである事業者システムと、ユーザが登録した絵記号を管理する絵記号管理サーバとが接続されたシステムにおけるログインプログラムであって、前記絵記号管理サーバにおいて、前記ユーザの端末から受け付けた絵記号を登録するステップと、前記登録された絵記号又はその組み合わせを、前記事業者システムにログインするためのログインＩＤ及びパスワードに対応させて、又はログインＩＤとパスワードの代わりの認証手段として、ログイン絵記号登録テーブルに格納するステップと、前記事業者システムへの前記認証手段としての絵記号を受け付けるステップと、前記ログイン絵記号登録テーブルに格納された絵記号又はその組み合わせと、前記絵記号を受け付けるステップにおいて受け付けた絵記号又はその組み合わせとを比較し、正規ユーザか否かを判定するステップと、をコンピュータに実行させることを特徴とする。

【発明の効果】

【0013】

本発明によれば、絵記号を利用したログインシステムを提供することができる。

【図面の簡単な説明】

【0014】

【図1】本発明の実施形態に係るトークルームを利用して顧客をサポートするシステムの基本イメージを示す図である。

【図2】本発明の一実施形態に係るトークルーム管理サーバの機能構成を示す図である。

【図3A】合鍵スタンプの登録方法を説明するための図である。

【図3B】ワンタイム合鍵スタンプの生成方法を説明するための図である。

【図3C】合鍵スタンプの別の登録方法を説明するための図である。

【図4】トークルーム管理サーバのトークルームＤＢに格納されるデータ構成の一例を示す図である。

【図5】商品購入から配送までにおける、購入者、店舗、配送業者間の処理の流れの一例を示す図である。

【図6】商品購入から配送までにおける、購入者、店舗、配送業者間の処理の流れの別の一例を示す図である。

【図7】商品代金の支払方法がクレジットカードの場合に、購入者と店舗以外にクレジットカード会社をトークルームに参加させた場合の処理の流れの一例を示す図である。

【図8】商品の修理が必要な場合、購入者、店舗、メーカー間の処理の流れの一例を示す図である。

【図9】商品購入時の決済におけるトーク画面の一例を示す図である。

【図10】商品購入から消耗品の購入に至るまでのトーク画面の一例を示す図である。

【図11】商品購入後のアフターサービスにおけるトーク画面の一例を示す図である。

【図12】商品購入後の配送サービスにおける合鍵スタンプの使用例を示す図である。

【図13】ログインスタンプを実現するためのログインシステムの機能構成の概略を示した図である。

【図14】ログインスタンプを使ったログイン画面の具体例を示した図である。

【図15】ログインスタンプでＷＥＢページの自動立ち上げを実現するための機能構成の概略を示した図である。

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

【0015】

以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。以降の図においては、実施形態の説明の全体を通して同じ構成要素には同じ符号を付している。また、機能構成の図において、機能ブロック間の矢印は、データの流れ方向又は処理の流れ方向を表す。また、処理フロー図（フローチャート）においては、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。

【0016】

（基本イメージ）
図１は、トークルームを利用して顧客をサポートするシステム（以下、本システムと呼ぶ）の基本イメージを示す図である。「トークルーム」とは、ＳＮＳ上でのアプリケーションにおいて、ユーザ間でメッセージ（トーク）を会話形式でやり取りを記録する記憶領域及びそれを表示する画面であり、仲間うちだけの掲示板といった性格を持つ。トークルームの開設者は、１又は複数の参加者を指定する。トークルームが開設されると、指定された参加者は、いつでもそのトークルームに「入室」と「退室」をすることができ、そのトークルームでの会話は、トークルームに入室している間、参加者はいつでも閲覧することができる。もちろん、一度退室した参加者であっても必要なときには再度入室することが可能である。

【0017】

本システムのトークルームは、個人が商品又はサービス（以下、「商品等」と呼ぶことがある）の購入を決定したときに、その個人と購入される商品又はサービスごとに生成され、購入店舗、配送業者、製造業者、サービス／メンテナンス業者（場合によっては購入店舗とは別の店舗や保険会社を含む）などその商品等に関わる様々な事業者と、個人がＳＮＳのメッセージ（文字だけでなく画像や音声を含む）で、その商品等に関する情報のやり取りをすることができる。ここでいう「個人」とは、実際にその商品等を購入した者だけでなく、その商品を購入者から譲渡された者（「継承者」と呼ぶ）を含む。また、ここでいう「商品」は、住宅、住宅設備機器、家電製品、パソコン関連製品、複合機、家具、ペット（生体）、オートバイ、自動車、スポーツ用具、マッサージ機など、長期に渡って使い続けられる可能性が高い製品であり、購入後もメンテナンスやサポートが必要となる製品である。もちろん、メンテナンスやサポートが必要な商品であれば上記以外の商品及び関連する商品（オプション品など）を含めてもよい。また、ここでいう「サービス」には、一過性以外のサービスがほとんど含まれる。住宅の新築やリフォーム時のローンが典型例である。

【0018】

例えば、ネット店舗（ネット上だけの仮想店舗及び実店舗のネット販売部門）で家電製品（例えば掃除機）を購入したとすると、掃除機の商品情報とともに、支払方法の選択（支払方法がクレジットカードの場合にはその決済も含む）、配達日、配達時間の指定などの連絡（情報のやり取り）が店舗側と発生する。そして、商品出荷後、配送業者から配達状況の連絡や不在時の再配達の連絡が発生する。また、商品到着後には、初期不良があった場合の連絡、使用中は、商品の使い方の問い合わせやフィルタなどの消耗品の購入、故障の場合には修理の依頼など様々なやり取りが店舗以外の事業者とも発生する可能性がある。

【0019】

トークルームの参加者（最初の段階では購入者と購入先の店舗）は、第三者をトークルームに招待することができるので、トークルームを顧客とのサポート手段として利用すれば、このような複数の事業者に跨るサポートをスムーズに行うことができる。例えば、店舗に対して購入商品に関する質問がありメーカーに問い合わせる必要が生じた場合、店舗は、購入者の同意を得て、メーカー（顧客サポートセンターなど）をこのトークルームに招待する。そうすることによって、購入者は、以後メーカーと直接メッセージのやり取りをすることができる。もちろん、店舗はそのメッセージのやり取りを知ることができる。このようにすることで、当事者でいる間は、自分以外の参加者同士のやり取りを確認することができる。また、店舗にとっては、自分の店で販売したものが、きちんとメンテナンスされて長く使われているのか、故障が多いのか、故障が多い場合はどのような故障が多いのか、消耗品はどのようなタイミングで発注されるのかなどを知ることも可能となる。それらの情報は、自店で商品販売するときの商品説明に活用することができ、仕入れ商品の見直しなどにも役立てることができる。

【0020】

また、店舗が自店舗では扱っていない関連商品の質問を受けた場合は、その関連商品を扱っている他の店舗をトークルームに招待することもできる。また、車など高額で保険をかけるような商品の場合には、保険会社をトークルームに招待することもできる。また、商品を譲渡された継承者は、購入者の地位を引き継ぎ同様なサポートを得たり、継承前の商品の履歴情報（例えば、修理履歴）を知ったりすることができる。また、購入者は、家族や友人などをトークルームに参加させて、商品に対するアドバイスを受けたり、逆に商品情報を提供したりすることができる。

【0021】

このように、本システムは、ＳＮＳのトークルームを利用して、商品購入からその後のメンテナンスまで、一貫して顧客サポートを提供することができる。また、本システムのトークルームは、その商品が破棄されるか消滅するまで存続させることができ、商品のライフサイクルに渡って顧客をサポートする、言わば、「商品ライフサイクル・サポートシステム」として機能させることができる。

【0022】

（機能構成）
図２は、本システムの中核であるトークルーム管理サーバ１００の機能構成を示す図である。トークルーム管理サーバ１００（以後、単に「管理サーバ」と呼ぶ）は、商品等の購入者の端末であるユーザ端末１０と複数の事業者システム２０と接続される。ユーザ端末１０も複数であってもよく、商品等の購入者の端末である購入者端末１０ａ、購入者からその商品を譲渡された者の端末である継承者端末１０ｂを含む。また、友人や家族の端末を含んでもよい。ユーザ端末１０は、一般的なスマートフォン、タブレット端末、ＰＣ（パーソナルコンピュータ）であってよく、管理サーバと接続して情報を送受信するための専用のプログラム（アプリケーション）がインストールされているものとする。

【0023】

事業者システム２０は、購入される商品等に関係する様々な事業者のシステムの総称であり、商品等を販売する店舗の店舗システム２０ａ、店舗からの依頼を受けて商品を配送する配送業者の配送業者システム２０ｂ、商品の製造者（メーカー）の製造業者システム２０ｃ、店舗やメーカーからの依頼を受けて、商品のメンテナンスなどのサービスを提供するサービス業者のサービス業者システム２０ｄ、その他関連する業者のシステムで構成される。

【0024】

管理サーバは、ＳＮＳを運営する事業者又はその他の企業グループによって構築され運用され、トークルームを管理するためのサーバである。管理サーバは、図２で示すように、ユーザ端末通信手段１０１、ユーザスタンプ登録手段１０２、ユーザ情報ＤＢ１０３、事業者システム通信手段１０４、事業者スタンプ登録手段１０５、事業者情報ＤＢ１０６、合鍵スタンプ登録手段１０７、合鍵スタンプ判定手段１０８、トークルーム管理手段１１０、トークルームＤＢ１２０を備える。なお、上記のデータベース（ＤＢ）を管理サーバの外部に設けて、管理サーバと通信可能に接続するようにしてもよい。以下、各機能手段とＤＢについて順に説明する。

【0025】

ユーザ端末通信手段１０１は、ユーザ端末１０との通信を制御し、ユーザ端末１０からユーザＩＤとログインパスワードを受信し、本システムの登録ユーザであることの認証を行う。

【0026】

ユーザスタンプ登録手段１０２（ユーザ側の絵記号登録手段）は、スタンプ、アイコン、シンボル、イラスト、写真、その他の画像（以下、これらをまとめて「スタンプ」又は「絵記号」と呼ぶことにする）を、ユーザの登録スタンプ（登録絵記号）として、管理サーバに登録する手段を提供する。具体的には、ユーザが用意したスタンプの絵柄の電子データを受信し、スタンプに識別情報（ＩＤ）を付加し、ユーザ情報ＤＢ１０３に格納する。

【0027】

ユーザ情報ＤＢ１０３は、ユーザごとに、ユーザＩＤ、ログインパスワード、住所・氏名、メールアドレスなどのユーザの個人情報、登録スタンプＩＤ、及びユーザ側の合鍵スタンプ（合鍵絵記号）情報を格納するデータベースである。合鍵スタンプとは、スタンプを合鍵として利用し、取引の際に相手方の認証に使う特別のスタンプであるが、詳細については後述する。

【0028】

事業者システム通信手段１０４は、事業者システム２０との通信を制御し、事業者ＩＤ及びログインパスワードなどを事業者システム２０から受信し、事業者の認証を行う。

【0029】

事業者スタンプ登録手段１０５（事業者側の絵記号登録手段）は、スタンプ（絵記号）を事業者の登録スタンプとして管理サーバに登録する手段を提供する。具体的には、各事業者が用意したスタンプの絵柄の電子データを受信し、そのスタンプに識別情報を付加し、事業者情報ＤＢ１０６に格納する。

【0030】

事業者情報ＤＢ１０６は、事業者ごとに、事業者ＩＤ、ログインパスワード、事業者の居所、名称などの事業者情報、登録スタンプＩＤ及び事業者側の合鍵スタンプ情報を格納するデータベースである。

【0031】

合鍵スタンプ登録手段１０７（合鍵絵記号登録手段）は、ユーザ情報ＤＢ１０３に格納されたユーザ側の合鍵スタンプ情報と事業者情報ＤＢ１０６に格納された事業者側の合鍵スタンプ情報を読み出し、ユーザ登録スタンプと事業者登録スタンプのそれぞれ一つをユーザに選択させ、両者がそろったときにのみ、特定の処理を実行する「合鍵」として、１組又は複数組のスタンプの組み合わせを登録する。図３Ａは、この合鍵スタンプの登録方法を説明するための図である。

【0032】

図示するように、ユーザ側の登録スタンプＡ２と事業者側の登録スタンプＢ４をユーザが選択したとすると、この２つのスタンプがユーザ側と事業者側から一度に提示されたときのみに、特定の処理、例えばクレジットカードで購入する際の認証手段として、又は継承者であることの認証手段として、この特定のスタンプの組み合わせを双方の登録スタンプ情報に記憶する。ユーザ側の合鍵スタンプにクレジットカード情報を紐付けて、合鍵スタンプをクレジットカードごとに定義してもよい。例えば、クレジットカードＸで商品代金を支払いたいときは、ユーザ側の登録スタンプＡ２と事業者側（店舗側）の登録スタンプＢ４の組み合わせを合鍵とし、別のクレジットカードＹで支払いたいときは、ユーザ側の登録スタンプＡ３と店舗側の登録スタンプＢ１のスタンプの組み合わせを合鍵とする。

【0033】

図３Ａの例では登録スタンプをそのまま合鍵スタンプとして使用しているが、商品と購入日時によって、登録スタンプから一度限り有効な「ワンタイム合鍵スタンプ」の図柄をその都度生成するようにしてもよい。その場合は、ユーザ側と事業者側の合鍵スタンプ情報には、その生成ロジック（プログラム）及びワンタイム合鍵スタンプが格納される。

【0034】

図３Ｂは、ワンタイム合鍵スタンプの生成方法を説明するための図である。ワンタイム合鍵スタンプは、登録合鍵スタンプ（登録合鍵絵記号）から生成される。すなわち、ユーザ側及び事業者側の登録合鍵スタンプを所定のルールで変換してそれぞれのワンタイム合鍵スタンプ（ワンタイム合鍵絵記号）を生成する。図の例では、登録合鍵スタンプは亀と兎の図柄であるが、ワンタイム合鍵スタンプは、それぞれの登録合鍵スタンプに共通要素を持つ絵柄（図の例では人物や葉の絵柄）の画像を合成して生成している。追加する絵柄の画像は他の登録スタンプであってもよい。このようにすることで、登録合鍵スタンプの組み合わせさえ覚えていれば、ワンタイム合鍵スタンプの正しい組み合わせが類推できる。したがって毎回異なるワンタイム合鍵スタンプが表示されても、対応するワンタイム合鍵スタンプを候補スタンプの中から正しく選択することができる。なお、合鍵スタンプ情報の表示や変更は、別途厳重な認証手段（指紋認証など）で管理されるのは言うまでもない。

【0035】

図３Ｃは、合鍵スタンプの別の登録方法を説明するための図である。以下、ここでいう「商品」にはサービスを含んでもよい。合鍵スタンプは、事業者が店舗である場合、ユーザ登録スタンプと購入者が商品を閲覧したときの商品情報（商品名、商品のキーワード、商品画像など）からも生成できる。図の例では、ユーザ登録スタンプＡ３と店舗が備える商品情報ＤＢに格納される商品Ｂ１（ブーツ）の画像を合成して合鍵スタンプＡ３−Ｂ１を生成している。この生成は、購入者が商品Ｂ１を閲覧し、所定の操作（例えば、「お気に入り」に登録したときなど）をしたときに生成される。

【0036】

また、商品情報ＤＢに適当な商品の画像が無くても、その商品のキーワードから画像を別途取得し、ユーザ登録スタンプと合成し、合鍵スタンプを生成することもできる。図の例では、ユーザ登録スタンプＡ２と商品Ｂ４のキーワード（バッグ）から取得可能な画像から合鍵スタンプＡ２−Ｂ４を生成している。このような合鍵スタンプの登録方法は、事業者側に登録スタンプを用意しておく必要がなく、ユーザ独自で合鍵スタンプを合成できるという利点がある。ただし、このようにして生成された合鍵スタンプは、お互いに相手を認証するという本来の目的からは外れるので、その利用方法については後述する。

【0037】

図２に戻り、合鍵スタンプ判定手段１０８（合鍵絵記号判定手段）は、トークルーム（トーク画面）で、特定の取引において、ユーザ側と事業者側双方から提示されたスタンプを突合し、合鍵スタンプ情報で登録された組み合わせと一致するか否かを判定し、一致すると判定された場合にのみ、特定の取引を実行させる機能を有する。ここで特定の取引としては、クレジットカードでの決済の他、購入者の継承の認証、商品の保証書の認証などにも用いられる。購入者が商品を転売などで他の者に譲渡した場合は、登録合鍵スタンプの情報も継承者に譲渡されるようにしてもよいし、継承者が新たに合鍵スタンプを登録し直してもよい。

【0038】

商品の保証書の認証は、商品が購入者のもとに到着したときに、保証書の合鍵スタンプを購入者と店舗との間で登録させるようにする。このようにすることで、購入者に対して正確な保証期間を提示することができる。また、保証書の偽造防止にもなる。

【0039】

トークルーム管理手段１１０は、商品又はサービスの購入時に、ユーザごと及び商品又はサービスごとに専用のトークルームを生成するトークルーム生成手段１１１、参加者のトークルームへの入退室を管理するトークルーム入退室管理手段１１２、購入者であるユーザが商品を転売するなどして他のユーザに譲渡したときに、その譲り渡されたユーザを新たな購入者として継承させるユーザ継承手段１１３、商品が破棄されたときやその他の事情が発生したときに、ユーザ側の要求に応じてトークルームの情報をすべて消去するトークルーム消去手段１１４を備えている。

【0040】

また、トークルーム生成手段１１１は、ネットショップから商品又はサービスを購入したときにトークルームを生成するだけでなく、実店舗から商品又はサービスを購入したときでも、クレジットカードの決済情報などからトークルームを生成することもできる。すなわち、クレジットカードの決済情報をトリガに（商品又はサービスの購入代金の決済が完了した際に）トークルームを生成することができる。

【0041】

また、トークルーム入退室管理手段１１２は、事業者の仕事が完了したことを示す情報（例えば、仕事の完了を示すメッセージが投稿されたとき、所定期間メッセージが投稿されないときなど）を検知したときは、その事業者をトークルームから退出させる機能を有する。図示は省略するが、「事業者継承手段」を備えていてもよい。事業者の継承は、事業者の合併や事業の移管などによって生じる。

【0042】

また、図示は省略するが、トークルーム管理手段１１０には、複数のトークルームを関連付ける「トークルーム関連付手段」、関連するトークルームに投稿されたメッセージを別のトークルームに投影（反映）する「トークルーム投影手段」、長期に渡って存続するトークルーム内をキーワードやスタンプで効率よく検索することができる「トークルーム検索手段」を備えてもよい。

【0043】

トークルームＤＢ１２０は、トークルームに投稿（送信）されたメッセージ、スタンプを累積的に記憶するデータベースである。より詳細には図４に例示するように、トークルームごとに、トークルームＩＤ、トークルーム名、生成者ＩＤ、生成日時、商品ＩＤ、購入者ＩＤ、購入店舗ＩＤ、製造者ＩＤ、及びそれらの名称（ニックネーム）などが格納され、メッセージ（トーク）が投稿されるごとに、投稿日時、投稿ユーザＩＤ、メッセージ内容（スタンプ含む）、メッセージステータス（未読、既読、編集済など）が格納される。

【0044】

既存のＳＮＳのトーク、例えばＬＩＮＥ（登録商標）などでは一度送信したメッセージやスタンプは修正できないが、本システムのトークルームでは、相手が未読の場合はメッセージやスタンプの修正や削除ができる（修正した場合はメッセージステータスに「編集済」と表示される）ので、誤ってメッセージやスタンプを投稿してしまった場合でも対処が可能である。また、トークルーム名は、商品ＩＤ（サービスＩＤ）若しくは商品名（サービス名）又は購入者ＩＤ若しくは購入者名から自動生成されるが、購入者が識別しやすい名称に変更することもできる。もちろん、購入者、購入店舗を始めとする事業者のトークルーム上の名称も同様に識別しやすいものに変更できる。

【0045】

上記で説明した本システムの機能構成は、あくまで一例であり、一つの機能ブロック（データベース及び機能処理部）を分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。各機能処理部は、コンピュータシステムにおいて、サーバや端末の装置に内蔵されたＣＰＵ（Central Processing Unit）が、ＲＯＭ（Read Only Memory）、フラッシュメモリ、ＳＳＤ(Solid State Drive)、ハードディスクなどの記憶装置に格納されたプログラムを読み出し、ＣＰＵにより実行されたプログラムによって実現される。すなわち、各機能処理部は、このプログラムが、記憶装置に格納されたデータベース（ＤＢ;Data Base)やメモリ上の記憶領域からテーブルなどの必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。

【0046】

（処理フロー）
以下、本システムの参加者間の処理の流れを説明する。以降の図面中の丸付の番号は、処理ステップの順序を表し、以下のかっこ付の番号に対応している。また、特に断らない限り、「購入者」とは、商品の購入者自身又は購入者の端末（ユーザ端末１０）を表し、「店舗」とは、購入店舗のシステム（店舗システム２０ａ）又は場合によってはその店舗の店員を表すこととする。ただし、実際の処理は管理サーバで行い、その結果をユーザ端末１０又は店舗システム２０ａに送信し、トーク画面上では、あたかもユーザ端末１０又は店舗システム２０ａで処理されたように見せかけてもよい。

【0047】

また、「Ｓ_Ａ」は購入者側のスタンプ、「Ｓ_Ｂ」は購入店側のスタンプ、「Ｓ_カ」、「Ｓ_ｃ」はクレジットカード会社のスタンプ、「Ｓ_配」は配送業者のスタンプ、「Ｓ_保」はメーカー保証期間中のスタンプを表すものとし、メーカー又はサービス業者が入室したときに商品が保証期間中である場合に自動的に表示するようにしてもよい。もちろん、保証期間中でない場合はそのスタンプを自動的に消去するようにしてもよい。なお、特に「Ｓ_Ａ」、「Ｓ_Ｂ」、「Ｓ_ｃ」は、それぞれ事前に合鍵として登録された「合鍵スタンプ」を表すものとする。

【0048】

図５は、商品購入から配送までにおける、購入者、店舗、配送業者間の処理の流れの一例を示す図である。この場合、本システムでは以下の処理が実行される。ただし、一部に人間が行うステップを含んでいる（以下同じ）。
（１）店舗から商品の購入画面を送信する（この段階ではまだトークルームは生成されない）。
（２）購入者が購入を決定すると、ワンタイム合鍵スタンプの場合は、この段階で店舗との合鍵スタンプＳ_Ａをユーザ側の登録スタンプから生成する。登録合鍵スタンプの場合は、その合鍵スタンプを選択する。
（３）購入者から購入要求を店舗に送信する。
（４）店舗でユーザの登録を確認し、合鍵スタンプＳ_Ｂを店舗側の登録スタンプから生成する（ワンタイム合鍵スタンプの場合）。
（５）トークルームを生成する。このとき、トークルーム名を商品名、ユーザ名などから自動生成する。
（６）店舗が合鍵スタンプＳ_Ｂを送信する。
（７）購入者が合鍵スタンプＳ_Ａを送信する。
（８）店舗から合鍵スタンプ判定結果を購入者に送信する。
（９）判定の結果、両者の合鍵スタンプが適合した場合、支払方法がクレジットカードの場合はクレジットカード決済が実行され、正常に決済が完了すれば店舗は商品を発送する。支払方法が代引きの場合はそのまま商品を出荷する。なお、図示は省略するが、支払方法が振込の場合は、振込が実行されるまでこの段階で待機する。
（１０）店舗から配送業者に通知する。
（１１）通知を受けた配送業者がトークルームに入室する。このとき入室を表す配送業者のスタンプを送信してもよい。
（１２）配送状況を送信する。
（１３）購入者はその配送状況をチェックする。
（１４）配送（商品の配達）を実行する。このとき、支払方法が代引きの場合は、配送業者は商品と引き換えに代金を徴収する。
（１５）購入者が受領確認を送信する。
（１６）配送業者がトークルームから退室する。

【0049】

図６は、商品購入から配送までにおける、購入者、店舗、配送業者間の処理の流れの別の一例を示す図である。この処理では、ステップ（６）で購入者側から合鍵スタンプを先に送信し、ステップ（７）で店舗側の合鍵スタンプを送信し、ステップ（８）で合鍵スタンプの判定結果を購入者から店舗に送信し、ステップ（９）で支払承認を行う以外は図５の処理の流れと同様である。

【0050】

このようにすることで、商品の購入時の決済から配送完了までを一貫してトークルームを利用して行うことができる。また、図５、図６の処理を併用することによって、購入者、事業者の合鍵スタンプどちらが先に送信されても相手側は対処することができる。

【0051】

図７は、商品代金の支払方法がクレジットカードの場合に、購入者と店舗以外にクレジットカード会社（以下、カード会社）をトークルームに参加させた場合の処理の流れの一例を示す図である。この場合、本システムでは以下の処理が実行される。
（１）、（２）の処理は図５の場合と同じなので省略する。
（３）購入者は、特定のクレジットカード（ここではクレジットカードＸとする）で支払うことを決めている場合は、このステップでクレジットカードの名称のみを店舗側に送信する。クレジットカード番号、名義人、有効期限、セキュリティコードなどは送信する必要はない。
（４）店舗はユーザＩＤとログインパスワードからユーザの登録を確認する。
（５）ユーザの登録が確認されると、トークルームを生成する。
（６）この段階でカード会社にユーザが店舗に登録した情報（住所、氏名など）及び店舗側から商品の価格、送料を含む商品購入情報が通知される。
（７）通知を受けたカード会社がトークルームに入室する。
（８）購入者は購入者側の合鍵スタンプＳ_Ａを店舗に送信する。この合鍵スタンプＳ_Ａにはカード番号が紐付されているものとする。
（９）ワンタイム合鍵スタンプの場合、カード会社は、ここでカード会社側の合鍵スタンプＳ_Ｃを生成する。
（１０）カード会社がカード会社側の合鍵スタンプＳ_Ｃを送信する。
（１１）購入者側で合鍵スタンプの適合を判定する。あるいは管理サーバで判定を行いその結果を購入者側に通知する。
（１２）合鍵スタンプが適合した場合、購入者からカード会社に決済要求を送信する。
（１３）カード会社側でカード決済が完了すると、店舗側に通知する。このとき、店舗側にカード会社が立て替えた商品代金を支払う。
（１４）カード会社から決済完了を通知されると店舗側は商品を出荷する。このとき、配送業者に商品の配達を依頼する。
（１５）カード会社は購入者の口座から代金の引落を完了する。
（１６）カード会社はトークルームから退室する。

【0052】

このようにすることで、店舗側にクレジットカード番号などを送信して、店舗とカード会社の間でカード決済させるのではなく、クレジットカード番号を店舗に知らせることなく、カード会社と直接カード決済を完了することができる。なお、カード会社との合鍵スタンプの登録方法は店舗の場合と同様である。

【0053】

図８は、商品の配送後に初期不良などで商品の修理が必要な場合、購入者、店舗、メーカー間の処理の流れの一例を示す図である。この場合、本システムでは以下の処理が実行される。
（１）配送業者から配送完了通知が店舗に送信される。
（２）店舗では、その商品のメーカーの情報を取得する。
（３）店舗は、メーカーでメンテナンスを行う商品であることを確認後、メーカーに通知する。このとき、商品のシリアル番号などが送信される。
（４）店舗から通知を受けたメーカー（顧客サポートセンターなど）は、既に存在しているその顧客のその商品のトークルームに入室する。このとき、保証期間中であれば、そのことを示す保証期間スタンプ「Ｓ_保」を送信するようにしてもよい。保証期間が過ぎていればその旨を表すスタンプを送信してもよい。また、購入者に会員登録などを促すメッセージを送信してもよい。
（５）更にメーカーは、サービス情報や保証情報のメッセージを送信する。サービス情報には購入者の最寄りのサービスセンターなどの情報が含まれる。
（６）この段階で、購入者からメーカーに直接、各種の問い合わせ、オプションや消耗品の購入等を受け付けられる状態になる。
（７）商品が故障した場合は、トークルームから修理依頼を出すことができる。
（８）修理依頼が出されると修理サービスが購入者に提供される。この段階では、故障品の引き取り、修理中の代替製品の提供、出張修理サービスなどが提供される。
（９）修理が完了したときは、購入者は修理完了確認を送信する。
（１０）修理確認通知を受けたメーカーは、トークルームからいったん退室する。
（１１）その後、商品の保証期間が終了するまでトークルームの参加者にとどまるようにしてもよい。
（１２）そして、保証期間が終了したときには、トークルーム退室していてもメーカーから店舗と購入者に通知を送信するようにしてもよい。

【0054】

このようにすることで、商品購入後も、メーカーに対して直接問い合わせを行ったり、オプションや消耗品を購入したり、商品の修理を依頼したり、トークルームを利用して商品のアフターケアを一貫して行うことができる。

【0055】

（画面例）
以下では、実際のトーク画面におけるメッセージやスタンプのやり取りの具体例について説明する。図９は、商品購入時の決済におけるトーク画面の一例を示す図である。この図は、掃除機を購入しようとするユーザが、商品代金の支払をクレジットカードで行う場合に、合鍵スタンプを使って店舗と購入者がお互いに相手を認証する様子を示している。図９（ａ）は、合鍵スタンプの組み合わせが予め登録した組み合わせに一致せず、認証がＮＧとなった場合を示し、図９（ｂ）、（ｃ）は、合鍵スタンプの組み合わせが一致した場合を示している。この例では、店舗側から先に合鍵スタンプを送信し認証を行っているが、店舗側の合鍵スタンプは自動的に選択される。トークルームの名称は、製品名から自動的に生成される。この例では、商品名から「〇〇掃除機トークルーム」となっているが、購入者の名前を含め「Ａさんの掃除機○〇のトークルーム」などとしてもよい。

【0056】

購入者側の合鍵スタンプの送信は、画面下の候補スタンプ表示欄４００からスタンプを選択（タッチパネルではタップ）することで行われる。候補スタンプ表示欄４００は、直前の店舗側からのメッセージの内容を解析して、スタンプの入力が必要となったときに自動的に表示されるようにしてもよい。図９（ａ）の画面で、合鍵スタンプを間違って選択し、認証ＮＧとなった場合は、スタンプを置いた場所（符号３００で示す場所）をタップし、再度、候補スタンプ表示欄４００から、正しいスタンプを選んで認証をやり直すことができるようにしてもよい。もちろん、所定回数やり直しても認証がＮＧになった場合は、その後一定期間認証が行えなくなるようにする。すなわち、スタンプが暗証番号やパスワードの代わりになる。なお、既に述べたように、合鍵スタンプの組み合わせは１つでなくともよいので、店舗側から表示される登録スタンプをランダムに入れ替えてもよい。

【0057】

また、図９（ｂ）の画面のように認証ＯＫの場合、画面上に表示された合鍵スタンプ２００と合鍵スタンプ３０１は、図９（ｃ）のように、直ちに非表示（消去）にしてもよい。合鍵スタンプの露出を少しでも減らすためである。

【0058】

図１０は、商品購入から配送、消耗品の購入に至るまでのトーク画面の一例を示す図である。この図では、掃除機のクレジットカードでの決済が完了し、店舗から商品が出荷されると、店舗から通知を受けた配送業者がトークルームに入室し、配達状況を逐次購入者に送信する様子を示している。配送業者からのメッセージは、荷物が配送業者の配達拠点を通過するたびに自動的に送信される。不在時の再配達の依頼などもこの画面を通じて行える。配達が正常に完了すると、配送業者は自動的にトークルームから退室する。このとき、退室を示すメッセージ５００がシステムから自動的に送信される。

【0059】

配送業者が退室すると、再び店舗からのメッセージを受信できる状態になる。この例では店舗から配達完了日を基準としたメーカーの保証期間が通知されている。商品到着時のアンケートなどもこの段階で行ってもよい。また、メッセージ５０１のように、この掃除機のフィルタの価格をこの画面から問い合わせることもできる。この時点では商品名は既に分かっているのでフィルタの型番などを入力する必要はない。このようにすることで、商品を届けた後でも、更なる商品販売に繋げることができる。

【0060】

図１１は、商品購入後のアフターサービスにおけるトーク画面の一例を示す図である。この例では、ネット上のペットショップから犬の生体を購入した「Ａさん」のもとにペットショップから送られたメッセージを契機にして、「Ａさん」が動物病院の獣医に相談する様子が示されている。

【0061】

本システムのトークルームでは、メッセージに付加するスタンプは任意の画像とすることができるので、写真スタンプ５１０のように実際にペットの写真を送ることもできる。もちろんスタンプの画像の拡大縮小も可能である。また、「元気ですか」、「そうしました」、「了解」、「ありがとう」、「ではまた」などのような決まりきったメッセージは、スタンプだけで行ってもよい。このようにすることで、購入者の近くに実店舗を持たないペットショップであっても、ユーザフレンドリーなメッセージやスタンプを使って顧客のサポートを行うことができる。

【0062】

（変形例１）
図１２は、商品購入後の配送サービスにおける合鍵スタンプの使用例を示す図である。
合鍵スタンプは、決済の場面以外でも使用できるのは前述したとおりであるが、ここでは合鍵スタンプが商品情報と紐付けられることを利用して、購入した商品の情報を後で確認するために使用する「確認スタンプ」について説明する。

【0063】

図１２の画面は、商品をまとめて買った購入者のもとに、後日配送業者から専用のトークルームに対してメッセージが届いた場面を示したものである。ここでいう専用トークルームとは、いままで説明したような購入した商品ごとのトークルームではなく、商品ごとのトークルームをカテゴリごとに分類したトークルームである。このカテゴリとしては、例えば、特定の店舗、特定の時期、特定の商品カテゴリなどに分類できる。すなわち、トークルームのカテゴリ分類手段をトークルーム管理サーバ１００に備えるようにする。この専用トークルームを使えば、購入者は商品ごとでなく、カテゴリごとにまとめて何らかの処理を各事業者に依頼することができる。

【0064】

図の例ではトークルームの名称として、商品ごとのトークルームをまとめて、「Ａさんが９月に購入した商品」という専用トークルームが生成され、このトークルームに配送業者が配達予定を投稿した場面を示している。ただし、配送業者は、この専用トークルームの存在を意識する必要はない。本来の商品ごとのトークルームに投稿されたメッセージは、この専用トークルームにも自動的に投影されるからである。ここで「投影」とは、関連する複数のトークルームがあった場合、そのうちの１つのトークルームにメッセージを投稿するだけで他のトークルームにも自動的に反映される機能をいう。この機能は、トークルーム管理手段１１０に「トークルーム関連付手段」と「メッセージ投影手段」を設けることで実現できる。

【0065】

配送業者から配達予定のメッセージを受け取った購入者は、多数の商品を毎月のように複数のネットショップなどから購入しているユーザであり、購入した商品をいちいち覚えていないものとする。このような場合、専用トークルームから初めての配送業者からの配達予定を受け取ると何が届くのか確認する必要がある。しかし、従来の方法では、店舗のサイトにまずログインし、配送情報を商品ごとに確認しなければならない。そもそも、どこの店舗で買ったかも覚えていないこともある。しかし、合鍵スタンプを確認スタンプとして使用し、その商品が確かに特定の店舗から購入したものであることをトークルームから容易に確認することができる。もちろん文字入力は不要である。したがって、商品の誤配達の防止、買ってもいない商品を送りつけるような詐欺を防止することにも役立つ。また、上記の例では配送業者とのトーク場面を取り上げたが、口座番号やクレジットカードなど重要情報や個人情報の入力を求めるような要求があった場合などは、その要求に回答してよい相手かどうかの確認が可能となる。

【0066】

(変形例２）
合鍵スタンプは、更に別の使用方法として、ログインＩＤとパスワードとしても利用できる。すなわち、様々なログイン画面ごとのログインＩＤとパスワードを、それぞれ１又は複数の絵記号に対応させて登録しておき、登録された絵記号の組み合わせが正しい組合せであったときにログインが完了させるようにする。この場合の合鍵スタンプを、特に「ログインスタンプ」（ログイン絵記号）と呼ぶことにする。なお、合鍵スタンプ、確認スタンプ、ログインスタンプをまとめて、より一般的に「認証スタンプ」（認証絵記号）と呼んでもよい。

【0067】

図１３は、ログインスタンプを実現するための「ログインシステム」として、ユーザの絵記号を管理する絵記号管理サーバ６００、ネットワークを介してサービスを提供する任意の事業者のシステムである事業者システム２０、及びユーザ端末１０の機能構成の概略を示したものである。

【0068】

絵記号管理サーバ６００は、図２で示したトークルーム管理サーバ１００の一部の機能を再構成したものであり、ユーザが用意したスタンプを登録するスタンプ登録手段６０１（ログインシステムにおける絵記号登録手段）、システムによって必要なユーザの各種の情報を格納するユーザ情報ＤＢ６０２、事業者システム２０から受信したログインスタンプが正規のものか否かを判定する絵記号判定手段６０４を備えている。ユーザ情報ＤＢ６０２には、ログインスタンプ登録テーブル６０３（ログイン絵記号登録テーブル）を含み、ログインスタンプ登録テーブル６０３には、ユーザが登録したサイトごとに、そのＵＲＬ、ログインＩＤ、パスワードが格納され、それぞれのログインＩＤ及びパスワードに１又は複数のスタンプを対応づけて格納される。ログインスタンプ登録テーブル６０３の情報は、暗号化されて格納されるのは言うまでもない。

【0069】

事業者システム２０は、ユーザが登録したサイトを管理し、ネットワークを介して商品又はサービスを提供するための任意のシステムであるが、ここでは正規ユーザを認証するための認証手段のみを示している。ログイン画面制御手段２１は、ユーザ端末１０から、ログインＩＤ及びパスワードを受け付けるためのログイン画面を制御する。ログインＩＤ及びパスワードは、通常はテキスト情報であるが、事業者システム２０のログイン画面制御手段２１は、テキスト情報による通常の認証を行うテキスト認証手段２２と、絵記号による認証を行う絵記号認証手段２３とを選択可能に制御することができる。また、テキスト情報による認証と絵記号による認証を併用するように制御してもよい。例えば、ログインＩＤはテキスト情報とし、パスワードは複数の絵記号の組み合わせとするなどである。また、ログインＩＤとパスワードの組み合わせを、１又は複数の絵記号と紐付けてもよい。このようにすることで、絵記号をログイン画面上にドラッグ＆ドロップするだけでワンタッチでログインが行うことができる。

【0070】

絵記号認証手段２３は、ユーザ端末１０から絵記号の組み合わせの入力を受け付け、入力された絵記号の組み合わせと、当該ログイン画面のＵＲＬとを絵記号管理サーバ６００に送信し、ログインスタンプ登録テーブル６０３にあらかじめ格納された当該ＵＲＬのログインＩＤ及びパスワードの絵記号と、事業者システム２０のログイン画面から入力された絵記号の組み合わせとを比較し、両者の絵記号の組み合わせが一致するか否かを判定し、その判定結果を事業者システム２０に送信する。事業者システム２０は、この判定結果を受けて正規ユーザか否かを判断する。

【0071】

図１４は、ログインスタンプを使ったログイン画面の具体例を示した図である。図示する事業者システムのログイン画面７００は、ＷＥＢブラウザのログイン画面の例であり、ログインスタンプを実現するためのツールバー７０１があらかじめインストールされているものとする。ツールバー７０１にはユーザが登録したスタンプのリストを表示するためのスタンプリストボタンを備える。ここで表示されるスタンプリスト７０２には、ユーザが登録したスタンプ以外にもダミーのスタンプを含めるようにしてもよい。なお、ツールバー７０１にはスタンプを登録するため手段としてスタンプ登録ボタンを備えるようにしてもよい。

【0072】

ユーザが、表示されたスタンプリスト７０２から所定のスタンプを選択し、ログインＩＤ入力欄７０３及びパスワード入力欄７０４に、それぞれスタンプをドラッグ＆ドロップすると、事業者システム２０の絵記号認証手段２３は、ログインＩＤ及びパスワードとして選択された絵記号の組み合わせを、絵記号管理サーバ６００に送信する。既に述べたように、選択する絵記号は複数であってもよいし、登録された複数の絵記号を１つに合成した合成絵記号であってもよい。上記の画面例では、ＷＥＢブラウザを使ったログイン画面について説明したが、スマートフォンやタブレット端末などで、ログインの機能が専用のアプリケーションで実現されている場合は、ツールバー７０１の機能をアドインとして、そのアプリケーション側に提供するようにしてもよい。なお、絵記号による認証方式をユーザに選択させる手段として「絵記号キーボード７０５」を、テキスト認証におけるソフトウェアキーボードを選択させることと同じように、ログイン画面７００に表示するようにしてもよい。

【0073】

図１３のログインシステムは、絵記号でログインするだけでなく、絵記号によって所定のＷＥＢページを自動的に立ち上げる機能を持たせることもできる。図１５は、絵記号（ログインスタンプ）でＷＥＢページの自動立ち上げを実現するための機能構成の概略を示した図である。図示するように、絵記号管理サーバ６００Ａに、絵記号の入力を受け付け、自動ログインするための絵記号受付ダイアログ６０５を設け、絵記号受付ダイアログ６０５に絵記号を入力（ドラッグ＆ドロップ）すると、その絵記号にあらかじめ対応づけられた事業者システム２０のＷＥＢベージを起動し、自動的にログインまでを完了するようにできる。

【0074】

図１５のログインスタンプ登録テーブル６０３（絵記号登録テーブル）には、登録された絵記号又はその組み合わせを、事業者システム２０にログインするためのログインＩＤ及びパスワードに対応させて、又はログインＩＤとパスワードの代わりの認証手段として格納する。また、図示は省略するが、事業者システム２０に絵記号管理サーバ６００Ａの機能を取り込んでもよい。その場合、事業者システム２０は、通常のログインＩＤとパスワードによるテキスト認証手段だけでなく、絵記号による認証手段も可能となる。絵記号による認証手段では、図１４のログイン画面において、ログインＩＤ入力欄７０３とパスワード入力欄７０４は不要となり、スタンプリスト７０２（絵記号リスト）から所定の絵記号を選択するだけでログインが可能となる。

【0075】

（実施形態の効果）
本システムによれば、ＳＮＳのトークルームを用いて新たな顧客サポートを提供することができる。本システムにより、従来はメーカーしか知り得なかった販売後のサポート情報を店舗が共有できる。購入店舗を始めとする事業者は、購入者ごと、及び商品ごとに生成されたトークルーム上で、メッセージやスタンプを使ってユーザフレンドリーな方法でサポートやサービスを行うことができる。また、商品購入時の代金の決済から、商品の配送、商品に関する質問、オプションや消耗品の購入、修理など、その商品が破棄されるまで一貫してサポートを継続することができる。その商品が長期間に使用され、その間に、たとえ事業者が廃業になったとしても、その事業を継承した事業者が引き続きその顧客に対してサポートを続けることができる。また、購入者が商品を譲渡しても、譲渡された者が購入者の地位を継承することができるので、購入者と同等なサポートを引き続き受けることができる。もちろん、譲渡された者も、譲渡される前の商品の履歴情報も知ることができる。また、トーク部屋には、商品・サービスに関連する情報が関連付けて記憶される。例えば、保証書情報、商品の仕様を含む商品情報やサービスの内容、等が考えられる。この商品・サービスの関連情報がトーク部屋ごとに関連付けられているので、ユーザは問い合わせに際して、どこでいつ買ったか、どんな商品・サービスなのかの説明等が不要となり、サポートする側は、例えば消耗品や交換部品も即座に特定できる。なお、トーク部屋では、写真や動画なども共有できるため、顧客からの事情説明、サポートからの回答説明も分かりやすくなることは言うまでもない。

【0076】

このように、本システムのトークルームは、長期に使用する商品や長期に渡るサービスにおいて、顧客を継続的にサポートするための非常に有用なツールとなる。例えば、野球チームなどがスポーツ用具店と一度付き合いを始めると、２０年、３０年と付き合いが続き、新しいメンバーが新しい背番号のユニフォームを作るたびに、文字の字体、帽子の刺繍など細かな指定をする必要があるが、このような場合、本システムを使えば、その都度指定する必要がなくなる。また、住宅の購入では、最初は住宅メーカーや不動産会社、次に住宅ローンの金融機関、そしてリフォーム会社などが次々に登場するが、本システムを使えば、たとえ業者が変わっても継続性のある顧客サービスを提供できる。また、合鍵スタンプや確認スタンプを使うことで、決済時の認証や正規の事業者であるかどうかの確認が簡単に行える。また、被保険者が家族構成や収入の変化などで生命保険や医療保険を見直したい場合に、本システムのトークルームを使えば、現在の保険の契約内容が簡単に検索できる。また、「保険」というカテゴリの専用ト−クルームを生成すれば、複数の保険会社に相談したり、複数の保険商品を一度に検索したりすることが可能となる。

【0077】

また、合鍵スタンプによって、商品購入時の決済の認証、継承者の認証、保証書の認証精度を高めることができる。合鍵スタンプは、登録されたスタンプを用いてもよいし、登録合鍵スタンプとその他の登録スタンプを合成することで、一度限りのワンタイム合鍵スタンプを生成してもよい。また、合鍵スタンプは、上述の目的以外にも、様々な場面で商品情報や相手の情報を確認するための確認スタンプとしても使用できる。

【0078】

また、絵記号を用いたログインシステムの認証方式では、テキスト情報を入力する必要がないのでログイン操作が簡単になる他、事業者システムと絵記号管理サーバとの間で、ユーザのログインＩＤとパスワードのテキスト情報がやり取りされることはないので、より安全性が高まる。また、使用する絵記号の数や組み合わせを使い分けすることで、ログインを簡単にしたり逆に厳格にしたりして、様々なセキュリティレベルを設定することができる。

【0079】

以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されないことは言うまでもない。上記実施形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。またそのような変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。なお、上記の実施形態では、本発明を物の発明として、顧客サポートシステムについて説明したが、本発明は、方法の発明（顧客サポートシステムにおける管理方法）又はコンピュータ・プログラムの発明（顧客サポートプログラム）としても捉えることもできる。

【0080】

（付記）
なお、本発明をトークルームに関する発明として捉えたとき、又はログインシステムの発明として捉えたときの請求項を以下に付記する。
［請求項１］
ＳＮＳを利用した顧客サポートシステムにおける管理サーバであって、
購入者が店舗で商品又はサービスの購入を決定した際に、前記購入者と前記店舗との間のメッセージを記録するトークルームを生成するトークルーム生成手段と、
前記購入者、前記店舗、及び前記購入者又は前記店舗から招待され前記商品又はサービスに関わる事業者の、前記トークルームの入退室を管理するトークルーム入退室管理手段と、を備え、
前記購入者に対する商品又はサービスの代金の決済又は購入後のサポートを、前記トークルームに入室した事業者に対するメッセージ又は絵記号の投稿によって受け付けることを特徴とする管理サーバ。
［請求項２］
前記トークルーム生成手段は、前記商品又はサービスの購入代金の決済が完了した際に、前記トークルームを生成することを特徴とする請求項１に記載の管理サーバ。
［請求項３］
前記商品が破棄されたとき又は前記購入者の要求に応じて、前記トークルームを消去するトークルーム消去手段を備えることを特徴とする請求項１又は２に記載の管理サーバ。
［請求項４］
前記商品が譲渡された際に、前記商品を譲渡された者を前記商品の履歴情報を継承させるユーザとして登録するユーザ継承手段を備えることを特徴とする請求項１から３までのいずれか１項に記載の管理サーバ。
［請求項５］
前記事業者は、配送業者、製造業者、又はサービス業者であることを特徴とする請求項１から４までのいずれか１項に記載の管理サーバ。
［請求項６］
前記事業者は、他の店舗又は保険会社であることを特徴とする請求項１から５までのいずれか１項に記載の管理サーバ。
［請求項７］
前記製造業者又は前記サービス業者が前記トークルームに入室した際に、前記商品の保証期間を表す絵記号を提示する請求項５に記載の管理サーバ。
［請求項８］
ＳＮＳを利用した顧客サポートシステムにおける管理方法であって、
購入者が店舗で商品又はサービスの購入を決定した際に、前記購入者と前記店舗との間のメッセージを記録するトークルームを生成する段階と、
前記購入者、前記店舗、及び前記購入者又は前記店舗から招待され前記商品又はサービスに関わる事業者の、前記トークルームの入退室を管理する段階と、を含み、
前記購入者に対する商品又はサービスの代金の決済及び購入後のサポートを、前記トークルームに入室した事業者に対するメッセージ又は絵記号の投稿を受け付けることによって行わせることを特徴とする管理方法。
［請求項９］
ネットワークを介して商品又はサービスを提供する事業者のシステムである事業者システムと、ユーザが登録した絵記号を管理する絵記号管理サーバとが接続されたログインシステムであって、
前記事業者システムは、
ログイン画面から入力された絵記号又はその組み合わせを前記絵記号管理サーバに送信する絵記号認証手段を備え、
前記絵記号管理サーバは、
前記ユーザの端末から受け付けた絵記号を登録する絵記号登録手段と、
前記登録された絵記号の組み合わせを、前記事業者システムにログインするためのログインＩＤ及びパスワードに対応させて、又はログインＩＤとパスワードの代わりの認証手段として、格納するログイン絵記号登録テーブルと、
前記ログイン絵記号登録テーブルに格納された絵記号の組み合わせと、前記ログイン画面から入力された絵記号の組み合わせとを比較し、正規ユーザか否かを判定する絵記号判定手段と、
を備えることを特徴とするログインシステム。

【符号の説明】

【0081】

１０ ユーザ端末
１０ａ 購入者端末
１０ｂ 継承者端末
２０ 事業者システム
２０ａ 店舗システム
２０ｂ 配送業者システム
２０ｃ 製造業者システム
２０ｄ サービス事業者システム
２１ ログイン画面制御手段
２２ テキスト認証手段
２３ 絵記号認証手段
２４ ログイン実行手段
１００ トークルーム管理サーバ
１０１ ユーザ端末通信手段
１０２ ユーザスタンプ登録手段（ユーザ側の絵記号登録手段）
１０３ ユーザ情報ＤＢ
１０４ 事業者システム通信手段
１０５ 事業者スタンプ登録手段（事業者側の絵記号登録手段）
１０６ 事業者情報ＤＢ
１０７ 合鍵スタンプ登録手段（合鍵絵記号登録手段）
１０８ 合鍵スタンプ判定手段（合鍵絵記号判定手段）
１１０ トークルーム管理手段
１１１ トークルーム生成手段
１１２ トークルーム入退室管理手段
１１３ ユーザ継承手段
１１４ トークルーム消去手段
１２０ トークルームＤＢ
２００ 店舗側合鍵スタンプ
３００，３０１ 購入者側合鍵スタンプ
４００ 候補スタンプ表示欄
５００，５０１ メッセージ
５１０ 写真スタンプ
６００，６００Ａ 絵記号管理サーバ
６０１ スタンプ登録手段（ログインシステムにおける絵記号登録手段）
６０２ ユーザ情報ＤＢ
６０３ ログインスタンプ登録テーブル
６０４ 絵記号判定手段
６０５ 絵記号受付ダイアログ
７００ 事業者システムのログイン画面
７０１ ツールバー
７０２ スタンプリスト（絵記号リスト）
７０３ ログインＩＤ入力欄
７０４ パスワード入力欄
７０５ 絵記号キーボード

【図1】

【図2】

【図3A】

【図3B】

【図3C】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】