以下に、本願に係る情報処理装置、情報処理方法および情報処理プログラムを実施するための形態(以下、「実施形態」と記載する。)について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法および情報処理プログラムが限定されるものではない。
〔1.実施形態〕
図1を用いて、本実施形態の情報処理装置等により実現される情報処理について説明する。図1は、実施形態に係る情報処理の一例を示す図である。なお、図1では、本実施形態に係る情報処理装置10によって、実施形態に係る情報処理などが実現されるものとする。
図1に示すように、実施形態に係る情報処理システム1は、情報処理装置10と、利用者端末50と、決済サーバ100と、店舗端末200と、事業者端末300とを含む。情報処理装置10、利用者端末50、決済サーバ100、店舗端末200および事業者端末300は、ネットワークを介して有線または無線により相互に通信可能に接続される。ネットワークは、例えば、インターネットなどのWAN(Wide Area Network)である。なお、図1に示した情報処理システム1には、情報処理装置10、利用者端末50、決済サーバ100、店舗端末200および事業者端末300がそれぞれ複数台含まれていてもよい。
図1に示す情報処理装置10は、実施形態に係る情報処理を実行する情報処理装置であり、サーバ装置やクラウドシステム等により実現される。例えば、情報処理装置10は、決済サーバ100が提供する利用者端末50を用いる電子決済に関する電子決済サービスに関する情報に基づき、電子決済サービスの加盟店から債権の買い取りを行うことで、加盟店に対し資金を提供するファクタリングサービスを提供する。
例えば、決済サーバ100は、取引対象の提供者(事業者)や取引対象が提供される利用者の口座を管理しており、利用者からの決済要求に従って、口座間において電子マネーの移行等を行うことで、各種決済を実現する。なお、電子マネーとは、例えば、各種企業が独自に用いるポイントや通貨等であってもよく、日本円やドル等の国家により提供される貨幣を電子的に取引可能としたものであってもよい。
また、決済サーバ100は、電子決済サービスにおいて利用者に付与され、電子決済サービスにおいて利用可能な利益(クーポン等)に関する利益情報を、利益の提供者(言い換えると、クーポンの企画、設定等を行い、クーポンの原資を出資(提供)する者)から受け付け、自装置の記憶部で管理する。
また、決済サーバ100は、各エリアに所在する店舗(電子決済サービスの加盟店)等の情報を含むエリア情報を自装置の記憶部で管理する。例えば、情報処理装置10は、各エリアを識別する識別情報(エリアID)や、各エリアの所在情報(所在地や範囲など)、各エリア内の道路情報、各エリア内の路線情報、各エリアに所在する店舗などを含むエリア情報を記憶する。なお、エリアは、任意の広さの範囲が適宜設定されてもよい。例えば、エリアは、緯度及び経度を基に同様の大きさの網の目(メッシュ)に分割されたものであってもよい。すなわち、エリアは、地域メッシュで区切られたエリアであってもよい。この場合、エリアIDには、地域メッシュコードが用いられてもよい。なお、上記は、一例であり、エリアは、地域メッシュに限らず種々の情報を基に設定されてもよい。例えば、エリアは、「町」、「区」、「市」、「県」等の行政区画を基に設定されてもよい。また、エリアは、店舗等の施設ごとに設定されてもよいし、通りや商店街等ごとに設定されてもよい。
図1に示す利用者端末50は、利用者Uによって利用される情報処理装置である。利用者端末50は、例えば、スマートフォンや、タブレット型端末、ノート型PC(Personal Computer)、デスクトップPC、携帯電話機、PDA(Personal Digital Assistant)等により実現される。
図1に示す店舗端末200は、利用者に取引対象を提供する店舗によって利用される情報処理装置である。店舗端末200は、例えば、POS(Point of Sales)端末や、スマートフォン、タブレット型端末、ノート型PC、デスクトップPC、携帯電話機、PDA等により実現される。また、店舗端末200は、決済サーバ100によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図1に示す例では、店舗端末200がPOS端末である場合を示す。
なお、利用者端末50及び店舗端末200は、所定の情報処理を実現する制御情報を情報処理装置10から受け取った場合には、制御情報に従って情報処理を実現する。ここで、制御情報は、例えば、JavaScript(登録商標)等のスクリプト言語やCSS(Cascading Style Sheets)等のスタイルシート言語、Java(登録商標)等のプログラミング言語、HTML(HyperText Markup Language)等のマークアップ言語等により記述される。なお、決済サーバ100から配信される所定のアプリケーションそのものを制御情報とみなしてもよい。
図1に示す事業者端末300は、例えば、各店舗を運営する事業者によって利用される情報処理装置である。事業者端末300は、スマートフォン、タブレット型端末、ノート型PC、デスクトップPC、携帯電話機、PDA等により実現される。また、事業者端末300は、情報処理装置10や決済サーバ100によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図1に示す例では、事業者端末300がノート型PCである場合を示す。
〔1-1.利用者端末50を用いた決済について〕
ここで、情報処理装置10が実行する提供処理に先立ち、利用者端末50を用いた決済(電子決済)の一例について説明する。なお、以下の説明では、店舗Aに配置された2次元コード(QRコード(登録商標))であって、店舗Aを識別する店舗識別情報を示す2次元コードを用いて、利用者Uが利用者端末50を用いた決済を行う例について説明するが、実施形態は、これに限定されるものではない。以下に説明する決済の一例は、任意の利用者が任意の利用者端末50を用いて、任意の店舗にて決済を行う場合においても適用可能である。また、店舗識別情報は、QRコードのみならず、バーコードや所定のマーク、番号等であってもよい。
例えば、利用者Uが店舗Aにて各種の商品やサービスといった決済対象(取引対象)の利用や購入に伴う決済を行う場合、利用者Uは、利用者端末50に予めインストールされた決済アプリを起動する。そして、利用者Uは、決済アプリを介して、店舗Aに設置された店舗識別情報を撮影する。このような場合、利用者端末50は、決済対象の価格を入力するための画面を表示し、利用者U或いは店舗Aの店員から決済金額の入力を受け付ける。そして、利用者端末50は、利用者Uを識別する利用者識別情報と、店舗識別情報(若しくは、店舗識別情報が示す情報、すなわち、店舗A(若しくは店舗Aの事業者)を示す情報(例えば、店舗ID)と、決済金額とを示す決済情報を情報処理装置10へ送信する。
このような場合、情報処理装置10は、利用者識別情報が示す利用者Uの口座から、店舗識別情報が示す店舗Aの口座へと、決済金額が示す額の電子マネーを移行させる。そして、情報処理装置10は、決済が完了した旨の通知を利用者端末50へ送信する。このような場合、利用者端末50は、決済が完了した旨の画面や所定の音声を出力することで、電子マネーによる決済が行われた旨を通知する。
なお、利用者端末50を用いた決済は、上述した処理に限定されるものではない。例えば、利用者端末50を用いた決済は、店舗Aに設置された店舗端末200を用いたものであってもよい。例えば、利用者端末50は、利用者Uを識別するための利用者識別情報を画面上に表示させる。このような場合、店舗Aに設置された店舗端末200は、利用者端末50に表示された利用者識別情報を読み取り、利用者識別情報(若しくは、利用者識別情報が示す情報、すなわち、利用者Uを示す情報(例えば、利用者ID)と、決済金額と、店舗Aを識別する情報とを示す決済情報を決済サーバ100へ送信する。このような場合、情報処理装置10は、利用者識別情報が示す利用者Uの口座から、店舗Aの口座へ、決済金額が示す額の電子マネーを移行させ、店舗Aの店舗端末200或いは利用者端末50に対し、決済が完了した旨の画面や所定の音声を出力させることで、決済が行われた旨を通知してもよい。
また、利用者端末50を用いた決済は、利用者Uが予め電子マネーをチャージした口座から店舗Aの口座へ電子マネーを移行させる処理のみならず、例えば、利用者Uが予め登録したクレジットカードを用いた決済であってもよい。このような場合、例えば、利用者端末50は、店舗Aの口座に対して決済金額の電子マネーを移行させるとともに、利用者Uのクレジットカードの運用会社(カード会社)に対し、決済金額を請求してもよい。
〔1-2.実施形態に係る情報処理について〕
実施形態に係る情報処理装置10は、各店舗で行われた電子決済サービスの決済履歴に基づき、各店舗の事業者に対しファクタリングサービスを提供する。ここで、ファクタリングサービスとは、店舗の将来の売り上げの一部を債権として買い取ることで、事業者に対し資金を提供するサービスである。
このようなファクタリングサービスを提供するうえで、店舗の将来の動向に応じて債権の買い取り条件(以下、ファクタリング条件)の決定を行う必要があり、通常、店舗の資産や将来性などをスコア化した信用スコアによって、ファクタリング条件が決定される。
ところで、たとえば、電子決済サービスにおいては、決済内容によってキャッシュバック等のキャンペーンが行われる場合がある。このような場合、たとえば、電子決済サービスの加盟店(以下、単に加盟店)の関係者とユーザが共謀することで、キャッシュバックの不正取得が行われるケースがある。
このような店舗については、信用を低くすることが求められるものの、不正に関与する加盟店か否かを推定するのは容易ではない。また、たとえば、加盟店が不正商品を取り扱っている場合についても、信用を低くすることが求められるものの、通常、不正商品は秘密裡に売買が行われるため、不正商品の取り扱いを特定するのは困難である。なお、ここでの不正商品とは、公序良俗に反する商品(薬物、児童ポルノなど)、条約などによって保護される生き物等をはじめとして、電子決済サービスの利用規約に反する商品である。
そこで、実施形態に係る情報処理装置10では、不正決済に関与する加盟店か否か、あるいは、不正商品を取り扱う加盟店か否かに関する信頼スコアを推定するための学習モデル(以下、モデル)の学習を行うこととした。
そして、実施形態に係る情報処理装置10は、モデルから出力される信頼スコアに基づき、ファクタリング条件を決定する。たとえば、図1に示すように、実施形態に係る情報処理システム1において、利用者Uが店舗Aで電子決済サービスを用いて商品(あるいはサービス)を購入した場合、決済情報が決済サーバ100に通知される(ステップS1)。決済サーバ100は、各店舗から通知される決済情報を集約し、各店舗における電子決済サービスの決済情報を情報処理装置10へ通知する(ステップS2)。
情報処理装置10は、決済情報を店舗情報データベースに格納する。また、たとえば、情報処理装置10は、ウェブサーバ400から不正商品の取引に関する取引情報(以下、単に取引情報と記載)を取得する(ステップS3)。ここで、ウェブサーバ400は、各種ウェブサイトを運営するサーバ装置である。ウェブサーバ400が運営するウェブサイトとして、たとえば、各種SNS(Social Networking Service)、各店舗に関する口コミサイトなどがある。
たとえば、情報処理装置10は、不正商品に関する商品キーワードに基づき、ウェブ上の情報から取引情報を取得する。ここで、商品キーワードとは、不正商品の商品名であってもよく、不正商品を指す隠語であってもよい。具体的な例を挙げると、情報処理装置10は、SNSから「XXXX売ります(XXXXは不正商品に関する商品キーワード)」などといった取引情報を取得する。
なお、たとえば、情報処理装置10は、ユーザからの申告された取引情報を取得するようにしてもよい。具体的には、「YYY店でXXXXが売っていた」などの口コミ情報を取引情報として取得するようにしてもよい。また、たとえば、警察や報道機関によってウェブ上に発表された不正商品の取引に関する報道情報を取引情報として取得するようにしてもよい。
つづいて、情報処理装置10は、これらの情報に基づき、モデルの学習を行う(ステップS4)。たとえば、図1に示すように、情報処理装置10は、モデルM1~M3(以下、モデルMとも記載)の学習を行う。
図1に示すモデルM1は、店舗の将来性に関する信頼スコアを推定するモデルであり、たとえば、電子決済サービスの将来の取引額に関する信頼スコアを推定するモデルである。たとえば、情報処理装置10は、加盟店それぞれの電子決済サービスの取引履歴などといった各種データを学習データしてモデルM1の学習を行う。
図1に示すモデルM2は、不正決済に関与する加盟店か否かに関する信頼スコアを出力するモデルである。たとえば、情報処理装置10は、過去に不正決済に関与した加盟店の決済情報、不正決済に関与したユーザの決済情報を学習データとしてモデルM2の学習を行う。
図1に示すモデルM3は、不正商品の取引に関与した加盟店か否かに関する信頼スコアを出力するモデルである。たとえば、情報処理装置10は、不正商品に関する取引情報と、電子決済サービスの決済情報とを予め紐づけた学習データとしてモデルM3の学習を行う。たとえば、情報処理装置10は、取引情報による不正商品の売買が、どの店舗のどの決済情報に対応するかといった正解情報とする学習データを用いてモデルM3の学習を行う。
つづいて、情報処理装置10は、事業者端末300からファクタリングの申し込みを受け付けると(ステップS5)、これらモデルM1~M3を用いて信用スコアを算出する(ステップS6)。
たとえば、情報処理装置10は、対応する店舗に関する店舗情報(たとえば、店舗に関する電子決済サービスの決済履歴)をモデルM1およびモデルM2に入力し、当該店舗情報と取引情報とをモデルM3に入力することで、モデルM1~M3の出力結果としてそれぞれ信用スコアを得る。
モデルM1は、対応する店舗が電子決済サービスから撤退する確率、あるいは、店舗における今後の電子決済サービスの取引高が増加する確率(あるいは減少する確率)を信頼スコアとして出力する。すなわち、モデルM1は、店舗の将来性に基づき、債権が貸し倒れる確率を信頼スコアとして出力する。
モデルM2は、対応する店舗がユーザと共謀して電子決済サービスのキャンペーン詐欺などといった不正決済に関与するか否かに関する確率を信頼スコアとして出力する。すなわち、モデルM2は、たとえば、キャンペーン詐欺などの不正決済に店舗関係者が関与することで、電子決済サービスの運営側が対応する店舗と強制的に取引停止する可能性を信頼スコアとして出力する。
モデルM3は、対応する店舗が不正商品を取り扱う不正店舗である確率を信頼スコアとして出力する。店舗が不正商品を取り扱っている場合、言うまでもなく何らかの行政処分を受ける可能性が高い。
すなわち、これらモデルM1~M3によって得られる信頼スコアは、債権が貸し倒れる可能性を示唆する指標となる。つづいて、情報処理装置10は、算出したそれぞれの信用スコアに基づいてファクタリング条件を決定する(ステップS7)。たとえば、情報処理装置10は、信頼スコアが高いほど、すなわち、債権の貸し倒れる可能性が低い事業者ほど、有利なファクタリング条件を決定する。
たとえば、ファクタリング条件は、債権の買取上限額、回収態様などといった条件が含まれ、情報処理装置10は、これら信頼スコアに応じて、それぞれの条件を決定することになる。
その後、情報処理装置10は、決定したファクタリング条件を事業者に提示する(ステップS8)。その結果、たとえば、事業者が提示したファクタリング条件での契約を了承した場合、情報処理装置10は、事業者から債権の買取を行い、事業者に対し資金提供を行う。
このように、実施形態に係る情報処理装置10は、将来性に関する信頼スコアを出力するモデルM1、不正決済に関与する不正店舗か否かに関する信頼スコアを出力するモデルM2および不正商品を販売する不正店舗か否かに関する信頼スコアを出力するモデルM3の学習を行う。
そして、実施形態に係る情報処理装置10は、これらモデルM1~M3を用いて、店舗の信頼スコアを推定する。したがって、実施形態に係る情報処理装置10によれば、オフラインの実店舗について、将来性の観点、不正決済あるいは不正商品の取り扱いに関する観点から適切に信頼スコアを推定することが可能となる。
また、実施形態に係る情報処理装置10では、モデルM1~M3の推定結果に基づき、ファクタリング条件を決定することで、オフラインの実店舗に対して適切なファクタリング条件を決定することができる。
なお、モデルM2およびモデルM3の利用目的は、ファクタリング条件の決定に限定されるものではない。たとえば、電子決済サービスの取引停止措置や、悪質な店舗の摘発等を目的として活用するようにしてもよい。
〔1-3.実施形態に係る学習処理について〕
たとえば、上記の学習データには、各加盟店の店舗情報と、電子決済サービスの取引高を示すラベル(「正解情報」ともいう)とを対応付けたデータが含まれる。
また、例えば、正解情報としては、電子決済サービスから撤退した場合は「1」が割り当てられ、電子決済サービスから撤退していない場合は「0」が割り当てられる。なお、正解情報としては、ある時点(時点X)までに、対応する店舗が時点Xから一年以内に撤退した場合は「1」が割り当てられ、その店舗が時点Xから一年以内に撤退していない場合は「0」が割り当てられてもよい。この場合、情報処理装置10は、一年に限らず、所望の期間(例えば一カ月、六カ月、五年等)内にその店舗が撤退する確率(可能性)を推定(予測)するモデルを生成することができる。
例えば、情報処理装置10は、モデルMが出力するスコアが、モデルMに入力したチェーンストアのチェーン情報に対応付けられた正解情報(ラベル)に近づくように、バックプロパゲーション(誤差逆伝播法)等の手法により学習処理を行う。例えば、情報処理装置10は、正解情報が「1」である場合、その正解情報が割り当てられた店舗の店舗情報が入力された場合に、モデルMが出力するスコアが「1」に近づくように、学習処理を行う。また、例えば、情報処理装置10は、正解情報が「0」である場合、その正解情報が割り当てられた店舗の店舗情報が入力された場合に、モデルMが出力するスコアが「0」に近づくように、学習処理を行う。
例えば、情報処理装置10は、学習処理によりノード間で値が伝達する際に考慮される重み(すなわち、接続係数)の値を調整する。このように、情報処理装置10は、モデルMにおける出力と、入力に対応する正解情報との誤差が少なくなるようにパラメータ(接続係数)を補正するバックプロパゲーション等の処理によりモデルMを学習する。例えば、情報処理装置10は、所定の損失(ロス)関数を最小化するようにバックプロパゲーション等の処理を行うことによりモデルMを生成する。これにより、情報処理装置10は、モデルMのパラメータを学習する学習処理を行うことができる。
なお、モデルの学習手法については、上述した手法に限定されるものではなく、任意の公知技術が適用可能である。なお、各モデルの生成は、機械学習に関する種々の従来技術を適宜用いて行われてもよい。例えば、モデルの生成は、SVM(Support Vector Machine)等の教師あり学習の機械学習に関する技術を用いて行われてもよい。また、例えば、モデルの生成は、教師なし学習の機械学習に関する技術を用いて行われてもよい。例えば、モデルの生成は、深層学習(ディープラーニング)の技術を用いて行われてもよい。例えば、モデルの生成は、DNN(Deep Neural Network)やRNN(Recurrent Neural Network)やCNN(Convolutional Neural Network)等の種々のディープラーニングの技術を適宜用いて行われてもよい。なお、上記モデルの生成に関する記載は例示であり、モデルの生成は、取得可能な情報等に応じて適宜選択された学習手法により行われてもよい。すなわち、情報処理装置10は、学習データに含まれる店舗情報が入力された場合に、正解情報に対応するスコアを出力するようにモデルMを学習可能であれば、どのような手法によりモデルMの生成を行ってもよい。
〔2-1.情報処理装置の構成例〕
次に、図2を用いて、情報処理装置10の構成例について説明する。図2は、実施形態に係る情報処理装置10の構成例を示すブロック図である。図2に示すように、情報処理装置10は、通信部110と、記憶部120と、制御部130とを有する。
通信部110は、例えば、NIC(Network Interface Card)等によって実現される。そして、通信部110は、ネットワークNと有線または無線で接続され、決済サーバ100、事業者端末300等との間で情報の送受信を行う。
記憶部120は、例えば、RAM(Random Access Memory)、フラッシュメモリ(Flash Memory)等の半導体メモリ素子、または、ハードディスク、光ディスク等の記憶装置によって実現される。図2に示すように、記憶部120は、店舗情報データベース121と、加盟店情報データベース122と、ユーザ情報データベース123と、モデルデータベース124と、ファクタリングデータベース125とを有する。
店舗情報データベース121は、電子決済サービスを利用する加盟店に関する情報を記憶するデータベースである。図3は、実施形態に係る店舗情報データベース121に記憶する情報の一例を示す図である。
図3に示すように、店舗情報データベース121は、「店舗ID」、「加盟店ID」、「出店日」、「閉店日」、「撤退理由」、「カテゴリID」、「売上高」、「取扱高」、「住所」などといった項目の情報を互いに対応付けて記憶する。
「店舗ID」は、店舗を識別するための識別子である。たとえば、店舗IDは、電子決済サービスにおける店舗IDが用いられる。「加盟店ID」は、対応する店舗IDによって識別される店舗が加盟するチェーンストアを識別するための識別子である。
たとえば、同一のチェーンストアに加盟している場合、同一の加盟店IDが付与される。なお、同一のチェーンストアに加盟している場合であっても、各店舗の契約態様に応じて、異なるIDを付与することにしてもよい。すなわち、「加盟店ID」は、直営店あるいはフランチャイズ店を識別するための識別子を含むようにしてもよい。
「出店日」は、対応する店舗IDによって識別される店舗が出店した日であり、「閉店日」は、対応する店舗IDによって識別される店舗が閉店(店じまい)した日であり、「出店日」および「閉店日」については、それぞれ電子決済サービスへ加盟した加盟日、電子決済サービスから撤退した撤退日へ読み替えることにしてもよい。
「撤退理由」は、対応する店舗が電子決済サービスから撤退した理由を示す。たとえば、図3に示す例では、撤退理由として「不正商品」や「不正決済」による強制退店を例示す。
「カテゴリID」は、対応する店舗IDによって識別される店舗の店舗カテゴリを識別するための識別子である。たとえば、業種、取扱商品(取扱サービス)によって、カテゴリIDが決定される。なお、一つの店舗に対し複数種別のカテゴリIDを付与するようにしてもよい。
「売上高」は、対応する店舗IDによって識別される店舗の1か月あたりの売上高(すなわち、月商)であり、「取扱高」は、対応する店舗IDによって識別される店舗における電子決済サービスの取扱高である。
「住所情報」は、対応する店舗IDによって識別される店舗の住所に関する情報である。たとえば、「住所情報」には、店舗の所在地、店舗面積、駐車場の有無等に関する情報が含まれ得る。
なお、図3に示す店舗情報データベース121は一例であって、その他、たとえば、営業時間に関する営業時間情報、従業員や従業員数に関する従業員情報などといった項目の情報を対応付けて記憶するようにしてもよい。
図2の説明に戻り、加盟店情報データベース122について説明する。加盟店情報データベース122は、加盟店に関する情報を記憶するデータベースである。図4は、実施形態に係る加盟店情報データベース122に記憶する情報の一例を示す図である。
図4に示すように、加盟店情報データベース122は、「加盟店ID」、「店舗数」、「総営業時間」、「従業員数」、「月商」などといった項目の情報を互いに対応付けて記憶する。
「加盟店ID」は、チェーンストアを識別するための識別子であり、「店舗数」は、対応する加盟店IDによって識別されるチェーンストアの店舗数である。「総営業時間」は、対応する加盟店IDによって識別されるチェーンストア全体の1カ月当たりの営業時間の総和であり、「従業員数」は、チェーンストア全体の従業員数である。
また、「月商」は、対応する加盟店IDによって識別されるチェーンストア全体の1か月の売り上げである。なお、月商については、チェーンストア全体の電子決済サービスの取引高の総和であってもよい。
図2の説明に戻り、ユーザ情報データベース123について説明する。ユーザ情報データベース123は、電子決済サービスのユーザに関するユーザ情報を記憶するデータベースである。図5は、実施形態に係るユーザ情報データベース123に記憶する情報の一例を示す図である。
図5に示すように、たとえば、ユーザ情報データベース123は、「ユーザID」、「登録情報」、「決済履歴」、「不正フラグ」、「不正内容」などといった項目の情報を互いに対応付けて記憶する。
「ユーザID」は、電子決済サービスを利用する利用者を識別するための識別子である。「登録情報」は、対応する利用者が電子決済サービスに登録した情報である。登録情報の一例として、たとえば、氏名、年齢、住所、電話番号、職業、連携口座(電子決済サービスとの間で入出金を行う口座)、クレジットカード情報などが挙げられる。なお、図5では、対応するユーザが本人認証を行っていない場合の登録情報を「―(ハイフン)」として示している。
「決済履歴」は、対応するユーザの電子決済サービスにおける決済履歴を示す。なお、たとえば、「決済履歴」は、電子決済サービスを利用した個人間送金の履歴を含むようにしてもよい。
「不正フラグ」は、対応するユーザが不正決済に関与したユーザか否かに関するフラグである。たとえば、ユーザが過去に不正決済に関与していた場合、「1」となり、これまで不正決済に関与していない場合には、「0」となる。
「不正内容」は、不正フラグが「1」であるユーザが行った不正決済の具体的な内容を示す。たとえば、不正内容として、電子決済サービスのポイント詐欺が挙げられる。ポイント詐欺は、たとえば、商品を購入せず、電子決済サービス上で決済だけを行うことで、ユーザ口座から店舗口座へ決済金額が支払われ、ユーザには、決済に応じたポイントが付与されることで行われる。たとえば、このようなケースにおいて、店舗が、上記の決済金額をユーザへバックすることで、事実上、ユーザおよび店舗間での収支は「0」となり、電子決済サービスから付与されたポイントだけを獲得することができる。
図2の説明に戻り、モデルデータベース124について説明する。モデルデータベース124は、モデルを記憶するデータベースである。図6は、実施形態に係るモデルデータベース124に記憶する情報の一例を示す図である。
図6に示すように、モデルデータベース124は、「モデルID」、「用途」、「モデルデータ」および「学習データ」などといった項目の情報を互いに対応付けて記憶する。「モデルID」は、各モデルを識別するための識別子である。
「用途」は、対応するモデルIDによって識別されるモデルの用途を示す。図6に示す例では、用途に、「将来予測」、「不正決済予測」、「不正商品予測」が含まれる場合を示している。
「モデルデータ」は、対応するモデルIDによって識別されるモデルのデータ本体であり、「学習データ」は、対応するモデルIDによって識別されるモデルを生成するための学習データである。
なお、モデルデータベース124に格納するモデルM2は、たとえば、ルールベースで信頼スコアを出力するモデルであってもよい。図7は、実施形態に係る不正決済に関するルールの一例を示す図である。
たとえば、モデルM2は、図7に示す不正決済に関するルールに合致するほど、不正決済を行う店舗である可能性が高いと推定するモデルとすることもできる。この場合、学習部132は、図7に示すようなルールに合致する決済履歴あるいは個人間送金を抽出するためのモデルM2を学習することとなる。
具体的には、図7に示すようにルールID「♯1」で識別されるルールは、「店舗全体の決済回数に対して1ユーザの決済回数がX%以上(Xは任意の数;たとえば、X=50)」である。
すなわち、ルールID「♯1」は、1ユーザの決済比率が異常に高い場合に、当該1ユーザと店舗側で不正決済を行っている可能性が高いと推定するためのルールである。なお、ここでの「決済回数」については「決済総額」と読み替えることにしてもよい。
また、図7に示すルールID「♯2」で識別されるルールは、「決済間隔が短い、または、決済間隔が長い」である。たとえば、決済間隔が短いとは、1ユーザによって10秒間に何度も決済した履歴がある場合など、1ユーザによる決済が短期間で何度もされている場合を示す。また、決済間隔が長いとは、たとえば、1ユーザが、朝、昼、晩など所定時間以上の間隔をあけて決済が行われた決済履歴が行われることを示す。すなわち、決済間隔が長いとは、1ユーザが当該当該店舗内に1日中滞在しているかのような決済の特徴を有することを指す。ルールID「♯2」では、これら決済間隔の観点から不審な決済を抽出するためのルールである。
また、図7に示すルールID「♯3」で識別されるルールは、「営業時間外(休業日を含む)の決済」である。すなわち、この場合においては、通常であれば、決済できない日時に決済が行われたことを示し、ルールID「♯3」では、これら決済時刻の観点から不審な決済を抽出するためのルールである。
また、図7に示すルールID「♯4」で識別されるルールは、「店舗業態に対して異常な時間帯の決済」である。具体的な例を挙げると、店舗業態が夜間営業を行わない八百屋である場合を想定すると、八百屋で深夜に決済が行われた場合に、何かしらの事由による異常な決済が行われたと推定することができ、ルールID「♯4」では、これら店舗業態の営業時間を考慮して、不審な決済を抽出するためのルールである。
また、図7に示すルールID「♯5」で識別されるルールは、「業態内の決済相場と乖離」である。業態内(たとえば、定食屋)における決済相場が1500円であるのに対し、当該決済相場と乖離した500000円の決済が行われた場合に、当該決済が不正決済な決済である可能性が高いと推定することができ、ルールID「♯5」では、業態内の決済相場の観点から不審な決済を抽出するためのルールである。
また、図7に示すルールID「♯6」で識別されるルールは、「同一店舗における決済金額と乖離」である。たとえば、対応する店舗の顧客単価から乖離する決済金額の決済が行われた場合がルールID「♯6」に対応する。
また、図7に示すルールID「♯7」で識別されるルールは、「CP(キャンペーン)で獲得できる上限付近での決済」である。すなわち、たとえば、キャンペーンのキャッシュバック率が「20%」、キャッシュバックの上限が「2000ポイント」である場合、2000ポイントを得るためには、1万円分の決済を行う必要がある。
そのため、たとえば、1つの加盟店でキャンペーン期間中に約1万円前後の決済が頻繁に行われていた場合、当該加盟店がユーザと共謀してポイント詐欺を働いている可能性があり、ルールID「♯7」ではこれらを抽出するためのルールである。
また、図7に示すルールID「♯8」で識別されるルールは、「個人間送金で店舗関係者による送金履歴」である。ここで、個人間送金とは、決済サーバ100が提供する電子決済サービスを用いて、ユーザ間で電子マネーの送金を行う機能である。また、店舗関係者とは、加盟店のオーナー、従業員であるが、たとえば、オーナーや従業員の親族や友人を含むようにしてもよい。
たとえば、特定の加盟店でポイントを獲得したユーザの個人間送金の履歴に、当該加盟店の店舗関係者からの送金履歴があると、当該ユーザと当該店舗関係者が共謀して不正決済を行ったことが疑われ、ルールID「♯8」ではこれらを抽出するためのルールである。
また、図7に示すルールID「♯9」で識別されるルールは、「個人間送金のメッセージに不審な履歴」である。たとえば、決済サーバ100が提供する電子決済サービスでは、個人間送金時にメッセージを送ることができる。
そして、たとえば、特定の加盟店でポイントを獲得したユーザの個人間送金のメッセージ履歴に、店舗関係者から不審決済を匂わすメッセージがあった場合に、ルールID「♯9」のルールが適用される。なお、図7に示すルールは、一例であって、任意に変更することができる。
図2の説明に戻り、ファクタリングデータベース125について説明する。ファクタリングデータベース125は、ファクタリングに関する各種情報を記憶する。図8は、実施形態に係るファクタリングデータベース125に記憶する情報の一例を示す図である。
図8に示すように、ファクタリングデータベース125は、「加盟店ID」、「スコア情報」、「ファクタリング情報」などといった項目の情報を互いに対応付けて記憶する。「加盟店ID」は、加盟店を識別するための識別子である。
「スコア情報」は、対応する加盟店IDによって識別される加盟店に対するスコアである。「ファクタリング情報」は、対応するチェーンストアのファクタリングを利用中であるか否かを示す。例えば、「ファクタリング情報」が「-(ハイフン)」であるチェーンストアは、ファクタリングを利用していないストアであることを示す。
「ファクタリング情報」がファクタリング情報#2であるチェーンストアは、ファクタリングを利用中のチェーンストアであることを示し、ファクタリングの金額やその回収態様(回収期間や回収間隔等)等、ファクタリングに関する具体的な情報が格納される。
図2の説明に戻り、制御部130について説明する。制御部130は、コントローラ(controller)であり、例えば、CPU(Central Processing Unit)やMPU(Micro Processing Unit)等によって、情報処理装置10内部の記憶装置に記憶されている各種プログラムがRAMを作業領域として実行されることにより実現される。また、制御部130は、例えば、ASIC(Application Specific Integrated Circuit)やFPGA(Field Programmable Gate Array)等の集積回路により実現される。実施形態に係る制御部130は、取得部131と、学習部132と、推定部133と、決定部134とを有し、以下に説明する情報処理の機能や作用を実現または実行する。
取得部131は、各店舗に関する店舗情報を取得し、店舗情報データベース121へ格納する。たとえば、取得部131は、実店舗における電子決済サービスの取引に関する取引情報を決済サーバ100から取得する。たとえば、取得部131は、実店舗における売上高に関する売上情報を取得するようにしてもよい。なお、売上情報とは、決済サーバ100が提供する決済サーバ100が提供する電子決済サービスの取引高に加え、現金、クレジットカードなどその他の決済手段を含めた店舗の売り上げに関する情報である。たとえば、取得部131は、各実店舗、あるいは、当該実店舗が加盟する本部へのアンケートによって売上情報を取得する。なお、取得部131は、各実店舗における電子決済サービスの取引履歴から売上情報を推定するようにしてもよい。また、売上情報については、たとえば、月商であってもよく、1か月間の利益(月商から経費を差し引いた額)であってもよい。
また、取得部131は、たとえば、ウェブサーバ400(図1参照)から不正商品の取引に関する取引情報を取得する。たとえば、取得部131は、SNSやブログ、口コミサイト上に投稿された投稿情報から不正商品に関する商品キーワード(たとえば、商品名、当該商品名を指す隠語)で検索することで、取引情報を取得する。
なお、たとえば、取得部131は、商品キーワードと、各加盟店の店舗名を検索ワードとして取引情報を取得するようにしてもよい。また、取得部131は、検索に限らず、ウェブ上を巡回(クロール)することで、取引情報を取得するようにしてもよい。
学習部132は、取得部131によって取得された各種情報に基づき、モデルM1~M3を学習する。上述のように、モデルM1は、加盟店の将来性に関する信頼スコアを出力するモデルである。
たとえば、モデルM1の学習段階において、学習部132は、加盟店の電子決済サービスの取引高に関する取引履歴、当該加盟店の増減数あるいは、同一カテゴリにおける各加盟店の取引履歴などといった学習データを生成する。
たとえば、学習データは、すべての加盟店の取引履歴のうち、電子決済サービスから撤退した店舗の取引履歴にラベル(正解情報)付けされたデータである。なお、ここでの撤退とは、倒産による閉店、あるいは、その他の事由により、店舗側の意向で撤退した場合を示し、不正決済や不正商品の取り扱いによって電子決済サービス側から強制的に取引を停止した場合を除くものとする。
例えば、正解情報としては、店舗が電子決済サービスから撤退した場合は「1」が割り当てられ、店舗が撤退していない場合は「0」が割り当てられる。例えば、学習部132は、正解情報が「1」である場合、その正解情報が割り当てられたチェーンストアのチェーン情報が入力された場合に、モデルM1が出力するスコアが「1」に近づくように、学習処理を行う。また、例えば、情報処理装置10は、正解情報が「0」である場合、その正解情報が割り当てられた加盟店の取引履歴が入力された場合に、モデルM1が出力するスコアが「0」に近づくように、学習処理を行う。
また、モデルM1の学習段階において、学習部132は、正解情報として加盟店における電子決済サービスの取引高が減少(あるいは増加)した場合を「1」、電子決済サービスの取引高が減少(あるいは増加)してない場合を「0」としてモデルM1の学習を行うようにしてもよい。
また、たとえば、学習部132は、チェーンストア単位でモデルM1の学習を行うようにしてもよい。すなわち、同一チェーンに加盟する加盟店すべての取引履歴を用いて、モデルM1の学習を行うようにしてもよい。この場合、たとえば、モデルM1は、対応するチェーンストアの将来性に関する信頼スコアを出力することになる。
なお、学習部132は、そのほか、特定の地域における店舗カテゴリ全体での取引履歴を用いて、モデルM1の学習を行うようにしてもよいし、あるいは、取扱商品や顧客単価が類似する加盟店の取引履歴をまとめてモデルM1の学習を行うようにしてもよい。
また、学習部132は、実店舗が不正決済に関与する不正店舗であるか否かに関する信用スコアを出力するモデルM2を学習する。
この場合、学習データは、すべての店舗およびユーザの決済履歴のうち、不正店舗の決済履歴および不正決済に関与したユーザの決済履歴にラベル(正解情報)を紐づけたデータである。
また、学習部132は、たとえば、電子決済サービスのキャンペーン期間に関するラベル(正解情報)を紐づけた学習データを用いてモデルM2を学習するようにしてもよい。また、キャンペーン期間中のラベルについてはさらにキャッシュバック率あるいはポイント上限に関するデータを紐づけるようにしてもよい。
つまり、モデルM2は、キャンペーン期間中と、キャンペーン期間以外における不正決済に関する傾向や、キャッシュバック率あるいは獲得可能なポイントの上限による不正決済の傾向に基づいて、実店舗が不正決済に関与する不正店舗であるか否かに関する信用スコアを出力することができる。
なお、たとえば、モデルM2の学習段階において、モデルM2は、たとえば、不正に入手したクレジットカード(たとえば、盗難など)を用いて行われた決済に関する決済情報にラベル付けした学習データを用いることにしてもよい。
また、学習部132は、不正商品を販売する不正店舗であるか否かに関する信用スコアを出力するモデルM3を学習する。たとえば、学習部132は、過去の事例から、不正商品の取引情報と、当該不正商品の売買時に行われた電子決済サービスの決済情報とを対応付けた学習データを用いてモデルM3を学習する。
なお、学習データについては、たとえば、ウェブ上に投稿された不正商品に関する申告情報を用いて、取引情報と決済情報とを対応付けるようにしてもよい。具体的な例を挙げると、「A店でXXX(不正商品)をYYY円で売っていました」などといったユーザによるネット上の投稿に基づき、店舗および決済金額を特定することができ、これらの情報に基づいて、不正商品に関する決済を特定することができる。
その他、たとえば、店舗が不正商品の取り扱いに関して、行政処分などを受けた場合に、当該店舗の決済履歴あるいは店舗関係者の個人送金履歴と、店舗関係者によるウェブ上への不正商品に関する投稿情報(取引情報)とを照合することによっても、不正商品に関する決済を特定することができる。
なお、モデルM3の学習に際し、学習部132は、投稿情報に基づき、投稿情報に対応する不正商品の売買に対応する決済情報の絞り込みを行うようにしてもよい。図9は、実施形態に係る投稿情報に対応する絞り込み処理の一例を示す図である。
図9に示すように、たとえば、「XXX格安で販売します(XXXXは不正商品に関する商品キーワード)」といった投稿情報Twがあった場合、当該投稿情報Twがネット上に掲載された掲載日時(同図では17;30 2021/05/19)に基づいて、決済履歴から投稿情報Twに対応する決済情報の絞り込みを行う。
すなわち、この場合、投稿情報Twが掲載された投稿日時以前に行われた決済については、投稿情報Twに対応する不正商品に関する決済とは関係ないことになる。また、投稿情報Twにタグ付けされた位置情報(同図では東京都千代田区)と、各店舗の所在地に基づいて店舗の絞り込みを行うようにしてもよい。
たとえば、商品を直接(手渡し)で販売する場合、投稿情報Twにタグ付けされた位置情報から限定されたエリアで商品の売買が行われる可能性が高く、当該位置情報に基づき、投稿情報Twに関する商品を売買可能な店舗を絞り込む。たとえば、投稿情報Twに郵送で販売することが示唆される記述がある場合には、絞り込む範囲を拡大することにしてもよい。
その後、絞り込みによって残った決済情報と、投稿情報Twに関する不正商品の売買に関する情報とを照合し、対応する決済情報および不正商品を販売した店舗を特定する。このように、投稿情報Twの掲載日時や位置情報に基づき、決済情報の絞り込みを行うことで、効率よく投稿情報Twと決済情報とを対応付けることができる。
推定部133は、学習部132によって学習されたモデルMを用いて、各種信頼スコアを推定する。たとえば、学習部132は、対象となる店舗に関する店舗情報(たとえば、決済履歴)をモデルM1に入力することで、当該店舗の将来性に関する信頼スコアを推定する。
また、たとえば、推定部133は、対象となる店舗の店舗情報をモデルM2に入力することで、当該店舗が不正決済に関与する不正店舗であるか否かに関する信頼スコアを推定する。
また、たとえば、推定部133は、対象となる店舗の店舗情報および不正商品の取引に関する取引情報をモデルM3に入力することで、当該店舗が不正商品を販売する不正店舗であるか否かに関する信頼スコアを推定する。
決定部134は、推定部133による推定結果に基づき、ファクタリング条件を決定する。たとえば、決定部134は、推定部133による推定結果と予め設定されたファクタリングルールとに基づき、チェーンストアに対するファクタリング条件を決定する。たとえば、ファクタリング条件は、債権の買い取り金額、回収態様などが含まれる。
なお、決定部134は、たとえば、実際に債権の買取を行った際のファクタリング条件と、その回収状況とを学習データとして学習されたモデルに基づき、ファクタリング条件を決定するようにしてもよい。
たとえば、かかるモデルは、チェーンストアに関するスコア情報と、実際に債権の買取を行った際のファクタリング条件とにおいて、債権の回収ができた場合、あるいは、回収ができなかった場合を正解情報とする学習データを用いて生成することができる。
決定部134によって決定されたファクタリング条件は、事業者へ提示される。事業者は、提示されたファクタリング条件などを確認し、ファクタリングの申込内容の入力、利用規約を承諾したうえで、申し込みボタンを選択する。これにより、ファクタリングが成立する。
たとえば、決定部134は、ファクタリングが成立すると、申込内容をファクタリングデータベース125(図2参照)へ格納し、返済率に関する情報を決済サーバ100へ通知する。これにより、決済サーバ100は、かかる返済率に基づき、事業者の毎月の売り上げから返済率に応じた金額を差し引くことで、債権に対する資金回収を行うことができる。
〔3.実施形態に係る情報処理の処理手順について〕
次に、図10~12を用いて、実施形態に係る情報処理装置10が実行する処理手順の一例について説明する。図10~12は、実施形態に係る情報処理の一例を示す図である。
まず、図10を用いて、モデルM2に関する処理について説明する。図10に示すように、まず、情報処理装置10は、不正決済に関与した店舗またはユーザの決済情報から学習データを生成し(ステップS101)、生成した学習データを用いて学習モデル(モデルM2)を学習する(ステップS102)。
つづいて、情報処理装置10は、店舗の決済情報を取得し(ステップS103)、当該決済情報をモデルM2に入力することで、当該店舗の信用スコアを推定する(ステップS104)。そして、情報処理装置10は、処理を終了する。
次に、図11を用いてモデルM3に関する処理について説明する。図11に示すように、まず、情報処理装置10は、不正商品の取引に関する学習データ(投稿情報および決済情報)を生成し(ステップS111)、生成した学習データを用いて学習モデル(モデルM3)を学習する(ステップS112)。
つづいて、情報処理装置10は、取引情報および店舗の決済情報を取得し(ステップS113)、取得した取引情報および店舗の決済情報をモデルM3に入力することで、当該店舗の信用スコアを推定する(ステップS114)。そして、情報処理装置10は、処理を終了する。
次に、図12を用いて、ファクタリング条件の決定処理について説明する。図12に示すように、まず、情報処理装置10は、事業者からファクタリング申し込みを受け付けると(ステップS121)、当該事業者に関する各店舗に関する情報をモデルM1~M3に入力することで、当該事業者に関する信頼スコアを推定する(ステップS122)。
つづいて、情報処理装置10は、信頼スコアに基づいて、ファクタリング条件を決定する(ステップS123)。そして、情報処理装置10は、処理を終了する。
〔4.変形例〕
ところで、上述した実施形態では、実店舗を対象として場合について説明したが、これに限定されるものではない。たとえば、オフライン販売とオンライン販売を組み合わせてサービスを提供する店舗を対象とすることにしてもよい。たとえば、この場合、オンライン販売分については、たとえば、各種ECサイトの販売履歴を学習データとしてモデルMの学習を行う。また、たとえば、このような場合には、オフライン販売分とオンライン販売分とをあわせてモデルMの学習を行うようにしてもよく、オフライン販売分のモデルMとオンライン販売分のモデルMとをそれぞれ学習するようにしてもよい。
また、上述した実施形態では、ウェブ上に公開されたテキストを取引情報として取得する場合について説明したが、これに限定されるものではない。すなわち、不正商品の取引に関する画像、映像あるいは音声を取引情報とすることにしてもよい。
〔5.効果〕
実施形態に係る情報処理装置10は、ウェブ上の情報から不正商品の取引に関する取引情報を取得する取得部131と、取得部131によって取得された取引情報と、対象店舗に関する店舗情報とが入力された際に、当該対象店舗が不正商品を販売する不正店舗であるか否かに関する信用スコアを出力する学習モデルを学習する学習部132とを備える。したがって、実施形態に係る情報処理装置10によれば、不正商品の取り扱いに基づく信用スコアを適切に推定することができる。
また、実施形態に係る学習部132は、店舗情報として対象店舗における決済サービスの取引履歴に関する情報を用いて信用スコアを出力する学習モデルを学習する。したがって、実施形態に係る情報処理装置10によれば、不正商品の取引情報と決済サービスの決済履歴とを照合することができるので、信用スコアを適切に推定することができる。
また、実施形態に係る学習部132は、取引情報がウェブ上に掲載された掲載日時と、決済サービスの決済日時とに基づいて信用スコアを出力する学習モデルを学習する。したがって、実施形態に係る情報処理装置10によれば、投稿日時と決済日時との関係性から不正商品の取引を特定することが可能となる。
また、実施形態に係る学習部132は、取引情報にタグ付けされた位置情報と、対象店舗の所在地とに基づいて信用スコアを出力する学習モデルを学習する。したがって、実施形態に係る情報処理装置10によれば、位置情報に基づき、不正商品を売買する店舗を絞り込むことができる。
また、実施形態に係る取得部131は、ウェブ上でユーザから申告された不正商品に関する申告情報を取引情報として取得する。したがって、実施形態に係る情報処理装置10によれば、不正商品の取引を容易に特定することができる。
また、実施形態に係る取得部131は、ソーシャルネットワーキングサービス上に投稿された投稿情報から取引情報を取得する。したがって、実施形態に係る情報処理装置10によれば、たとえば、SNS上に不特定多数に向けて発信された投稿情報に基づいて、寸用スコアを推定することができる。
また、実施形態に係る取得部131は、ウェブ上を巡回し、対象店舗に関する取引情報を取得する。したがって、実施形態に係る情報処理装置10によれば、対象店舗に取引情報を個別に取得することができるので、信頼スコアに関する精度を向上させることができる。
また、実施形態に係る取得部131は、不正商品に関する商品キーワードに基づいて、ウェブ上の情報から取引情報を取得する。したがって、実施形態に係る情報処理装置10によれば、取引情報を簡便に取得することができる。
また、実施形態に係る情報処理装置10は、学習モデルから出力される信用スコアに基づいて、対象店舗の債権の買い取りに関する買い取り条件を決定する決定部134を備える。したがって、実施形態に係る情報処理装置10によれば、適切なファクタリング条件を決定することができる。
また、実施形態に係る決定部134は、債権の回収不能になる確率が高いほど、厳しい買い取り条件に決定する。したがって、実施形態に係る情報処理装置10によれば、適切なファクタリング条件を決定することができる。
また、実施形態に係る情報処理方法は、コンピュータが実行する情報処理方法であって、ウェブ上の情報から不正商品の取引に関する取引情報を取得する取得工程と、取得工程によって取得された取引情報と、対象店舗に関する店舗情報とが入力された際に、当該対象店舗が不正商品を販売する不正店舗であるか否かに関する信用スコアを出力する学習モデルを学習する。したがって、実施形態に係る情報処理方法によれば、不正商品の取り扱いに基づく信用スコアを適切に推定することができる。
また、実施形態に係る情報処理プログラムは、ウェブ上の情報から不正商品の取引に関する取引情報を取得する取得手順と、取得手順によって取得された引情報と、対象店舗に関する店舗情報とが入力された際に、当該対象店舗が不正商品を販売する不正店舗であるか否かに関する信用スコアを出力する学習モデルを学習する学習手順とをコンピュータに実行させる。したがって、実施形態に係る情報処理プログラムによれば、正商品の取り扱いに基づく信用スコアを適切に推定することができる。
〔6.ハードウェア構成〕
また、上述してきた実施形態に係る情報処理装置10は、例えば図13に示すような構成のコンピュータ1000によって実現される。図13は、実施形態に係る情報処理装置10の機能を実現するコンピュータの一例を示すハードウェア構成図である。コンピュータ1000は、CPU1100、RAM1200、ROM1300、HDD1400、通信インターフェイス(I/F)1500、入出力インターフェイス(I/F)1600、及びメディアインターフェイス(I/F)1700を有する。
CPU1100は、ROM1300またはHDD1400に格納されたプログラムに基づいて動作し、各部の制御を行う。ROM1300は、コンピュータ1000の起動時にCPU1100によって実行されるブートプログラムや、コンピュータ1000のハードウェアに依存するプログラム等を格納する。
HDD1400は、CPU1100によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス1500は、ネットワーク(通信ネットワーク)Nを介して他の機器からデータを受信してCPU1100へ送り、CPU1100が生成したデータをネットワークNを介して他の機器へ送信する。
CPU1100は、入出力インターフェイス1600を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置(図13では、出力装置および入力装置を総称して「入出力装置」と記載する)を制御する。CPU1100は、入出力インターフェイス1600を介して、入力装置からデータを取得する。また、CPU1100は、生成したデータを入出力インターフェイス1600を介して出力装置へ出力する。
メディアインターフェイス1700は、記録媒体1800に格納されたプログラムまたはデータを読み取り、RAM1200を介してCPU1100に提供する。CPU1100は、かかるプログラムを、メディアインターフェイス1700を介して記録媒体1800からRAM1200上にロードし、ロードしたプログラムを実行する。記録媒体1800は、例えばDVD(Digital Versatile Disc)、PD(Phase change rewritable Disk)等の光学記録媒体、MO(Magneto-Optical disk)等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。
例えば、コンピュータ1000が実施形態に係る情報処理装置10として機能する場合、コンピュータ1000のCPU1100は、RAM1200上にロードされたプログラムを実行することにより、制御部130の機能を実現する。コンピュータ1000のCPU1100は、これらのプログラムを記録媒体1800から読み取って実行するが、他の例として、他の装置からネットワークNを介してこれらのプログラムを取得してもよい。
以上、本願の実施形態のいくつかを図面に基づいて詳細に説明したが、これらは例示であり、発明の開示の欄に記載の態様を始めとして、当業者の知識に基づいて種々の変形、改良を施した他の形態で本発明を実施することが可能である。
〔7.その他〕
また、上記実施形態及び変形例において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
また、上述してきた「部(section、module、unit)」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。