(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024006621
(43)【公開日】2024-01-17
(54)【発明の名称】情報処理方法、プログラム及びシステム
(51)【国際特許分類】
G06Q 50/10 20120101AFI20240110BHJP
【FI】
G06Q50/10
【審査請求】未請求
【請求項の数】16
【出願形態】OL
(21)【出願番号】P 2022107691
(22)【出願日】2022-07-04
(71)【出願人】
【識別番号】513040384
【氏名又は名称】株式会社マネーフォワード
(74)【代理人】
【識別番号】110002789
【氏名又は名称】弁理士法人IPX
(72)【発明者】
【氏名】チャン バー ヴィン ソン
(72)【発明者】
【氏名】トマール ガガンディープ
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049CC11
(57)【要約】
【課題】ユーザーが利用しているサービスに対する支払金額を容易に把握することが可能な技術を提供すること。
【解決手段】本発明の一態様によれば、コンピュータにより実行される情報処理方法が提供される。この情報処理方法は、取得ステップと、アクセスステップと、特定ステップと、表示制御ステップと、を備える。取得ステップでは、利用しているサービスである利用サービスに対する支払情報を取得する。支払情報は、支払金額と、支払金額に対応するテキスト情報と、を含む。アクセスステップでは、複数のサービス名を記憶するデータベースにアクセスする。特定ステップでは、アクセスしたデータベースに記憶される複数のサービス名の中から、テキスト情報に対応するサービス名を特定する。表示制御ステップでは、特定されたサービス名と、特定されたサービス名に対応する利用サービスに対する支払金額と、をユーザー端末に表示させる。
【選択図】
図1
【特許請求の範囲】
【請求項1】
コンピュータにより実行される情報処理方法であって、
取得ステップと、アクセスステップと、特定ステップと、表示制御ステップと、を備え、
前記取得ステップでは、利用しているサービスである利用サービスに対する支払情報を取得し、
前記支払情報は、支払金額と、前記支払金額に対応するテキスト情報と、を含み、
前記アクセスステップでは、複数のサービス名を記憶するデータベースにアクセスし、
前記特定ステップでは、前記アクセスしたデータベースに記憶される前記複数のサービス名の中から、前記テキスト情報に対応するサービス名を特定し、
前記表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、をユーザー端末に表示させる、
方法。
【請求項2】
請求項1に記載の方法において、
受付ステップを備え、
前記支払情報は、複数の利用サービスに関するものであり、
前記支払情報は、複数の支払金額と、前記複数の支払金額にそれぞれ対応する複数のテキスト情報と、を含み、
前記特定ステップでは、前記アクセスしたデータベースに記憶される前記複数のサービス名の中から、前記複数のテキスト情報のそれぞれに対応する複数のサービス名を特定し、
前記受付ステップでは、前記ユーザー端末から、特定された前記複数のサービス名から1つのサービス名の選択を受け付け、
前記表示制御ステップでは、受け付けた前記サービス名と、受け付けた前記サービス名に対応する前記利用サービスに対する支払金額と、を前記ユーザー端末に表示させる、
方法。
【請求項3】
請求項2に記載の方法において、
前記表示制御ステップでは、前記支払金額を時系列に沿って可視化したグラフを前記ユーザー端末に表示させる、
方法。
【請求項4】
請求項3に記載の方法において、
前記グラフは、以下の(1)~(3)の少なくとも1つの態様で表現される、
(1)前記複数の利用サービスに対する支払金額の合計金額を時系列に沿って可視化する
(2)前記複数の利用サービスを区別可能に可視化する
(3)前記複数の利用サービスのうち、前記ユーザー端末により選択された利用サービスを可視化する
方法。
【請求項5】
請求項1~4のいずれか1項に記載の方法において、
前記表示制御ステップでは、前記利用サービスに対する統合処理を実行することを選択する選択画像を前記ユーザー端末に表示させ、
前記統合処理は、前記利用サービスを提供するサービスシステムから、前記利用サービスに紐づくユーザーIDの数と、前記支払金額と、を取得できる状態にする処理である、
方法。
【請求項6】
請求項5に記載の方法において、
前記取得ステップでは、前記統合処理が実行された後、前記利用サービスに紐づくユーザーIDの数と、前記支払金額と、を取得し、
前記表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、前記ユーザーIDの数と、を前記ユーザー端末に表示させる、
方法。
【請求項7】
請求項6に記載の方法において、
算出ステップを備え、
前記取得ステップでは、前記統合処理が実行された後、前記利用サービスを利用しているアカウントに関するアカウント情報を取得し、
前記アカウント情報は、前記ユーザーIDと、前記ユーザーIDのユーザーが属する組織に関する情報と、が紐づいた情報であり、
前記算出ステップでは、前記取得した前記ユーザーIDの数と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、前記アカウント情報と、に基づいて、以下の(1)及び(2)の少なくとも一方を算出する、
(1)ユーザー1人あたりの支払金額
(2)特定のユーザー又は特定の組織による過去から現在までの支払金額の合計金額
方法。
【請求項8】
請求項6又は7に記載の方法において、
算出ステップを備え、
前記算出ステップでは、前記利用サービスへのアクセス頻度と、前記ユーザーIDの数と、に基づくエンゲージメントスコアを算出し、
前記エンゲージメントスコアは、第1時点に前記利用サービスにアクセスした場合、第2時点に前記利用サービスにアクセスしたときよりも大きくなるスコアであり、
前記第2時点は、前記第1時点よりも過去の時点であり、
表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、前記ユーザーIDの数と、前記エンゲージメントスコアと、を前記ユーザー端末に表示させる、
方法。
【請求項9】
請求項8に記載の方法において、
前記表示制御ステップでは、前記エンゲージメントスコアが閾値を下回る前記利用サービスを前記ユーザー端末に表示させ、
前記閾値は、前記ユーザー端末を管理する管理者の現在の口座残高と、前記管理者の将来における口座残高の予測値と、の少なくとも一方に基づいて変化する、
方法。
【請求項10】
請求項5~9のいずれか1項に記載の方法において、
前記データベースは、複数の前記サービス名毎にユーザー1人あたりの料金を記憶しており、
前記算出ステップでは、前記統合処理が実行されない場合、前記支払金額と、前記データベースに記憶される前記料金と、に基づいて、前記ユーザーIDの数を算出する、
方法。
【請求項11】
請求項5~10のいずれか1項に記載の方法において、
算出ステップを備え、
前記算出ステップでは、所定期間における前記利用サービスへのアクセス履歴に基づいて、前記ユーザーIDの数を算出する、
方法。
【請求項12】
請求項1~11のいずれか1項に記載の方法において、
特定ステップを備え、
前記特定ステップでは、前記テキスト情報の中に同じ提供者名が複数存在する場合、サブスクリプション契約で利用している利用サービスと、前記サブスクリプション契約で利用している利用サービスに対する支払金額と、を特定し、
前記提供者名は、前記利用サービスを提供する者の名称であり、
前記表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する利用サービスであって、前記サブスクリプション契約で利用している利用サービスに対する前記支払金額と、をユーザー端末に表示させる、
方法。
【請求項13】
請求項1~12のいずれか1項に記載の方法において、
特定ステップを備え、
前記特定ステップでは、前記支払金額と、前記支払情報の取得頻度と、の少なくとも一方に基づいて、前記利用サービスに対する支払金額が月払いであるか年払いであるかを特定する、
方法。
【請求項14】
請求項1~13のいずれか1項に記載の方法において、
前記データベースは、前記複数のサービス名毎に、サービスの種類を示すカテゴリ情報を記憶し、
表示制御ステップでは、前記ユーザー端末に、前記カテゴリ情報により特定されるカテゴリ別に、前記特定されたサービス名を表示させる、
方法。
【請求項15】
プログラムであって、
少なくとも1つのコンピュータに、請求項1~14に記載の情報処理方法の各ステップを実行させる、
プログラム。
【請求項16】
少なくとも1つの装置からなるシステムであって、
請求項1~14に記載の情報処理方法の各ステップがなされるようにプログラムを実行可能な、少なくとも1つのプロセッサを備える、
システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理方法、プログラム及びシステムに関する。
【背景技術】
【0002】
近年、様々なサービスを業務で利用することが増えている。特許文献1には、利用者によるクラウドサービスの利用を管理するクラウドサービス利用管理装置が開示されている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
ところで、利用しているサービスの数が多くなると、これらのサービスに対して支払っている費用を把握することが手間になる。
【0005】
本発明では上記事情を鑑み、ユーザーが利用しているサービスに対する支払金額を容易に把握することが可能な技術を提供することとした。
【課題を解決するための手段】
【0006】
本発明の一態様によれば、コンピュータにより実行される情報処理方法が提供される。この情報処理方法は、取得ステップと、アクセスステップと、特定ステップと、表示制御ステップと、を備える。取得ステップでは、利用しているサービスである利用サービスに対する支払情報を取得する。支払情報は、支払金額と、支払金額に対応するテキスト情報と、を含む。アクセスステップでは、複数のサービス名を記憶するデータベースにアクセスする。特定ステップでは、アクセスしたデータベースに記憶される複数のサービス名の中から、テキスト情報に対応するサービス名を特定する。表示制御ステップでは、特定されたサービス名と、特定されたサービス名に対応する利用サービスに対する支払金額と、をユーザー端末に表示させる。
【0007】
本開示によれば、電子契約に係る情報の管理を支援する技術を提供することができる。
【図面の簡単な説明】
【0008】
【
図1】本発明の一実施形態に係るシステム100の構成を示す図である。
【
図2】情報処理システム1のハードウェア構成を示すブロック図である。
【
図3】情報処理システム1の機能を示す機能ブロック図である。
【
図4】データベース4に記憶されるデータの一例である。
【
図5】会計システム3から取得した支払情報の一例である。
【
図6】支払情報の他の例であるカード明細の一例である。
【
図7】支払情報の他の例であるメールの一例である。
【
図8】情報処理システム1により実行される情報処理方法の一例を表すアクティビティ図である。
【
図9】利用サービスに対する支払金額を可視化したグラフの一例である。
【
図10】利用サービス毎の支払金額を示すグラフの一例である。
【
図11】利用サービスのカテゴリを選択する様子を表す図である。
【
図12】利用サービスのサービス名を選択する様子を表す図である。
【
図13】受け付けたサービス名と、受け付けたサービス名に対応する利用サービスに対する支払金額と、を含む画面の例である。
【
図14】統合処理を実行することを選択する選択画像Ia~Ieを含む画面例である。
【発明を実施するための形態】
【0009】
以下、図面を用いて本発明の実施形態について説明する。以下に示す実施形態中で示した各種特徴事項は、互いに組み合わせ可能である。
【0010】
本実施形態に登場するソフトウェアを実現するためのプログラムは、コンピュータが読み取り可能な非一時的な記録媒体(Non-Transitory Computer-Readable Medium)として提供されてもよいし、外部のサーバからダウンロード可能に提供されてもよいし、外部のコンピュータで当該プログラムを起動させてクライアント端末でその機能を実現(いわゆるクラウドコンピューティング)するように提供されてもよい。
【0011】
また、本実施形態において「部」とは、例えば、広義の回路によって実施されるハードウェア資源と、これらのハードウェア資源によって具体的に実現されうるソフトウェアの情報処理とを合わせたものも含みうる。また、本実施形態においては様々な情報を取り扱うが、これら情報は、例えば電圧・電流を表す信号値の物理的な値、0又は1で構成される2進数のビット集合体としての信号値の高低、又は量子的な重ね合わせ(いわゆる量子ビット)によって表され、広義の回路上で通信・演算が実行されうる。
【0012】
また、広義の回路とは、回路(Circuit)、回路類(Circuitry)、プロセッサ(Processor)、及びメモリ(Memory)等を少なくとも適当に組み合わせることによって実現される回路である。すなわち、特定用途向け集積回路(Application Specific Integrated Circuit:ASIC)、プログラマブル論理デバイス(例えば、単純プログラマブル論理デバイス(Simple Programmable Logic Device:SPLD)、複合プログラマブル論理デバイス(Complex Programmable Logic Device:CPLD)、及びフィールドプログラマブルゲートアレイ(Field Programmable Gate Array:FPGA))等を含むものである。
【0013】
1.情報処理システム1を含むシステム100の概要
図1に示すように、本発明の一実施形態に係るシステム100は、情報処理システム1を備える。本実施形態では、システム100はさらに、ユーザー端末2と、会計システム3と、データベース4と、サービスシステム5とを備える。そして、情報処理システム1、ユーザー端末2、会計システム3、データベース4、及びサービスシステム5がネットワークNWを介して互いに接続されている。
【0014】
情報処理システム1は、例えばサーバにより構成される。ここで、情報処理システム1は、1又は複数の装置又は構成要素からなるものである。つまり、1つのサーバにより情報処理システム1が構成されてもよく、複数の処理を複数のサービスにより実現するシステムとして情報処理システム1が構成されてもよい。また、情報処理システム1を構成するサーバは、本特許出願がなされる国の国内に設置されてもよく、国外に設置されてもよい。
【0015】
また、情報処理システム1により、ユーザー又はユーザーが属する組織が利用しているサービスを管理するための管理サービスが提供される。管理サービスは、SaaS(Software as a Service)の形態で提供されるものでもよい。
【0016】
ユーザー端末2は、ユーザーが利用する端末であり、任意のコンピュータにより構成される。例えば、スマートフォン、タブレット端末、スマートウォッチ、ノートPC、デスクトップPC、多機能音楽プレーヤー等の多機能端末により構成される。また、ユーザー端末2は、表示部を備える。表示部は、テキストや画像(静止画及び動画を含む)を表示するものであり、任意のディスプレイにより構成される。ここで、本実施形態におけるユーザーは、少なくとも1つの有料サービスを利用している人物又は組織の一員であり、企業の従業員であってもよく、個人事業を営む者であってもよい。
【0017】
また、ユーザー端末2を操作することで情報処理システム1が提供する管理サービスにアクセスし、ユーザー又はユーザーが属する組織が利用している利用サービスを管理することができる。
【0018】
会計システム3は、経費申請サービス及び請求書管理サービスの少なくとも一方の機能を実現するシステムである。会計システム3は、ユーザー端末2を管理する管理主体が利用するものであり、管理主体の従業員等により日々の経費申請や請求書管理等の情報が管理される。会計システム3は、SaaSの形態で提供されるものでもよい。
【0019】
データベース4は、複数のサービス名を記憶する。データベース4は、情報処理システム1の提供者により構築されるものであり、手動又は自動で複数のサービス名を記憶させたものである。
【0020】
サービスシステム5は、ユーザーが利用可能な種々のサービスを提供するためのシステムである。サービスシステム5は、例えば、サブスクリプション型のサービスを提供するサーバにより構成される。
【0021】
2.情報処理システム1のハードウェア構成
図2に示すように、情報処理システム1は、制御部10、通信部20、記憶部30、入力部40及び表示部50を備える。
【0022】
<制御部10>
制御部10は、情報処理システム1に関連する全体動作の処理・制御を行う。制御部10は、例えば、不図示の中央処理装置(Central Processing Unit:CPU)により構成される。制御部10は、記憶部30に記憶された所定のプログラムを読み出すことによって、情報処理システム1に係る種々の機能を実現する。すなわち、記憶部30に記憶されているソフトウェアによる情報処理が、ハードウェア(制御部10)によって具体的に実現されることで、制御部10に含まれる各機能部(
図3参照)として実行されうる。なお、制御部10は、単一のモジュールにより構成されてもよく、機能ごとに複数のモジュールにより制御部10を構成してもよい。
【0023】
<通信部20>
通信部20は、他の情報処理装置又は構成要素と有線又は無線によりデータ通信可能に構成される。通信部20は、例えば、USB、IEEE1394、Thunderbolt(登録商標)、有線LANネットワーク通信等といった有線型の通信手段、及び無線LANネットワーク通信、5G/LTE/3G等のモバイル通信、Bluetooth(登録商標)通信等の組み合わせにより構成される。
【0024】
<記憶部30>
記憶部30は、種々のプログラム及びデータを記憶するものであり、例えばメモリ、HDD(Hard Disk Drive)、SSD(Solid State Drive)、ROM(Read Only Memory)、RAM(Random Access Memory)等により構成される。また、記憶部30は、プログラムや種々のデータ等を記憶する。そして、記憶部30に記憶されているプログラムに基づいて制御部10が種々の処理を実行することにより、種々の機能が実現する。
【0025】
<入力部40>
入力部40は、情報処理システム1に種々の情報を入力するものであり、マウス、キーボード、ポインティングデバイス等により構成される。なお、他の情報処理装置に接続されたこれらのデバイスを用いて、ネットワークNWを介して入力部40として機能させてもよい。
【0026】
<表示部50>
表示部50は、テキスト、写真、画像(静止画及び動画を含む)を表示するものであり、任意のディスプレイにより構成される。表示部50は、情報処理システム1がサーバである場合、情報処理システム1に直接又は間接的に接続されたディスプレイにより構成される。
【0027】
3.情報処理システム1の機能構成
図3に示すように、情報処理システム1の制御部10は、取得部11と、アクセス部12と、特定部13と、表示制御部14とを備える。制御部10はさらに、受付部15及び算出部16を備えてもよい。
【0028】
<取得部11>
取得部11は、利用しているサービスである利用サービスに対する支払情報を取得可能に構成される。本実施形態では、支払情報は、会計システム3から取得される。合わせて、またはこれに変えて、カード明細及びメールの少なくとも一方から支払情報を取得してもよい。また、支払情報は、ユーザー端末2から情報処理システム1にアップロードされたcsvデータ又はユーザーが手動で入力した任意の形式のデータであってもよい。さらに、ユーザー端末2で利用している電子メールを転送してもらう、又は電子メールを管理するメールサーバへのアクセス権を付与してもらうことにより、ユーザーの電子メールに添付している任意のデータを支払情報として利用してもよい。
本実施形態における利用サービスは、サブスクリプション型のサービスであり、月単位または年単位で利用料が発生するものである。また、利用サービスは、SaaS型のサービスだけでなく、例えば、ウォーターサーバーで利用するための水の配送等、物である製品の定期又は不定期の配送サービスも含む。さらに、利用サービスは、スポーツジム等の施設の利用や、新聞配達等のサービスも含む。
【0029】
支払情報は、支払金額と、支払金額に対応するテキスト情報と、を含む。支払金額は、利用サービスの利用料に相当するものである。また、テキスト情報は、テキスト形式で記述された情報であり、利用サービスのサービス名、利用サービスの提供者名、及びそれらの略語の少なくとも1つを含む情報である。
【0030】
また、取得部11は、利用サービスに紐づくユーザーIDの数を取得可能に構成されてもよい。ここで、利用サービスに紐づくユーザーIDの数は、例えば、ある企業で利用している利用サービスがあり、1,000人の従業員にこの利用サービスを利用させている場合、ユーザーIDの数は1,000となる。
【0031】
<アクセス部12>
アクセス部12は、複数のサービス名を記憶するデータベース4にアクセス可能に構成される。
【0032】
<特定部13>
特定部13は、アクセスしたデータベース4に記憶される複数のサービス名の中から、テキスト情報に対応するサービス名を特定可能に構成される。これは、支払情報に含まれるテキスト情報により特定されるサービス名が、データベース4に記憶される複数のサービス名のいずれかと一致するか否かを判定するマッチング処理に相当する。
【0033】
<表示制御部14>
表示制御部14は、特定部13により特定されたサービス名と、特定されたサービス名に対応する利用サービスに対する支払金額と、をユーザー端末2に表示可能に構成さる。ここで、本実施形態では、情報処理システム1が提供する管理サービスにアクセス中のユーザー端末2に、表示制御部14が種々の情報を表示させる。
【0034】
また、表示制御部14は、支払金額を時系列に沿って可視化したグラフをユーザー端末2に表示させてもよい。ここで、表示制御部14は、ユーザー端末2に表示させる表示画像を生成し、表示画像をユーザー端末2に送信することでユーザー端末2に画像を表示させてもよい。また、表示制御部14は、表示命令をユーザー端末2に送信し、ユーザー端末2側で表示画像を生成させることでユーザー端末2に画像を表示させてもよい。また、これらの組み合わせでもよい。
【0035】
<受付部15>
受付部15は、情報処理システム1又は他の端末から、種々の命令及び選択を受付可能に構成される。本実施形態では、受付部15は、ユーザー端末2から、特定された複数のサービス名から1つのサービス名の選択を受け付ける。
【0036】
<算出部16>
算出部16は、取得したユーザーIDの数と、特定されたサービス名に対応する利用サービスに対する支払金額と、アカウント情報と、に基づいて、以下の(1)及び(2)の少なくとも一方を算出可能に構成される。
(1)ユーザー1人あたりの支払金額
(2)特定のユーザー又は特定の組織による過去から現在までの支払金額の合計金額
【0037】
また、算出部16は、利用サービスへのアクセス頻度と、ユーザーIDの数と、に基づくエンゲージメントスコアを算出可能に構成されてもよい。ここで、エンゲージメントスコアは、第1時点に利用サービスにアクセスした場合、第2時点に利用サービスにアクセスしたときよりも大きくなるスコアである。第2時点は、第1時点よりも過去の時点である。別の言い方をすれば、情報処理システム1は、利用サービスに対するユーザーのアクセスログ、利用履歴、及び利用頻度を示すアクティビティデータを取得し、当該アクティビティデータに基づいて、エンゲージメントスコアを算出することが出来る。詳細については
図16を用いて後述する。
【0038】
また、算出部16は、種々の方法により、ユーザーIDの数を算出可能に構成されてもよい。かかる方法については後述する。
【0039】
4.データベース4が記憶するデータ
図4は、データベース4に記憶されるデータの一例である。データベース4は、少なくとも複数のサービス名を記憶している。また、
図4に示されるように、データベース4は、複数のサービス名毎に、サービス名を特定するサービスID、サービス名、サービス名の提供者、カテゴリ、ユーザー1人あたりの料金[円/月]、及びサービスに関する説明が掲載されているウェブサイトへのリンクを表すURLを対応付けて記憶してもよい。
【0040】
ここで、
図4におけるサービス名は、主にサブスクリプション型のSaaS形式で提供されるものを示している。かかるサービスのカテゴリは、機能別に分類されたカテゴリであって、チャット、TV会議、案件管理、勤怠管理、財務・会計であってもよい。ここで、カテゴリは任意に分類することが可能であり、機能別、料金別、利用地域別、関連会社別、部署別、チーム別、ユーザー別により分類されたものでもよい。また、かかるカテゴリは、複数のサービスをインストール可能なアプリストアで表記されている記載を用いてもよく、データベース4の構築者が独自のカテゴリに分類してもよい。すなわち、データベース4は、複数のサービス名毎に、サービスの種類を示すカテゴリ情報を記憶してもよい。
【0041】
5.支払情報について
図5~
図7は、支払情報の一例を示す図である。
図5は、情報処理システム1が会計システム3から取得した支払情報の一例である。
【0042】
<支払情報を会計システム3から取得する場合>
図5は、会計システム3により管理される支払情報又は建替情報を示す。かかる支払情報は、情報処理システム1と会計システム3をAPI(Application Programming Interface)により接続することで、スプレッドシート形式で取得することができる。
図5に示されるように、支払情報は、支払金額(金額の列に含まれる情報)と、支払金額に対応するテキスト情報(支払先・内容の列に含まれる情報)を含む。ここで、テキスト情報は、サービスの提供者名(A社、B社、C社)と、サービス名(service_a,service_b,service_c)と、の少なくとも一方を特定できる情報である。
図5の例では、テキスト情報として、サービスの提供者名とサービス名がセットになった情報がテキスト情報に相当する。ここで、テキスト情報は、サービスの提供者名のみ、またはサービス名のみ、であってもよい。
【0043】
図5の例では、明細番号毎に、サービスを利用した(又は費用が発生する起点となる)「日付」と、テキスト情報の一例である「支払先・内容」と、利用サービスに対する支払金額である「金額」と、経費計上する際の経費科目」と、現在の「税区分」と、が対応付いて管理されている。ここで、支払情報の内容は、支払情報を生成する者が任意に定めることができる。
【0044】
<支払情報としてカード明細を利用する場合>
図6は、支払情報として利用可能なカード明細の一例である。
図6の例では、カードの利用毎に、カード決済を実行した日である「ご利用日」と、カード決済を行った店舗である「ご利用店舗名」と、カードの利用金額である「ご利用金額」と、が対応付いて管理されている。
【0045】
図6の例では、「ご利用店舗名」の列に含まれる情報の一部又は全部がテキスト情報に相当する。
図6の例では、サービスの提供者名(D社)と、サービス名(service_e)と、がテキスト情報に相当する。
【0046】
ここで、カード明細は、ユーザー端末2のユーザーにより情報処理システム1にアップロードされてもよく、情報処理システム1がユーザーアカウントを預かり、ユーザーが利用するカード会社のシステムとAPI接続することで、カード会社のシステムから情報処理システム1がカード明細を取得してもよい。
【0047】
<支払情報としてメールを利用する場合>
図7は、支払情報として利用可能なメールの一例である。
図7の例では、X社が提供するXマーケットから水を購入したときに送信されるメールを表す。本メールには、注文内容として、注文番号、注文日、商品名、商品の金額(小計)、配送料・手数料、注文合計、及び支払方法が含まれる。このとき、商品名である「Xの水(定期配送)」がテキスト情報に相当する。つまり、かかる商品名が、ユーザーが利用する利用サービスのサービス名を特定できる情報である。
【0048】
6.情報処理システム1により実行される情報処理方法
次に、
図8~
図16を用いて、情報処理システム1により実行される情報処理方法について説明する。本実施形態における情報処理方法は、コンピュータの一例である情報処理システム1により実行される。情報処理方法は、取得ステップと、アクセスステップと、特定ステップと、表示制御ステップと、を備える。以下、具体的に説明する。
【0049】
まず、A1において、取得ステップが実行される。本実施形態では、取得部11により取得ステップが実行され、会計システム3から利用サービスに対する支払情報を取得する。支払情報は、支払金額と、支払金額に対応するテキスト情報と、を含む。なお、会計システム3から支払情報を取得することと合わせ、またはこれに変えて、カード明細及びメールの少なくとも一方から支払情報を取得してもよい。また、支払情報は、ユーザー端末2から情報処理システム1にアップロードされたcsvデータ又はユーザーが手動で入力した任意の形式のデータであってもよい。さらに、ユーザー端末2で利用している電子メールを転送してもらう、又は電子メールを管理するメールサーバへのアクセス権を付与してもらうことにより、ユーザーの電子メールに添付している任意のデータを支払情報として利用してもよい。
【0050】
次に、A2において、アクセスステップが実行される。本実施形態では、アクセス部12によりアクセスステップが実行され、複数のサービス名を記憶するデータベース4にアクセスする。
【0051】
次に、A3において、特定ステップが実行される。本実施形態では、特定部13により特定ステップが実行され、アクセスしたデータベース4に記憶される複数のサービス名の中から、テキスト情報に対応するサービス名を特定する。例えば、支払情報に含まれるテキスト情報が、
図5に示される「A社(service_a)」である場合には、データベース4に記憶されるデータ(
図4参照)の中に、「A社(service_a)」に対応するサービス名が存在するか否かを調べる。そして、データベース4に記憶されるデータの中に「A社(service_a)」に対応するサービス名である「service_a」が存在する場合、サービスIDが「1」で特定される「service_a」を、テキスト情報である「A社(service_a)」に対応するサービス名として特定する。
【0052】
ここで、かかる特定は、支払情報に含まれる、サービス名又はサービスの提供者に紐づいたテキスト情報を利用すればどのような手法を用いてもよい。例えば、テキスト情報に、利用サービスのサービス名、利用サービスの提供者名、及びそれらの略語の少なくとも1つが含まれる場合、それらの情報とデータベース4に記憶されるサービス名との対応付を規定したテーブルを作成し、かかるテーブルによりテキスト情報とサービス名との対応関係を特定してもよい。また、自然言語処理を用いることにより、テキスト情報に含まれる文字列と、データベース4に記憶されるサービス名に含まれる文字列と、が予め定められた割合以上一致する場合には、両者が対応しているものとして特定してもよい。
【0053】
次にA4において、表示制御ステップが実行される。本実施形態では、表示制御部14により表示制御ステップが実行され、特定ステップにおいて特定されたサービス名と、特定されたサービス名に対応する利用サービスに対する支払金額と、をユーザー端末2に表示させる。
【0054】
図9は、ユーザー端末2に表示される画面の一例である。
図9の例では、利用サービスの一例として、ユーザー又はユーザーが属する組織が利用しているSaaSのサービスに対する支出額を縦軸に、月単位を横軸にとり、月ごとの支出額(支払金額)を可視化したグラフである。
【0055】
図10は、ユーザー端末2に表示される画面の他の一例である。
図10の例では、利用サービスの一例であり、特定ステップにおいて特定されたサービス名である「service_a」、「service_b」、及び「service_c」と、これらのサービスに対する支出額(支払金額)と、が含まれる。
【0056】
このとき、「service_a」、「service_b」、及び「service_c」をまとめて表示させてもよく、1つずつのサービスを表示させてもよい。ここで、
図10に示されるように、複数のサービスをまとめて表示させるためには、複数のサービスに関する支払情報を取得する必要がある。このとき、取得部11により取得される支払情報は、複数の利用サービスに関するものである。そして、支払情報は、複数の支払金額と、複数の支払金額にそれぞれ対応する複数のテキスト情報と、を含む。
図5の例では、1つの支払情報の中に複数の支払金額が含まれる。このうち、明細番号が「2,4,5」で特定されるものが、利用サービスに関する情報である。このとき、「service_a」、「service_b」、及び「service_c」に対する金額が「複数の支払金額」に相当し、「A社(service_a)」、「B社(service_b)」、及び「C社(service_c)」が「複数の支払金額にそれぞれ対応する複数のテキスト情報」に相当する。
【0057】
支払情報に、複数の支払金額と、複数の支払金額にそれぞれ対応する複数のテキスト情報と、が含まれる場合には、特定ステップでは、アクセスしたデータベース4に記憶される複数のサービス名の中から、複数のテキスト情報のそれぞれに対応する複数のサービス名を特定する。
【0058】
このように、
図10に示されるように、表示制御ステップでは、支払金額を時系列に沿って可視化したグラフをユーザー端末2に表示させてもよい。これにより、いずれのサービスにどの程度の金額を支払っているかを直感的に把握することが可能になる。例えば、「service_a」は、2022年6月~2021年12月までは支出額が約35万円で一定であったところ、2022年2月には支出額が約270万円と大幅増となっている。これは、2022年2月に「service_a」を利用する社内ユーザーが増加したか、上位プランに切り替えたためであると推察される。
【0059】
また、ボックスb1は、ユーザー端末2に表示させる利用サービスのカテゴリを選択するためのボックスである。ユーザーは、ユーザー端末2を操作してボックスb1の右部にあるプルダウンアイコンPDIを押下することで、ボックスb1の下部に
図11に示される領域r1が展開される。領域r1は、利用サービスのカテゴリを示すカテゴリ情報が表示される領域である。ユーザーは、ユーザー端末2を操作することで利用サービスのカテゴリを選択することができる。例えば、
図11の状態でカテゴリ「チャット」を選択すると、ユーザー端末2の画面には、カテゴリが「チャット」に属する利用サービスと、その利用サービスに対する支出額(支払金額)と、が表示される。
【0060】
このとき、表示制御ステップでは、ユーザー端末2に、カテゴリ情報により特定されるカテゴリ別に、特定されたサービス名を表示させる。
【0061】
さらに、ボックスb2は、ユーザー端末2に表示させる利用サービスを選択するためのボックスである。ユーザーは、ユーザー端末2を操作してボックスb2の右部にあるプルダウンアイコンPDIを押下することで、ボックスb2の下部に
図12に示される領域r2が展開される。領域r2は、利用サービスを示す選択肢が表示される領域である。ユーザーは、ユーザー端末2を操作することで利用サービスを選択することができる。
【0062】
そして、領域r2に表示される選択肢のうち、特定の選択肢が選択されると、A5において、受付ステップが実行される。本実施形態では、受付部15により受付ステップが実行され、ユーザー端末2から、特定された複数のサービス名から1つのサービス名の選択を受け付ける。
【0063】
そして、A6において、表示制御ステップが実行される。本実施形態では、表示制御部14により表示制御ステップが実行され、受け付けたサービス名と、受け付けたサービス名に対応する利用サービスに対する支払金額と、をユーザー端末2に表示させる。
【0064】
例えば、
図12の状態でサービス名である「service_a」が選択されると、
図13に示すように、ユーザー端末2の画面には、「service_a」と、「service_a」に対する支出額(支払金額)と、が表示される。なお、情報処理システム1は、1つの利用サービスのみの選択を受け付けてもよく、複数の利用サービスの選択をまとめて受け付けてもよい。
【0065】
このように、表示制御ステップにおいてユーザー端末2に表示させるグラフは、以下の(1)~(3)の少なくとも1つの態様で表現されてもよい。
(1)複数の利用サービスに対する支払金額の合計金額を時系列に沿って可視化する:
図9に対応
(2)複数の利用サービスを区別可能に可視化する:
図10に対応
(3)複数の利用サービスのうち、ユーザー端末により選択された利用サービスを可視化する:
図13に対応
なお、情報処理システム1が実現する機能としては、上記の(1)~(3)の全てを実現することができるものであってもよく、(1)~(3)のどの態様を表示するかをユーザーによって選択可能であってもよい。
【0066】
<統合処理>
次に、統合処理について説明する。A7において、表示制御ステップが実行される。本実施形態では、表示制御部14により表示制御ステップが実行される。
【0067】
表示制御ステップでは、利用サービスに対する統合処理を実行することを選択する選択画像をユーザー端末に表示させる。ここで、統合処理は、利用サービスを提供するサービスシステム5から、利用サービスに紐づくユーザーIDの数と、支払金額と、を取得できる状態にする処理である。例えば、情報処理システム1とサービスシステム5をAPIで接続することにより、情報処理システム1がサービスシステム5からユーザーIDの数と支払金額を取得できるようになる。
【0068】
図14は、ユーザー端末2に表示される、選択画像Ia~Ieを含む画面の一例である。
図14の例では、統合処理の対象となり得るサービスを「インテグレーション候補」として表示している。そして、統合処理が既に実行されたサービスを「全てのインテグレーション」として表示している。
【0069】
また、ユーザー端末2を操作して利用サービスのサービス名をボックスb3に入力することで、特定のサービスを検索することができる。また、出力アイコンOIを押下することにより、インテグレーション候補の一例である検出したSaaSに関する情報をまとめてcsv形式等で出力できる構成としてもよい。
【0070】
そして、選択画像Ia~Ieのいずれか又は全てが選択された場合、A8において、制御部10が統合処理を実行する。これにより、本実施形態では、情報処理システム1と、利用サービスを提供するサービスシステム5とがAPIで接続され、利用サービスに紐づくユーザーIDの数と、支払金額と、をサービスシステム5から取得することが可能になる。
【0071】
そして、例えば、
図14において選択画像Ia~Icが選択された場合には、「service_a」~「sevice_c」に対して統合処理が実行される。その後、
図15に示されるように、統合処理が完了した利用サービス(「service_a」~「sevice_c」)が「全てのインテグレーション」の中に表示され、「インテグレーション候補」からは消えた状態となる。
【0072】
そして、A9aにおいて、取得ステップが実行される。本実施形態では、統合処理が実行された後、取得部11により取得ステップが実行され、利用サービスに紐づくユーザーIDの数と、支払金額と、を取得する。
【0073】
また、本実施形態では、統合処理が実行された後、取得部11により取得ステップが実行され、利用サービスを利用しているアカウントに関するアカウント情報を取得してもよい。ここで、アカウント情報は、ユーザーIDと、ユーザーIDのユーザーが属する組織に関する情報と、が紐づいた情報である。また、アカウント情報は、特定のユーザーの利用プラン及び利用プランの料金を含んでも良い。
【0074】
次に、A10aにおいて、算出ステップが実行される。本実施形態では、算出部16により算出ステップが実行される。ここで、
図8では、説明の都合上、算出ステップにおいて実行される処理を算出処理と表記している。
【0075】
算出ステップでは、取得したユーザーIDの数と、特定されたサービス名に対応する利用サービスに対する支払金額と、アカウント情報と、に基づいて、以下の(1)及び(2)の少なくとも一方を算出してもよい。
(1)ユーザー1人あたりの支払金額
(2)特定のユーザー又は特定の組織による過去から現在までの支払金額の合計金額
なお、情報処理システム1が実現する機能としては、上記の(1)及び(2)の両方を算出することができるものであってもよい。
【0076】
(1)は、「利用サービスに対する支払情報に含まれる支払金額/ユーザーIDの数」により算出することができる。
(2)は、特定のユーザーに着目し、過去から現在までの期間における支払金額を足し合わせることで合計金額を算出することができる。特に、アカウント情報に、特定ユーザーの利用プラン及びその料金が含まれる場合、過去から現在までの期間のどこかで利用プランが変更された場合でも、特定のユーザーの過去から現在までの支払金額の合計金額を正確に算出することができる。さらに、特定のユーザーが属する組織に関する情報を利用することで、特定の組織における過去から現在までの支払金額の合計金額を算出することができる。
【0077】
また、算出ステップでは、利用サービスへのアクセス頻度と、ユーザーIDの数と、に基づくエンゲージメントスコアを算出してもよい。ここで、エンゲージメントスコアは、第1時点に利用サービスにアクセスした場合、第2時点に利用サービスにアクセスしたときよりも大きくなるスコアである。なお、
第2時点は、第1時点よりも過去の時点である。つまり、本実施形態におけるエンゲージメントスコアは、利用サービスへのアクセスがなされていない期間が長いほど利用頻度が低いとみなし、利用サービスに対するエンゲージメントが低いものとして扱うためのスコアである。
【0078】
エンゲージメントスコアは、例えば、以下のようなエンゲージメント係数を用いて定めることができる。
(エンゲージメント係数の例)
・3日以内にアクセスがある場合:エンゲージメント係数=10pt
・10日以内にアクセスがある場合:エンゲージメント係数=5pt
・30日以内にアクセスがある場合:エンゲージメント係数=2pt
・31日以上アクセスがなされていない場合:エンゲージメント係数=0pt
【0079】
そして、「エンゲージメントスコア=エンゲージメント係数×ユーザーIDの数」としてエンゲージメントスコアを算出してもよい。例えば、ある利用サービスに対して3日以内にアクセスしたユーザーが10名いた場合には、その利用サービスに対するエンゲージメントスコアは「100pt(=10pt×10人)」となる。
【0080】
<統合処理が実行されない場合>
一方、A7において、選択画像Ia~Ieのいずれも選択されなかった場合、A9bに処理を進める。そして、A9bにおいて、取得部11により取得ステップが実行され、支払情報を取得する。ここで、A1においてすでに支払情報を取得している場合には、A9bの処理をスキップすることができる。
【0081】
そして、A10bにおいて、統合処理が実行されなかった場合における算出ステップが実行される。本実施形態では、統合処理が実行されない場合、算出部16により算出ステップが実行され、支払金額と、データベース4に記憶される料金と、に基づいて、ユーザーIDの数を算出してもよい。本実施形態では、取得部11が取得した支払金額、すなわち、組織全体としての支払金額の合計金額を、
図4に示される「1人あたりの料金[円/月](データベース4に記憶される料金の一例)で除することにより、ユーザーIDの数を算出することができる。
【0082】
また、データベース4に料金が記憶されていない場合には、算出ステップでは、所定期間における利用サービスへのアクセス履歴に基づいて、ユーザーIDの数を算出してもよい。例えば、利用サービスとしてブラウザからアクセスするSaaSサービスを利用している場合には、ブラウザからのアクセス履歴を解析し、所定期間(例:3ヶ月)にSaaSサービスにアクセスした人数をユーザーIDの数として算出してもよい。
【0083】
あわせて、統合処理が実行されていない利用サービスに対しても、エンゲージメントスコアを算出してもよい。
【0084】
このように、A10a及びA10bの少なくとも一方によりユーザーIDの数が算出された場合、
図14に示されるように、「インテグレーション候補」及び「全てのインテグレーション」に含まれる画像の一部に、各サービスに紐づくユーザーIDの数を表示させてもよい。
図14の例では、統合処理が完了したサービスである「service_o」~「service_z」のそれぞれに対応する画像には、各サービスに紐づくユーザーIDの数が表示されている(例:service_oでは2,400人)。また、統合処理が実行されていない場合でも、すでにA10bによりユーザーIDの数が算出されたサービスには、ユーザーIDの数が表示されてもよい。
図14の例では、「service_a」及び「service_c」については、統合処理が実行されていないものの、A10bによりユーザーIDの数が算出されたことで、ユーザーIDの数が表示されている。一方、「service_b」については、統合処理も実行されておらず、A10bにおける算出処理も実行されていないため、ユーザーIDの数が表示されていない。一方、「service_b」に対して統合処理が実行された場合、
図15に示すように、「service_b」と合わせて「service_b」のユーザーIDの数が表示されている。
【0085】
そして、A11において、表示制御ステップが実行される。本実施形態では、表示制御部14により表示制御ステップが実行される。表示制御ステップでは、特定ステップ(A3)において特定されたサービス名と、特定されたサービス名に対応する利用サービスに対する支払金額と、算出ステップ(A10a及びA10bの少なくとも一方)により算出されたユーザーIDの数と、エンゲージメントスコアと、をユーザー端末2に表示させてもよい。
【0086】
図16は、ユーザー端末2に表示される画面であって、エンゲージメントスコアを可視化した画面の一例である。
図16の例では、利用サービスへの支出額(支払金額)を縦軸に、月単位を横軸にとり、エンゲージメントスコアをバブルのサイズで表現している。ここで、バブルa~eはそれぞれ、「service_a」~「service_e」に対するエンゲージメントスコアを表す。バブルのサイズが大きいものほど、エンゲージメントスコアが大きい。
図16の例では、エンゲージメントスコアが大きい順に、バブルd>バブルa>バブルb>バブルe>バブルcとなっている。ここで、バブルのサイズに変えて、バブル又は他のアイコンの明度、彩度、輝度や、区別可能な色により、エンゲージメントスコアの大小を表現してもよい。
【0087】
また、ユーザー端末2により操作されるカーソル(不図示)がオーバーレイされたバブルに対応する情報を表示させてもよい。
図16の例では、バブルbにカーソルがオーバーレイされた場合に、バブルbの近傍に領域r3が展開されている。そして、領域r3には、バブルbに対応するサービスである「service_b」、ユーザーIDの数(1200 ID)、月毎の支出額(¥75万)、エンゲージメントスコア(40)が表示される。
【0088】
このように、エンゲージメントスコアを可視化することにより、複数の利用サービスのうち、利用を継続するか否か(つまり、利用サービスを解約するか否か)の判断を容易に行うことができる。例えば、各サービスについて、以下の示唆を得ることができる。なお、以下の示唆はあくまで一例であり、エンゲージメントスコアからどのような情報を読み取るかは人により異なる。
・service_a:ユーザーIDの数及び支出額が多く、エンゲージメントスコアが比較的高い。つまり、ある程度のユーザーが実際に高頻度でservice_aを利用しており、利用を継続すべきである。
・service_b:ユーザーIDの数が比較的多いが支出額が少ない。エンゲージメントスコアもまずまず高い。このため、service_bの利用を停止するほどでもない。
・service_c:ユーザーIDの数及び支出額が低く、エンゲージメントスコアも低い。そのため、service_cは早めに解約すべきである。
・service_d:ユーザーIDの数は少ないが支出額が大きい。これは、1ユーザー当たりの料金が高額なサービスであるといえる。同時に、エンゲージメントスコアも大きい。つまり、service_dは、利用するユーザーの数は少ないものの、利用者は高頻度で利用しているものであり、解約することはおすすめできない。
・service_e:ユーザーIDの数及び支出額が多いものの、エンゲージメントスコアが低い。このため、コスト削減の観点から、service_eのユーザーIDの一部又は全部を解約すべきである。
【0089】
また、
図16に示される画面にも、
図10に示されるものと同様のボックスb1及びボックスb2が含まれてもよい。
【0090】
また、表示制御ステップでは、エンゲージメントスコアが閾値を下回る利用サービスをユーザー端末2に表示させてもよい。このとき、当該利用サービスの解約(もしくは、解約の検討)をレコメンドするメッセージをユーザー端末2に表示させてもよい。また、閾値は、ユーザー端末2を管理する管理者の現在の口座残高と、管理者の将来における口座残高の予測値と、の少なくとも一方に基づいて変化してもよい。ここで、ユーザー端末2を管理する管理者は、ユーザー端末2のユーザーであってもよく、ユーザーが属する組織(特に企業)の責任者であってもよい。管理者が企業の責任者の場合には、事業口座で管理される口座残高が多いほど、閾値を大きくしてもよい。これは、口座残高が多いほど多くの支払に耐えられる一方、口座残高が少なくなると、できるだけ支出を節約することが好ましいためである。これにより、コストパフォーマンスの低い利用サービスを容易に把握することができ、必要に応じてかかる利用サービスを解約することで、コストを削減することができる。
【0091】
以上説明したように、本実施形態に係る情報処理システム1により、取得ステップと、アクセスステップと、特定ステップと、表示制御ステップと、を備える情報処理方法が提供される。これにより、ユーザーが利用しているサービスに対する支払金額を容易に把握することが可能になる。
【0092】
7.他の実施形態
<サブスクリプション契約で利用している利用サービスを表示>
図8のA3において特定部13により実行される特定ステップでは、テキスト情報の中に同じ提供者名が複数存在する場合、サブスクリプション契約で利用している利用サービスと、サブスクリプション契約で利用している利用サービスに対する支払金額と、を特定してもよい。ここで、提供者名は、利用サービスを提供する者の名称である。かかる特定は、例えば、
図5に示されるように、明細番号が「2,3」で特定されるものには、同じ提供者名である「A社」が含まれる。このとき、A社により提供される「service_a」については、支払情報に含まれる「日付」が13日となるサブスクリプション契約である場合には、13日の支払に対応する利用サービスを、サブスクリプション契約でしている利用サービスとして特定することができる。このように、毎月の請求日が固定されている場合には、情報処理システム1の記憶部30又はデータベース4に予め請求日を記憶させておき、この請求日を参照することにより、サブスクリプション契約で利用している利用サービスであるか、明細番号が「3」で特定されるもののようなスポット的な支払であるかを特定することができる。
【0093】
そして、A4において表示制御部14により実行される表示制御ステップでは、特定ステップにおいて特定されたサービス名と、特定されたサービス名に対応する利用サービスであって、サブスクリプション契約で利用している利用サービスに対する支払金額と、をユーザー端末2に表示させてもよい。
【0094】
これにより、サブスクリプション契約で利用しているサービスをまとめてユーザー端末2に表示させることができ、毎月又は毎年発生しうる利用料を可視化することができるので、将来の支払金額の予測をしやすくなる。
【0095】
<月払い又は年払いの表示>
図8のA3において特定部13により実行される特定ステップでは、支払金額と、支払情報の取得頻度と、の少なくとも一方に基づいて、利用サービスに対する支払金額が月払いであるか年払いであるかを特定してもよい。これは、支払金額の大きさ又は支払頻度により、支払金額が月払いであるか年払いであるかを特定することができる。具体的には、支払金額が、利用サービスの月毎の「ユーザー1人当たりの利用料」と「ユーザーIDの数」をかけ合わせた金額より多い場合、利用サービスに対する支払金額が年払いであると特定することができる。また、支払が数ヶ月連続で発生している場合には、用サービスに対する支払金額が年払いであると特定することができる。また、ユーザーがユーザー端末2を操作し、利用サービス毎に月払いであるか年払いであるかを情報処理システム1に入力してもよい。
【0096】
これにより、月払いであるか年払いであるかを区別しない場合と比べ、将来の支払金額の予測精度をさらに向上させることが可能になる。
【0097】
<他の例>
図16に示されるエンゲージメントスコアを含む画面のうち、ROI(Return On Investment)への寄与度が予め定められた値以下である利用サービスを提示してもよい。これにより、費用対効果が相対的に低い利用サービスを特定することが容易になる。このとき、費用対効果が相対的に低いものとして特定された利用サービスの解約(もしくは、解約の検討)をレコメンドするメッセージをユーザー端末2に表示させてもよい。
【0098】
また、ユーザー又はユーザーが属する組織で利用している複数の利用サービスのうち、同一のカテゴリに属する利用サービスが複数存在する場合、それらの利用サービスを提示してもよい。また、同一のカテゴリに属する複数のサービスのうち、エンゲージメントスコアが低いものから順に表示させてもよい。例えば、同一のカテゴリに属する利用サービスが複数存在する場合に、それらのサービスのうち、利用頻度が少ないサービス及び/又は一定期間全く利用されていないサービスの解約(もしくは、解約の検討)をレコメンドするメッセージをユーザー端末2に表示させてもよい。利用頻度が少ないサービス及び/又は一定期間全く利用されていないサービスは、エンゲージメントスコアが閾値を下回るサービスである。
【0099】
これにより、例えば、カテゴリが「チャット」である複数の利用サービスのうち、利用頻度が少ないサービスや、一定期間全く利用されていないサービスを解約し、支出を削減することができる。
【0100】
また、
図9及び
図10等に示される支出額につき、複数の形式で表示してもよい。例えば、実際に発生した支出額をそのまま表示する、いわゆる「キャッシュフローベース」で表示してもよい。また、実際に発生した支出額を支払期間に応じて按分(例:12分割)して表示する、いわゆる「P/Lベース」で表示してもよい。
【0101】
また、ユーザー1人あたりの費用(
図4参照)と、サービスへのアクセスが予め定められた期間以上なされていないユーザーIDの数と、に基づいて、これらのユーザーIDのアカウントを解約した場合に削減できる金額を表示してもよい。具体的には、「削減できる金額=ユーザー1人あたりの費用×サービスへのアクセスが予め定められた期間以上なされていないユーザーIDの数」となる。なお、サービスへのアクセスが予め定められた期間以上なされていないユーザーIDの数は、エンゲージメントスコア(
図16参照)を算出する際に合わせて算出することができる。
【0102】
また、支払情報として取得した様々なフォーマットのデータから、領収書に関する情報、請求書に関する情報、電子メールのタイトル、本文、またはユーザーが手動で入力した情報をまとめ、スプレッドシート形式で管理してもよい。
【0103】
[その他]
さらに、次に記載の各態様で提供されてもよい。
【0104】
(1)コンピュータにより実行される情報処理方法であって、取得ステップと、アクセスステップと、特定ステップと、表示制御ステップと、を備え、前記取得ステップでは、利用しているサービスである利用サービスに対する支払情報を取得し、前記支払情報は、支払金額と、前記支払金額に対応するテキスト情報と、を含み、前記アクセスステップでは、複数のサービス名を記憶するデータベースにアクセスし、前記特定ステップでは、前記アクセスしたデータベースに記憶される前記複数のサービス名の中から、前記テキスト情報に対応するサービス名を特定し、前記表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、をユーザー端末に表示させる、方法。
【0105】
(2)上記(1)に記載の方法において、受付ステップを備え、前記支払情報は、複数の利用サービスに関するものであり、前記支払情報は、複数の支払金額と、前記複数の支払金額にそれぞれ対応する複数のテキスト情報と、を含み、前記特定ステップでは、前記アクセスしたデータベースに記憶される前記複数のサービス名の中から、前記複数のテキスト情報のそれぞれに対応する複数のサービス名を特定し、前記受付ステップでは、前記ユーザー端末から、特定された前記複数のサービス名から1つのサービス名の選択を受け付け、前記表示制御ステップでは、受け付けた前記サービス名と、受け付けた前記サービス名に対応する前記利用サービスに対する支払金額と、を前記ユーザー端末に表示させる、方法。
【0106】
(3)上記(2)に記載の方法において、前記表示制御ステップでは、前記支払金額を時系列に沿って可視化したグラフを前記ユーザー端末に表示させる、方法。
【0107】
(4)上記(3)に記載の方法において、前記グラフは、以下の(1)~(3)の少なくとも1つの態様で表現される、(1)前記複数の利用サービスに対する支払金額の合計金額を時系列に沿って可視化する(2)前記複数の利用サービスを区別可能に可視化する(3)前記複数の利用サービスのうち、前記ユーザー端末により選択された利用サービスを可視化する方法。
【0108】
(5)上記(1)~(4)のいずれか1項に記載の方法において、前記表示制御ステップでは、前記利用サービスに対する統合処理を実行することを選択する選択画像を前記ユーザー端末に表示させ、前記統合処理は、前記利用サービスを提供するサービスシステムから、前記利用サービスに紐づくユーザーIDの数と、前記支払金額と、を取得できる状態にする処理である、方法。
【0109】
(6)上記(5)に記載の方法において、前記取得ステップでは、前記統合処理が実行された後、前記利用サービスに紐づくユーザーIDの数と、前記支払金額と、を取得し、前記表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、前記ユーザーIDの数と、を前記ユーザー端末に表示させる、方法。
【0110】
(7)上記(6)に記載の方法において、算出ステップを備え、前記取得ステップでは、前記統合処理が実行された後、前記利用サービスを利用しているアカウントに関するアカウント情報を取得し、前記アカウント情報は、前記ユーザーIDと、前記ユーザーIDのユーザーが属する組織に関する情報と、が紐づいた情報であり、前記算出ステップでは、前記取得した前記ユーザーIDの数と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、前記アカウント情報と、に基づいて、以下の(1)及び(2)の少なくとも一方を算出する、(1)ユーザー1人あたりの支払金額(2)特定のユーザー又は特定の組織による過去から現在までの支払金額の合計金額方法。
【0111】
(8)上記(6)又は(7)に記載の方法において、算出ステップを備え、前記算出ステップでは、前記利用サービスへのアクセス頻度と、前記ユーザーIDの数と、に基づくエンゲージメントスコアを算出し、前記エンゲージメントスコアは、第1時点に前記利用サービスにアクセスした場合、第2時点に前記利用サービスにアクセスしたときよりも大きくなるスコアであり、前記第2時点は、前記第1時点よりも過去の時点であり、表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、前記ユーザーIDの数と、前記エンゲージメントスコアと、を前記ユーザー端末に表示させる、方法。
【0112】
(9)上記(8)に記載の方法において、前記表示制御ステップでは、前記エンゲージメントスコアが閾値を下回る前記利用サービスを前記ユーザー端末に表示させ、前記閾値は、前記ユーザー端末を管理する管理者の現在の口座残高と、前記管理者の将来における口座残高の予測値と、の少なくとも一方に基づいて変化する、方法。
【0113】
(10)上記(5)~(9)のいずれか1項に記載の方法において、前記データベースは、複数の前記サービス名毎にユーザー1人あたりの料金を記憶しており、前記算出ステップでは、前記統合処理が実行されない場合、前記支払金額と、前記データベースに記憶される前記料金と、に基づいて、前記ユーザーIDの数を算出する、方法。
【0114】
(11)上記(5)~(10)のいずれか1項に記載の方法において、算出ステップを備え、前記算出ステップでは、所定期間における前記利用サービスへのアクセス履歴に基づいて、前記ユーザーIDの数を算出する、方法。
【0115】
(12)上記(1)~(11)のいずれか1項に記載の方法において、特定ステップを備え、前記特定ステップでは、前記テキスト情報の中に同じ提供者名が複数存在する場合、サブスクリプション契約で利用している利用サービスと、前記サブスクリプション契約で利用している利用サービスに対する支払金額と、を特定し、前記提供者名は、前記利用サービスを提供する者の名称であり、前記表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する利用サービスであって、前記サブスクリプション契約で利用している利用サービスに対する前記支払金額と、をユーザー端末に表示させる、方法。
【0116】
(13)上記(1)~(12)のいずれか1項に記載の方法において、特定ステップを備え、前記特定ステップでは、前記支払金額と、前記支払情報の取得頻度と、の少なくとも一方に基づいて、前記利用サービスに対する支払金額が月払いであるか年払いであるかを特定する、方法。
【0117】
(14)上記(1)~(13)のいずれか1項に記載の方法において、前記データベースは、前記複数のサービス名毎に、サービスの種類を示すカテゴリ情報を記憶し、表示制御ステップでは、前記ユーザー端末に、前記カテゴリ情報により特定されるカテゴリ別に、前記特定されたサービス名を表示させる、方法。
【0118】
(15)プログラムであって、少なくとも1つのコンピュータに、上記(1)~(14)に記載の情報処理方法の各ステップを実行させる、プログラム。
【0119】
(16)少なくとも1つの装置からなるシステムであって、上記(1)~(14)に記載の情報処理方法の各ステップがなされるようにプログラムを実行可能な、少なくとも1つのプロセッサを備える、システム。
もちろん、この限りではない。
【0120】
最後に、本発明に係る種々の実施形態を説明したが、これらは、例として提示したものであり、発明の範囲を限定することは意図していない。当該新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。当該実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。
【符号の説明】
【0121】
1 :情報処理システム
2 :ユーザー端末
3 :会計システム
4 :データベース
5 :サービスシステム
10 :制御部
11 :取得部
12 :アクセス部
13 :特定部
14 :表示制御部
15 :受付部
16 :算出部
20 :通信部
30 :記憶部
40 :入力部
50 :表示部
100 :システム
NW :ネットワーク
OI :出力アイコン
PDI :プルダウンアイコン
a :バブル
b :バブル
c :バブル
d :バブル
e :バブル
b1 :ボックス
b2 :ボックス
Ia :選択画像
Ib :選択画像
Ic :選択画像
Id :選択画像
Ie :選択画像
r1 :領域
r2 :領域
r3 :領域