JP2024006621A - 情報処理方法、プログラム及びシステム - Google Patents

Abstract

【課題】ユーザーが利用しているサービスに対する支払金額を容易に把握することが可能な技術を提供すること。【解決手段】本発明の一態様によれば、コンピュータにより実行される情報処理方法が提供される。この情報処理方法は、取得ステップと、アクセスステップと、特定ステップと、表示制御ステップと、を備える。取得ステップでは、利用しているサービスである利用サービスに対する支払情報を取得する。支払情報は、支払金額と、支払金額に対応するテキスト情報と、を含む。アクセスステップでは、複数のサービス名を記憶するデータベースにアクセスする。特定ステップでは、アクセスしたデータベースに記憶される複数のサービス名の中から、テキスト情報に対応するサービス名を特定する。表示制御ステップでは、特定されたサービス名と、特定されたサービス名に対応する利用サービスに対する支払金額と、をユーザー端末に表示させる。【選択図】図１

Description

本発明は、情報処理方法、プログラム及びシステムに関する。

近年、様々なサービスを業務で利用することが増えている。特許文献１には、利用者によるクラウドサービスの利用を管理するクラウドサービス利用管理装置が開示されている。

特開２０２１－７７２７１号公報

ところで、利用しているサービスの数が多くなると、これらのサービスに対して支払っている費用を把握することが手間になる。

本発明では上記事情を鑑み、ユーザーが利用しているサービスに対する支払金額を容易に把握することが可能な技術を提供することとした。

本発明の一態様によれば、コンピュータにより実行される情報処理方法が提供される。この情報処理方法は、取得ステップと、アクセスステップと、特定ステップと、表示制御ステップと、を備える。取得ステップでは、利用しているサービスである利用サービスに対する支払情報を取得する。支払情報は、支払金額と、支払金額に対応するテキスト情報と、を含む。アクセスステップでは、複数のサービス名を記憶するデータベースにアクセスする。特定ステップでは、アクセスしたデータベースに記憶される複数のサービス名の中から、テキスト情報に対応するサービス名を特定する。表示制御ステップでは、特定されたサービス名と、特定されたサービス名に対応する利用サービスに対する支払金額と、をユーザー端末に表示させる。

本開示によれば、電子契約に係る情報の管理を支援する技術を提供することができる。

本発明の一実施形態に係るシステム１００の構成を示す図である。 情報処理システム１のハードウェア構成を示すブロック図である。 情報処理システム１の機能を示す機能ブロック図である。 データベース４に記憶されるデータの一例である。 会計システム３から取得した支払情報の一例である。 支払情報の他の例であるカード明細の一例である。 支払情報の他の例であるメールの一例である。 情報処理システム１により実行される情報処理方法の一例を表すアクティビティ図である。 利用サービスに対する支払金額を可視化したグラフの一例である。 利用サービス毎の支払金額を示すグラフの一例である。 利用サービスのカテゴリを選択する様子を表す図である。 利用サービスのサービス名を選択する様子を表す図である。 受け付けたサービス名と、受け付けたサービス名に対応する利用サービスに対する支払金額と、を含む画面の例である。 統合処理を実行することを選択する選択画像Ｉａ～Ｉｅを含む画面例である。 統合処理が実行された後の画面例である。 エンゲージメントスコアの一例である。

以下、図面を用いて本発明の実施形態について説明する。以下に示す実施形態中で示した各種特徴事項は、互いに組み合わせ可能である。

本実施形態に登場するソフトウェアを実現するためのプログラムは、コンピュータが読み取り可能な非一時的な記録媒体（Ｎｏｎ－Ｔｒａｎｓｉｔｏｒｙ Ｃｏｍｐｕｔｅｒ－Ｒｅａｄａｂｌｅ Ｍｅｄｉｕｍ）として提供されてもよいし、外部のサーバからダウンロード可能に提供されてもよいし、外部のコンピュータで当該プログラムを起動させてクライアント端末でその機能を実現（いわゆるクラウドコンピューティング）するように提供されてもよい。

また、本実施形態において「部」とは、例えば、広義の回路によって実施されるハードウェア資源と、これらのハードウェア資源によって具体的に実現されうるソフトウェアの情報処理とを合わせたものも含みうる。また、本実施形態においては様々な情報を取り扱うが、これら情報は、例えば電圧・電流を表す信号値の物理的な値、０又は１で構成される２進数のビット集合体としての信号値の高低、又は量子的な重ね合わせ（いわゆる量子ビット）によって表され、広義の回路上で通信・演算が実行されうる。

また、広義の回路とは、回路（Ｃｉｒｃｕｉｔ）、回路類（Ｃｉｒｃｕｉｔｒｙ）、プロセッサ（Ｐｒｏｃｅｓｓｏｒ）、及びメモリ（Ｍｅｍｏｒｙ）等を少なくとも適当に組み合わせることによって実現される回路である。すなわち、特定用途向け集積回路（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ：ＡＳＩＣ）、プログラマブル論理デバイス（例えば、単純プログラマブル論理デバイス（Ｓｉｍｐｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ：ＳＰＬＤ）、複合プログラマブル論理デバイス（Ｃｏｍｐｌｅｘ Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ：ＣＰＬＤ）、及びフィールドプログラマブルゲートアレイ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ：ＦＰＧＡ））等を含むものである。

１．情報処理システム１を含むシステム１００の概要
図１に示すように、本発明の一実施形態に係るシステム１００は、情報処理システム１を備える。本実施形態では、システム１００はさらに、ユーザー端末２と、会計システム３と、データベース４と、サービスシステム５とを備える。そして、情報処理システム１、ユーザー端末２、会計システム３、データベース４、及びサービスシステム５がネットワークＮＷを介して互いに接続されている。

情報処理システム１は、例えばサーバにより構成される。ここで、情報処理システム１は、１又は複数の装置又は構成要素からなるものである。つまり、１つのサーバにより情報処理システム１が構成されてもよく、複数の処理を複数のサービスにより実現するシステムとして情報処理システム１が構成されてもよい。また、情報処理システム１を構成するサーバは、本特許出願がなされる国の国内に設置されてもよく、国外に設置されてもよい。

また、情報処理システム１により、ユーザー又はユーザーが属する組織が利用しているサービスを管理するための管理サービスが提供される。管理サービスは、ＳａａＳ（Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）の形態で提供されるものでもよい。

ユーザー端末２は、ユーザーが利用する端末であり、任意のコンピュータにより構成される。例えば、スマートフォン、タブレット端末、スマートウォッチ、ノートＰＣ、デスクトップＰＣ、多機能音楽プレーヤー等の多機能端末により構成される。また、ユーザー端末２は、表示部を備える。表示部は、テキストや画像（静止画及び動画を含む）を表示するものであり、任意のディスプレイにより構成される。ここで、本実施形態におけるユーザーは、少なくとも１つの有料サービスを利用している人物又は組織の一員であり、企業の従業員であってもよく、個人事業を営む者であってもよい。

また、ユーザー端末２を操作することで情報処理システム１が提供する管理サービスにアクセスし、ユーザー又はユーザーが属する組織が利用している利用サービスを管理することができる。

会計システム３は、経費申請サービス及び請求書管理サービスの少なくとも一方の機能を実現するシステムである。会計システム３は、ユーザー端末２を管理する管理主体が利用するものであり、管理主体の従業員等により日々の経費申請や請求書管理等の情報が管理される。会計システム３は、ＳａａＳの形態で提供されるものでもよい。

データベース４は、複数のサービス名を記憶する。データベース４は、情報処理システム１の提供者により構築されるものであり、手動又は自動で複数のサービス名を記憶させたものである。

サービスシステム５は、ユーザーが利用可能な種々のサービスを提供するためのシステムである。サービスシステム５は、例えば、サブスクリプション型のサービスを提供するサーバにより構成される。

２．情報処理システム１のハードウェア構成
図２に示すように、情報処理システム１は、制御部１０、通信部２０、記憶部３０、入力部４０及び表示部５０を備える。

<制御部１０>
制御部１０は、情報処理システム１に関連する全体動作の処理・制御を行う。制御部１０は、例えば、不図示の中央処理装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：ＣＰＵ）により構成される。制御部１０は、記憶部３０に記憶された所定のプログラムを読み出すことによって、情報処理システム１に係る種々の機能を実現する。すなわち、記憶部３０に記憶されているソフトウェアによる情報処理が、ハードウェア（制御部１０）によって具体的に実現されることで、制御部１０に含まれる各機能部（図３参照）として実行されうる。なお、制御部１０は、単一のモジュールにより構成されてもよく、機能ごとに複数のモジュールにより制御部１０を構成してもよい。

<通信部２０>
通信部２０は、他の情報処理装置又は構成要素と有線又は無線によりデータ通信可能に構成される。通信部２０は、例えば、ＵＳＢ、ＩＥＥＥ１３９４、Ｔｈｕｎｄｅｒｂｏｌｔ（登録商標）、有線ＬＡＮネットワーク通信等といった有線型の通信手段、及び無線ＬＡＮネットワーク通信、５Ｇ／ＬＴＥ／３Ｇ等のモバイル通信、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信等の組み合わせにより構成される。

<記憶部３０>
記憶部３０は、種々のプログラム及びデータを記憶するものであり、例えばメモリ、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等により構成される。また、記憶部３０は、プログラムや種々のデータ等を記憶する。そして、記憶部３０に記憶されているプログラムに基づいて制御部１０が種々の処理を実行することにより、種々の機能が実現する。

<入力部４０>
入力部４０は、情報処理システム１に種々の情報を入力するものであり、マウス、キーボード、ポインティングデバイス等により構成される。なお、他の情報処理装置に接続されたこれらのデバイスを用いて、ネットワークＮＷを介して入力部４０として機能させてもよい。

<表示部５０>
表示部５０は、テキスト、写真、画像（静止画及び動画を含む）を表示するものであり、任意のディスプレイにより構成される。表示部５０は、情報処理システム１がサーバである場合、情報処理システム１に直接又は間接的に接続されたディスプレイにより構成される。

３．情報処理システム１の機能構成
図３に示すように、情報処理システム１の制御部１０は、取得部１１と、アクセス部１２と、特定部１３と、表示制御部１４とを備える。制御部１０はさらに、受付部１５及び算出部１６を備えてもよい。

<取得部１１>
取得部１１は、利用しているサービスである利用サービスに対する支払情報を取得可能に構成される。本実施形態では、支払情報は、会計システム３から取得される。合わせて、またはこれに変えて、カード明細及びメールの少なくとも一方から支払情報を取得してもよい。また、支払情報は、ユーザー端末２から情報処理システム１にアップロードされたｃｓｖデータ又はユーザーが手動で入力した任意の形式のデータであってもよい。さらに、ユーザー端末２で利用している電子メールを転送してもらう、又は電子メールを管理するメールサーバへのアクセス権を付与してもらうことにより、ユーザーの電子メールに添付している任意のデータを支払情報として利用してもよい。
本実施形態における利用サービスは、サブスクリプション型のサービスであり、月単位または年単位で利用料が発生するものである。また、利用サービスは、ＳａａＳ型のサービスだけでなく、例えば、ウォーターサーバーで利用するための水の配送等、物である製品の定期又は不定期の配送サービスも含む。さらに、利用サービスは、スポーツジム等の施設の利用や、新聞配達等のサービスも含む。

支払情報は、支払金額と、支払金額に対応するテキスト情報と、を含む。支払金額は、利用サービスの利用料に相当するものである。また、テキスト情報は、テキスト形式で記述された情報であり、利用サービスのサービス名、利用サービスの提供者名、及びそれらの略語の少なくとも１つを含む情報である。

また、取得部１１は、利用サービスに紐づくユーザーＩＤの数を取得可能に構成されてもよい。ここで、利用サービスに紐づくユーザーＩＤの数は、例えば、ある企業で利用している利用サービスがあり、１，０００人の従業員にこの利用サービスを利用させている場合、ユーザーＩＤの数は１，０００となる。

<アクセス部１２>
アクセス部１２は、複数のサービス名を記憶するデータベース４にアクセス可能に構成される。

<特定部１３>
特定部１３は、アクセスしたデータベース４に記憶される複数のサービス名の中から、テキスト情報に対応するサービス名を特定可能に構成される。これは、支払情報に含まれるテキスト情報により特定されるサービス名が、データベース４に記憶される複数のサービス名のいずれかと一致するか否かを判定するマッチング処理に相当する。

<表示制御部１４>
表示制御部１４は、特定部１３により特定されたサービス名と、特定されたサービス名に対応する利用サービスに対する支払金額と、をユーザー端末２に表示可能に構成さる。ここで、本実施形態では、情報処理システム１が提供する管理サービスにアクセス中のユーザー端末２に、表示制御部１４が種々の情報を表示させる。

また、表示制御部１４は、支払金額を時系列に沿って可視化したグラフをユーザー端末２に表示させてもよい。ここで、表示制御部１４は、ユーザー端末２に表示させる表示画像を生成し、表示画像をユーザー端末２に送信することでユーザー端末２に画像を表示させてもよい。また、表示制御部１４は、表示命令をユーザー端末２に送信し、ユーザー端末２側で表示画像を生成させることでユーザー端末２に画像を表示させてもよい。また、これらの組み合わせでもよい。

<受付部１５>
受付部１５は、情報処理システム１又は他の端末から、種々の命令及び選択を受付可能に構成される。本実施形態では、受付部１５は、ユーザー端末２から、特定された複数のサービス名から１つのサービス名の選択を受け付ける。

<算出部１６>
算出部１６は、取得したユーザーＩＤの数と、特定されたサービス名に対応する利用サービスに対する支払金額と、アカウント情報と、に基づいて、以下の（１）及び（２）の少なくとも一方を算出可能に構成される。

（１）ユーザー１人あたりの支払金額
（２）特定のユーザー又は特定の組織による過去から現在までの支払金額の合計金額

また、算出部１６は、利用サービスへのアクセス頻度と、ユーザーＩＤの数と、に基づくエンゲージメントスコアを算出可能に構成されてもよい。ここで、エンゲージメントスコアは、第１時点に利用サービスにアクセスした場合、第２時点に利用サービスにアクセスしたときよりも大きくなるスコアである。第２時点は、第１時点よりも過去の時点である。別の言い方をすれば、情報処理システム１は、利用サービスに対するユーザーのアクセスログ、利用履歴、及び利用頻度を示すアクティビティデータを取得し、当該アクティビティデータに基づいて、エンゲージメントスコアを算出することが出来る。詳細については図１６を用いて後述する。

また、算出部１６は、種々の方法により、ユーザーＩＤの数を算出可能に構成されてもよい。かかる方法については後述する。

４．データベース４が記憶するデータ
図４は、データベース４に記憶されるデータの一例である。データベース４は、少なくとも複数のサービス名を記憶している。また、図４に示されるように、データベース４は、複数のサービス名毎に、サービス名を特定するサービスＩＤ、サービス名、サービス名の提供者、カテゴリ、ユーザー１人あたりの料金［円／月］、及びサービスに関する説明が掲載されているウェブサイトへのリンクを表すＵＲＬを対応付けて記憶してもよい。

ここで、図４におけるサービス名は、主にサブスクリプション型のＳａａＳ形式で提供されるものを示している。かかるサービスのカテゴリは、機能別に分類されたカテゴリであって、チャット、ＴＶ会議、案件管理、勤怠管理、財務・会計であってもよい。ここで、カテゴリは任意に分類することが可能であり、機能別、料金別、利用地域別、関連会社別、部署別、チーム別、ユーザー別により分類されたものでもよい。また、かかるカテゴリは、複数のサービスをインストール可能なアプリストアで表記されている記載を用いてもよく、データベース４の構築者が独自のカテゴリに分類してもよい。すなわち、データベース４は、複数のサービス名毎に、サービスの種類を示すカテゴリ情報を記憶してもよい。

５．支払情報について
図５～図７は、支払情報の一例を示す図である。図５は、情報処理システム１が会計システム３から取得した支払情報の一例である。

<支払情報を会計システム３から取得する場合>
図５は、会計システム３により管理される支払情報又は建替情報を示す。かかる支払情報は、情報処理システム１と会計システム３をＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）により接続することで、スプレッドシート形式で取得することができる。図５に示されるように、支払情報は、支払金額（金額の列に含まれる情報）と、支払金額に対応するテキスト情報（支払先・内容の列に含まれる情報）を含む。ここで、テキスト情報は、サービスの提供者名（Ａ社、Ｂ社、Ｃ社）と、サービス名（ｓｅｒｖｉｃｅ＿ａ，ｓｅｒｖｉｃｅ＿ｂ，ｓｅｒｖｉｃｅ＿ｃ）と、の少なくとも一方を特定できる情報である。図５の例では、テキスト情報として、サービスの提供者名とサービス名がセットになった情報がテキスト情報に相当する。ここで、テキスト情報は、サービスの提供者名のみ、またはサービス名のみ、であってもよい。

図５の例では、明細番号毎に、サービスを利用した（又は費用が発生する起点となる）「日付」と、テキスト情報の一例である「支払先・内容」と、利用サービスに対する支払金額である「金額」と、経費計上する際の経費科目」と、現在の「税区分」と、が対応付いて管理されている。ここで、支払情報の内容は、支払情報を生成する者が任意に定めることができる。

<支払情報としてカード明細を利用する場合>
図６は、支払情報として利用可能なカード明細の一例である。図６の例では、カードの利用毎に、カード決済を実行した日である「ご利用日」と、カード決済を行った店舗である「ご利用店舗名」と、カードの利用金額である「ご利用金額」と、が対応付いて管理されている。

図６の例では、「ご利用店舗名」の列に含まれる情報の一部又は全部がテキスト情報に相当する。図６の例では、サービスの提供者名（Ｄ社）と、サービス名（ｓｅｒｖｉｃｅ＿ｅ）と、がテキスト情報に相当する。

ここで、カード明細は、ユーザー端末２のユーザーにより情報処理システム１にアップロードされてもよく、情報処理システム１がユーザーアカウントを預かり、ユーザーが利用するカード会社のシステムとＡＰＩ接続することで、カード会社のシステムから情報処理システム１がカード明細を取得してもよい。

<支払情報としてメールを利用する場合>
図７は、支払情報として利用可能なメールの一例である。図７の例では、Ｘ社が提供するＸマーケットから水を購入したときに送信されるメールを表す。本メールには、注文内容として、注文番号、注文日、商品名、商品の金額（小計）、配送料・手数料、注文合計、及び支払方法が含まれる。このとき、商品名である「Ｘの水（定期配送）」がテキスト情報に相当する。つまり、かかる商品名が、ユーザーが利用する利用サービスのサービス名を特定できる情報である。

６．情報処理システム１により実行される情報処理方法
次に、図８～図１６を用いて、情報処理システム１により実行される情報処理方法について説明する。本実施形態における情報処理方法は、コンピュータの一例である情報処理システム１により実行される。情報処理方法は、取得ステップと、アクセスステップと、特定ステップと、表示制御ステップと、を備える。以下、具体的に説明する。

まず、Ａ１において、取得ステップが実行される。本実施形態では、取得部１１により取得ステップが実行され、会計システム３から利用サービスに対する支払情報を取得する。支払情報は、支払金額と、支払金額に対応するテキスト情報と、を含む。なお、会計システム３から支払情報を取得することと合わせ、またはこれに変えて、カード明細及びメールの少なくとも一方から支払情報を取得してもよい。また、支払情報は、ユーザー端末２から情報処理システム１にアップロードされたｃｓｖデータ又はユーザーが手動で入力した任意の形式のデータであってもよい。さらに、ユーザー端末２で利用している電子メールを転送してもらう、又は電子メールを管理するメールサーバへのアクセス権を付与してもらうことにより、ユーザーの電子メールに添付している任意のデータを支払情報として利用してもよい。

次に、Ａ２において、アクセスステップが実行される。本実施形態では、アクセス部１２によりアクセスステップが実行され、複数のサービス名を記憶するデータベース４にアクセスする。

次に、Ａ３において、特定ステップが実行される。本実施形態では、特定部１３により特定ステップが実行され、アクセスしたデータベース４に記憶される複数のサービス名の中から、テキスト情報に対応するサービス名を特定する。例えば、支払情報に含まれるテキスト情報が、図５に示される「Ａ社（ｓｅｒｖｉｃｅ＿ａ）」である場合には、データベース４に記憶されるデータ（図４参照）の中に、「Ａ社（ｓｅｒｖｉｃｅ＿ａ）」に対応するサービス名が存在するか否かを調べる。そして、データベース４に記憶されるデータの中に「Ａ社（ｓｅｒｖｉｃｅ＿ａ）」に対応するサービス名である「ｓｅｒｖｉｃｅ＿ａ」が存在する場合、サービスＩＤが「１」で特定される「ｓｅｒｖｉｃｅ＿ａ」を、テキスト情報である「Ａ社（ｓｅｒｖｉｃｅ＿ａ）」に対応するサービス名として特定する。

ここで、かかる特定は、支払情報に含まれる、サービス名又はサービスの提供者に紐づいたテキスト情報を利用すればどのような手法を用いてもよい。例えば、テキスト情報に、利用サービスのサービス名、利用サービスの提供者名、及びそれらの略語の少なくとも１つが含まれる場合、それらの情報とデータベース４に記憶されるサービス名との対応付を規定したテーブルを作成し、かかるテーブルによりテキスト情報とサービス名との対応関係を特定してもよい。また、自然言語処理を用いることにより、テキスト情報に含まれる文字列と、データベース４に記憶されるサービス名に含まれる文字列と、が予め定められた割合以上一致する場合には、両者が対応しているものとして特定してもよい。

次にＡ４において、表示制御ステップが実行される。本実施形態では、表示制御部１４により表示制御ステップが実行され、特定ステップにおいて特定されたサービス名と、特定されたサービス名に対応する利用サービスに対する支払金額と、をユーザー端末２に表示させる。

図９は、ユーザー端末２に表示される画面の一例である。図９の例では、利用サービスの一例として、ユーザー又はユーザーが属する組織が利用しているＳａａＳのサービスに対する支出額を縦軸に、月単位を横軸にとり、月ごとの支出額（支払金額）を可視化したグラフである。

図１０は、ユーザー端末２に表示される画面の他の一例である。図１０の例では、利用サービスの一例であり、特定ステップにおいて特定されたサービス名である「ｓｅｒｖｉｃｅ＿ａ」、「ｓｅｒｖｉｃｅ＿ｂ」、及び「ｓｅｒｖｉｃｅ＿ｃ」と、これらのサービスに対する支出額（支払金額）と、が含まれる。

このとき、「ｓｅｒｖｉｃｅ＿ａ」、「ｓｅｒｖｉｃｅ＿ｂ」、及び「ｓｅｒｖｉｃｅ＿ｃ」をまとめて表示させてもよく、１つずつのサービスを表示させてもよい。ここで、図１０に示されるように、複数のサービスをまとめて表示させるためには、複数のサービスに関する支払情報を取得する必要がある。このとき、取得部１１により取得される支払情報は、複数の利用サービスに関するものである。そして、支払情報は、複数の支払金額と、複数の支払金額にそれぞれ対応する複数のテキスト情報と、を含む。図５の例では、１つの支払情報の中に複数の支払金額が含まれる。このうち、明細番号が「２，４，５」で特定されるものが、利用サービスに関する情報である。このとき、「ｓｅｒｖｉｃｅ＿ａ」、「ｓｅｒｖｉｃｅ＿ｂ」、及び「ｓｅｒｖｉｃｅ＿ｃ」に対する金額が「複数の支払金額」に相当し、「Ａ社（ｓｅｒｖｉｃｅ＿ａ）」、「Ｂ社（ｓｅｒｖｉｃｅ＿ｂ）」、及び「Ｃ社（ｓｅｒｖｉｃｅ＿ｃ）」が「複数の支払金額にそれぞれ対応する複数のテキスト情報」に相当する。

支払情報に、複数の支払金額と、複数の支払金額にそれぞれ対応する複数のテキスト情報と、が含まれる場合には、特定ステップでは、アクセスしたデータベース４に記憶される複数のサービス名の中から、複数のテキスト情報のそれぞれに対応する複数のサービス名を特定する。

このように、図１０に示されるように、表示制御ステップでは、支払金額を時系列に沿って可視化したグラフをユーザー端末２に表示させてもよい。これにより、いずれのサービスにどの程度の金額を支払っているかを直感的に把握することが可能になる。例えば、「ｓｅｒｖｉｃｅ＿ａ」は、２０２２年６月～２０２１年１２月までは支出額が約３５万円で一定であったところ、２０２２年２月には支出額が約２７０万円と大幅増となっている。これは、２０２２年２月に「ｓｅｒｖｉｃｅ＿ａ」を利用する社内ユーザーが増加したか、上位プランに切り替えたためであると推察される。

また、ボックスｂ１は、ユーザー端末２に表示させる利用サービスのカテゴリを選択するためのボックスである。ユーザーは、ユーザー端末２を操作してボックスｂ１の右部にあるプルダウンアイコンＰＤＩを押下することで、ボックスｂ１の下部に図１１に示される領域ｒ１が展開される。領域ｒ１は、利用サービスのカテゴリを示すカテゴリ情報が表示される領域である。ユーザーは、ユーザー端末２を操作することで利用サービスのカテゴリを選択することができる。例えば、図１１の状態でカテゴリ「チャット」を選択すると、ユーザー端末２の画面には、カテゴリが「チャット」に属する利用サービスと、その利用サービスに対する支出額（支払金額）と、が表示される。

このとき、表示制御ステップでは、ユーザー端末２に、カテゴリ情報により特定されるカテゴリ別に、特定されたサービス名を表示させる。

さらに、ボックスｂ２は、ユーザー端末２に表示させる利用サービスを選択するためのボックスである。ユーザーは、ユーザー端末２を操作してボックスｂ２の右部にあるプルダウンアイコンＰＤＩを押下することで、ボックスｂ２の下部に図１２に示される領域ｒ２が展開される。領域ｒ２は、利用サービスを示す選択肢が表示される領域である。ユーザーは、ユーザー端末２を操作することで利用サービスを選択することができる。

そして、領域ｒ２に表示される選択肢のうち、特定の選択肢が選択されると、Ａ５において、受付ステップが実行される。本実施形態では、受付部１５により受付ステップが実行され、ユーザー端末２から、特定された複数のサービス名から１つのサービス名の選択を受け付ける。

そして、Ａ６において、表示制御ステップが実行される。本実施形態では、表示制御部１４により表示制御ステップが実行され、受け付けたサービス名と、受け付けたサービス名に対応する利用サービスに対する支払金額と、をユーザー端末２に表示させる。

例えば、図１２の状態でサービス名である「ｓｅｒｖｉｃｅ＿ａ」が選択されると、図１３に示すように、ユーザー端末２の画面には、「ｓｅｒｖｉｃｅ＿ａ」と、「ｓｅｒｖｉｃｅ＿ａ」に対する支出額（支払金額）と、が表示される。なお、情報処理システム１は、１つの利用サービスのみの選択を受け付けてもよく、複数の利用サービスの選択をまとめて受け付けてもよい。

このように、表示制御ステップにおいてユーザー端末２に表示させるグラフは、以下の（１）～（３）の少なくとも１つの態様で表現されてもよい。

（１）複数の利用サービスに対する支払金額の合計金額を時系列に沿って可視化する：図９に対応
（２）複数の利用サービスを区別可能に可視化する：図１０に対応
（３）複数の利用サービスのうち、ユーザー端末により選択された利用サービスを可視化する：図１３に対応

なお、情報処理システム１が実現する機能としては、上記の（１）～（３）の全てを実現することができるものであってもよく、（１）～（３）のどの態様を表示するかをユーザーによって選択可能であってもよい。

<統合処理>
次に、統合処理について説明する。Ａ７において、表示制御ステップが実行される。本実施形態では、表示制御部１４により表示制御ステップが実行される。

表示制御ステップでは、利用サービスに対する統合処理を実行することを選択する選択画像をユーザー端末に表示させる。ここで、統合処理は、利用サービスを提供するサービスシステム５から、利用サービスに紐づくユーザーＩＤの数と、支払金額と、を取得できる状態にする処理である。例えば、情報処理システム１とサービスシステム５をＡＰＩで接続することにより、情報処理システム１がサービスシステム５からユーザーＩＤの数と支払金額を取得できるようになる。

図１４は、ユーザー端末２に表示される、選択画像Ｉａ～Ｉｅを含む画面の一例である。図１４の例では、統合処理の対象となり得るサービスを「インテグレーション候補」として表示している。そして、統合処理が既に実行されたサービスを「全てのインテグレーション」として表示している。

また、ユーザー端末２を操作して利用サービスのサービス名をボックスｂ３に入力することで、特定のサービスを検索することができる。また、出力アイコンＯＩを押下することにより、インテグレーション候補の一例である検出したＳａａＳに関する情報をまとめてｃｓｖ形式等で出力できる構成としてもよい。

そして、選択画像Ｉａ～Ｉｅのいずれか又は全てが選択された場合、Ａ８において、制御部１０が統合処理を実行する。これにより、本実施形態では、情報処理システム１と、利用サービスを提供するサービスシステム５とがＡＰＩで接続され、利用サービスに紐づくユーザーＩＤの数と、支払金額と、をサービスシステム５から取得することが可能になる。

そして、例えば、図１４において選択画像Ｉａ～Ｉｃが選択された場合には、「ｓｅｒｖｉｃｅ＿ａ」～「ｓｅｖｉｃｅ＿ｃ」に対して統合処理が実行される。その後、図１５に示されるように、統合処理が完了した利用サービス（「ｓｅｒｖｉｃｅ＿ａ」～「ｓｅｖｉｃｅ＿ｃ」）が「全てのインテグレーション」の中に表示され、「インテグレーション候補」からは消えた状態となる。

そして、Ａ９ａにおいて、取得ステップが実行される。本実施形態では、統合処理が実行された後、取得部１１により取得ステップが実行され、利用サービスに紐づくユーザーＩＤの数と、支払金額と、を取得する。

また、本実施形態では、統合処理が実行された後、取得部１１により取得ステップが実行され、利用サービスを利用しているアカウントに関するアカウント情報を取得してもよい。ここで、アカウント情報は、ユーザーＩＤと、ユーザーＩＤのユーザーが属する組織に関する情報と、が紐づいた情報である。また、アカウント情報は、特定のユーザーの利用プラン及び利用プランの料金を含んでも良い。

次に、Ａ１０ａにおいて、算出ステップが実行される。本実施形態では、算出部１６により算出ステップが実行される。ここで、図８では、説明の都合上、算出ステップにおいて実行される処理を算出処理と表記している。

算出ステップでは、取得したユーザーＩＤの数と、特定されたサービス名に対応する利用サービスに対する支払金額と、アカウント情報と、に基づいて、以下の（１）及び（２）の少なくとも一方を算出してもよい。

（１）ユーザー１人あたりの支払金額
（２）特定のユーザー又は特定の組織による過去から現在までの支払金額の合計金額

なお、情報処理システム１が実現する機能としては、上記の（１）及び（２）の両方を算出することができるものであってもよい。

（１）は、「利用サービスに対する支払情報に含まれる支払金額／ユーザーＩＤの数」により算出することができる。
（２）は、特定のユーザーに着目し、過去から現在までの期間における支払金額を足し合わせることで合計金額を算出することができる。特に、アカウント情報に、特定ユーザーの利用プラン及びその料金が含まれる場合、過去から現在までの期間のどこかで利用プランが変更された場合でも、特定のユーザーの過去から現在までの支払金額の合計金額を正確に算出することができる。さらに、特定のユーザーが属する組織に関する情報を利用することで、特定の組織における過去から現在までの支払金額の合計金額を算出することができる。

また、算出ステップでは、利用サービスへのアクセス頻度と、ユーザーＩＤの数と、に基づくエンゲージメントスコアを算出してもよい。ここで、エンゲージメントスコアは、第１時点に利用サービスにアクセスした場合、第２時点に利用サービスにアクセスしたときよりも大きくなるスコアである。なお、
第２時点は、第１時点よりも過去の時点である。つまり、本実施形態におけるエンゲージメントスコアは、利用サービスへのアクセスがなされていない期間が長いほど利用頻度が低いとみなし、利用サービスに対するエンゲージメントが低いものとして扱うためのスコアである。

エンゲージメントスコアは、例えば、以下のようなエンゲージメント係数を用いて定めることができる。

（エンゲージメント係数の例）
・３日以内にアクセスがある場合：エンゲージメント係数＝１０ｐｔ
・１０日以内にアクセスがある場合：エンゲージメント係数＝５ｐｔ
・３０日以内にアクセスがある場合：エンゲージメント係数＝２ｐｔ
・３１日以上アクセスがなされていない場合：エンゲージメント係数＝０ｐｔ

そして、「エンゲージメントスコア＝エンゲージメント係数×ユーザーＩＤの数」としてエンゲージメントスコアを算出してもよい。例えば、ある利用サービスに対して３日以内にアクセスしたユーザーが１０名いた場合には、その利用サービスに対するエンゲージメントスコアは「１００ｐｔ（＝１０ｐｔ×１０人）」となる。

<統合処理が実行されない場合>
一方、Ａ７において、選択画像Ｉａ～Ｉｅのいずれも選択されなかった場合、Ａ９ｂに処理を進める。そして、Ａ９ｂにおいて、取得部１１により取得ステップが実行され、支払情報を取得する。ここで、Ａ１においてすでに支払情報を取得している場合には、Ａ９ｂの処理をスキップすることができる。

そして、Ａ１０ｂにおいて、統合処理が実行されなかった場合における算出ステップが実行される。本実施形態では、統合処理が実行されない場合、算出部１６により算出ステップが実行され、支払金額と、データベース４に記憶される料金と、に基づいて、ユーザーＩＤの数を算出してもよい。本実施形態では、取得部１１が取得した支払金額、すなわち、組織全体としての支払金額の合計金額を、図４に示される「１人あたりの料金［円／月］（データベース４に記憶される料金の一例）で除することにより、ユーザーＩＤの数を算出することができる。

また、データベース４に料金が記憶されていない場合には、算出ステップでは、所定期間における利用サービスへのアクセス履歴に基づいて、ユーザーＩＤの数を算出してもよい。例えば、利用サービスとしてブラウザからアクセスするＳａａＳサービスを利用している場合には、ブラウザからのアクセス履歴を解析し、所定期間（例：３ヶ月）にＳａａＳサービスにアクセスした人数をユーザーＩＤの数として算出してもよい。

あわせて、統合処理が実行されていない利用サービスに対しても、エンゲージメントスコアを算出してもよい。

このように、Ａ１０ａ及びＡ１０ｂの少なくとも一方によりユーザーＩＤの数が算出された場合、図１４に示されるように、「インテグレーション候補」及び「全てのインテグレーション」に含まれる画像の一部に、各サービスに紐づくユーザーＩＤの数を表示させてもよい。図１４の例では、統合処理が完了したサービスである「ｓｅｒｖｉｃｅ＿ｏ」～「ｓｅｒｖｉｃｅ＿ｚ」のそれぞれに対応する画像には、各サービスに紐づくユーザーＩＤの数が表示されている（例：ｓｅｒｖｉｃｅ＿ｏでは２，４００人）。また、統合処理が実行されていない場合でも、すでにＡ１０ｂによりユーザーＩＤの数が算出されたサービスには、ユーザーＩＤの数が表示されてもよい。図１４の例では、「ｓｅｒｖｉｃｅ＿ａ」及び「ｓｅｒｖｉｃｅ＿ｃ」については、統合処理が実行されていないものの、Ａ１０ｂによりユーザーＩＤの数が算出されたことで、ユーザーＩＤの数が表示されている。一方、「ｓｅｒｖｉｃｅ＿ｂ」については、統合処理も実行されておらず、Ａ１０ｂにおける算出処理も実行されていないため、ユーザーＩＤの数が表示されていない。一方、「ｓｅｒｖｉｃｅ＿ｂ」に対して統合処理が実行された場合、図１５に示すように、「ｓｅｒｖｉｃｅ＿ｂ」と合わせて「ｓｅｒｖｉｃｅ＿ｂ」のユーザーＩＤの数が表示されている。

そして、Ａ１１において、表示制御ステップが実行される。本実施形態では、表示制御部１４により表示制御ステップが実行される。表示制御ステップでは、特定ステップ（Ａ３）において特定されたサービス名と、特定されたサービス名に対応する利用サービスに対する支払金額と、算出ステップ（Ａ１０ａ及びＡ１０ｂの少なくとも一方）により算出されたユーザーＩＤの数と、エンゲージメントスコアと、をユーザー端末２に表示させてもよい。

図１６は、ユーザー端末２に表示される画面であって、エンゲージメントスコアを可視化した画面の一例である。図１６の例では、利用サービスへの支出額（支払金額）を縦軸に、月単位を横軸にとり、エンゲージメントスコアをバブルのサイズで表現している。ここで、バブルａ～ｅはそれぞれ、「ｓｅｒｖｉｃｅ＿ａ」～「ｓｅｒｖｉｃｅ＿ｅ」に対するエンゲージメントスコアを表す。バブルのサイズが大きいものほど、エンゲージメントスコアが大きい。図１６の例では、エンゲージメントスコアが大きい順に、バブルｄ>バブルａ>バブルｂ>バブルｅ>バブルｃとなっている。ここで、バブルのサイズに変えて、バブル又は他のアイコンの明度、彩度、輝度や、区別可能な色により、エンゲージメントスコアの大小を表現してもよい。

また、ユーザー端末２により操作されるカーソル（不図示）がオーバーレイされたバブルに対応する情報を表示させてもよい。図１６の例では、バブルｂにカーソルがオーバーレイされた場合に、バブルｂの近傍に領域ｒ３が展開されている。そして、領域ｒ３には、バブルｂに対応するサービスである「ｓｅｒｖｉｃｅ＿ｂ」、ユーザーＩＤの数（１２００ ＩＤ）、月毎の支出額（￥７５万）、エンゲージメントスコア（４０）が表示される。

このように、エンゲージメントスコアを可視化することにより、複数の利用サービスのうち、利用を継続するか否か（つまり、利用サービスを解約するか否か）の判断を容易に行うことができる。例えば、各サービスについて、以下の示唆を得ることができる。なお、以下の示唆はあくまで一例であり、エンゲージメントスコアからどのような情報を読み取るかは人により異なる。

・ｓｅｒｖｉｃｅ＿ａ：ユーザーＩＤの数及び支出額が多く、エンゲージメントスコアが比較的高い。つまり、ある程度のユーザーが実際に高頻度でｓｅｒｖｉｃｅ＿ａを利用しており、利用を継続すべきである。
・ｓｅｒｖｉｃｅ＿ｂ：ユーザーＩＤの数が比較的多いが支出額が少ない。エンゲージメントスコアもまずまず高い。このため、ｓｅｒｖｉｃｅ＿ｂの利用を停止するほどでもない。
・ｓｅｒｖｉｃｅ＿ｃ：ユーザーＩＤの数及び支出額が低く、エンゲージメントスコアも低い。そのため、ｓｅｒｖｉｃｅ＿ｃは早めに解約すべきである。
・ｓｅｒｖｉｃｅ＿ｄ：ユーザーＩＤの数は少ないが支出額が大きい。これは、１ユーザー当たりの料金が高額なサービスであるといえる。同時に、エンゲージメントスコアも大きい。つまり、ｓｅｒｖｉｃｅ＿ｄは、利用するユーザーの数は少ないものの、利用者は高頻度で利用しているものであり、解約することはおすすめできない。
・ｓｅｒｖｉｃｅ＿ｅ：ユーザーＩＤの数及び支出額が多いものの、エンゲージメントスコアが低い。このため、コスト削減の観点から、ｓｅｒｖｉｃｅ＿ｅのユーザーＩＤの一部又は全部を解約すべきである。

また、図１６に示される画面にも、図１０に示されるものと同様のボックスｂ１及びボックスｂ２が含まれてもよい。

また、表示制御ステップでは、エンゲージメントスコアが閾値を下回る利用サービスをユーザー端末２に表示させてもよい。このとき、当該利用サービスの解約（もしくは、解約の検討）をレコメンドするメッセージをユーザー端末２に表示させてもよい。また、閾値は、ユーザー端末２を管理する管理者の現在の口座残高と、管理者の将来における口座残高の予測値と、の少なくとも一方に基づいて変化してもよい。ここで、ユーザー端末２を管理する管理者は、ユーザー端末２のユーザーであってもよく、ユーザーが属する組織（特に企業）の責任者であってもよい。管理者が企業の責任者の場合には、事業口座で管理される口座残高が多いほど、閾値を大きくしてもよい。これは、口座残高が多いほど多くの支払に耐えられる一方、口座残高が少なくなると、できるだけ支出を節約することが好ましいためである。これにより、コストパフォーマンスの低い利用サービスを容易に把握することができ、必要に応じてかかる利用サービスを解約することで、コストを削減することができる。

以上説明したように、本実施形態に係る情報処理システム１により、取得ステップと、アクセスステップと、特定ステップと、表示制御ステップと、を備える情報処理方法が提供される。これにより、ユーザーが利用しているサービスに対する支払金額を容易に把握することが可能になる。

７．他の実施形態
<サブスクリプション契約で利用している利用サービスを表示>
図８のＡ３において特定部１３により実行される特定ステップでは、テキスト情報の中に同じ提供者名が複数存在する場合、サブスクリプション契約で利用している利用サービスと、サブスクリプション契約で利用している利用サービスに対する支払金額と、を特定してもよい。ここで、提供者名は、利用サービスを提供する者の名称である。かかる特定は、例えば、図５に示されるように、明細番号が「２，３」で特定されるものには、同じ提供者名である「Ａ社」が含まれる。このとき、Ａ社により提供される「ｓｅｒｖｉｃｅ＿ａ」については、支払情報に含まれる「日付」が１３日となるサブスクリプション契約である場合には、１３日の支払に対応する利用サービスを、サブスクリプション契約でしている利用サービスとして特定することができる。このように、毎月の請求日が固定されている場合には、情報処理システム１の記憶部３０又はデータベース４に予め請求日を記憶させておき、この請求日を参照することにより、サブスクリプション契約で利用している利用サービスであるか、明細番号が「３」で特定されるもののようなスポット的な支払であるかを特定することができる。

そして、Ａ４において表示制御部１４により実行される表示制御ステップでは、特定ステップにおいて特定されたサービス名と、特定されたサービス名に対応する利用サービスであって、サブスクリプション契約で利用している利用サービスに対する支払金額と、をユーザー端末２に表示させてもよい。

これにより、サブスクリプション契約で利用しているサービスをまとめてユーザー端末２に表示させることができ、毎月又は毎年発生しうる利用料を可視化することができるので、将来の支払金額の予測をしやすくなる。

<月払い又は年払いの表示>
図８のＡ３において特定部１３により実行される特定ステップでは、支払金額と、支払情報の取得頻度と、の少なくとも一方に基づいて、利用サービスに対する支払金額が月払いであるか年払いであるかを特定してもよい。これは、支払金額の大きさ又は支払頻度により、支払金額が月払いであるか年払いであるかを特定することができる。具体的には、支払金額が、利用サービスの月毎の「ユーザー１人当たりの利用料」と「ユーザーＩＤの数」をかけ合わせた金額より多い場合、利用サービスに対する支払金額が年払いであると特定することができる。また、支払が数ヶ月連続で発生している場合には、用サービスに対する支払金額が年払いであると特定することができる。また、ユーザーがユーザー端末２を操作し、利用サービス毎に月払いであるか年払いであるかを情報処理システム１に入力してもよい。

これにより、月払いであるか年払いであるかを区別しない場合と比べ、将来の支払金額の予測精度をさらに向上させることが可能になる。

<他の例>
図１６に示されるエンゲージメントスコアを含む画面のうち、ＲＯＩ（Ｒｅｔｕｒｎ Ｏｎ Ｉｎｖｅｓｔｍｅｎｔ）への寄与度が予め定められた値以下である利用サービスを提示してもよい。これにより、費用対効果が相対的に低い利用サービスを特定することが容易になる。このとき、費用対効果が相対的に低いものとして特定された利用サービスの解約（もしくは、解約の検討）をレコメンドするメッセージをユーザー端末２に表示させてもよい。

また、ユーザー又はユーザーが属する組織で利用している複数の利用サービスのうち、同一のカテゴリに属する利用サービスが複数存在する場合、それらの利用サービスを提示してもよい。また、同一のカテゴリに属する複数のサービスのうち、エンゲージメントスコアが低いものから順に表示させてもよい。例えば、同一のカテゴリに属する利用サービスが複数存在する場合に、それらのサービスのうち、利用頻度が少ないサービス及び／又は一定期間全く利用されていないサービスの解約（もしくは、解約の検討）をレコメンドするメッセージをユーザー端末２に表示させてもよい。利用頻度が少ないサービス及び／又は一定期間全く利用されていないサービスは、エンゲージメントスコアが閾値を下回るサービスである。

これにより、例えば、カテゴリが「チャット」である複数の利用サービスのうち、利用頻度が少ないサービスや、一定期間全く利用されていないサービスを解約し、支出を削減することができる。

また、図９及び図１０等に示される支出額につき、複数の形式で表示してもよい。例えば、実際に発生した支出額をそのまま表示する、いわゆる「キャッシュフローベース」で表示してもよい。また、実際に発生した支出額を支払期間に応じて按分（例：１２分割）して表示する、いわゆる「Ｐ／Ｌベース」で表示してもよい。

また、ユーザー１人あたりの費用（図４参照）と、サービスへのアクセスが予め定められた期間以上なされていないユーザーＩＤの数と、に基づいて、これらのユーザーＩＤのアカウントを解約した場合に削減できる金額を表示してもよい。具体的には、「削減できる金額＝ユーザー１人あたりの費用×サービスへのアクセスが予め定められた期間以上なされていないユーザーＩＤの数」となる。なお、サービスへのアクセスが予め定められた期間以上なされていないユーザーＩＤの数は、エンゲージメントスコア（図１６参照）を算出する際に合わせて算出することができる。

また、支払情報として取得した様々なフォーマットのデータから、領収書に関する情報、請求書に関する情報、電子メールのタイトル、本文、またはユーザーが手動で入力した情報をまとめ、スプレッドシート形式で管理してもよい。

［その他］
さらに、次に記載の各態様で提供されてもよい。

（１）コンピュータにより実行される情報処理方法であって、取得ステップと、アクセスステップと、特定ステップと、表示制御ステップと、を備え、前記取得ステップでは、利用しているサービスである利用サービスに対する支払情報を取得し、前記支払情報は、支払金額と、前記支払金額に対応するテキスト情報と、を含み、前記アクセスステップでは、複数のサービス名を記憶するデータベースにアクセスし、前記特定ステップでは、前記アクセスしたデータベースに記憶される前記複数のサービス名の中から、前記テキスト情報に対応するサービス名を特定し、前記表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、をユーザー端末に表示させる、方法。

（２）上記（１）に記載の方法において、受付ステップを備え、前記支払情報は、複数の利用サービスに関するものであり、前記支払情報は、複数の支払金額と、前記複数の支払金額にそれぞれ対応する複数のテキスト情報と、を含み、前記特定ステップでは、前記アクセスしたデータベースに記憶される前記複数のサービス名の中から、前記複数のテキスト情報のそれぞれに対応する複数のサービス名を特定し、前記受付ステップでは、前記ユーザー端末から、特定された前記複数のサービス名から１つのサービス名の選択を受け付け、前記表示制御ステップでは、受け付けた前記サービス名と、受け付けた前記サービス名に対応する前記利用サービスに対する支払金額と、を前記ユーザー端末に表示させる、方法。

（３）上記（２）に記載の方法において、前記表示制御ステップでは、前記支払金額を時系列に沿って可視化したグラフを前記ユーザー端末に表示させる、方法。

（４）上記（３）に記載の方法において、前記グラフは、以下の（１）～（３）の少なくとも１つの態様で表現される、（１）前記複数の利用サービスに対する支払金額の合計金額を時系列に沿って可視化する（２）前記複数の利用サービスを区別可能に可視化する（３）前記複数の利用サービスのうち、前記ユーザー端末により選択された利用サービスを可視化する方法。

（５）上記（１）～（４）のいずれか１項に記載の方法において、前記表示制御ステップでは、前記利用サービスに対する統合処理を実行することを選択する選択画像を前記ユーザー端末に表示させ、前記統合処理は、前記利用サービスを提供するサービスシステムから、前記利用サービスに紐づくユーザーＩＤの数と、前記支払金額と、を取得できる状態にする処理である、方法。

（６）上記（５）に記載の方法において、前記取得ステップでは、前記統合処理が実行された後、前記利用サービスに紐づくユーザーＩＤの数と、前記支払金額と、を取得し、前記表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、前記ユーザーＩＤの数と、を前記ユーザー端末に表示させる、方法。

（７）上記（６）に記載の方法において、算出ステップを備え、前記取得ステップでは、前記統合処理が実行された後、前記利用サービスを利用しているアカウントに関するアカウント情報を取得し、前記アカウント情報は、前記ユーザーＩＤと、前記ユーザーＩＤのユーザーが属する組織に関する情報と、が紐づいた情報であり、前記算出ステップでは、前記取得した前記ユーザーＩＤの数と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、前記アカウント情報と、に基づいて、以下の（１）及び（２）の少なくとも一方を算出する、（１）ユーザー１人あたりの支払金額（２）特定のユーザー又は特定の組織による過去から現在までの支払金額の合計金額方法。

（８）上記（６）又は（７）に記載の方法において、算出ステップを備え、前記算出ステップでは、前記利用サービスへのアクセス頻度と、前記ユーザーＩＤの数と、に基づくエンゲージメントスコアを算出し、前記エンゲージメントスコアは、第１時点に前記利用サービスにアクセスした場合、第２時点に前記利用サービスにアクセスしたときよりも大きくなるスコアであり、前記第２時点は、前記第１時点よりも過去の時点であり、表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、前記ユーザーＩＤの数と、前記エンゲージメントスコアと、を前記ユーザー端末に表示させる、方法。

（９）上記（８）に記載の方法において、前記表示制御ステップでは、前記エンゲージメントスコアが閾値を下回る前記利用サービスを前記ユーザー端末に表示させ、前記閾値は、前記ユーザー端末を管理する管理者の現在の口座残高と、前記管理者の将来における口座残高の予測値と、の少なくとも一方に基づいて変化する、方法。

（１０）上記（５）～（９）のいずれか１項に記載の方法において、前記データベースは、複数の前記サービス名毎にユーザー１人あたりの料金を記憶しており、前記算出ステップでは、前記統合処理が実行されない場合、前記支払金額と、前記データベースに記憶される前記料金と、に基づいて、前記ユーザーＩＤの数を算出する、方法。

（１１）上記（５）～（１０）のいずれか１項に記載の方法において、算出ステップを備え、前記算出ステップでは、所定期間における前記利用サービスへのアクセス履歴に基づいて、前記ユーザーＩＤの数を算出する、方法。

（１２）上記（１）～（１１）のいずれか１項に記載の方法において、特定ステップを備え、前記特定ステップでは、前記テキスト情報の中に同じ提供者名が複数存在する場合、サブスクリプション契約で利用している利用サービスと、前記サブスクリプション契約で利用している利用サービスに対する支払金額と、を特定し、前記提供者名は、前記利用サービスを提供する者の名称であり、前記表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する利用サービスであって、前記サブスクリプション契約で利用している利用サービスに対する前記支払金額と、をユーザー端末に表示させる、方法。

（１３）上記（１）～（１２）のいずれか１項に記載の方法において、特定ステップを備え、前記特定ステップでは、前記支払金額と、前記支払情報の取得頻度と、の少なくとも一方に基づいて、前記利用サービスに対する支払金額が月払いであるか年払いであるかを特定する、方法。

（１４）上記（１）～（１３）のいずれか１項に記載の方法において、前記データベースは、前記複数のサービス名毎に、サービスの種類を示すカテゴリ情報を記憶し、表示制御ステップでは、前記ユーザー端末に、前記カテゴリ情報により特定されるカテゴリ別に、前記特定されたサービス名を表示させる、方法。

（１５）プログラムであって、少なくとも１つのコンピュータに、上記（１）～（１４）に記載の情報処理方法の各ステップを実行させる、プログラム。

（１６）少なくとも１つの装置からなるシステムであって、上記（１）～（１４）に記載の情報処理方法の各ステップがなされるようにプログラムを実行可能な、少なくとも１つのプロセッサを備える、システム。
もちろん、この限りではない。

最後に、本発明に係る種々の実施形態を説明したが、これらは、例として提示したものであり、発明の範囲を限定することは意図していない。当該新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。当該実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれるものである。

１ ：情報処理システム
２ ：ユーザー端末
３ ：会計システム
４ ：データベース
５ ：サービスシステム
１０ ：制御部
１１ ：取得部
１２ ：アクセス部
１３ ：特定部
１４ ：表示制御部
１５ ：受付部
１６ ：算出部
２０ ：通信部
３０ ：記憶部
４０ ：入力部
５０ ：表示部
１００ ：システム
ＮＷ ：ネットワーク
ＯＩ ：出力アイコン
ＰＤＩ ：プルダウンアイコン
ａ ：バブル
ｂ ：バブル
ｃ ：バブル
ｄ ：バブル
ｅ ：バブル
ｂ１ ：ボックス
ｂ２ ：ボックス
Ｉａ ：選択画像
Ｉｂ ：選択画像
Ｉｃ ：選択画像
Ｉｄ ：選択画像
Ｉｅ ：選択画像
ｒ１ ：領域
ｒ２ ：領域
ｒ３ ：領域

Claims (16)

1. コンピュータにより実行される情報処理方法であって、
   取得ステップと、アクセスステップと、特定ステップと、表示制御ステップと、を備え、
   前記取得ステップでは、利用しているサービスである利用サービスに対する支払情報を取得し、
   前記支払情報は、支払金額と、前記支払金額に対応するテキスト情報と、を含み、
   前記アクセスステップでは、複数のサービス名を記憶するデータベースにアクセスし、
   前記特定ステップでは、前記アクセスしたデータベースに記憶される前記複数のサービス名の中から、前記テキスト情報に対応するサービス名を特定し、
   前記表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、をユーザー端末に表示させる、
   方法。
2. 請求項１に記載の方法において、
   受付ステップを備え、
   前記支払情報は、複数の利用サービスに関するものであり、
   前記支払情報は、複数の支払金額と、前記複数の支払金額にそれぞれ対応する複数のテキスト情報と、を含み、
   前記特定ステップでは、前記アクセスしたデータベースに記憶される前記複数のサービス名の中から、前記複数のテキスト情報のそれぞれに対応する複数のサービス名を特定し、
   前記受付ステップでは、前記ユーザー端末から、特定された前記複数のサービス名から１つのサービス名の選択を受け付け、
   前記表示制御ステップでは、受け付けた前記サービス名と、受け付けた前記サービス名に対応する前記利用サービスに対する支払金額と、を前記ユーザー端末に表示させる、
   方法。
3. 請求項２に記載の方法において、
   前記表示制御ステップでは、前記支払金額を時系列に沿って可視化したグラフを前記ユーザー端末に表示させる、
   方法。
4. 請求項３に記載の方法において、
   前記グラフは、以下の（１）～（３）の少なくとも１つの態様で表現される、
   （１）前記複数の利用サービスに対する支払金額の合計金額を時系列に沿って可視化する
   （２）前記複数の利用サービスを区別可能に可視化する
   （３）前記複数の利用サービスのうち、前記ユーザー端末により選択された利用サービスを可視化する
   方法。
5. 請求項１～４のいずれか１項に記載の方法において、
   前記表示制御ステップでは、前記利用サービスに対する統合処理を実行することを選択する選択画像を前記ユーザー端末に表示させ、
   前記統合処理は、前記利用サービスを提供するサービスシステムから、前記利用サービスに紐づくユーザーＩＤの数と、前記支払金額と、を取得できる状態にする処理である、
   方法。
6. 請求項５に記載の方法において、
   前記取得ステップでは、前記統合処理が実行された後、前記利用サービスに紐づくユーザーＩＤの数と、前記支払金額と、を取得し、
   前記表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、前記ユーザーＩＤの数と、を前記ユーザー端末に表示させる、
   方法。
7. 請求項６に記載の方法において、
   算出ステップを備え、
   前記取得ステップでは、前記統合処理が実行された後、前記利用サービスを利用しているアカウントに関するアカウント情報を取得し、
   前記アカウント情報は、前記ユーザーＩＤと、前記ユーザーＩＤのユーザーが属する組織に関する情報と、が紐づいた情報であり、
   前記算出ステップでは、前記取得した前記ユーザーＩＤの数と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、前記アカウント情報と、に基づいて、以下の（１）及び（２）の少なくとも一方を算出する、
   （１）ユーザー１人あたりの支払金額
   （２）特定のユーザー又は特定の組織による過去から現在までの支払金額の合計金額
   方法。
8. 請求項６又は７に記載の方法において、
   算出ステップを備え、
   前記算出ステップでは、前記利用サービスへのアクセス頻度と、前記ユーザーＩＤの数と、に基づくエンゲージメントスコアを算出し、
   前記エンゲージメントスコアは、第１時点に前記利用サービスにアクセスした場合、第２時点に前記利用サービスにアクセスしたときよりも大きくなるスコアであり、
   前記第２時点は、前記第１時点よりも過去の時点であり、
   表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する前記利用サービスに対する前記支払金額と、前記ユーザーＩＤの数と、前記エンゲージメントスコアと、を前記ユーザー端末に表示させる、
   方法。
9. 請求項８に記載の方法において、
   前記表示制御ステップでは、前記エンゲージメントスコアが閾値を下回る前記利用サービスを前記ユーザー端末に表示させ、
   前記閾値は、前記ユーザー端末を管理する管理者の現在の口座残高と、前記管理者の将来における口座残高の予測値と、の少なくとも一方に基づいて変化する、
   方法。
10. 請求項５～９のいずれか１項に記載の方法において、
    前記データベースは、複数の前記サービス名毎にユーザー１人あたりの料金を記憶しており、
    前記算出ステップでは、前記統合処理が実行されない場合、前記支払金額と、前記データベースに記憶される前記料金と、に基づいて、前記ユーザーＩＤの数を算出する、
    方法。
11. 請求項５～１０のいずれか１項に記載の方法において、
    算出ステップを備え、
    前記算出ステップでは、所定期間における前記利用サービスへのアクセス履歴に基づいて、前記ユーザーＩＤの数を算出する、
    方法。
12. 請求項１～１１のいずれか１項に記載の方法において、
    特定ステップを備え、
    前記特定ステップでは、前記テキスト情報の中に同じ提供者名が複数存在する場合、サブスクリプション契約で利用している利用サービスと、前記サブスクリプション契約で利用している利用サービスに対する支払金額と、を特定し、
    前記提供者名は、前記利用サービスを提供する者の名称であり、
    前記表示制御ステップでは、前記特定されたサービス名と、前記特定されたサービス名に対応する利用サービスであって、前記サブスクリプション契約で利用している利用サービスに対する前記支払金額と、をユーザー端末に表示させる、
    方法。
13. 請求項１～１２のいずれか１項に記載の方法において、
    特定ステップを備え、
    前記特定ステップでは、前記支払金額と、前記支払情報の取得頻度と、の少なくとも一方に基づいて、前記利用サービスに対する支払金額が月払いであるか年払いであるかを特定する、
    方法。
14. 請求項１～１３のいずれか１項に記載の方法において、
    前記データベースは、前記複数のサービス名毎に、サービスの種類を示すカテゴリ情報を記憶し、
    表示制御ステップでは、前記ユーザー端末に、前記カテゴリ情報により特定されるカテゴリ別に、前記特定されたサービス名を表示させる、
    方法。
15. プログラムであって、
    少なくとも１つのコンピュータに、請求項１～１４に記載の情報処理方法の各ステップを実行させる、
    プログラム。
16. 少なくとも１つの装置からなるシステムであって、
    請求項１～１４に記載の情報処理方法の各ステップがなされるようにプログラムを実行可能な、少なくとも１つのプロセッサを備える、
    システム。