JP2022166343A - サービス利用支援方法、サービス利用支援プログラム及びサービス利用支援システム - Google Patents

Abstract

【課題】セキュリティを担保しつつ、ウェブサービスの利用者による情報入力の煩雑さの解消とともに、サービス運営管理者の手間をも軽減することが可能なサービス利用支援方法、サービス利用支援プログラム及びサービス利用支援システムを提供する。【解決手段】サービス利用支援システム０２００は、利用者端末からのウェブサービス利用に関する決済要求を受信する決済要求受信部０２０１と、受信した決済要求に応じて、利用者端末に対し、決済代行処理サーバに対するトークン発行要求を送信させる発行要求部０２０２と、発行要求に対応し決済代行処理サーバから発行され、発行要求と紐づけられている情報を含むトークンを取得するトークン取得部０２０３と、取得したトークンとともに、サービスサーバに対し、決済要求に応じたサービス利用に関連する情報である利用関連情報を出力する利用関連情報出力部０２０４と、を備える。【選択図】図２

Description

本発明は、ＥＣサイトなどの運営支援サービスに付随して、滞りのない決済環境を提供するためのサービス利用支援方法などに関する。

従来から、ＥＣサイト等の運営にあたっては、決済方法としてクレジットカードの利用が広く採用されている。簡易に決済が行えて取引の関係者にとって便利な反面、取引データやクレジットカード情報の漏洩や不正利用のリスクも無視できない。そのため当該決済についてはセキュリティに関する様々な技術的な対処が求められるところであり、例えば、ＰＣＩＤＳＳなどのオフィシャルな基準を満たしたセキュリティ体制の構築や、いわゆる「カード情報の非保持化」などの観点からのトークン決済といった方策を採ることが広く知られている。

いっぽう、ＥＣサイトの運営に関連して、購入ユーザによる情報入力の支援を行うことで、決済までのスムーズな導線確保のための仕組みを提供するサービスもよく知られている。具体的には、チャットボットなどの仕組みを提供し、購入ユーザに所定事項の入力を促したり、好適な質問を送信したりすることで、ＥＣサイト運営者による、ユーザ対応コストの低減が実現できている。このようなECサイト管理支援システムに関する技術としては、例えば引用文献１記載の技術が知られている。

特開２０１８－０８１５３８号

しかしながら、特許文献１に記載されている先行技術は、所定フォーマットなどに情報の入力を促すことができるにとどまるため、却って購入ユーザに対し、カード情報の直接入力を促すような事態にもなりかねず、セキュリティの観点から不安がぬぐえなかった。

以上のような課題を解決すべく、本発明は、所定のウェブサービスを提供するサーバであるサービスサーバと、当該ウェブサービスを利用する利用者端末と、当該ウェブサービスに関連した決済代行処理を行うサーバである決済代行処理サーバと、の間でコンピュータを実行して情報の送受信を行うサービス利用支援方法であって、利用者端末からのウェブサービス利用に関する決済要求を受信する決済要求受信ステップと、受信した決済要求に応じて、利用者端末に対し、決済代行処理サーバに対するトークン発行要求を送信させる発行要求ステップと、前記発行要求に対応したトークンを取得するトークン取得ステップと、取得したトークンとともに、サービスサーバに対し、前記決済要求に応じたサービス利用に関連する情報である利用関連情報を出力する利用関連情報出力ステップと、サービスサーバより前記利用関連情報に対応する決済結果を取得する決済結果取得ステップと、前記取得した決済結果に応じたメッセージを前記利用者端末宛に出力するメッセージ出力ステップと、からなるサービス利用支援方法などを提案する。

また、上記発明に関連し、所定のウェブサービスと、当該ウェブサービスに関連する利用関連情報に対応する入力受付ルールを取得する入力受付ルール取得ステップと、利用者端末から前記ウェブサービスに係る利用関連情報の入力を受け付ける入力受付ステップをさらに有し、利用関連情報出力ステップは、前記受け付けた利用関連情報を、入力受付ルールに基づいて出力する適合処理サブステップをさらに有するサービス利用支援方法なども提案する。

また、上記各発明に関連し、利用関連情報出力ステップは、サービスサーバが予定する決済処理を前記トークンを用いて実行可能な態様にて実行させるための決済制御情報をも出力する決済制御情報出力サブステップをさらに有するサービス利用支援方法なども提案する。

また、上記方法を実現するためのプログラムやシステムなども提案する。

主に以上のような構成をとる本発明によって、セキュリティを担保しつつ、ウェブサービスの利用者による情報入力の煩雑さの解消とともに、サービス運営管理者の手間をも軽減することが可能になる。

本発明のシステムの概略図 実施形態１のシステムの機能ブロックの一例を示す図 実施形態１のシステムの機能的な各構成をまとめて一のハードウェアとして実現した際の構成の一例を示す概略図 実施形態１のシステムにおける処理の流れの一例を示す図 実施形態１のシステムにおける処理の流れの一例を示す図 実施形態２のシステムの機能ブロックの一例を示す図 実施形態２のシステムにおける処理の流れの一例を示す図 実施形態３のシステムの機能ブロックの一例を示す図 実施形態３のシステムにおける処理の流れの一例を示す図

まず図１を示す。図１は本発明の概要を示す図である。本図に示されているように、本発明は、所定のウェブサービスを提供するサーバであるサービスサーバ０１２１と、当該ウェブサービスを利用する利用者端末０１１１、０１１２、０１１３と、当該ウェブサービスに関連した決済代行処理を行うサーバである決済代行処理サーバ０１３１と、の間でコンピュータを実行して情報の送受信を行うように構成されており、具体的には、一又は複数のサーバ０１０１、０１０２により実現される。

同図を示して説明したとおり、本発明は、所定のウェブサービスを提供するサーバであるサービスサーバと、当該ウェブサービスを利用する利用者端末と、当該ウェブサービスに関連した決済代行処理を行うサーバである決済代行処理サーバと、の間で情報の送受信を行うことを特徴とする。ここでいう「所定のウェブサービス」としては、ECサービス、オンラインスクールサービス、オンデマンドコンテンツサービス、その他決済処理を行うことで利用可能なウェブサービスであれば、特にその種別を問わずに適用可能である。また、ウェブサービスであることが特徴となるため、ウェブブラウザを介して利用可能なサービスであることが求められる。

次に、利用者端末については、上記ウェブサービスを利用可能な構成であれば、その種別を特に限定することはなく、例えば、スマートフォン０１１１やパソコン０１１２、タブレット０１１３などが利用者端末として考えられ、その他スマートグラスやスマートウォッチ、スマートペンなどが考えられる。

また、決済代行処理サーバとは、上記所定のウェブサービスにおいて決済処理が要求される場合、当該決済処理を必要とするユーザに代わり、クレジットカード会社その他の決済金融機関との間で決済処理を行うためのサーバであることが一般的である。ただ、ここでいう「決済」は必ずしも現金ないし現金的価値と直結する価値との交換（為替）処理のみに限定されず、暗号資産や前払式支払手段、特定のサービスでのみ利用可能なポイントなどの現金類似の価値との交換を行うための処理を広く含んでいる。上述のとおり、インターネット上での取引における決済処理については、セキュリティの観点から決済代行処理サーバが介在するケースが広くみられるところであり、本発明における決済代行処理サーバの位置づけも、かかる一般的な取引における意義と変わるところはない。

さきに述べたとおり、本発明は一又は複数のサーバ０１０１、０１０２により実現されうる。より具体的に言えば、一のサービスを提供するためのアプリケーションサーバ０１０１と、当該サービスに利用される種々のデータを管理するためのデータベースサーバ０１０２などが複数用いられることが考えられ、他の事業者が管理するアプリケーションサーバとＡＰＩ連携の形式により相互に接続されることにより、当該他の事業者が提供するサービスアプリケーションを実行することも可能である。それらのサーバの組み合わせにより、広汎なサービス内容への対応を可能とするのみならず、それぞれのサーバがネットワークを介して接続可能に構成されることにより、多様な地理的拠点を設けつつ、効率性の高いサービス提供を可能とする。

以下、本発明の各実施形態について図面とともに説明する。まず実施形態と請求項の相互の関係は、以下のとおりである。まず、実施形態１は主に請求項１、４、５などに対応する。実施形態２は主に請求項２などに対応する。実施形態３は主に請求項３などに対応する。

なお、本発明はこれらの実施形態に何ら限定されるものではなく、技術常識に従って特許請求の範囲の各請求項に記載の技術的思想を有し、その要旨を逸脱しない範囲内において、様々な態様で実施し得る。

＜＜実施形態１＞＞
＜概要＞
図２は、本実施形態のサービス利用支援システムの機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「サービス利用支援システム」０２００は、「決済要求受信部」０２０１と、「発行要求部」０２０２と、「トークン取得部」０２０３と、「利用関連情報出力部」０２０４と、「決済結果取得部」０２０５と、「メッセージ出力部」０２０６と、を有する。

なお、以下で詳しく説明するサービス利用支援システムは、その機能の一又は複数の機能を複数の装置にて実現するようにも構成され得るものであって、その機能ブロックは、いずれもハードウェア又はソフトウェアとして実現され得る。コンピュータを用いるものを例にすれば、ＣＰＵやメインメモリ、ＧＰＵ、ＴＰＵ、画像メモリ、バス、二次記憶装置（ハードディスクや不揮発性メモリ）、キーボードやマイク、タッチパネル、タッチパネルをタッチするための電子ペンなどの各種入力デバイス、スピーカ、ディスプレイその他各種出力デバイス、その他の外部周辺装置などのハードウェア構成部、またその外部周辺装置用のインタフェース、通信用インタフェース、それらのハードウェアを制御するためのドライバプログラムやその他のアプリケーションプログラムなどが挙げられる。

そしてメインメモリ上に展開したプログラムに従った演算処理によって、入力デバイスやその他インタフェースなどから入力されメモリやハードウェア上に保持されているデータなどが加工、蓄積されたり、前記各ハードウェアやソフトウェアを制御するための命令が作成されたりする。ここで、上記プログラムは、モジュール化された複数のプログラムとして実現されてもよいし、２以上のプログラムをクラウドコンピューティングその他の方法により組み合わせて一のプログラムとして実現されても良い。

また、本実施形態をはじめとする本発明は、所定のウェブサービスを提供するサーバであるサービスサーバと、当該ウェブサービスを利用する利用者端末と、当該ウェブサービスに関連した決済代行処理を行うサーバである決済代行処理サーバと、の間でそれぞれ情報の送受信を行うことをその技術的特徴として備えている。すなわち、本発明は、サービスサーバの運営者でも、サービス利用者でも、決済代行機関でもない第三者が管理するコンピュータを用いて実現可能である。特にサービスサーバの運営者にとっては、決済処理のために必要とされる煩雑な処理を外部に委託しつつ、サービス利用者にストレスを与えることなくサービス提供が実現できるため、その技術的資源を、ユーザーフレンドリーなサービス提供の面に集中することができる。

このような構成をとる際の好適な態様として、特にウェブサービスを例にとると、ウェブブラウザ上に当該ウェブサービス利用を促進するためのウェブページである促進ページを表示させ、当該促進ウェブページと上記ウェブサービスとを、HTMLのiframe要素を用いて関連付けるような処理を行うことが考えられる。当該構成を採用することで、所定のウェブサービスのサービス利用者が違和感なく促進ページをも閲覧することができる。

なおここでいう促進ページの具体例としては、アンケートの入力や、決済のための必要情報の入力、サービス対象となる商品の色やサイズ、型番などの選択入力、数あるサービスメニューの検索入力などを受け付けるためのページとして構成されることが考えられる。当該構成を採用してサービスサーバの運営者に提供可能とすることにより、サービスサーバの運営者は、アンケートフォーマットや商品購入カート用のフォーマットなどをわざわざ自身で作成することなく、手軽にウェブサービスの展開を開始し、運営することができるようになる。

なお、促進ページは、例えばチャットボットのように対話形式でユーザに対し情報入力を促すような構成とすることが考えられる。当該構成を採用すれば、ユーザの反応に応じて適宜の反応をもって、更なる情報の入力や加除修正を促したり、タイムリーに入力完了の旨をユーザに伝えたりすることができるようになるため、ユーザによるサービス利用の離脱率の低減を図ることができるようになる。また、別の角度から見ると、対話形式で一定形式の情報入力を促すことで、ユーザからの情報入力受付を、イレギュラーではなく一定のルールに基づいて処理することができるため、当該ルールに応じて後述する利用関連情報を出力しやすくなる。

＜機能的構成＞
「決済要求受信部」０２０１は、利用者端末からのウェブサービス利用に関する決済要求を受信するように構成されている。ここでの決済要求には、少なくとも決済金額が含まれ、決済対象となる商品やサービスを識別するための情報、決済要求日時その他決済対象に関する情報が含まれる。

なお、決済要求受信部にて決済要求を受信した場合、当該決済要求の内容を、サービスサーバに対して出力する構成を採用することは必ずしも排除しない。ただ後述する利用関連情報出力部における処理内容と重複する処理となるため、煩雑さ回避の観点からは当該構成を採用することは避けることが望ましい。

「発行要求部」０２０２は、受信した決済要求に応じて、利用者端末に対し、決済代行処理サーバに対するトークン発行要求を送信させるように構成される。「トークン発行要求を送信させる」処理の具体的な態様としては、利用者端末に対し、決済代行処理サーバにトークン発行要求を送信せよ、という趣旨のメッセージを出力する場合もあれば、特定の決済代行処理サーバに対し、トークン発行要求を送信するためのウェブページその他の機能を利用可能に提供する場合もある。いずれの態様を採用してもよいが、特にAPI連携機能などを用いてトークン発行要求のための機能を提供することで、利用者に対し、特段の端末操作を求めることなく、簡易な方式にてトークン発行要求の送信を促すことが可能になる。

なおここでいうトークン発行要求は、特定の決済代行処理サーバを管理する事業者を識別するための情報の選択入力とともに受け付けることとなる。そのいっぽう、発行要求部をはじめとするいずれの機能においても、本発明の実施主体は、クレジットカード番号その他の決済処理を行うにあたり決済対象者を直接識別可能な情報は取得しない。当該構成を採用することにより、ＰＣＩＤＳＳなどのセキュリティ体制を構築せずとも、サービス利用者に安心してサービス利用のための決済手続を提供することが可能になる。

なお、発行要求部では決済要求に応じてトークン発行要求を行うところ、トークン発行要求は、当該決済要求との関連付けを意味するための識別子を含めて行われる。当該構成を採用することにより、トークンと決済要求とを突合させてその後の処理を適正に行うことができるようになる。

「トークン取得部」０２０３は、前記発行要求に対応したトークンを取得するように構成される。ここでいう「前記発行要求に対応したトークン」は、前記発行要求に対応し決済代行処理サーバから発行され、利用者端末にて取得されたトークンを意味しており、前記発行要求と紐づけられている情報を含んでいる。前記識別子をはじめとする決済要求とトークンとの関連性の有無を判定可能な情報が含まれており、かかる情報をも取得することにより、当該取得したトークンが、いずれの決済要求と紐づいたものなのかを判断可能となる。

なお、トークン取得部は、利用者端末からトークンを取得することを技術的特徴として備えている。そのため、もし何らかの理由により、前記識別子をはじめとする決済要求とトークンとの関連性の有無を判定可能な情報の取得が困難ないし不可能であった場合であっても、当該トークンが送信された利用者端末と、発行要求部にてトークン発行要求を受け付けた利用者端末とを識別する情報を取得することで、当該取得した情報を用いて取得したトークンが、いずれの決済要求と紐づいたものなのかを判定してもよい。

「利用関連情報出力部」０２０４は、取得したトークンとともに、サービスサーバに対し、前記決済要求に応じたサービス利用に関連する情報である利用関連情報を出力するように構成されている。ここでいう利用関連情報の一例を前記促進ページに関する説明と関連させて具体化すると、決済のための必要情報として入力を受け付けたサービスの会員IDや氏名、住所、年齢、決済対象となる商品又はサービスあるいはそれらを識別するためのID、配送希望日時、住所と異なる配送先の希望有無及び当該配送先、配送方法（配送事業者の指定や配送サービスの指定、配送時の置き配可否や定期購入の場合の購入間隔などを含むが、これらに関連する情報として想定される情報について特に限定はしない）などが利用関連情報として含まれると考えられる。

利用関連情報出力部においては、利用関連情報をトークンとともに出力することから、いわばサービス利用者やサービス事業者との関係で言えば「注文代行」処理を行っているような意義を有することとなる。出力先であるサービスサーバにおいては、当該情報を取得することで速やかに、当該情報に応じたサービス利用のための処理を行うことができる。すなわち、ＥＣサイトを運営する場合であれば、速やかに商品販売のための決済処理及び当該商品配送のための処理を進めることができ、自ら利用者との間で、商品販売のための必要情報の入力受付や、トークン発行を促すための情報送信などの煩雑な処理を行う手間から解放される。

利用関連情報出力部においては、あらかじめサービスサーバにおいて提供されているサービスの内容に応じ、情報出力の態様に関するルールである情報出力ルールを保持しておき、当該情報出力ルールに応じて利用関連情報を出力することが考えられる。具体的には、利用関連情報の内容のうち、どの情報をどの態様で、どのサイトページの、どの入力欄に入力すべきか、といった内容を情報出力ルールとして保持する。

情報出力ルールは、上記サービスの内容ごとに個別に設けられてもよいし、汎用的に提供されるサービスに対しては、汎用的に適用可能なルールとして汎用情報出力ルールを設けたうえで用いてもよい。外部のサーバから随時取得したうえでAPIの態様にて適用してももちろんよい。当該構成を採用することで、利用関連情報出力部における出力処理の効率化が図られるのみならず、サービスサーバ側でもエラー等のリスクを低減して利用関連情報を取得できるようになるため、円滑な取引に資することができるようになる。

「決済結果取得部」０２０５は、サービスサーバより前記利用関連情報に対応する決済結果を取得するように構成されている。利用関連情報出力部における利用関連情報の出力先であるサービスサーバにおいては、取得したトークンを用いて、トークン発行元である決済代行処理サーバとの間で情報の送受信を行い、当該トークンと紐づけられた決済処理を進めることの可否を判定する。そして当該判定内容を決済結果として取得することとなる。決済代行処理サーバとの情報の送受信自体はサービスサーバが担う本構成を採用することにより、サービス運営者として迅速にその後の商品発送等の処理を進めることができるほか、決済結果を迅速に取得できるため、売上管理においても安心感をもってその後の処理を進めることができるようになる。

「メッセージ出力部」０２０６は、前記取得した決済結果に応じたメッセージを前記利用者端末宛に出力するように構成されている。ここでいう「前記利用者端末宛に出力する」とは、必ずしも特定の利用者端末に限定してメッセージを出力することを意味するのではない。例えば、前記利用者端末と紐づけて管理される利用者IDを同じくする他の利用者端末への出力であっても、同一の利用者IDを介して「前記利用者端末宛」へ情報が出力されたと評価することができる。本発明を通じ利用者端末宛にメッセージを送ることで、利用者は、サービス利用の申し出から完了までの間、一貫して同じインタフェースを介して情報の送受信を行うことができるため、煩雑さを感じさせることなく、高いサービス利用満足度を維持できるようになる。

＜具体的な構成＞
ここで図３を示す。同図は本実施形態のサービス利用支援システムの機能的な各構成をまとめて一のハードウェアとして実現した際の構成の一例を示す概略図である。各装置はいずれも、それぞれ各種演算処理を実行するための「ＣＰＵ」０３０１と、「記憶装置（記憶媒体）」０３０２と、「メインメモリ」０３０３と、「入力インタフェース」０３０４、「出力インタフェース」０３０５、「ネットワークインタフェース」０３０６と、を備え、入出力インタフェースを介して、例えば「タッチパネル」０３０７、「ディスプレイ」０３０８などの外部周辺装置と情報の送受信を行う。また、ネットワークインタフェースを介して複数の「利用者端末」０３０９や「サービスサーバ」０３１０などの外部装置と情報の送受信を行う。さらに図示しないが、他のウェブアプリケーションサーバとネットワークを介して接続し、情報の送受信を行いＡＰＩ連携を行う場合もある。このネットワークインタフェースの具体的な態様は無線を念頭に置くが、有線による通信を排除するものではない。また、通信方法も直接、間接を問わない。よって特定の外部装置ないし同装置の利用者と紐づけられた第三者の管理するサーバとの間で情報の送受信を行ういわゆるクラウドコンピューティングの形式を採用することも可能である。

記憶装置には以下で説明するような各種プログラムが格納されており、ＣＰＵはこれら各種プログラムをメインメモリのワーク領域内に読み出して展開、実行する。なお、これらの構成は、「システムバス」０３９９などのデータ通信経路によって相互に接続され、情報の送受信や処理を行う（以上の構成の基本的な構成は、以下で説明する他の装置のいずれについても同様である。

（決済要求受信部の具体的な構成）
決済要求受信部は、コンピュータプログラムとコンピュータハードウェアにより構成され、具体的には、ＣＰＵが記憶装置から「決済要求受信プログラム」０３２０をメインメモリに読み出して実行し、利用者端末からのウェブサービス利用に関する決済要求を受信してメインメモリの所定のアドレスに格納する。

（発行要求部の具体的な構成）
発行要求部は、コンピュータプログラムとコンピュータハードウェアにより構成され、具体的には、ＣＰＵが記憶装置から「発行要求プログラム」０３３０をメインメモリに読み出して実行し、決済要求受信プログラムの実行により受信した決済要求に応じて、利用者端末に対し、決済代行処理サーバに対するトークン発行要求を送信させるための情報を出力する。

（トークン取得部の具体的な構成）
トークン取得部は、コンピュータプログラムとコンピュータハードウェアにより構成され、具体的には、ＣＰＵが記憶装置から「トークン取得プログラム」０３４０をメインメモリに読み出して実行し、前記発行要求に対応したトークンを利用者端末から取得し、メインメモリの所定のアドレスに格納する。

（利用関連情報出力部の具体的な構成）
利用関連情報出力部は、コンピュータプログラムとコンピュータハードウェアにより構成され、具体的には、ＣＰＵが記憶装置から「利用関連情報出力プログラム」０３５０をメインメモリに読み出して実行し、トークン取得プログラムの実行により取得したトークンとともに、サービスサーバに対し、前記決済要求に応じたサービス利用に関連する情報である利用関連情報を出力する。

（決済結果取得部の具体的な構成）
決済結果取得部は、コンピュータプログラムとコンピュータハードウェアにより構成され、具体的には、ＣＰＵが記憶装置から「決済結果取得プログラム」０３６０をメインメモリに読み出して実行し、前記利用関連情報に対応する決済結果をサービスサーバから取得してメインメモリの所定のアドレスに格納する。

（メッセージ出力部の具体的な構成）
メッセージ出力部は、コンピュータプログラムとコンピュータハードウェアにより構成され、具体的には、ＣＰＵが記憶装置から「メッセージ出力プログラム」０３７０をメインメモリに読み出して実行し、決済結果取得プログラムの取得した決済結果に応じたメッセージを前記利用者端末宛に出力する。

＜処理の流れ＞
図４は、本実施形態のサービス利用支援システムにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０４０１では、利用者端末から、ウェブサービス利用に関する決済要求を受信する（決済要求受信ステップ）。その後ステップＳ０４０２では、受信した決済要求に応じて、利用者端末に対し、決済代行処理サーバに対するトークン発行要求を送信させる（発行要求ステップ）。そしてステップＳ０４０３では、前記発行要求に対応したトークンを利用者端末から取得し（トークン取得ステップ）、ステップＳ０４０４では、取得したトークンとともに、サービスサーバに対し、前記決済要求に応じたサービス利用に関連する情報である利用関連情報を出力する（利用関連情報出力ステップ）。その後ステップＳ０４０５では、サービスサーバより前記利用関連情報に対応する決済結果を取得し（決済結果取得ステップ）、ステップＳ０４０６で前記取得した決済結果に応じたメッセージを前記利用者端末宛に出力する（メッセージ出力ステップ）。

ここでさらに図５を示す。同図は、本実施形態のサービス利用支援システムにおける処理の流れの一例を、サーバや各端末間の情報の送受信の流れの観点から示す図である。ステップＳ０５０１では、利用者端末から決済要求を受信し、ステップＳ０５０２は、利用者端末に対し、決済代行処理サーバに対するトークン発行要求を送信させる情報を出力する。ステップＳ０５０３で、利用者端末から決済代行処理サーバに対しトークン発行要求が送信されると、ステップＳ０５０４では、決済代行処理サーバから利用者端末に対し、トークンが発行される。そしてステップＳ０５０５では、利用者端末からトークンを取得し、ステップＳ０５０６では、サービスサーバに対し、利用関連情報を出力する。ステップＳ０５０７では、サービスサーバから、決済代行処理サーバに対し、トークンを用いて決済処理の可否を照会し、ステップＳ０５０８で、サービスサーバは、決済代行処理サーバより当該紹介結果を取得する。そしてそこでの照会結果が決済処理可との内容であれば、ステップＳ０５０９にて、サービスサーバから決済結果を取得し、ステップＳ０５１０で、決済結果に応じたメッセージを前記利用者端末宛に出力する。

＜効果＞
以上の構成を採用するサービス利用支援システムを利用することにより、セキュリティを担保しつつ、ウェブサービスの利用者による情報入力の煩雑さの解消とともに、サービス運営管理者の手間をも軽減することが可能になる。

＜＜実施形態２＞＞
＜概要＞
本実施形態のサービス利用支援システムは、基本的には実施形態１に記載のサービス利用支援システムの技術的特徴と同様であるが、所定のウェブサービスと、当該ウェブサービスに関連する利用関連情報に対応する入力受付ルールを保持し、利用者端末から前記ウェブサービスに係る利用関連情報の入力を受け付け、利用関連情報の出力に際し、前記受け付けた利用関連情報を、入力受付ルールに基づいて出力する点を特徴としている。

＜機能的構成＞
図６は、本実施形態のサービス利用支援システムの機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「サービス利用支援システム」０６００は、「決済要求受信部」０６０１と、「発行要求部」０６０２と、「トークン取得部」０６０３と、「利用関連情報出力部」０６０４と、「決済結果取得部」０６０５と、「メッセージ出力部」０６０６と、「入力受付ルール保持部」０６０７と、「入力受付部」０６０８と、を有し、利用関連情報出力部は、「適合処理手段」０６１４をさらに有する。基本的な構成は、実施形態１の図２を用いて説明したサービス利用支援システムと共通するため、以下では相違点である「入力受付ルール保持部」０６０７と、「入力受付部」０６０８と、「適合処理手段」０６１４の機能について説明する。

「入力受付ルール保持部」０６０７は、所定のウェブサービスと、当該ウェブサービスに関連する利用関連情報に対応する入力受付ルールを保持するように構成されている。入力受付ルールとは、先に説明した情報出力ルールと対応して保持されることが考えられるが、ウェブサービスごとに入力を求められる情報の種別と内容、複数の情報の入力を受け付ける際の受付順や受付方法などのルールであることが考えられる。入力受付ルールはサービスサーバから取得し保持することが考えられるが、サービスサーバ側にて入力受付ルールのアップデートがあった場合に、当該アップデートの内容が適宜のタイミングで反映されるよう、サービスサーバとの間において情報の送受信が行われることが好ましい。

「入力受付部」０６０８は、利用者端末から前記ウェブサービスに係る利用関連情報の入力を受け付けるように構成されている。具体的には、ここまで説明してきたように、チャットボットなどの入力促進手段を用いながら、利用者端末から適宜の情報入力を受け付ける構成を採用することが好ましい。

「適合処理手段」０６１４は、利用関連情報出力部において、利用関連情報出力ステップは、前記受け付けた利用関連情報を、入力受付ルールに基づいて出力するように構成されている。当該構成を採用することで、サービスサーバは、自らが設定した入力受付ルールに応じた情報を利用関連情報として取得することができ、情報の変換処理やそもそも変換不能な情報の取扱などに対応する懸念を低減することができる。

＜具体的な構成＞
本実施形態のサービス利用支援システムを構成する各装置のハードウェア構成は、基本的には、図３を用いて説明した実施形態１のサービス利用支援システムにおけるハードウェア構成と同様である。そこで以下については、これまで説明していない「入力受付ルール保持部」と、「入力受付部」と、「適合処理手段」の具体的な処理について説明する。

（入力受付ルール保持部の具体的な構成）
入力受付ルール保持部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、ＣＰＵが記憶装置から「入力受付ルール取得プログラム」をメインメモリに読み出して実行し、サービスサーバから入力受付ルールを取得し、メインメモリの所定のアドレスに格納する。

（利用受付部の具体的な構成）
利用受付部は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、ＣＰＵが記憶装置から「利用受付プログラム」をメインメモリに読み出して実行し、利用者端末から利用関連情報の入力を受付け、メモリの所定のアドレスに格納する。

（適合処理手段の具体的な構成）
適合処理手段は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、利用関連情報出力プログラムの実行に際しＣＰＵが記憶装置から「適合処理サブプログラム」をメインメモリに読み出して実行し、利用受付プログラムの実行により受け付けた利用関連情報を、入力受付ルールに基づいて出力する。

＜処理の流れ＞
図７は、本実施形態のサービス利用支援システムにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０７０１では、サービスサーバから、所定のウェブサービスと、当該ウェブサービスに関連する利用関連情報に対応する入力受付ルールを取得する（入力受付ルール取得ステップ）。その後ステップＳ０７０２では、利用者端末から前記ウェブサービスに係る利用関連情報の入力を受け付け（入力受付ステップ）、重ねてステップＳ０７０３では、利用者端末から、ウェブサービス利用に関する決済要求を受信する（決済要求受信ステップ）。その後ステップＳ０７０４では、受信した決済要求に応じて、利用者端末に対し、決済代行処理サーバに対するトークン発行要求を送信させる（発行要求ステップ）。そしてステップＳ０７０５では、前記発行要求に対応したトークンを利用者端末から取得し（トークン取得ステップ）、ステップＳ０７０６では、取得したトークンとともに、サービスサーバに対し、前記決済要求に応じたサービス利用に関連する情報である利用関連情報を入力受付ルールに基づいて出力する（適合処理ステップ）。その後ステップＳ０７０７では、サービスサーバより前記利用関連情報に対応する決済結果を取得し（決済結果取得ステップ）、ステップＳ０７０８で前記取得した決済結果に応じたメッセージを前記利用者端末宛に出力する（メッセージ出力ステップ）。

＜効果＞
本実施形態のサービス利用支援システムを用いることにより、実施形態１のサービス利用支援システムを用いる場合に比べて、サービスサーバの負担を低減可能な形式にて利用関連情報を出力することが可能になる。

＜＜実施形態３＞＞
＜概要＞
本実施形態のサービス利用支援システムは、基本的には実施形態１や２に記載のサービス利用支援システムの技術的特徴と同様であるが、利用関連情報の出力に際し、サービスサーバが予定する決済処理を前記トークンを用いて実行可能な態様にて実行させるための決済制御情報をも出力する点を特徴としている。

＜機能的構成＞
図８は、本実施形態のサービス利用支援システムの機能ブロックの一例を示す図である。同図において示されているように、本実施形態の「サービス利用支援システム」０８００は、「決済要求受信部」０８０１と、「発行要求部」０８０２と、「トークン取得部」０８０３と、「利用関連情報出力部」０８０４と、「決済結果取得部」０８０５と、「メッセージ出力部」０８０６と、を有し、利用関連情報出力部は、「決済制御情報出力手段」０８１４をさらに有する。基本的な構成は、実施形態１の図２を用いて説明したサービス利用支援システムと共通するため、以下では相違点である「決済制御情報出力手段」０８１４の機能について説明する。

「決済制御情報出力手段」０８１４は、利用関連情報出力部において、サービスサーバが予定する決済処理を前記トークンを用いて実行可能な態様にて実行させるための決済制御情報をも出力するように構成されている。「サービスサーバが予定する決済処理」とは、当該サービスサーバ上で入力受付を予定されている、所定の商品の購入対価又はサービスの利用対価の決済処理にほかならず、より具体的には、クレジットカードなどを用いた決済代行処理であるのが一般的である。

ただ、本発明においては既に、トークン取得部において当該取引において予定する決済処理に用いられるトークンはすでに取得されているところ、サービスサーバ側で、当該事情にかかわらず改めて、決済代行処理サーバからトークンを取得するための処理を行ってしまう場合がありえ、そのような処理は煩雑に過ぎるほか、二重取引として利用者に想定外の金銭的負担を生じさせてしまう可能性もある。そのため、いったんトークン取得部にて取得したトークンとともに利用関連情報を出力した場合には、もはやサービスサーバ側にて、再度トークン取得のための処理は行わないようにするための情報をあわせて出力することが好ましい。そのため、前記既に取得したトークンを用いて決済処理を実行可能な態様にてサービスサーバの各種処理を実行させるための情報である決済制御情報をもサービスサーバに対して出力することが考えられる。当該構成を採用することにより、サービスサーバ側での二重取引処理などを行う弊害を回避することが可能になる。

＜具体的な構成＞
本実施形態のサービス利用支援システムを構成する各装置のハードウェア構成は、基本的には、図４を用いて説明した実施形態１のサービス利用支援システムにおけるハードウェア構成と同様である。そこで以下については、これまで説明していない「決済制御情報出力手段」の具体的な処理について説明する。

（決済制御情報出力手段の具体的な構成）
決済制御情報出力手段は、具体的にはコンピュータプログラムとコンピュータハードウェアにより構成され、利用関連情報出力プログラムの実行に際しＣＰＵが記憶装置から「決済制御情報出力サブプログラム」をメインメモリに読み出して実行し、サービスサーバが予定する決済処理を前記トークンを用いて実行可能な態様にて実行させるための決済制御情報をも出力する。

＜処理の流れ＞
図９は、本実施形態のサービス利用支援システムにおける処理の流れの一例を示す図である。同図の処理の流れは以下のステップからなる。最初にステップＳ０９０１では、利用者端末から、ウェブサービス利用に関する決済要求を受信する（決済要求受信ステップ）。その後ステップＳ０９０２では、受信した決済要求に応じて、利用者端末に対し、決済代行処理サーバに対するトークン発行要求を送信させる（発行要求ステップ）。そしてステップＳ０９０３では、前記発行要求に対応したトークンを利用者端末から取得し（トークン取得ステップ）、ステップＳ０９０４では、取得したトークンとともに、サービスサーバに対し、前記決済要求に応じたサービス利用に関連する情報である利用関連情報と、サービスサーバが予定する決済処理を前記トークンを用いて実行可能な態様にて実行させるための決済制御情報をも出力する（決済制御情報出力サブステップ）。その後ステップＳ０９０５では、サービスサーバより前記利用関連情報に対応する決済結果を取得し（決済結果取得ステップ）、ステップＳ０９０６で前記取得した決済結果に応じたメッセージを前記利用者端末宛に出力する（メッセージ出力ステップ）。

＜効果＞
本実施形態のサービス利用支援システムを用いることにより、実施形態１や２のサービス利用支援システムを用いる場合に比べて、サービスサーバ側での二重取引処理などを行う弊害を回避することが可能になる。

０２００・・・サービス利用支援システム、０２０１・・・決済要求受信部、０２０２・・・発行要求部、０２０３・・・トークン取得部、０２０４・・・利用関連情報出力部、０２０５・・・決済結果取得部、０２０６・・・メッセージ出力部

Claims (5)

1. 所定のウェブサービスを提供するサーバであるサービスサーバと、当該ウェブサービスを利用する利用者端末と、当該ウェブサービスに関連した決済代行処理を行うサーバである決済代行処理サーバと、の間でそれぞれ情報の送受信を行うサービス利用支援方法であって、
   利用者端末からのウェブサービス利用に関する決済要求を受信する決済要求受信ステップと、
   受信した決済要求に応じて、利用者端末に対し、決済代行処理サーバに対するトークン発行要求を送信させる発行要求ステップと、
   前記発行要求に対応したトークンを取得するトークン取得ステップと、
   取得したトークンとともに、サービスサーバに対し、前記決済要求に応じたサービス利用に関連する情報である利用関連情報を出力する利用関連情報出力ステップと、
   サービスサーバより前記利用関連情報に対応する決済結果を取得する決済結果取得ステップと、
   前記取得した決済結果に応じたメッセージを前記利用者端末宛に出力するメッセージ出力ステップと、
   からなるサービス利用支援方法。
2. 所定のウェブサービスと、当該ウェブサービスに関連する利用関連情報に対応する入力受付ルールを取得する入力受付ルール取得ステップと、
   利用者端末から前記ウェブサービスに係る利用関連情報の入力を受け付ける入力受付ステップをさらに有し、
   利用関連情報出力ステップは、前記受け付けた利用関連情報を、入力受付ルールに基づいて出力する適合処理サブステップをさらに有する請求項１又は２に記載のサービス利用支援方法。
3. 利用関連情報出力ステップは、サービスサーバが予定する決済処理を前記トークンを用いて実行可能な態様にて実行させるための決済制御情報をも出力する決済制御情報出力サブステップをさらに有する請求項１から３のいずれか一に記載のサービス利用支援方法。
4. 所定のウェブサービスを提供するサーバであるサービスサーバと、当該ウェブサービスを利用する利用者端末と、当該ウェブサービスに関連した決済代行処理を行うサーバである決済代行処理サーバと、の間でそれぞれ情報の送受信をコンピュータに実行させるサービス利用支援プログラムであって、
   利用者端末からのウェブサービス利用に関する決済要求を受信する決済要求受信ステップと、
   受信した決済要求に応じて、利用者端末に対し、決済代行処理サーバに対するトークン発行要求を送信させる発行要求ステップと、
   前記発行要求に対応したトークンを取得するトークン取得ステップと、
   取得したトークンとともに、サービスサーバに対し、前記決済要求に応じたサービス利用に関連する情報である利用関連情報を出力する利用関連情報出力ステップと、
   サービスサーバより前記利用関連情報に対応する決済結果を取得する決済結果取得ステップと、
   前記取得した決済結果に応じたメッセージを前記利用者端末宛に出力するメッセージ出力ステップと、
   をコンピュータに実行させるサービス利用支援プログラム。
5. 所定のウェブサービスを提供するサーバであるサービスサーバと、当該ウェブサービスを利用する利用者端末と、当該ウェブサービスに関連した決済代行処理を行うサーバである決済代行処理サーバと、の間でそれぞれ情報の送受信を行うサービス利用支援システムであって、
   利用者端末からのウェブサービス利用に関する決済要求を受信する決済要求受信部と、
   受信した決済要求に応じて、利用者端末に対し、決済代行処理サーバに対するトークン発行要求を送信させる発行要求部と、
   前記発行要求に対応したトークンを取得するトークン取得部と、
   取得したトークンとともに、サービスサーバに対し、前記決済要求に応じたサービス利用に関連する情報である利用関連情報を出力する利用関連情報出力部と、
   サービスサーバより前記利用関連情報に対応する決済結果を取得する決済結果取得部と、
   前記取得した決済結果に応じたメッセージを前記利用者端末宛に出力するメッセージ出力部と、
   を備えるサービス利用支援システム。
   
   
   

Images