JP6680946B2 - 発注処理方法及び装置 - Google Patents

Description

本出願は、２０１６年４月１８日付けで出願されると共に「Order Processing Method and Device」という名称を有する中国特許出願第 201610239677.X 号の優先権を主張するものであり、この特許文献の内容のすべては、引用により、そのすべてが本明細書に包含される。

本出願は、オンライン支払技術の分野に属し、且つ、更に詳しくは、発注処理方法及び装置に属する。

インターネット技術の持続的な発展に伴って、人々は、オンラインショッピング、オンラインナビゲーション、オンラインサーチ、及びオンライン登録などのような、生活の基本的な需要を充足するべく、益々、インターネットを使用するようになっている。オンラインショッピングは、特に、人々が購入を実施するための益々重要な方法となっている。

オンライン支払を実施する際に、人々は、一般に、支払を実行するべくクレジットカード又は第三者支払機関を使用している。通常、これらの支払モードは、支払が、国内におけるものである際には、即ち、国の内部において実施される際には、相対的に簡単であるが、国境を跨いだ電子商取引においては、特定の問題が生じる可能性がある。その理由は、国境を跨いだ電子商取引においては、ユーザが、支払を実施するべくブラウザを使用している場合には、しばしば、支払が実施されたことを供給側に通知するべく、ブラウザのリダイレクトを使用する必要があるからである。ユーザが、支払を実施した後に、ブラウザを閉じた場合には、供給側は、ユーザが支払を完了しているという情報を知る方法を有しておらず、且つ、これらの状況下においては、供給側は、供給しないことになる。

この状況においては、ユーザは、払戻し要求を能動的に開始する必要があり、その時点において、供給側は、検討及び確認を実施する。供給側が検討及び確認を実行した後にのみ、第三者支払機関は、払戻しを実行するように、通知されることになる。払戻しの検討サイクルは、非常に長く、且つ、払戻し要求のフローは、かなり複雑である。

この問題に対する有効な解決策に依然として対処しなければならない。

本出願の目的は、ユーザが発注について支払ったが、供給に失敗した後に、迅速且つ簡単にユーザに払い戻すことを可能にし、これにより、ユーザ経験を改善する、発注処理方法及び装置を提供するというものである。

本出願によって提供される発注処理方法及び装置は、以下のように実現することができる。

発注処理方法であって、方法は、
第三者支払機関により、支払われたが、供給機関によって正常に供給されていない発注を取得するステップと、
第三者支払機関により、供給に失敗した支払済みの発注の払戻し動作を能動的に開始するステップと、
を有する。

第三者支払機関内において配設される発注処理装置であって、装置は、
支払われたが、供給機関によって正常に供給されていない発注を取得するように構成された取得モジュールと、
供給に失敗した支払済みの発注の払戻し動作を能動的に開始するように構成された払戻しモジュールと、
を有する。

本出願によって提供される発注処理方法及び装置は、支払済みの発注が供給されたかどうかについてクエリするべく、第三者支払機関による能動的なトリガを使用することができる。供給されていない支払済みの発注の場合に、第三者支払機関は、払戻し動作を能動的にトリガすることにより、払戻しを必要としている発注を迅速に払い戻すことを可能にし、これにより、現時点の技術における過度に複雑な発注払戻しのフロー及び長期にわたる払戻しサイクルという技術的問題を解決し、これにより、払戻しサイクルを効果的に短縮し、その結果、ユーザ経験を改善するという技術的効果を実現している。

本出願の実施形態における又は現時点の技術における技術的方式について更に明瞭に説明するために、実施形態又は現時点の技術について説明するべく必要とされる添付図面について、以下のとおり、簡潔に説明する。以下の説明における添付図面は、本出願において記録されているいくつかの実施形態であるに過ぎないことが明らかである。当業者は、創造的な努力を費やすことなしに、これらの添付図面に基づいて、その他の添付図面を入手することができる。

図１は、本出願によって提供される発注処理方法の一実施形態の方法フロー図である。 図２は、本出願における既存のチケットのやり取りフロー図である。 図３は、本出願における既存の国境を跨いだチケットのやり取りフロー図である。 図４は、本出願における既存の国境を跨いだチケットの別のやり取りフロー図である。 図５は、本出願によって提供される国境を跨いだチケットのやり取りフロー図である。 図６は、本出願によって提供される発注処理装置の構造ブロック図である。

当業者が本出願の技術的方式について更に十分に理解することができるように、本出願の実施形態の添付図面との組合せにおいて、本出願の実施形態における技術的方式について、以下の通り、明瞭且つ広範に説明する。当然のことながら、記述されている実施形態は、本出願の実施形態の、すべてではなく、いくつかであるに過ぎない。本出願の実施形態に基づいて、且つ、創造的な努力を実施することなしに、当業者によって入手可能なすべてのその他の実施形態は、本出願の保護の範囲に含まれるものとする。

添付図面との関連において、以下は、本出願の発注処理方法及び装置の詳細な説明である。図１は、本出願によって提示される発注処理方法の一実施形態の方法フロー図である。本出願は、後述する実施形態又は添付図面の方法動作ステップ又は装置構造を提供しているが、従来の又は非創造的な努力に基づいて、方法又は装置は、更に多くの数の又は少ない数の動作ステップ又はモジュール構造を有することができる。論理的に必要とされる因果関係が存在していないステップ又は構造においては、ステップの実装シーケンス又は装置のモジュール構造は、本出願の実施形態によって提供されている実装シーケンス又はモジュール構造に限定されるものではない。方法又はモジュール構造の装置又は最終製品の実際の実装の際には、実施形態又は添付図面において示されている方法又はモジュール構造接続に従って、逐次的な実装又は（例えば、並列プロセッサ又はマルチスレッド処理環境などの）並行的な実装が可能である。

本出願は、ユーザが外国航空会社からプレーンチケットを購入するという方式を採用しており、且つ、顧客による払戻し要求を待った後にのみ一連の複雑な払戻し動作を実行することなしに、ユーザによる支払後の特定の誤った動作に起因して正常な供給を不可能にする傾向を有するようなシナリオにおける払戻しを能動的に実行している。払戻しが、第三者支払構造によって能動的に実施されていることから、払戻し動作を迅速且つ簡単に実装することができる。例えば、状態の取得及び解釈システムを第三者支払機関内において追加することにより、第三者支払機関は、供給を伴うことなしに支払が実施されている状況を即座に発見することができる。当然のことながら、本出願は、ユーザが外国の航空会社からプレーンチケットを購入している状況のみならず、その他のオンライン支払状況にも適用することができる。

例えば、図１に示されているように、本出願によって提供される発注処理方法の一実施形態は、以下のステップを有することができる。

Ｓ１：第三者支払機関により、支払われたが、供給機関によって正常に供給されていない発注を取得する。

即ち、ユーザが支払を完了した後に、第三者支払機関は、ユーザが払戻しの申し込みをする時点まで供給の失敗を発見しない代わりに、供給に成功したかどうかを能動的に判定している。例えば、（例えば、１時間などの）それぞれの予め設定された時間インターバルにおいて、第三者支払機関は、この時間インターバルにおけるすべての支払指示を取得することが可能であり、且つ、次いで、これらの支払指示が、正常に供給されたかどうかを一つずつ判定することができる。又、タイムスタンプが、すべての正常に支払われた発注について構成されてもよく、次いで、この発注が支払われた後の（例えば、３０分などの）予め設定された時間の後に、この発注が供給されているかどうかを判定することができる。例えば、発注Ａが午前８：００において支払われたとすれば、午前８：３０において、第三者支払機関は、発注Ａが供給されているかどうかを能動的に判定することができる。

但し、二つの先行する判定メカニズムは、本発明について更に十分に説明するためのものに過ぎないことに留意するのは有益である。例えば、これらの二つのモードを組み合わせた、或いは、異なる発注ごとに異なる予め設定された時間を構成する、モードなどの、その他のトリガメカニズムを利用することにより、判定を実施することもできる。

国境を跨いだ電子商取引の持続的な発展に伴って、国内ユーザに対するプレーンチケットの販売を実施するべく、益々多くの外国航空会社がオンライン支払モードを使用している。オンラインプレーンチケット販売サービスを実施する際に、外国航空会社は、一般に、クレジットカードを支払及び決済ツールとして使用しているユーザ及び航空会社と関連した高費用を引き下げるべく、ＵＡＴＰ（Universal Air Travel Plan）とリンクアップすることを選択している。ＵＡＴＰは、グローバルな航空会社によって共有されているビジネス旅行支払ネットワークである。ＵＡＴＰカードは、世界中の航空会社によって発行されており、且つ、これは、航空会社によってそのビジネス顧客に提供される低費用の支払方式である。ＵＡＴＰは、その航空会社に対して無料のサービスを約束している。以下においては、プレーンチケットの国境を跨いだ購入が実施される際の一例として、能動的な払戻しフローを使用することにより、説明しているが、その前に、国境を跨いだプレーンチケットの購入における既存のチケット及び払戻しのフローについて説明する。

図２に示されているように、海外ユーザが、ＵＡＴＰにリンクされた航空会社からプレーンチケットの外国購入を実施するフローは、主には、ユーザがプレーンチケットを選択した後に、海外航空会社が、プレーンチケットの金額を生成し、且つ、カードの有効化を実行するようにＵＡＴＰに対して要求し、ＵＡＴＰが、仮想ＵＡＴＰカードを生成し、現時点の支払のための事前認可を実施し、且つ、有効化の結果を海外航空会社に返す、というステップを有する。海外航空会社は、ユーザを支払ページまでガイドするべく、ブラウザページを使用している。ユーザは、支払を完了させるべく、クレジットカードを選択し、次いで、ユーザのクレジットカードの事前認可が、海外ユーザのカード発行銀行によって実施される。ＵＡＴＰは、仮想カードの事前認可確認を実行する。次いで、海外ユーザのカード発行銀行は、クレジットカード事前認可確認を海外航空会社に返し、次いで、海外航空会社が、チケットを発行し、且つ、正常なチケットの発行についてユーザに通知する。

但し、上述の国境を跨いだオンラインチケット購入の際には、支払フローの全体に関与する様々な機関の間のやり取りは、ブラウザページのリダイレクトモードを通じて実施されている。この結果、問題をもたらされる可能性がある。例えば、図２のステップ２．３におけるユーザによる支払が成功したが、ユーザが不注意によってブラウザを閉じた場合には、航空会社は、必然的に、ユーザの成功した支払動作の検出に失敗することになり、この場合には、海外航空会社は、チケットを発行することを選択しなくなる。このシナリオが海外におけるものである際には、即ち、ユーザが海外ユーザである際には、事前認可の取消費用が非常に小さく、その理由は、ユーザがクレジットカードによる支払を利用しているからであり、海外ユーザは、発行銀行を直接的に呼び出すことにより、事前認可を即座に取り消し、これにより、チケットが発行されることなしに、支払の問題を解決することができる。但し、外国航空会社がビジネスを国内において実施している際には、外国航空会社は、第三者支払機関とリンクアップしており、且つ、第三者支払機関がカードの発行銀行でない際には、ユーザが払戻しを実施することが極めて困難である。海外航空会社に対して要求する必要がある。その後に、海外航空会社は、第三者支払機関の払戻しを開始することになる。フローが、複雑であり、且つ、サイクルが、極めて長い。

支払が国内の第三者支払機関を通じて実施される状況においては、図３に示されているように、仮想ＵＡＴＰカードの有効化及びこれに類似したものなどのフローは、ユーザの支払の後に始まっている。次いで、仮想ＵＡＴＰカードの有効化の後に、チケットが海外航空会社を通じて発行される。これらの状況における支払フローにおいては、航空会社が第三者支払機関とリンクした際に、情報通知は、依然として、ブラウザに基づいたページのリダイレクトモードを利用することによって実施されている。ユーザが正常な支払の後にブラウザを閉じるという問題点が存続しており、その結果、支払の結果について航空会社に通知することが不可能となる。又、ユーザが支払の後にプレーンチケットを取得できないという状況も生じ得る。これを目的として、第三者支払機関は、図４に示されているように、海外航空会社の支払要求方式を提示している。ユーザの正常な支払が判明した後に、海外航空会社は、現時点の仮想ＵＡＴＰカードが、事前認可の確認を実現しているかどうかについてＵＡＴＰと協議している。事前認可確認を実現している場合には、海外航空会社は、チケットを発行する、即ち、海外航空会社が、それ自体で、支払要求をトリガすることになる。

但し、これらの動作によっても、ユーザがブラウザを閉じるという問題点は、依然として発生し、その結果、支払結果についての航空会社への通知の失敗をもたらし得る。その理由は、ユーザがブラウザを閉じた後に、海外航空会社は、仮想ＵＡＴＰカードのカード番号を取得する方法を有しておらず、従って、海外航空会社が支払要求を能動的に実施する際に、この取引の支払を要求することができないからである。従って、所与の時間限度が経過した場合に、第三者支払会社は、プレーンチケットを受け取っていないユーザに対して支払金額を払い戻すことができるが、全体的なフローが、有効期限に依存している。通常、この有効期限は、ユーザが、払戻しを取得する前に、７日間にわたって待たなければならないように、例えば、７日間などのように、合理的に設定されており、従って、ユーザ経験が極めて乏しい。

この例によって提供されている発注処理方法が利用された場合には、仮想カードの有効化及びユーザの支払結果は、第三者支払機関内において実行され、且つ、第三者支払機関が知ることができる。このケースにおいて、ユーザが、支払を実施した後に、ブラウザを閉じた、且つ、従って、チケットの発行を妨げた、場合には、第三者支払機関は、仮想ＵＡＴＰカードについてＵＡＴＰ内の海外航空会社によって実施された事前認可確認の結果を能動的に判定することができる。ユーザが第三者支払機関内において支払を実施したが、ＵＡＴＰからの第三者支払機関によって協議される仮想カードの状態が、確認済みの事前認可状態ではない場合には、それは、誤ったユーザ動作が、海外航空会社がＵＡＴＰにおいて事前認可を確認することに失敗するという結果をもたらしたことを意味している。又、これは、航空会社がチケットを発行していないことをも意味している。このような際には、第三者支払機関は、ユーザに対する払戻しを能動的に開始することが可能であり、且つ、払戻し動作を実行するために支払要求を待つ必要がない。払戻しサイクルの全体を非常に短縮することができる。例えば、第三者支払機関用の確認規則を設定することができる。一例として、確認を実施するべく、以下の二つのモードを利用することができる。

１）第三者支払機関は、（例えば、１時間などの）予め設定された時間インターバルごとに、予め設定された時間における一つ又は複数の発注について実施された、但し、仮想ＵＡＴＰカード状態として未確認の事前認可状態を有する、支払についてＵＡＴＰに対してクエリする。第三者支払機関は、予め設定された時間内において支払われたが、未確認の事前認可という仮想ＵＡＴＰカード状態を有する、これらの一つ又は複数の発注を供給機関による供給に失敗した支払済みの発注として使用する。即ち、時間サイクルが設定され、且つ、これらの時間サイクルのそれぞれごとに、第三者支払機関は、中央集中化された確認を実施し、これにより、これらの発注の中から、払戻しを必要としている発注として使用されるべく、支払われているが、確認済みの状態に入っていないものを見出する。

２）第三者支払機関は、現時点の発注の正常な支払以降の時間が、第二の予め設定された時間に到達しているかどうかを判定する。第二の予め設定された時間に到達している場合には、第三者支払機関は、現時点の発注の仮想ＵＡＴＰカード状態が、確認済みの事前認可状態であるかどうかについてＵＡＴＰに対してクエリし、それが、未確認の事前認可状態である場合には、第三者支払機関は、現時点の発注を供給機関による供給に失敗した支払済みの発注として使用する。即ち、支払猶予期間が、すべての発注ごとに設定される。支払猶予期間が満了した際に、この発注が、支払われたが、供給されていない発注であるかどうかが判定される。「はい」である場合に、この発注は、払戻しを必要としている発注として使用される。

Ｓ２：第三者支払機関により、供給に失敗した支払済みの発注の払戻し動作を能動的に開始する。

即ち、支払機関は、ユーザに対する払戻しを能動的に実行しており、その理由は、これが、第三者支払機関によって能動的にトリガされる判定動作であるからである。この結果、供給側が払戻しをトリガすることを待つ必要なしに、これらの発注が払戻しを必要としているという確認の後に、払戻しを直接的に処理することが可能であり、これにより、払戻し効率を効果的に向上させることができる。

例えば、実装の際には、払戻しは、発注ユーザの第三者支払機関の口座において直接的に実施することも可能であり、発注ユーザのバンドルされた銀行カードに返すことも可能であり、或いは、異なる支払金額の支払者に返すこともできる。払戻しが実施される具体的な場所を具体的に指定することができる。

例えば、（１時間以内の）予め設定された時点において、第三者支払機関は、以下の発注についてクエリする。それぞれの対応する事前認可確認状態は、以下の表に示されているとおりである。

この表は、GH89023 という発注は、支払済みの、但し、未確認の、状態を有しており、これは、これが、誤ったユーザ動作を伴う発注であり、且つ、払戻し動作を必要としている、ことを通知している。この時点で、第三者支払機関は、この発注を必要に応じて払い戻すことができる。

上述の方法を使用することにより、ユーザが支払を実施した後に、誤った動作が、ブラウザが閉じられることに、且つ、リダイレクトを実施できないことに、結び付いた場合に、第三者支払機関の払戻しを短期間において受け取ることが可能であり、且つ、払戻しの理由についてユーザに通知することが可能であり、これにより、ユーザ経験が事実上改善される。

以下は、詳細な実施形態との組合せにおける全体的な発注フローの説明である。この実施形態においては、国内ユーザが、海外航空会社からのプレーンチケットの国境を跨いだ購入を実施するべく、第三者支払機関を使用している例が、一例として使用されている。但し、この詳細な実施形態は、本発明を更に十分に説明するためのものであるに過ぎず、且つ、これは、本発明に対する不適切な限定を構成するものではないことに留意することが有益である。

図４の現時点の国境を跨いだプレーンチケットの処理モードによれば、プレーンチケットの国境を跨いだ購入における既存のユーザ払戻しプロセスにおいては、ユーザの払戻し動作は、航空会社の支払要求に依存しており、且つ、払戻しの主導権は、海外航空会社にある。この例においては、払戻しの主導権が国内第三者支払機関に移されている。ＵＡＴＰカードの事前認可確認状態を能動的に協議することにより、第三者支払機関は、決定を実施し、且つ、ユーザ用の払戻し動作を実行するかどうかを判定している。この払戻しの主導権の移動は、払戻し効率を事実上向上させることができる。

具体的には、この例においては、全体的な発注処理プロセスは、図５に示されているように、以下のステップを含むことができる。

ステップ１：国内ユーザは、海外航空会社のウェブサイトに進み、且つ、プレーンチケットを選択する。

ステップ１．１：海外航空会社は、プレーンチケット情報を記録する。

ステップ１．２：海外航空会社は、ユーザを支払ページまでガイドする。

ステップ２：国内ユーザは、支払のための第三者支払機関を選択する。

ステップ２．１：第三者支払機関は、ユーザの支払を完了させる。

ステップ２．２：第三者支払機関は、仮想ＵＡＴＰカードを生成し、且つ、有効化を要求する。

ステップ２．３：国内第三者支払機関は、ＵＡＴＰ仮想カードの有効化のためにＵＡＴＰに進む。

ステップ２．３．１：ＵＡＴＰは、有効化の成功結果を第三者支払機関に返す。

ステップ２．３．１．１：第三者支払機関は、料金の引き落としに成功したことを国内ユーザに通知する。

ステップ２．３．１．１．１：ユーザは、ブラウザを閉じ、且つ、海外航空会社は、ユーザが支払ったことを知ることができず、且つ、事前認可確認を実施することもできず、従って、海外航空会社は、チケットを発行することができない。

ステップ３：第三者支払機関は、１時間以内にユーザによって支払われたプレーンチケットと、仮想ＵＡＴＰカード番号と、に関する情報を取得する。

ステップ４：ＵＡＴＰにおいて、第三者支払機関は、仮想カードの事前認可状態についてクエリし、且つ、仮想カードが事前認可確認を経験したかどうかを判定する。

ステップ５：現時点の正常に支払われたプレーンチケットの仮想ＵＡＴＰカードが事前認可確認を経験していない場合に、払戻しが処理される。

ステップ６：第三者支払機関が払戻しをユーザに対して実施する。

上述の例は、第三者支払機関が、予め設定された時間インターバル内のすべての発注の確認についてクエリすることを示している。実際の一実装形態においては、中央集中化された方式を利用するのではなく、それぞれの発注ごとに別個の確認クエリを実施することができる。ニーズに従って、具体的な処理モードを判定することができる。

更には、先行する例においては、プレーンチケットの国境を跨いだ購入を実施するユーザが、例として使用されていることに留意されたい。又、払戻しが必要とされているかどうかに関する第三者支払機関によるこのタイプの能動的な確認は、その他の支払状況に適用することもできる。予め設定されたモードに従って確認を実施するためのプロトコル又は規則が存在している限り、このタイプの発注処理モードは、払戻し動作を単純化するべく、且つ、ユーザが払戻しを相対的に迅速に取得することを可能にするべく、任意の支払フローに対して適用することができる。

又、同一の発明概念に基づいて、本発明の実施形態は、以下の実施形態において記述されているように、発注処理装置をも提供している。発注処理装置の解決策の原理は、発注処理方法に類似していることから、発注処理装置の実装形態については、発注処理方法の実装形態を参照することが可能であり、従って、その重複する態様についての説明は、省略することとする。以下において使用されている「要素」又は「モジュール」という用語は、予め設定された機能を実現し得るソフトウェア及び／又はハードウェアの組合せである。又、記述されている装置は、以下の実施形態においては、ソフトウェアを通じて実装することが好ましいが、ハードウェア或いはソフトウェアとハードウェアとの組合せを通じた実装形態を想定することもできる。図６は、本発明の一実施形態の発注処理装置の構造ブロック図である。この発注処理装置は、第三者支払機関内において配置される。図６に示されているように、この発注処理装置は、取得モジュール６０１と、払戻しモジュール６０２と、を有することができる。以下、この構造について説明する。

取得モジュール６０１は、供給機関による供給に失敗した支払済みの発注を取得するように構成することができる。

払戻しモジュール６０２は、供給に失敗した支払済みの発注の払戻し動作を能動的に開始するように構成することができる。

一実装方式においては、供給機関は、外国航空会社を有することが可能であり、且つ、供給機関による供給は、供給機関によるチケットの発行を有することができる。

一実装方式においては、取得モジュール６０１は、支払われているが、供給機関によって正常に供給されていない、発注を取得するべく、ＵＡＴＰを通じて支払済みの発注の仮想ＵＡＴＰカード状態についてクエリするように構成することができる。

一実装方式においては、取得モジュールは、第一の予め設定された時間のそれぞれのインターバルにおいて、ＵＡＴＰを通じて、第一の予め設定された時間内において支払われたが、未確認の事前認可という仮想ＵＡＴＰカード状態を有する、一つ又は複数の発注についてクエリするように構成された第一クエリ要素と、第一の予め設定された時間内において支払われたが、未確認の事前認可という仮想ＵＡＴＰカード状態を有する一つ又は複数の発注を、支払われたが、供給機関によって正常に供給されていない発注として、使用するように構成された第一判定要素と、を有することができる。

一実装方式においては、取得モジュール６０１は、現時点の発注が正常に支払われた以降の時間が、第二の予め設定された時間に到達したかどうかを判定するように構成することができる判定要素と、第二の予め設定された時間に到達していると判定された場合に、ＵＡＴＰを通じて、現時点の発注の仮想ＵＡＴＰカード状態が、未確認の事前認可状態であるかどうかについてクエリするように構成することができる第二クエリ要素と、現時点の発注の仮想ＵＡＴＰカード状態が、未確認の事前認可状態であると判定された場合に、支払われたが、供給機関によって正常に供給されていない、発注として現時点の発注を使用するように構成することができる第二判定要素と、を有することができる。

一実装方式においては、異なる発注は、異なる長さを有する第二の予め設定された時間に対応している。

一実装方式においては、供給機関は、支払済みの発注の供給動作を実行するべく、ブラウザのリダイレクトを使用している。

本出願によって提供される発注処理方法及び装置は、支払済みの発注が供給されたかどうかについてクエリするべく、第三者支払機関による能動的なトリガを使用している。供給されていない支払済みの発注の場合には、第三者支払機関は、払戻し動作を能動的にトリガし、これにより、払戻しを必要としている発注を迅速に払い戻すことを可能にすると共に、現時点の技術における過度に複雑な発注払戻しフロー及び長い払戻しサイクルという技術的問題点を解決している。この結果、払戻しサイクルを効果的に短縮すると共にユーザ経験を改善するという技術的効果が実現される。

本出願の詳細は、国境を跨いだプレーンチケットの発注処理フローを例として使用しているが、本出願は、その他の発注処理プロセスにも適用することが可能であり、且つ、これにのみ限定されるものではない。実際の適用プロセスにおいては、発注を処理するべく言及されているモードに完全に従う、という制限は、存在していない。本出願の実施形態に関係している説明は、本出願の特定の実施形態におけるいくつかの適用形態であるに過ぎない。又、特定の規格、モデル、及び方法に基づいてわずかに変更された実装方式も、本出願の実施形態の方式を実行することができる。当然のことながら、本出願の実施形態の処理方法ステップのその他の非創造的な変形に準拠しつつ、同一の用途を実現することが可能であり、これらの非創造的な変形の詳細についての説明は、省略することとする。

本出願は、実施形態又はフロー図において提示されている方法動作ステップを提供しているが、従来の又は非創造的な努力に基づいて、更に多くの数の又は少ない数の動作ステップを含むことができる。一実施形態において一例として付与されているステップシーケンスは、様々なステップ実行シーケンスの一つであるに過ぎず、且つ、唯一の実行シーケンスを表すものではない。装置又は顧客最終製品の実際の実装の際には、実施形態又は添付図面において示されている方法に従って、逐次的な実装又は（例えば、並列プロセッサ又はマルチスレッド処理環境などの）並行的な実装が可能である。

先行する実施形態において示されている装置又はモジュールは、コンピュータチップ又はエンティティにより、或いは、特定の機能を処理する製品により、実現することができる。利便を目的として、先行する装置について記述する際に、機能は、異なるモジュールに分割されるものとして、別個に記述されている。本出願を実装する際には、それぞれのモジュールの機能は、同一の又は複数のソフトウェア及び／又はハードウェアユニットとして実現することができる。当然のことながら、特定の機能を実現するモジュールは、複数のサブモジュール又はサブ要素の組合せを通じて実現することができる。

本出願における方法、装置、又はモジュールは、任意の適切な手段によって実現されたコンピュータ可読プログラムコードモードを通じて、コントローラにより、実装することができる。例えば、マイクロプロセッサ又はプロセッサをコントローラとして採用することが可能であり、且つ、メモリは、コンピュータ可読媒体、論理ゲート、スイッチ、用途固有の集積回路（ＡＳＩＣ：Application Specific Integrated Circuit）、プログラム可能な論理コントローラ、或いは、その（マイクロ）プロセッサによって実行されるコンピュータ可読プログラムコード（例えば、ソフトウェア又はファームウェア）の組込み型のマイクロコントローラの形態を有することができる。コントローラの例は、限定を伴うことなしに、ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20、及び Silicone Labs C8051F320 というマイクロコントローラを含む。又、メモリコントローラは、メモリの制御論理部分として実現することもできる。当業者は、コントローラを実装するための純粋なコンピュータ可読プログラムコードを使用することに加えて、コントローラが、論理ゲート、スイッチ、用途固有の集積回路、プログラム可能な論理コントローラ、又は組込み型のマイクロプロセッサの形態において、同一の機能を実現することを可能にするべく、方法ステップ用の論理プログラミングを使用することも完全に可能であることを知ることになろう。従って、このタイプのコントローラは、一つのタイプのハードウェアユニットとして見なされてもよく、且つ、様々な機能を実現するべく使用されるその含まれている装置も、ハードウェアユニット内の一構造として見なすことができる。或いは、場合によっては、様々な機能を実現するべく使用されている装置は、方法を実装するためのソフトウェアモジュールのみならず、ハードウェアユニット内の一構造として見なすこともできる。

本出願の装置内のモジュールのいくつかは、プログラムモジュールなどの、コンピュータによって実行されるコンピュータ実行可能命令の一般的な文脈において記述することができる。一般に、プログラムモジュールは、特定のタスクを実行するための、或いは、特定のデータ抽象化を実現するための、ルーチン、プログラム、オブジェクト、コンポーネント、及びデータ構造などを有する。又、本出願は、分散演算環境において実装することもできる。これらの分散演算環境においては、タスクの実行のために、通信ネットワークを通じて接続されたリモート処理装置が使用されている。分散演算環境においては、プログラムモジュールは、ストレージ装置を含むことにより、ローカルに配置することも可能であり、且つ、リモートコンピュータストレージ媒体内において配置することもできる。

先行する実装方式の説明によれば、本出願が、ソフトウェア及び必要なハードウェアモードの支援により、実現され得ることを当業者が明瞭に理解し得ることが明らかである。このような理解に基づいて、本出願の技術的方式の、或いは、現時点の技術に寄与する部分の、本質は、ソフトウェア製品の形態において実装されてもよく、且つ、データマイグレーション実装プロセスを通じて実装されてもよい。このコンピュータソフトウェアプロダクトは、ＲＯＭ／ＲＡＭ、磁気ディスク、又は光ディスクなどの、ストレージ媒体内において保存されてもよく、且つ、コンピュータ装置（パーソナルコンピュータ、モバイル端末、サーバ、又はネットワーク装置であってもよい）が、本出願の、実施形態の方法、又は実施形態の特定の一部分、を実行するようにするべく、いくつかの命令を含むこともできる。

この「発明を実施するための形態」の節における別個の実施形態は、漸進的に記述されており、且つ、実施形態は、その同一又は類似の部分との関連おいて相互に参照することができる。それぞれの実施形態の説明は、その他の実施形態とは異なる方式に合焦している。本出願は、全体として又は部分的に、例えば、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド型装置又は携帯型装置、タブレット装置、モバイル通信端末、マルチプロセッサシステム、マイクロプロセッサに基づいたシステム、プログラム可能な電子装置、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、並びに、これらのシステム又は装置のいずれかを有する分散演算環境などのような、多数の汎用又は特殊目的コンピュータシステム環境又は構成において使用することができる。

本出願を説明するべく、実施形態が使用されているが、当業者は、本出願は、本出願の精神を逸脱しない、いくつかの変形及び変更を有することを知ることになろう。添付の特許請求の範囲は、本出願の精神を逸脱しない、これらの変形及び変更を含むことが求められている。

Claims (11)

1. 発注処理方法であって、
   支払機関コンピュータ装置が、供給機関コンピュータ装置で発注を実施するユーザのための支払取引を完了させるステップであって、前記供給機関コンピュータ装置は、支払取引完了から発注供給までリダイレクトするためにブラウザリダイレクトを使用し、前記ユーザのブラウザは、前記支払機関コンピュータ装置が前記支払取引を正常に完了させた後、前記発注供給にリダイレクトすることから妨げられる、ステップと、
   前記支払機関コンピュータ装置が、仮想カード支払ネットワークを通じて仮想カードを生成し且つ有効化するステップと、
   前記支払機関コンピュータ装置が、前記仮想カード支払ネットワークを通じて、支払済みの発注の仮想カード状態についてクエリするステップと、
   前記支払済みの発注が、前記供給機関コンピュータ装置によって正常に供給されていないと判定したことに応答して、前記支払機関コンピュータ装置が、支払われたが、前記供給機関コンピュータ装置によって正常に供給されていない前記発注を取得するステップと、
   前記支払機関コンピュータ装置が、供給に失敗した支払済みの発注の払戻し動作を開始するステップと、
   を具備する方法。
2. 前記供給機関は、外国航空会社を具備し、且つ、前記供給機関コンピュータ装置の供給は、チケットの発行を具備する、請求項１に記載の方法。
3. 前記仮想カードは、仮想ＵＡＴＰ（Universal Air Travel Plan）カードを具備し、前記仮想カード支払ネットワークは、仮想ＵＡＴＰカードネットワークを具備する、請求項２に記載の方法。
4. 前記支払機関コンピュータ装置が、前記仮想カード支払ネットワークを通じて、前記支払済みの発注の仮想カード状態についてクエリする前記ステップは、
   第一の予め設定された時間のそれぞれのインターバルにおいて、前記支払機関コンピュータ装置が、前記仮想ＵＡＴＰカードネットワークを通じて、前記第一の予め設定された時間内において支払われたが、未確認の事前認可という仮想ＵＡＴＰカード状態を有する、一つ又は複数の発注についてクエリするステップと、
   前記支払機関コンピュータ装置が、前記第一の予め設定された時間内において支払われたが、前記未確認の事前認可という前記仮想ＵＡＴＰカード状態を有する前記一つ又は複数の発注を、支払われたが、前記供給機関コンピュータ装置によって正常に供給されていない、前記発注として、使用するステップと、
   を具備する、請求項３に記載の方法。
5. 前記支払機関コンピュータ装置が、前記仮想カード支払ネットワークを通じて、前記支払済みの発注の仮想カード状態についてクエリする前記ステップは、
   前記支払機関コンピュータ装置が、現時点の発注が正常に支払われた以降の時間が、第二の予め設定された時間に到達したかどうかを判定するステップと、
   前記第二の予め設定された時間に到達している場合に、仮想ＵＡＴＰカード状態を通じて、前記支払機関コンピュータ装置が、前記現時点の発注の仮想ＵＡＴＰカード状態が未確認の事前認可状態であるかどうかについてクエリするステップと、
   前記現時点の発注の前記仮想ＵＡＴＰカード状態が前記未確認の事前認可状態である場合に、前記支払機関コンピュータ装置が、前記現時点の発注を、支払われたが、前記供給機関コンピュータ装置によって正常に供給されていない、前記発注として、使用するステップと、
   を具備する、請求項３に記載の方法。
6. 異なる発注は、異なる長さの第二の予め設定された時間に対応する、請求項５に記載の方法。
7. 支払機関内において配設される発注処理装置であって、前記装置は少なくともプロセッサと該プロセッサによって実行される命令を収容するメモリとを有し、モジュール及び要素が該プロセッサ及びメモリを通して実現され、前記装置は、
   取得モジュールであって、
   供給機関コンピュータ装置で発注を実施するユーザのための支払取引を完了させ、前記供給機関コンピュータ装置は、支払取引完了から発注供給までリダイレクトするためにブラウザリダイレクトを使用し、前記ユーザのブラウザは、支払機関コンピュータ装置が前記支払取引を正常に完了させた後、前記発注供給にリダイレクトすることから妨げられ、
   仮想カード支払ネットワークを通じて仮想カードを生成し且つ有効化し、
   前記仮想カード支払ネットワークを通じて、支払済みの発注の仮想カード状態についてクエリし、
   前記支払済みの発注が、前記供給機関コンピュータ装置によって正常に供給されていないと判定したことに応答して、支払われたが、前記供給機関コンピュータ装置によって正常に供給されていない前記発注を取得する、
   ように構成された取得モジュールと、
   供給に失敗した支払済みの発注の払戻し動作を開始するように構成された払戻しモジュールと、
   を具備する装置。
8. 前記供給機関は、外国航空会社を具備し、且つ、前記供給機関コンピュータ装置の供給は、チケットの発行を具備する、請求項７に記載の装置。
9. 前記仮想カードは、仮想ＵＡＴＰ（Universal Air Travel Plan）カードを具備し、前記仮想カード支払ネットワークは、仮想ＵＡＴＰカードネットワークを具備する、請求項８に記載の装置。
10. 前記取得モジュールは、
    第一の予め設定された時間のそれぞれのインターバルにおいて、前記仮想ＵＡＴＰカードネットワークを通じて、前記第一の予め設定された時間内において支払われたが、未確認の事前認可という仮想ＵＡＴＰカード状態を有する、一つ又は複数の発注についてクエリするように構成された第一クエリ要素と、
    前記第一の予め設定された時間内において支払われたが、前記未確認の事前認可という前記仮想ＵＡＴＰカード状態を有する前記一つ又は複数の発注を、支払われたが、前記供給機関コンピュータ装置によって正常に供給されていない、前記発注として、使用するように構成された第一判定要素と、
    を具備する、請求項９に記載の装置。
11. 前記取得モジュールは、
    現時点の発注が正常に支払われた以降の時間が、第二の予め設定された時間に到達しているかどうかを判定するように構成された判定要素と、
    前記第二の予め設定された時間に到達していると判定された場合に、前記仮想ＵＡＴＰカードネットワークを通じて、前記現時点の発注の仮想ＵＡＴＰカード状態が未確認の事前認可状態であるかどうかについてクエリするように構成された第二クエリ要素と、
    前記現時点の発注の前記仮想ＵＡＴＰカード状態が未確認の事前認可状態であると判定された場合に、前記現時点の発注を、支払われたが、前記供給機関コンピュータ装置によって正常に供給されていない前記発注として、使用するように構成された第二判定要素と、
    を具備する、請求項９に記載の装置。

Images