JP2015053078A - 支払基金のためのコンピュータ可読媒体、方法及びシステム、 - Google Patents

Abstract

【課題】取扱対価物の支払に使える複数の支払元を定義でき、複数の支払元のうちの支払元を選択可能とする。【解決手段】ネットワークシステムにおいて支払いを行うための、複数の支払元及び該複数の支払元の優先度を定義する、支払明細要求を受信するステップと、支払明細要求において、ネットワークシステムを介して行われるトランザクションに対して複数のユーザーから供出される対価物の量の一部に関する割合配分を指定する支払充当法が受信されたかどうかを判定するステップと、支払明細要求において支払充当法が受信されていないと判定されたことに基づいて、複数のユーザーから供出されるデフォルトの支払充当法を識別するステップと、支払明細要求において指定された優先度に基づいて、複数の支払元のうちの少なくとも１つから、少なくとも一部の支払を行うステップと、を含む。【選択図】図１１

Description

〔関連出願〕
本出願は、2007年01月31日出願のU.S. Application Serial No. 11/700,444, 表題"METHOD AND SYSTEM FOR PAYMENT FUNDING" （この参照によりその内容は本開示に含まれる）の優先権を主張する。

〔技術分野〕
本出願は概してデータ処理分野に関し、特定の実施例においては、支払基金（payment funding）のための方法およびシステムに関する。

インターネットのユーザーは、world-wide webを使って物品を購買している。選んだ物品への支払金は、単独のユーザーがクレジットカードや他の支払元を使って払うのが普通である。ときどき、ユーザーはクーポンや割引券を換金して、支払金に充てる。

実施形態群は例として示したものであり、以下の付随する図面に限定はされない。
或る実施形態にかかる、ネットワークシステムを描いたネットワーク図であって、ネットワークを介してデータの交換を行うクライアント-サーバ構造を有している。 ネットワークに基づいたマーケットプレイス（市場）の一部として提供される、ネットワーク-マーケットプレイス・アプリケーション群についての実施形態例を描いたブロック図である。 或る実施形態例にかかる、高レベルなエンティティの関係図であって、ひとつ以上のデータベースの中で維持が可能なさまざまなテーブルを描いてある。 基金アプリケーションの実施形態例である。 或る実施形態例にかかる、ショッピングセッションを実施するための方法を示すフローチャートである。 或る実施形態例にかかる、共同的セッションを実施するための方法を示すフローチャートである。 或る実施形態例にかかる、ユーザー対話を処理するための方法を示すフローチャートである。 或る実施形態例にかかる、閲覧要求を処理するための方法を描いたフローチャートである。 或る実施形態例にかかる、ナビゲーション要求を処理するための方法を描いたフローチャートである。 或る実施形態例にかかる、ナビゲーション要求を処理するための方法を描いたフローチャートである。 或る実施形態例にかかる、実行要求を処理するための方法を描いたフローチャートである。 或る実施形態例にかかる、支払明細要求を処理するための方法を描いたフローチャートである。 或る実施形態例にかかる、共同基金（joint fund）設立要求を処理するための方法を描いたフローチャートである。 或る実施形態例にかかる、注文要求を処理するための方法を描いたフローチャートである。 或る実施形態例にかかる、完結した注文情報を処理するための方法を描いたフローチャートである。 或る実施形態例にかかる、派生的セッションを行うための方法を描いたフローチャートである。 或る実施形態例にかかる、プライベートセッション（private session） を行うための方法を描いたフローチャートである。 或る実施形態例にかかる、セッション要素の指定を行うための方法を描いたフローチャートである。 或る実施形態例にかかる、共同的セッションを行うための方法を描いたフローチャートである。 或る実施形態例にかかる、セッションの作成方法を描いたフローチャートである。 コンピュータシステムの形態例内の機械を模式的に表現したブロック図であり、このコンピュータシステム内で命令の組を実行することで、本明細書にて述べる方法のうちのひとつ以上を実施可能である。

支払基金のための方法とシステムの例を記載してゆく。以降の記載においては、あくまで説明のため、数多の具体的な詳細な特徴を、実施形態例を徹底的に理解できるように提示してある。しかしながら、これらの具体的な詳細な特徴を使わなくとも本発明は実施可能であるのは、当業者にとっては自明のことであろう。

或る実施形態例では、支払明細要求を受信できる。支払明細要求には、ネットワーク化されたシステム（ネットワークシステム）にて取扱対価物（selection of value）の支払に使える、複数の支払元を定義できる。支払充当法（payment allocation）は、複数の支払元のうちの第一の支払元を指定している支払明細要求から選択可能である。なおここでいう支払充当法とは、ネットワークシステムを使いある価格（value due）で購入される取扱対価物への支払いのために、複数のユーザーから供出される対価物の量に関する割合配分のことと考えてもらってもよい。或るユーザーアカウントを主アカウント（primary account）として指定するには、こうした支払明細要求から選択すればよい。また主アカウントが、複数の支払元のうちの第二の支払元であってもよい。主アカウントは、取扱対価物に対する価格を供出する上で最終的な責任（債務）を負うものとできる。その価格に対する支払は、第一の支払元から行うことができる。第一の支払元からの支払では、その取扱対価物に対する価格を充当できない（料金に足りない）という場合には、第二の支払元から、追加支払の処理を行ってもよい。

或る実施形態例では、ネットワークシステムの複数のユーザーのための支払元として、共同基金を選ぶこともできる。こうした共同基金にはあらかじめ、ネットワークシステムを介して複数のユーザーから供出された対価物を含めておける。ある取扱対価物に対して、ある価格にアクセス可能である。共同基金からその価格を支払う処理を行うことができる。

或る実施形態例では、支払明細要求を受信可能である。支払明細要求は、ネットワークシステムにて取扱対価物への支払に使える、複数の支払元を定義できる。複数の支払元のうちの第一の支払元として、共同基金を指定するには、支払明細要求から選択すればよい。こうした共同基金にはあらかじめ、ネットワークシステムを介して複数のユーザーから供出された対価物を含めておくことができる。複数の支払元のうちの第二の支払元を指定する支払充当法も、支払明細要求から選択しておくことができる。なおここでいう支払充当法とは、ネットワークシステムを使いある価格で購入される取扱対価物への支払にあたり、複数のユーザーから供出される対価物の量に関する割合配分のことと考えてもらってもよい。或るユーザーアカウントを主アカウントとして指定するには、こうした支払明細要求から選択すればよい。また主アカウントが、複数の支払元のうちの第三の支払元であってもよい。主アカウントは、取扱対価物に対する価格を供出する上で最終的な責任を負うものとできる。その価格に対する支払の処理は、第一の支払元から行うことができる。第一の支払元からの支払では、その取扱対価物に対する価格を充当できないという場合には、第二の支払元から、一回以上の第一の追加支払の処理を行ってもよい。あるいは、第一の支払元からの支払と第一の追加支払では、その取扱対価物に対する価格を充当できないという場合には、第三の支払元から、第二の追加支払の処理を行ってもよい。

或る実施形態例では、データベースに、複数のユーザーアカウントを含めてよい。そうした複数のユーザーアカウントのうちの各々のユーザーアカウントを、一名以上のユーザーに関連づけることができる。アプリケーションサーバには、第一のモジュールと、第二のモジュールと、第三のモジュールとを含めることができる。第一のモジュールは、支払明細要求の受信が可能なよう構成できる。支払明細要求では、ネットワークシステムでの取扱対価物への支払に使える、複数の支払元を指定できる。第二のモジュールは、支払明細要求から、複数の支払元のうちの第一の支払元を指定する支払充当法を選択するように構成できる。ここで支払充当法とは、ネットワークシステムを使うことで購入された取扱対価物への支払のために、複数のユーザーから供出された対価物の割合配分のことと考えてもらってもよい。複数のユーザーアカウントのうちから或るユーザーアカウントを主アカウントとして指定するにあたり、支払明細要求から選択するよう、第二のモジュールを構成できる。主アカウントは、複数の支払元のうちの第二の支払元であってもよい。主アカウントは、取扱対価物に対する価格を供出する上で最終的な責任を負うものとできる。第三のモジュールは、第一の支払元から価格の支払の処理を行うよう構成可能である。さらに第三のモジュールが、その第一の支払元からの支払では、取扱対価物に対する価格を充当できないという場合に、第二の支払元から、追加支払の処理を行うようにも構成可能である。

図１は、クライアント-サーバシステム100 を描いたネットワーク図であって、システム 100 内には実施形態例を配備可能である。ネットワークシステム 102 （ネットワークに基づくマーケットプレイスもしくは公示システムの一例）では、サーバ側の機能を、ネットワーク 104 （インターネットもしくはWide Area Network (WAN)）を介して、ひとつ以上のクライアントへ提供できる。図１には例えば、クライアント機 110 上で実行されているwebクライアント 106 （Washington州RedmondのMicrosoft Corporation開発のInternet Explorerブラウザなどといったブラウザなど）と、クライアント機 112 上で実行されているプログラム的クライアント 108 とが描かれている。

Application Program Interface（API）サーバ 114 およびwebサーバ 116 は、ひとつ以上のアプリケーションサーバ118 に接続しており、プログラム的インターフェイスとwebインターフェイスをそれぞれ提供している。アプリケーションサーバ 118 は、ひとつ以上のマーケットプレイス・アプリケーション 120 および支払アプリケーション 122 のホストとなっている。また示してあるように、アプリケーションサーバ 118 は、ひとつ以上のデータベースサーバ 124 に接続し、ひとつ以上のデータベース 126 へのアクセスをしやすくしている。

マーケットプレイス・アプリケーション 120 は、数多のマーケットプレイス機能とサービスを、ネットワークシステム102 にアクセスするユーザーへと提供できる。支払アプリケーション 122 も同様に、数多の支払サービスと機能をユーザーへと提供できる。支払アプリケーション 122 により、ユーザーは、アカウントに対価物（例えば、USドルなどの市場通貨や、いわゆる「ポイント」などの独自通貨といったもの）を貯めることができる。そしてその後にユーザーは、貯めた対価物を、マーケットプレイス・アプリケーション 120 を介して得られる商材（物品やサービスなど）と、交換できる。図１には、マーケットプレイス・アプリケーション 120 と支払アプリケーション 122 の双方がネットワークシステム 102 の一部をなすように描いてあるが、別の実施形態では、支払アプリケーション 122 が、ネットワークシステム 102 とは分離した別の支払サービスの一部をなしていてもよいことは理解されたい。

さらに言えば、図１のシステム100 ではクライアント-サーバ構造をとっているけれども、当然のことながら本発明はそうした構造だけに限定はされず、アプリケーションを、例えば分散型構造システムやピアツーピア（P2P）型構造システムにて同様に設定することもできると考えられる。また、種々のマーケットプレイス・アプリケーション 120 および支払アプリケーション 122 を、スタンドアローンな（ネットワーク対応機能を必要としない）ソフトウェアプログラムとして実施することも可能である。

webクライアント 106 は、webサーバ 116 がサポートするwebインターフェイスを介して、種々のマーケットプレイス・アプリケーション 120 および支払アプリケーション 122 へとアクセスする。同様に、プログラム的クライアント 108 は、APIサーバ 114 の与えるプログラム的インターフェイスを介して、マーケットプレイス・アプリケーション 120 および支払アプリケーション 122 が与える種々のサービスと機能へとアクセスする。プログラム的クライアント 108 は例えば、出品者（売り手）用アプリケーション（California州San JoseのeBay Inc.開発のアプリケーションであるTurbo Listerなど）であってよい。こうした出品者用アプリケーションにより、出品者が、ネットワークシステム 102上での出品用リスト（リスティング）の作成と管理をオフラインで行うことが可能となり、さらには、プログラム的クライアント 108 とネットワークシステム 102 とのあいだでの一括（バッチ）モード通信を行うこともできるようになる。

また図１には、サードパーティサーバ機 130 上で実行されるサードパーティアプリケーション 128 も描かれている。サードパーティアプリケーション 128 は、APIサーバ 114 が提供するプログラム的インターフェイスを介して、ネットワークシステム 102 へとプログラム的なアクセスができる。例えばサードパーティアプリケーション128 は、ネットワークシステム 102 から検索した情報を使って、サードパーティがホストするwebサイト上での機能を一種類以上サポートすることができる。サードパーティのwebサイトは例えば、ネットワークシステム 102 の関連アプリケーションによりサポートされる販促機能、マーケットプレイス機能、もしくは支払機能を一種類以上、提供可能である。

図２は、複数のアプリケーション120, 122 を描いたブロック図であり、これらは或る実施形態例では、ネットワークシステム 102 の一部として提供される（図１参照）。アプリケーション群 120 は、専用サーバ機もしくは共用サーバ機（不図示）上でホストできる。これらのサーバ機は通信可能なように結合されており、サーバ機同士で通信ができるようになっている。アプリケーション自体も（適切なインターフェイスなどを介して）、互い同士で、および種々のデータ源に、通信可能なように結合される。こうすることで、アプリケーション間で情報を受け渡すことができるし、または、アプリケーションが、共用データを共有してアクセスできる。さらにアプリケーションは、データベースサーバ124 を介して、ひとつ以上のデータベース 126 にアクセス可能である。

ネットワークシステム 102 は、数多の公示（パブリッシング）機構、出品機構、および価格設定機構を提供可能である。このため出品者は、物品やサービスを売るために出品できる（または、それらの物品やサービスに関する情報を公示できる）。また入札者（買い手）は、そうした物品やサービスに興味があるかもしくは購入する気があることを表明できる。そして価格を、そうした物品やサービスに属するトランザクション（処理）に関して設定可能である。この目的のため、示してあるマーケットプレイス 120 には、ひとつ以上の公示アプリケーション200 と、ひとつ以上のオークション（競売）アプリケーション 202 とを含めてある。このオークションアプリケーション 202 は、オークション形式の出品機構と価格設定機構をサポートする（例えば、Englishオークション、Dutchオークション、Vickreyオークション、Chineseオークション、Doubleオークション、Reverseオークションなど）。また種々のオークションアプリケーション 202 は、各種オークション形式の出品をサポートする数多の機能を提供できる。そうした機能としては、最低落札価格（reserve price）機能があり、これにより出品者（売り手）は、最低落札価格を出品と関連づけて設定可能となる。また他の機能として代理入札（proxy-bidding）機能もあり、これにより入札者は自動代理入札を発動できる。

複数の即決価格（fixed-price）アプリケーション 204 は、即決価格の出品形式（旧来の区分でいう広告型出品、もしくはカタログ型出品など）、ならびに、買取型出品をサポートする。具体的には、買取型出品（California州San JoseのeBay Inc.開発のBuy-It-Now (BIN) technologyなど）は、オークション形式出品と結びつけての提示が可能である。またこうした買取型出品により、入札者は、オークションの開始価格よりも普通は高い即決価格でオークションを介して販売される、物品やサービスを購入可能である。

ストア・アプリケーション 206 は、出品者に、「仮想的な」商店内でのまとめての出品を可能とするものである。なおこうした「仮想的な」商店には、出品者自らによってかもしくは出品者のためとして、商標を付したりまたは他の何らかの個別化を施すこともできる。また、こうした仮想的な商店は、関連する出品者に特有で個別の販促やインセンティブ、機能を提供してもよい。

評価（クチコミ；reputation）アプリケーション 208 により、取引をしたユーザーが、ネットワークシステム 102 を使って、評価の設定、構築、および保持をすることが可能となる。こうした評価は、将来に取引の相手となりうる人（潜在的な取引相手）に対しても、公示し利用させることができる。例えばネットワークシステム 102 が人対人の取引をサポートしている場合を考えてみると、ユーザーは、潜在的な取引相手の信頼性を評価できるような、履歴や他の参照情報を他のやり方で持たなくてもよい。評価アプリケーション 208 により、ユーザーは、他の取引相手から寄せられるフィードバックなどを介して、ネットワークシステム 102 内での評価を時間とともに積立ててゆくことができる。したがって、他の潜在的な取引相手は、信頼性を評価する目的でそうした評価を参照できる。

パーソナリゼーション（個別化）アプリケーション 210 により、ネットワークシステム 102 のユーザーは、ネットワークシステム 102 との連絡におけるさまざまな態様を個別化できる。例えばユーザーは、適切なパーソナリゼーション・アプリケーション 210 を使い、そのユーザーが当事者である（もしくは当事者であった）取引に関連した情報を閲覧可能なように個別化された参照ページを、作成できる。さらにパーソナリゼーション・アプリケーション 210 により、ユーザーは、出品、ならびに、ネットワークシステム 102 および他の関係者とそのユーザーとのあいだの連絡に関する他の態様をも、個別化可能である。

ネットワークシステム 102 は、複数のマーケットプレイスをサポート可能である。こうしたマーケットプレイスでは例えば、特定の地域に関するカスタマイズができる。ネットワークシステム 102 の或るバージョンを、英国用にカスタマイズできる。その一方でネットワークシステム102 の別のバージョンを、米国用にカスタマイズしてもよい。こうしたバージョンの各々が、独立したマーケットプレイスとして動作してもよい。あるいはそうしたバージョンの各々にて、共通する基礎となるマーケットプレイスでの表記を、カスタマイズ（または多言語化および／もしくはローカライズ）してもよい。つまりネットワークシステム 102 には、複数の多言語化（インターナショナリゼーション）アプリケーション 212 を含めることができる。そしてそうした多言語化アプリケーション 212 を用いることで、ネットワークシステム 102 が情報（および／もしくは情報の表記）に対して施すカスタマイズを、所定の基準（地域的基準、人口統計学的基準、もしくはマーケットプレイス的基準など）に応じたものとすることができる。例えば多言語化アプリケーション 212 を使って、複数の地域特化型webサイトについての情報のカスタマイズをサポート可能である。そうした地域特化型webサイトは、ネットワークシステム 102 により動作し、各webサーバ 116 を介してアクセス可能である。

ネットワークシステム 102 のナビゲーションを、ひとつ以上のナビゲーション・アプリケーション 214 により促進できる。例えば（ナビゲーション・アプリケーションの一例である）検索アプリケーションにより、ネットワークシステム 102 を介して公示された出品を、キーワード検索することが可能となる。閲覧アプリケーションにより、ユーザーは種々のカテゴリ、カタログ、もしくは、システム在庫構造を閲覧可能であり、それらに従って、ネットワークシステム 102 内で出品が分類されうる。また、そうした検索アプリケーションおよび閲覧アプリケーションを補助する目的で、さまざまな他のナビゲーション・アプリケーションを用意してもよい。

ネットワークシステム 102 を介してなるべく視覚的に訴えるものとして利用可能な出品リストを作成するために、マーケットプレイス・アプリケーション 120 には、ひとつ以上の撮像アプリケーション 216 を含めることができる。こうした撮像アプリケーション 216 を利用して、ユーザーは出品リストに含めるために画像をアップロードできる。また撮像アプリケーション 216 は、閲覧されている出品リスト中に画像を入れ込む動作も行う。また撮像アプリケーション216 は、一種以上の販促機能もサポートでき、例えば、潜在的な入札者へ提示するための画像ギャラリーをサポートできる。出品者は例えば、追加料金を払って、販促品用の画像ギャラリー内に含まれた画像を得ることもできる。

出品作成アプリケーション 218 により、出品者は、ネットワークシステム 102 を介しての取引が希望されている物品やサービスに関係する出品を簡便に作成できる。また出品管理アプリケーション 220 により、出品者は上述したような出品を管理できる。とりわけ、特定の出品者が大量の出品を作成および／もしくは公示する場合、それらの出品の管理は面倒であることが多い。出品管理アプリケーション 220 では、そうした出品を管理する上で出品者を援けるための数多の機能（自動再出品、在庫量監視など）を提供できる。ひとつ以上の出品後管理アプリケーション 222 もまた、出品後に発生しやすいいろいろな作業をする出品者を援けるものである。例えば、ひとつ以上のオークション・アプリケーション 202 の援けによるオークションが完了したとき、出品者が、特定の入札者に関するフィードバックを残したいと思うこともあるだろう。そういう場合にそなえ、出品後管理アプリケーション 222 では、ひとつ以上の評価アプリケーション 208 へのインターフェイスを提供できる。これにより出品者は、複数の入札者に関するフィードバックを、評価アプリケーション 208 へと簡便に渡すことができる。

紛争解決アプリケーション 224 は、取引者同士のあいだに持ちあがった紛争を解決できる機能を提供する。例えば紛争解決アプリケーション 224 は、誘導手順を提供し、取引者が、紛争を治めたいと思ったときに複数の段階を辿れるようになっている。その誘導手順でも紛争が解決できないような場合には、紛争を第三者である調停者もしくは仲裁人の管轄するところへ上げることができる。

詐欺防止アプリケーション 226 は、詐欺行為の検知機構と防止機構を実現し、ネットワークシステム 102 内での詐欺行為の低減を図る。

伝言アプリケーション 228 は、ネットワークシステム 102 のユーザーへの伝言（メッセージ）を、生成し送達する役目を負う。そうした伝言により例えば、ネットワークシステム 102 での出品の状況を、ユーザーに報知できる（そうした例としては、オークション期間中に「現在価格更新（outbid）」の報せを入札者へ与えることや、または、ユーザーに販促・商品企画（マーチャンダイジング）情報を与えること、などがある）。評価伝言アプリケーション 228 では、伝言をユーザーへ送達するための複数の伝言送達ネットワークおよびプラットフォームを有するような任意のものを利用可能である。例えば、伝言アプリケーション 228 で送達できるものとしては、電子メール（e-mail）、インスタントメッセージ（IM）、ショートメッセージサービス（SMS）、テキスト、ファクシミリ、または、有線ネットワーク（インターネットなど）、基本電話サービス（POTS）、もしくは無線ネットワーク（モバイル、携帯電話、WiFi、WiMAX）を介した音声メッセージ（Voice over IP （VoIP））、などがある。

商品企画（マーチャンダイジング）アプリケーション 230 では、出品者がネットワークシステム 102 を介して販売数を伸ばすために利用できる、種々の商品企画機能をサポートする。また商品企画アプリケーション 230 は、出品者が発動できる種々の商品企画機能の動作も担い、出品者が採った販売戦略の成功を監視し追跡可能である。

ネットワークシステム 102 自体、または、ネットワークシステム 102 を介して取引する一名以上の取引者は、ひとつ以上の特典／販促アプリケーション232 がサポートする特典（loyalty）プログラムを動作させることができる。例えば入札者は、特定の出品者と成立および／もしくは締結した取引毎に、特典もしくは販促のポイントを稼ぐことができる。そして入札者は、貯めた特典ポイントから換金できる景品の提供を受けられる。

ショッピングセッション・アプリケーション 234 は、ネットワークシステム 102 内での種々のショッピングセッションをサポートし、例えば、プライベートショッピングセッション、共同的ショッピングセッション、派生的ショッピング（side shopping）セッション、および個別閲覧セッションなどをサポートできる。例えばユーザーは、共同的ショッピングセッション中に他のユーザーと一緒になって買いものができる。またユーザーが、プライベートショッピングセッション中にお買い得情報を受けとることも可能である。

基金（funding）アプリケーション 236 は、競り落した物品および／もしくは購入した物品への支払をサポートする。例えば基金アプリケーションは、多数のユーザーから対価物を受けとり、それを（ショッピングセッション中などに）商材の購入に充てることができる。

図３Ａは、高レベルなエンティティの関係図であって、種々のテーブル 300 を描いてある。こうしたテーブル 300 は、データベース 131 内に保持でき、アプリケーション 120, 122 により利用されかつサポートすることができる（図１参照）。ユーザー・テーブル 302 は、ネットワークシステム 102 の各登録ユーザーに関する記録を格納し、それら各登録ユーザーに属する識別子、住所、金融商品情報などを含むことができる。ユーザーは、ネットワークシステム 102 の出品者、入札者、もしくはその双方としてふるまうことができる。或る実施形態例では、対価物（市場通貨や独自通貨など）を貯めて持っているユーザーが、入札者になることができ、そしてその貯めた対価物を、ネットワークシステム 102 を通じて売りに出された商材（物品および／もしくはサービスなど）と交換できる。

またテーブル群 300 には、商材テーブル 304 も含まれる。この商材テーブル 304 内には、ネットワークシステム 102 を介して取引可能なもしくは取引可能だった物品とサービスについての、商材記録が保持される。商材テーブル 304中の各商材記録はさらに、ユーザー・テーブル 302 内のひとつ以上のユーザー記録へのリンクを張ってもよい。こうすることで、各商材記録毎に、出品者と、一名以上の実際のまたは潜在的な入札者とのあいだに、関連づけ（紐付け）が可能となる。

取引テーブル 306 には、商材テーブル 304 内に在る記録に関する商材に属した取引の各々（購入をした取引もしくは販売した取引など）についての記録が、格納される。

注文テーブル 308 には、注文記録を入れこむことができ、各注文記録は、物品および／もしくはサービスの注文に関連づけられる。一方、各注文が、取引テーブル 306 内に在る記録に関するひとつ以上の取引についてのものであってもよい。

入札テーブル 310 内の入札記録の各々は、オークション・アプリケーション 202 がサポートするオークション形式の出品と関連した、ネットワークシステム 102 で受信される入札に関する。フィードバック・テーブル 312 は、ひとつ以上の評価アプリケーション 208 により使用されるものであって、或る実施形態例では、ユーザーに関する評価情報を構築し保持できる。

履歴テーブル 314 では、ユーザーが取引者だった取引の履歴を保持する。取引としては、商材テーブル 304 中に記録が有る商材についての取引と、商材テーブル 304 中に記録が無い商材についての取引と、を含めてもよい（そうした商材テーブル304 は例えば、支払アプリケーション 122 の持つ支払サービスおよび機能を、マーケットプレイス・アプリケーション 120 抜きで使用したものであってもよい）。

ひとつ以上の属性テーブル 316 では、商材テーブル 304 中に記録が有る商材についての属性情報を記録している。そうした属性のあくまで一例を考えてみると、属性テーブル
316 では、特定の商材に関連した通貨属性を指定できる。こうした通貨属性は、出品者によってテーブル内に指定された関連商材についての価格の通貨を指定するものである。

セッション・テーブル 318 には、セッション履歴に関するセッション記録（ショッピングセッションの履歴など）を含めることができる。セッション・テーブルには、ネットワークシステム内でのセッション中に過去に訪れたエリア（ストアおよび／もしくは出品者など）の履歴を含めることができる。

図３Ｂでは、基金アプリケーションの例 236 （図２参照）を描いてある。基金アプリケーション 236 には、ひとつ以上の支払明細要求モジュール 352 、ひとつ以上の支払元指定モジュール 354 、および／もしくは、ひとつ以上の支払処理モジュール 356 、を含めることができる。

支払明細要求モジュール 352 （第一のモジュールなど）は、支払明細要求を受信するように構成できる。支払明細要求では、複数の支払元を指定して、ネットワークシステム
102 （図１参照）での取扱対価物に対する支払に使うことができる。

支払元指定モジュール 354 （第二のモジュールなど）は、複数の支払元のうちから第一の支払元を指定する支払充当法を、支払明細要求から選択するように構成できる。ここで支払充当法とは、ネットワークシステムを使うことで購入された取扱対価物の支払のために、複数のユーザーから供出された対価物の割合配分のことと考えてもらってもよい。複数のユーザーアカウントのうちから或るユーザーアカウントを主アカウントとして指定することを、支払明細要求から選択するよう、支払元指定モジュール 354 を構成できる。主アカウントは、複数の支払元のうちの第二の支払元であってもよい。主アカウントは、その取扱対価物に対する価格を供出する上で最終的な責任を負うものとできる。

支払処理モジュール 356 （第三のモジュールなど）は、第一の支払元からの価格の支払の処理を行うよう構成可能である。さらには、その第一の支払元からの支払では、その取引対価物に対する価格を充当できないという場合に、支払処理モジュール 356 が、第二の支払元からの追加支払の処理を行うようにも構成可能である。

図４では、ショッピングセッションを実行するための方法 400 を描いてある。或る実施形態例では、方法 400 を、ショッピングセッション・アプリケーション 234 （図２参照）により実行できる。

ショッピングセッション要求には、段階 402 にてアクセス可能である。例えば、共同的ショッピングセッション、プライベートショッピングセッション、個別ショッピングセッション、もしくは派生的ショッピングセッションについて、ショッピングセッション・アプリケーション 234 がショッピングセッション要求を受信できる。

判断段階 404 にて、共同的ショッピング要求が受信されたかどうかについての判断を行うことができる。共同的ショッピングセッション要求が受信されていたならば、共同的ショッピングセッションを段階 406 で行うことができる。例えば、共同的ショッピングセッションには、複数のユーザーによるショッピングについての共通インターフェイスを共有することを含めることができる（例えば、そうした共通インターフェイスを、各ユーザーが持つコンピュータシステム上に表示できる）。共同的セッションを実行する実施形態例については、以降でさらに詳しく説明してゆく。また、共同的ショッピングセッション要求が判断段階 404 で受信されていなかったならば、方法 400 は判断段階 408 へと進む。

判断段階 408 では、プライベートショッピング要求が受信されたかどうかについての判断を行うことができる。プライベートショッピングセッション要求が受信されていたならば、プライベートショッピングセッションを段階 410 で行うことができる。例えばプライベートショッピングセッションに含めることができるショッピングセッションとして、一名以上の参加者の各々が、ひとつ以上の商材への特別なアクセス権、および／もしくは、ひとつ以上の商材への特価（割引もしくは無料など）を以ったアクセス権を持っているというショッピングセッションがある。プライベートセッションを実行するための実施形態例については、以降でさらに詳しく説明してゆく。また、プライベートショッピングセッション要求が判断段階 408 で受信されていなかったならば、方法 400 は判断段階 412 へと進む。

判断段階 412 では、セッション履歴へのアクセス要求が受信されたかどうかについての判断を行うことができる。セッション履歴へのアクセス要求が受信されていたならば、セッション要求へのアクセスを段階 414 で行うことができる。例えばユーザーは、セッション・テーブル 318 （図３Ａ参照）から、プライベートショッピングセッション、共同的ショッピングセッション、派生的ショッピングセッション、および／もしくは個別ショッピングセッションの履歴にアクセスできる。或る実施形態例では、或るセッション（共同的ショッピングセッションなど）についてのセッション履歴の要求を受信したなら、セッション・テーブル 318 のセッション記録中に格納されている、セッション中に過去に訪れたエリアのネットワークシステム 102 内での所在を、共通インターフェイスおよび／もしくは個別インターフェイスを介して提供できる。なおここで個別インターフェイスとは例えば、或るセッション中に同時に別のユーザーと共有されないインターフェイスのことをいう。

判断段階 412 にて、セッション履歴へのアクセス要求が受信されていなかったならば、個別ショッピングセッションを段階416 にて実行できる。例えば個別ショッピングセッションには、個別インターフェイスを用いたショッピングセッションに参加する（関連づけられる）ユーザーを含めることができる。段階 406 、段階 410 、段階 414 、もしくは段階 416 での作業が完了したなら、方法 400 を判断段階 418 へと進めることができる。

判断段階 418 では、別のショッピング要求がなされるかどうかについての判断をすることができる。別のショッピング要求があるということであるならば、方法 400 を段階 402 に回帰させられる。判断段階 418 において別のショッピング要求がないということならば、方法 400 を終了できる。

図５では、或る実施形態例にかかる、共同的セッション（共同的ショッピングセッションなど）を実行するための方法 500 を示してある。或る実施形態例では、方法 500 を段階 406 （図４参照）にて実行することもできるし、かつ／あるいは、方法 500 をショッピングセッション・アプリケーション 234 （図２参照）を用いて実行することも可能である。

共同的セッション（共同的ショッピングセッションなど）を、段階 502 から開始できる。例えばネットワークシステム102 の第一のユーザーが、共同的セッションを開始可能である。或る実施形態例では、共同的セッションを開始することに、派生的セッションの併合規準および／もしくは共同セッションの完了規準を定義することを含めてもよい。派生的セッションの併合規準と共同セッションの完了規準の使いかたについては、以降にてさらに詳しく説明してゆく。

段階 504 にて、複数のユーザー（二名以上のユーザーなど）を、共同的セッションに関連づけることができる。例えば第一のユーザーは、他の一名以上のユーザーを選んで、第一のユーザーと一緒に共同的セッションに参加させることができる。こうした関連づけをするための選択の指示は、ショッピングセッション・アプリケーション 234 に与えることができる。他のユーザーについては、共同的セッションに参加可能であるということを、ネットワークシステム 102 （図１）によって第一のユーザーへ提示できる（例えば、違うアイコンを用いたり、アイコンの色を変えたりして、など）。複数のユーザーが、特別なパスワードを使って共同的セッションに（設定した開始時にかもしくは随時にかで）参入可能である。これらのユーザーは、別のアプリケーションのユーザーリストからインポートすることもできるし、もしくは連絡先帳からインポートしてもいい。そうしたユーザーリストとしてはSkype LimitedのSkypeのものなどがあり、またそうした連絡先帳としてはMicrosoft CorporationのMicrosoft Outlookのものなどがある。また、共同的セッションの開始時かもしくは共同的セッションの実行中かにおける、ユーザーの共同的セッションとの他の関連づけを使ってもかまわない。

判断段階 506 では、共同的セッションの複数のユーザーに対し、権限レベルを指定するかどうかの決定を行うことができる。権限レベルの指定をするという決定になった場合には、段階 508 にて、権限レベルを共同的セッションに関連する複数のユーザーに対して指定する。なお権限レベルとは、共同的セッションの複数のユーザーのうちのいずれかのユーザーが、他のユーザーが何らかのセッション対話を行おうとしている際に、そうしたセッション対話を行う強い権限および／もしくは変動する権限を持つことを表すものであってよい。権限レベルを共同的セッション中に使う手法については、以降でさらに詳しく説明してゆく。また、判断段階 506 にて権限レベルの指定をするという決定がなされなかった場合、もしくは段階 508 の作業が完了した際に、方法 500 を判断段階 510 へと進めることができる。

或る実施形態例では、段階 508 にて、実行要求を行うにあたっての閾権限レベルを共同的セッションに対して指定できる。例えば、共同的セッションに参加するユーザーが、共同的セッションの閾権限レベルに合わなかったならば実行ができず、合っていたならば共同的セッションに参加できるようにしてもよい。権限レベルを実行要求に使うやりかたについては、以降でさらに詳しく説明してゆく。

或る実施形態例では、共同的セッションのユーザーに、デフォルト権限レベルを与えてもよい。例えば共同的セッションを要求したユーザーが、共同的セッションのその他のユーザーよりも高い権限レベルを持ってもよい。他のデフォルト権限レベルを使ってもよい。

段階 510 では、基金積立通知（funding notification）を発行するかどうかの決定を行うことができる。例えば基金積立通知では、共同的セッションの一名以上のユーザーからの対価物を、その共同的ショッピングセッションに関連づけることができる旨を通知できる（例えば、一名以上のユーザーからの対価物に対する要求として）。また基金積立通知では、ユーザーアカウント（主アカウントなど）および／もしくは共同基金（或るセッションの複数のユーザーから投資集約された対価物など）を介して、対価物が共同的セッションに関連づけられた旨を通知することもできる。基金積立通知の発行をする決定がなされた場合には、段階 512 にて、基金積立通知を（共同的セッションの複数のユーザーなどへ宛てて）発行できる。判断段階510 で基金積立通知を発行しないという決定がされた場合、もしくは段階 512 での作業が完了した際に、方法 500 を段階 514 へと進めることができる。

段階 514 では、共同的セッションに関連づけられたユーザー（参加者など）同士のあいだでの、ひとつ以上のユーザー対話（users interactions）を処理できる。ユーザー対話の処理に関する実施形態例については、以降でさらに詳しく説明してゆく。

判断段階 516 では、派生的セッションを実行するかどうかについての決定を行うことができる。段階 516 にて派生的セッションを行うという決定がなされたならば、段階 518 で派生的セッションを実行できる。派生的閲覧セッション（side browsing session）に参加しているユーザーは、共同的セッションの一部として参加しつづけることもできるし、あるいは、派生的セッションに従事しているあいだは共同的セッションから一時的に切断することもできる。例えば、派生的閲覧セッションに参加したユーザーに関する派生的セッションの作業中に、共同的セッションのほうは、複数のユーザーに対してそのまま続けてもよい。派生的セッションの実行に関する実施形態例については、以降でさらに詳しく説明してゆく。

判断段階 516 にて派生的閲覧セッションを実行しないという決定がなされた場合、または、段階 518 での作業が完了（および／もしくは開始）した際に、方法 500 を判断段階 520 へと進めることができる。

判断段階 520 では、共同的セッションに関連づけられたユーザーを更改するかどうかを決定できる。例えば、或るユーザー（参加者など）を、共同的セッションに加えてもよいし、あるいは共同的セッションから除いてもよい。共同的セッションに関連づけるユーザーを更改するという決定がなされたならば、段階 522 にて、このセッションに関連づけられたユーザーを更改できる。判断段階 520 にて共同的セッションに関連づけるユーザーは更改しないという決定がなされた場合、もしくは、段階 522 での作業が完了した際に、方法 500 を判断段階 524 へと進めることができる。

判断段階 524 では、共同的セッションを終了するかどうかの決定を行うことができる。例えば共同的セッションが、完了規準を満たしたとき（複数のユーザーかもしくは一名のユーザーが、共同的セッションの終了指示を出せる最高の権限レベルを持つ場合など）に、その共同的セッションを終了できる。共同的セッションを終了させないという決定がなされた場合には、方法 500 を判断段階 506 に回帰させられる。共同的セッションを終了させるという決定がなされた場合には、方法 500 も終了できる。

図６では、或る実施形態例にかかる、ユーザー対話の処理をするための方法 600 を示してある。或る実施形態例では、方法600 を段階 514 （図５参照）にて実施可能である。

段階 602 にて、ひとつ以上のユーザー対話を（或る期間内などに）受信できる。例えばそうしたユーザー対話としては、ユーザーがショッピングセッション・アプリケーション 234 （図２参照）に与える連絡（communication）が考えられる。

判断段階 604 では、ひとつ以上の閲覧要求が受信されたかどうかについての判断を行うことができる。閲覧要求を受信していたならば、段階 606 にて、（例えばコンテンツを得るために）その閲覧要求を処理できる。閲覧要求の処理に関する実施形態例については、以降でさらに詳しく説明してゆく。判断段階 604 で閲覧要求を受信していなかった場合、もしくは、段階 606 での作業の完了後に、方法 600 を判断段階 608 へと進めることができる。

判断段階 608 では、（複数のユーザーなどからの）ひとつ以上の連絡が受信されたかどうかについての判断を行うことができる。複数のユーザーのうちの連絡元ユーザーからの連絡を受信していた場合には、段階 610 にて、その連絡を、複数のユーザーのうちの一名以上の連絡先ユーザーへと送達可能である。そうした連絡を送達するにあたっては例えば、インスタントメッセージ（AOL, LLCのAOL Instant Messengerなど）や、音声通信 （Skype LimitedのSKYPEなど）や、テキストでの連絡、といったものを用いることができる。判断段階 608 にて連絡が受信されていなかった場合、もしくは、段階 610 での作業の完了後に、方法 600 を判断段階 612 へと進めることができる。

判断段階 612 では、さらなるユーザー対話があるか否かの判断を行うことができる。さらなるユーザー対話があったならば、方法 600 を段階 602 へと戻せる。判断段階 618
にてさらなるユーザー対話が無ければ、方法 600 を終了できる。

図７では、或る実施形態例にかかる、閲覧要求の処理のための方法を示してある。或る実施形態例では、方法 700 の作業を、段階 606 （図６参照）にて実施可能である。

段階 702 では、共同的セッションの一名以上のユーザー（参加者など）から、ひとつ以上の閲覧要求を受信可能である。そうした閲覧要求には例えば、カーソル移動要求、指示（indication）要求、実行要求、アカウント明細要求、注文要求、などが含まれうる。

判断段階 704 では、ひとつ以上のナビゲーション要求（参加者が、共同的セッションの共通インターフェイス上でのナビゲートを要求することなど）を受信したかどうかを判断できる。ナビゲーション要求を受信していたならば、段階 706 にて、ナビゲーション要求を処理できる。ナビゲーション要求の処理に関する実施形態例については、以降でさらに詳しく説明してゆく。判断段階 704 にてカーソル移動要求が受信されていなかった場合、もしくは段階 706 での作業の完了後に、この方法を判断段階 708 へと進めることができる。

判断段階 708 では、ひとつ以上の指示要求（参加者が、共同的セッションの画面上での指示を要求することなど）を受信したかどうかの判断を行うことができる。（例えば、カーソル移動をする第一のユーザー、もしくは第二のユーザーから）指示要求を受信していたならば、段階 710 にてその指示要求を処理して、共通インターフェイス上での指示を行わせることができる。指示要求により要求される指示としては例えば、共同的セッションの共通インターフェイス上での、印づけ（円や四角など）、注釈づけ（テキストや画像など）、範囲指定（数多の利用可能なオプションのうちのひとつ以上のオプションに関するものなど）、といったものがある。こうした指示は、画面上に表示するだけのものであってもよいし、あるいは、実行要求中に（ショッピングセッション・アプリケーション234 などにより）処理するものであってもよい。指示要求を処理するための方法については、以降でさらに詳しく説明してゆく。判断段階 708 にて指示要求が受信されていなかった場合、もしくは、段階 710 での作業の完了後に、方法 700 を判断段階 712 へと進めることができる。

或る実施形態例では、セッションの参加者の各々が自身のカーソルを持ち操縦できる場合であれば、共同的セッション中に、各参加者が指示（印づけや注釈づけなど）を出すことが可能となる。また、セッションの各参加者がカーソルを共有している場合には、共同的セッション中に参加者がカーソル操縦を共有する（共有されたカーソルを操縦するなど）場合にのみ、参加者の各々が指示（もしくは印づけなどの特定の指示）を出せるように制限をかけることができる。

判断段階 712 では、ひとつ以上の実行要求を受信したかどうか（閲覧要求が実行要求であったかどうか、など）についての判断を行うことができる。実行要求（参加者が、指示の処理を要求することなど）を受信していたならば、段階 714 でその実行要求を処理できる。実行要求の処理に関する実施形態例については、以降でさらに詳しく説明してゆく。段階 712 にて実行要求を受信していなかった場合、もしくは、段階 714 での作業が完了した際に、方法 700 を判断段階 716 へと進めることができる。

判断段階 716 では、ひとつ以上の支払明細要求を受信したかどうか（閲覧要求が支払明細要求であったかどうか、など）についての判断を行うことができる。支払明細要求を受信していたならば、段階 718 にて支払明細要求を処理できる。支払明細要求の処理に関する実施形態例については、以降でさらに詳しく説明してゆく。段階 716 にて支払明細要求を受信していなかった場合、もしくは、段階 718 での作業が完了した際に、方法 700 を判断段階 720 へと進めることができる。

判断段階 720 では、ひとつ以上の注文要求を受信したかどうか（閲覧要求が注文要求であったかどうか、など）についての判断を行うことができる。注文要求を受信していたならば、段階 722 にて注文要求（参加者が、共同的ショッピングセッション中にひとつ以上の商材の注文を要求することなど）を処理できる。段階 720 にて注文要求を受信していなかった場合、もしくは、段階722 での作業が完了した際に、方法 700 を判断段階
724 へと進めることができる。

判断段階 724 では、共同基金設立要求を受信したかどうか（閲覧要求が共同基金設立要求であったかどうか、など）についての判断を行うことができる。共同基金設立要求を受信していたならば、段階 726 にて共同基金設立要求を処理できる。共同基金設立要求の処理に関する実施形態例については、以降でさらに詳しく説明してゆく。段階 724 にて共同基金設立要求を受信していなかった場合、もしくは、段階 726 での作業が完了した際に、方法 700 を判断段階 728 へと進めることができる。

判断段階 728 では、ひとつ以上のさらなる閲覧要求を受信したかどうかについての判断を行うことができる。別の閲覧要求を受信していたならば、方法 700 を段階 702 へと回帰させられる。判断段階 728 にて別の閲覧要求を受信していなかったなら、方法 700
を終了できる。

図８では、或る実施形態例にかかる、ナビゲーション要求を処理するための方法 800
を示してある。或る実施形態例では、方法 800 を、段階 706 （図７参照）にて実施可能である。例えば方法 800 を実施する場合としては、共同的セッションにて単独のカーソルを使い、かつそのカーソルの移動をその共同的セッションのすべての参加者が行えるという状況を想定できる。

段階 802 では、或る期間にわたり、複数のユーザーからのひとつ以上のカーソル移動要求を受信できる。こうした期間は、或るユーザーからの単独のカーソル移動に適したもの（持続時間が一秒もしくは何分の一秒など）であってもよいし、あるいは、単独のユーザーからの複数回のカーソル移動に適するに充分なもの（可変であってもよいしもしくは固定であってもよい）とすることもできる。

判断段階 804 では、一名よりも多いユーザーからのカーソル移動要求があったかどうかを判断できる。期間中に一名よりも多いユーザーからカーソル移動要求を受信しなかったならば、段階 816 にて（一名の）ユーザーが要求した移動を実行できる。

判断段階 804 において、期間中に一名よりも多いユーザー（複数のユーザーのうちの二名以上のユーザーなど）からカーソル移動要求が出されたと判断した場合には、段階 806 にて、移動要求を出したその二名以上のユーザーの権限レベルへとアクセスできる。或る実施形態例では、そうした二名以上のユーザーの権限レベルを段階 508 （図５参照）での作業中に指定してもよいし、かつ／あるいは、段階 806 にて共同的セッションのすべてのユーザーに関して権限レベルにアクセスするようにしてもよい。

判断段階 808 では、移動要求を出した共同的セッションの二名以上のユーザーのうちのいずれかが、最高権限レベルを有するかどうかの判断を行うことができる。移動要求を出したユーザーが最高権限レベルを持っていたならば、段階 816 にて、その最高権限レベルのユーザーが（移動要求などから）指示したひとつ以上のカーソル移動を、（カーソルを動かすなどして）実行可能である。また、ユーザーが最高権限レベルを持っていなかった場合には、方法 800 を判断段階 810 へと進めることができる。

判断段階 810 では、移動要求を出した共同的セッションの二名以上のユーザーのうちのいずれかが、共同的セッション中に移動を処理させた最後のユーザーにあたるかどうかの判断を行うことができる。共同的セッションの二名以上のユーザーのうちの或るユーザーが、移動を処理させた最後のユーザーにあたった場合には、段階 816 にて、その最後のユーザーが指示したひとつ以上のカーソル移動を実行できる。

判断段階 810 で、移動要求を出した共同的セッションの二名以上のユーザーのうちの一名が、移動を処理させた最後のユーザーではなかった場合には、段階 812 にて、その二名以上のユーザーへとカーソル操縦通知を送信できる。カーソル操縦通知としては例えば、移動要求を出した二名以上のユーザーへと送信される、移動処理に関してのユーザーの選択を有効化する旨の要求を想定できる。例えば、移動要求を出した第二のユーザーが、移動要求を出した第一のユーザーを指定して、期間中にひとつ以上の移動を行わせるようにできる。

判断段階 814 では、或るユーザーに操縦権を付与したかどうかを判断できる。操縦権が付与されていたならば、段階816 にて、その付与を受けたユーザー（第一のユーザーなど）が指定した移動を実行できる。或る実施形態例では、最高権限レベルを満たしている（と判断段階 808 などから判断された）ユーザーからのカーソル移動要求か、カーソル移動を処理させた最後のユーザー（であると判断段階 810 などから判断されたユーザー）からのカーソル移動要求か、および／もしくは、別のユーザーから操縦権を付与された（と判断段階 814 などから判断された）ユーザーからのカーソル移動要求かに応じて、段階 816 での作業中にカーソルの移動を行うことが可能である。

或る実施形態例では、判断段階808 、判断段階 810 、および判断段階 814 の動作中に決定される移動規準は、任意の順番であってもよい。

段階 814 にて操縦権が付与されていなかった場合、もしくは、段階 816 での作業が完了した際に、方法 800 では、判断段階 818 にてさらなる移動要求を受信していたかどうかについての判断を行うことができる。さらなるひとつ以上の移動要求を受信するようになっていたならば、方法 800 を段階 802 へと回帰させられる。さらなる移動要求を受信しないようになっていたならば、方法 800 を終了できる。

なお、カーソル以外の他のナビゲーション装置もまた方法 800 にて使用可能であり、そしてナビゲーション要求により、共通インターフェイス上でのナビゲーション移動を得ることができる、ということを理解されたい。

図９では、或る実施形態例にかかる、ナビゲーション要求を処理するための方法を示してある。或る実施形態例では、方法 900 を、段階 706 （図７参照）にて実施可能である。方法 900 を実施するにあたっては例えば、共同的セッションにて、その共同的セッションの複数のユーザーの各々が、共通インターフェイス上で別々のカーソルを使えるようにしてあるという場合を想定できる。

段階 902 では、或る期間にわたり、複数のユーザーからのひとつ以上のカーソル移動要求を受信できる。こうした期間は、或るユーザーからの単独のカーソル移動に適したもの（持続時間が一秒もしくは何分の一秒など）であってもよいし、あるいは、単独のユーザーからの複数回のカーソル移動に適するに充分なもの（可変であってもよいしもしくは固定であってもよい）とすることもできる。

判断段階 904 では、一名よりも多いユーザー（複数のユーザーのうちの二名以上のユーザーなど）からの移動要求があったかどうかを判断できる。一名よりも多いユーザーからの移動要求が受信したと判断した場合には、段階 906 にて、期間中にその移動要求を出した二名以上のユーザーの持つカーソルを、共通インターフェイス上で区別できるカーソルに変えることができる。例えば、期間中にカーソル移動要求を出した二名以上のユーザーの持つカーソルがそれぞれ、別のカーソルとは違う色のカーソル、違うサイズのカーソル、アイコン（アバターなど）などを有していてもよい。

判断段階 904 で一名よりも多くのユーザーから移動（要求）を受信しなかった場合、もしくは、段階 906 での作業が完了した際に、段階 908 にて移動を実行できる。

判断段階 910 では、さらなる移動（要求）へアクセスすることになっているかどうかを判断できる。さらなる移動（要求）へアクセスすることになっていたならば、方法 900
を段階 902 へと回帰させられる。また、さらなる移動（要求）へアクセスすることになっていなかったならば、方法 900 を終了できる。

なお、カーソル以外の他のナビゲーション装置もまた方法 900 にて使用可能であり、そしてナビゲーション要求により、共通インターフェイス上でのナビゲーション移動を行うことができる、ということを理解されたい。

図１０では、或る実施形態例にかかる、実行要求を処理するための方法1000 を示してある。或る実施形態例では、方法1000 を段階 714 （図７参照）にて実施可能である。

段階 1002 では、共同的セッションのユーザーからの実行要求を受信できる。実行要求としては例えば、共同的セッションの共通インターフェイス上で行える指示を処理するための要求、といったものを想定できる。

段階 1004 では、共同的セッション中に実行要求を実施するためのユーザーの権限レベルおよび閾権限レベルへ、アクセスすることができる。そうした権限レベルは例えば、段階 508 （図５参照）の作業中に定義可能である。

判断段階 1006 では、ユーザーが、閾権限レベルに合うかどうか（そして共同的セッション中に実行要求を実施できるかどうかなど）を判断できる。閾権限レベルに合っていたならば、段階 1008 にて、その実行要求が要求した実行ができる。そうした実行としては例えば、注文要求、追加画面の要求、商材に関するさらなる情報の要求、などといったものを想定できる。判断段階 1006 で閾権限レベルに合っていなかった場合、もしくは、段階 1008 の作業の完了後に、方法 1000 を判断段階 1010 へと進めることができる。

判断段階 1010 では、別の実行要求を受信したかどうかについての判断をすることができる。別の実行要求を受信していたならば、方法 1000 を段階 1002 へと回帰させられる。判断段階 1010 にて別の実行要求を受信していなかったならば、方法 1000 を終了できる。

図１１では、或る実施形態にかかる、支払明細要求を処理するための方法 1100 を示してある。或る実施形態例では、方法 1100 を段階 718 （図７参照）にて実施可能である。

段階 1102 では、支払明細要求を受信できる。そうした支払明細要求では、ネットワークシステム内での（商材などの）取扱対価物への支払に使うための、複数の支払元を定めることが可能である。支払明細要求では、共同基金、支払用主アカウント、および／もしくは支払充当法を含んだ、複数種の支払元のうちひとつ以上を指定できる。

判断段階 1104 では、共同基金を（共同的セッションなどに）関連付けるかどうかの決定を行うことができる。こうした共同基金は、（ひとつ以上の共同的ショッピングセッション中などに）購入された商材への支払料金に充てるため、複数のユーザーから供出された対価物である。共同基金には例えば、支払処理中に、他の支払元に優先して利用される、ユーザーが提供した対価物を含めることができる。任意選択的に、共同基金を共同アカウント（joint account）に関連づけてもいい。共同基金の関連付けを行うという決定をしたならば、段階 1106 にて、共同基金を関連付けられる。例えば、既存の共同基金へアクセスしてもよいし、もしくは新たな共同基金を立ち上げてもかまわない。共同基金の設立に関する実施形態例については、以降でさらに詳しく説明してゆく。判断段階 1104 で共同基金の関連付けをさせないという決定がなされた場合、もしくは、段階1106 での作業が完了した際に、方法 1100 を判断段階1108 へと進めることができる。

判断段階 1108 では、ユーザーが選んだ主アカウントの指定がなされたかどうかについての決定を行うことができる。例えば、ユーザーアカウントを主アカウントとして指定することにより、そのユーザーアカウントに属する一名以上のユーザーに対し、取扱対価物（共同的ショッピングセッションを通じて即決価格もしくは入札により購入されたひとつ以上の商材など）に対する価格を供出する上で最終的な責任を負わせることができる。ユーザーが選んだ主アカウントについての明細（user selected primary account specific ation）を作成したならば、段階1110 にて、（共同的セッションのユーザー群などから）選択したユーザーアカウントを、主アカウント（例えば、価格を供出する最終的な責任を負うもの）に指定できる。

判断段階 1108 にてユーザーが選んだ主アカウントについての指定がなされなかった場合には、方法1100 を判断段階 1112 へ進め、共同アカウント明細を作成したかどうかの判断を行うことができる。共同アカウント指定がなされていなかった場合には、段階 1114 にて、デフォルトのユーザーアカウントを、主アカウントに指定できる。なお、デフォルトのユーザーとしては例えば、ネットワークシステム 102 （図１参照）へ登録した期間が最長であるユーザーや、貯めた対価物の量が最大であるユーザーといったものを想定できる。判断段階 1112 にて共同アカウント指定がなされていたならば、方法 1100 を判断段階 1116 へ進めることができる。

判断段階 1116 では、共同アカウントを作成できるかどうかの判断を行うことができる。例えばそうした共同アカウントを、複数のユーザーのうちの一名よりも多いユーザーに関連づけることができ、かつ、そうした共同アカウントを、共同的セッションを通じて購入されたひとつ以上の商材と交換するための対価物を供出する最終的な責任を負うものとすることができる。共同アカウントを作成することになっていたならば、段階 1118 にて、新たな共同アカウントを作成できる（そしてさらに、共同的セッションの複数のユーザーと関連づけることもできる）。そうしてから、段階 1120 にて、作成した共同アカウントを指定できる。判断段階 1116 にて、共同アカウントを作成しないことになっていた場合には、段階 1120 で既存の共同アカウントを指定できる。なお共同アカウントを、ひとつ以上のセッションに使用できることに留意されたい。

段階 1110 か段階 1114 か段階1120 かでの作業が完了したら、方法 1100 を判断段階1122 へと進めることができる。判断段階 1122 では、支払充当法（購入した商材もしくは支払について、指定されたユーザーが供出することになる対価物の量の配分のことなど）が段階 1102 にて受信されていたかどうかについての判断ができる。支払充当法には含まれるものとしては例えば、ネットワークシステム 102 を使用してある価格で購入された（商材などの）取扱対価物の支払に使う、複数のユーザーから供出される対価物の量の割合配分などがある。

支払充当法が受信されていたならば、段階 1124 にて、支払充当法を（共同的セッションなどのために）指定できる。判断段階1122 で支払充当法が受信されていなかったと判断されたならば、段階1126 にて、デフォルトの支払充当法を、指定したアカウントのために使うことができる（なお、デフォルトの支払充当法としては、共同的セッションの指定されたユーザーに対する均等な配分、共同的セッションの複数のユーザーに対する均等な配分、主アカウントが全分量を担う場合、もしくは、指定したユーザーに対しその金融資産に基づいて変化をつけた配分、といったものがある）。段階 1124 もしくは段階 1126 での作業が完了したら、方法 1100 を終了できる。

或る実施形態例では、段階1124 の作業中に、複数の支払元のうちの或る支払元を指定する支払充当法を、段階 1102 の作業中に受信した支払明細要求から選択可能である。

或る実施形態例では、方法1100 の実施により、ショッピングセッションもしくは他の支払金に対する対価物を供出するための、ひとつ以上の支払元ならびに／または優先度を規定する支払明細が得られる。

図１２では、或る実施形態例にかかる、共同基金設立要求を処理するための方法 1200 を示してある。或る実施形態例では、方法 1200 を、段階 726 （図７参照）にて実施してもよいし、かつ／あるいは、基金アプリケーション 236 （図２参照）が実施してもよい。

段階 1202 では、（共同的ショッピングセッションなどに関する）ひとつ以上の基金要素へとアクセスできる。こうした基金要素としては、共同的セッションのユーザーに要求されることになる対価物（全ユーザーからの総対価物、もしくは、特定のユーザーからの個別の対価物、など）や、セッション（共同的ショッピングセッションなど）を開始するにあたり望まれる対価物といったものを含めることができる。

段階 1204 では、支払充当法へと任意選択的にアクセスできる。例えば、段階 1102 （図１１参照）にて支払充当法を受信可能である。

段階 1206 では、セッションのユーザーから、対価物を要求できる。例えば対価物を、基金要素および／もしくはアクセスした支払充当法に応じて、セッションのユーザーから要求してもよい。

判断段階 1208 では、対価物（ひとつ以上の要求した対価物など）をユーザーから受信したかどうかを判断できる。ユーザーから対価物を受信していたと判断した場合には、段階 1210 にて、受けとった対価物を、共同基金に関連づけられる。そして段階 1212 で、ユーザーへと共同基金の状態を通知できる。判断段階 1208 でユーザーから対価物を受信していないと判断した場合には、段階 1214 にて、ユーザーからの対価物の受信に失敗した旨をユーザーに通知できる。段階 1212 もしくは段階 1214 での作業が完了したら、方法 1200 を判断段階 1216 へと進めることができる。

判断段階 1216 では、複数のユーザーのうちの一名以上から、対価物がさらに要求されるかどうかを決定できる。さらに要求されると決定したならば、方法 1200 を段階 1206 へ回帰させられる。さらなる要求はしないと決定したなら、方法 1200 を終了できる。

或る実施形態例では、共同基金を設立した後に、ユーザーはその共同基金へと対価物を追加してさらなる貢献をすることも可能である。

図１３では、或る実施形態例にかかる、注文要求を処理するための方法 1300 を示してある。或る実施形態例では、方法 1300 を段階 722 （図７参照）で実施可能である。

段階 1302 では、注文要求を受信できる。こうした注文要求として想定できるのは、ショッピングセッションの単独ユーザーによる商材の購入、もしくは、ショッピングセッションに関連づけられた複数のユーザーによる商材の購入、といったものである。

段階 1304 では、非注文コンテンツ（non-order content）を、任意選択的に提供可能である。非注文コンテンツを例えば、支払充当法に基づいた支払の責任を負う主アカウントに関連づけられていないすべてのユーザーへ与えてもよいし、かつ／あるいは、ショッピングセッションのための共同基金に貢献してないユーザーへ与えてもかまわない。非注文コンテンツとしては、注文していないユーザーに注文が完了するまでのあいだ待つよう告知する画面、もしくは、閲覧に利用可能な追加画面、といったものを含めることができる。

段階 1306 では、注文コンテンツを提供できる。注文コンテンツを例えば、支払充当法に基づいた支払の責任を負う主アカウントに関連づけられているすべてのユーザーへ与えてもよいし、かつ／あるいは、ショッピングセッションのための共同基金に貢献しているユーザーへ与えてもよい。注文コンテンツには、注文を完了する（ことで、即決価格のひとつ以上の商材を購入するか、かつ／あるいは、オークションを介して得られるひとつ以上の商材を入札して購入する）にあたって、一名以上のユーザーが使える情報を含めることができる。なお、段階 1304 での作業と、段階 1306 での作業とは、同時に行ってもよいし、または任意の順に行ってもよい。

段階 1306 にて提供された注文コンテンツに応じ、段階 1308 では、ユーザーからの注文情報を受信できる。例えば注文情報によって、注文コンテンツを踏まえて要求された情報を完結させられる。

判断段階 1310 では、受信した注文情報が完結しているかどうかの判断を行える。要求された注文情報が完結していなかったならば、段階 1312 にて注文要求の処理を続けるかどうかの決定を下すことができる。判断段階1312 にて注文要求を継続する旨の決定がなされた場合には、方法 1300 は段階 1306 へ回帰させられる。判断段階 1312 にて注文要求を継続しない旨の決定がなされた場合には、方法 1300 を終了できる（例えば、注文要求をキャンセルできる）。

判断段階 1310 にて注文情報が完結したならば、段階 1314 にて、完結した注文情報を処理可能である。完結した注文情報には例えば、ショッピングセッションに関連づけられた商材についての支払金額を含めることができる。完結した注文情報の処理に関する実施形態例については、以降でさらに詳しく説明してゆく。段階 1314 での作業が完結したら、方法 1300 を終了できる。

或る実施形態例では、段階1306 で提供された注文コンテンツを、ショッピングセッション中に発見したひとつ以上の商材を購入できるよう選ばれたショッピングセッションのユーザーへ、個別に提供できる。ショッピングセッションの他のユーザへ段階 1304 で提供されるコンテンツには、共同的ショッピングセッション中にひとつ以上の商材を購入するための注文コンテンツおよび／もしくは非注文コンテンツを含めることができる。

図１４では、或る実施形態例にかかる、完結した注文情報を処理するための方法 1400 を示してある。或る実施形態例では、方法 1400 を、段階 1314 （図１３参照）にて実施してもよいし、かつ／あるいは、基金アプリケーション236 （図２参照）で実施してもよい。

段階 1402 では、価格へアクセスできる。価格としては例えば、共同的セッションからの支払金額、もしくは他の支払金額（賃貸住宅の家賃など）を想定できる。

段階 1404 では、支払明細へアクセスできる。支払明細は、方法 1100 （図１１参照）の作業中に定義可能である。支払明細で定義するのは、ショッピングセッションもしくは他の支払金に対する対価物を供出するための、ひとつ以上の支払元ならびに／または優先度である。

判断段階 1406 では、対価物を共同基金から得られるかどうかについての判断を行うことができる。対価物を共同基金から得るのであれば、段階 1408 にて、共同基金からの支払を処理可能である。そうした支払は例えば、価格の全部を賄うものであってもよいし、もしくは価格の一部分を賄うものでもよい。判断段階 1406 で共同基金から対価物が得られないであろうという判断がなされた場合、もしくは、段階 1408 の作業の完了に際して、方法 1400 を判断段階 1410 へと進めることができる。

判断段階 1410 では、支払充当法に応じてユーザーから対価物が得られるかどうかの判断を行うことができる。支払充当法に応じて対価物をユーザーから得られる場合には、段階 1412 にて、支払充当法に応じて支払を処理できる。判断段階 1410 で支払充当法に応じてユーザーから対価物を受信できないであろうと判断した場合、もしくは、段階 1412 の作業の完了に際して、方法 1400 を判断段階 1414 へと進めることができる。

判断段階 1414 では、対価物を主アカウントから得られるかどうかの判断を下すことができる。対価物を主アカウントから得られる場合には、段階 1416 にて、主アカウントから支払を処理可能である。判断段階 1414 で主アカウントから対価物を得られないであろうと判断がなされた場合、もしくは、段階 1416 の作業の完了に際して、方法 1400 を判断段階 1418 へ進めることができる。

判断段階 1418 では、（取扱対価物などに対する）価格が、一回以上の支払で満たされたかどうかについての判断を下すことができる。価格が満たされていたならば、注文を処理して、（ひとつ以上の商材などの）購入および／もしくは入札を促すことができる。判断段階 1418 で価格が満たされていなかった場合、もしくは、段階 1420 の作業の完了に際して、方法 1400 を判断段階 1422 へと進めることができる。

判断段階 1422 では、共同基金に対価物が残っているかどうかの判断を下すことができる。対価物が共同基金に残っているならば、判断段階 1424 にて、共同基金を分配すべきかどうかの決定をすることができる。共同基金を分配すべきとの決定がなされた場合には、段階 1426 にて、共同基金に残った対価物を分配できる。判断段階 1424 で共同基金を分配すべきでないと決定がなされた場合（将来のショッピングセッションに備えて共同基金を保持できるといったような場合など）や、判断段階 1422 で共同基金に対価物が残っていなかった場合や、もしくは段階 1426 の作業の完了に際して、方法 1400 を終了できる。

或る実施形態例では、判断段階1418 もしくは段階 1420 の作業の完了後に、判断段階
1422 、判断段階 1424 、および段階 1426 の作業を飛ばしてもよい。

図１５では、或る実施形態例にかかる、派生的セッションを実行するための方法 1500 を示してある。或る実施形態例では、方法 1500 を段階 518 （図５参照）にて実施可能である。

段階 1502 では、派生的セッションを開始できる。派生的セッションの開始には例えば、その派生的セッションのユーザーに、そのユーザーのユーザーアクティビティを複数のユーザーの他のユーザーと共有しなくてもよい、追加インターフェイスおよび／もしくは既存のインターフェイスを与えることを含めてもよい。

段階 1504 では、共同的セッションのために、併合規準にアクセスできる。共同的セッションのための併合規準を、例えば段階 502 （図５参照）において定義可能である。

判断段階 1506 では、閲覧要求を受信したかどうかについての判断を下すことができる。閲覧要求を受信していたならば、段階 1508 にて、閲覧要求を処理できる。或る実施形態例では、段階 1508 での作業に、段階 606 （図６参照）にて実施する作業を含めることができる。判断段階 1506 にて閲覧要求が受信されなかった場合、もしくは、段階 1508 の作業の完了に際して、方法 1500 を判断段階 1510 へと進めることができる。

判断段階 1510 では、派生的セッションを終了させるかどうかの決定を下すことができる。派生的セッションを続ける場合には、方法 1500 を判断段階 1506 へと回帰させられる。判断段階 1510 で派生的セッションを終了することになるのであれば、方法 1500 を判断段階 1512 へと進めることができる。

判断段階 1512 では、併合規準を満たしているかどうかについての判断を下すことができる。こうした併合規準を使うことで、ユーザーの関わる派生的セッションを、共同的セッションに併合できるか否かの判断をすることができる。併合規準として想定できるものとしては例えば、派生的セッションのユーザーが併合を要求していたこと、派生的セッションのユーザーが併合を要求していてかつその併合が共同的セッションの参加者のうちの幾人か（もしくは全員）の支持を受けたこと、派生的セッションの現行コンテンツが共同的セッションの現行コンテンツに関係するものであったこと、ならびに、派生的セッションの現行コンテンツが共同的セッションの関心領域に関係するものであったこと、などがある。

併合規準が満たされていたならば、段階 1516 にて、派生的セッションと共同的セッションを併合できる。例えば併合をする際に、派生的セッションのコンテンツが、共同的セッションのコンテンツに取って代わってもよい。判断段階 1512 で併合規準が満たされていなかった場合には、段階 1514 にて、派生的セッションを終了できる。段階 1514 もしくは段階 1516 の作業を完了したら、方法 1500 を終了できる。

或る実施形態例では、或るユーザーが派生的セッションに関与して、そのユーザーが共同的セッションの他の参加者と共有しようとしていることが閲覧要求を通じて確認されたときには、そのユーザーはコンテンツの確認ができる。ユーザーが確認したコンテンツを、他の参加者と共有しようとしていた場合には、方法 1500 を判断段階 1512 へと進めて、併合規準が満たされたかどうかを判断できる。ユーザーが確認したコンテンツを、他の参加者と共有しようとはしていなかった場合には、判断段階 1510 にて派生的セッションを終了するかどうかの決定を行った後に、方法 1500 を終了できる。

図１６には、或る実施形態例にかかる、プライベートセッション（プライベートショッピングセッションなど）を実行するための方法 1600 を示してある。或る実施形態例では、方法 1600 を、段階 410 （図４参照）にて実施でき、かつ／あるいは、ショッピングセッション・アプリケーション234 （図２参照）で実施してもよい。

段階 1602 では、プライベートセッション（プライベートショッピングセッションなど）を開始できる。プライベートセッションとしては、プライベートセッションの各ユーザーが、商材への特権的なアクセス（その権利を持っていなければ不可能な商材へのアクセスなど）、または、特価（割引価格や無料など）での商材へのアクセスができるような、一名以上のユーザーに対するセッションが含まれる。

段階 1604 では、プライベートセッションについて、ひとつ以上の完了規準を設定できる。完了規準として想定されるものとしては例えば、セッション中に所定の数の商材を（ユーザーが支払った対価物で、および／もしくは、商材の適正市場価格で）購入したこと、セッション中に或る任意の商材を購入したこと、セッション中に総額で特定の対価物でひとつ以上の商材を購入したこと、セッションに対して設定された期間が満了したこと、ならびに、所定の時刻、といったものがありえる。

段階 1606 では、複数の参加者（選抜されて参加したユーザーなど）を、プライベートセッションに関連づけることができる。例えば、ネットワークシステム 102 内の過去履歴や、ネットワークシステム 102 内の一名以上の出品者や、ネットワークシステム 102 内でのひとつ以上の商材の購入歴や、ならびに参加者の地位（ひとつ以上の無料商材を貰える催事に出席する著名人である、など）、といった事を踏まえて複数の参加者を選抜し、関連づけることが可能である。或る実施形態例では、参加者がプライベートセッション中に、共同的にではなくプライベート的に参加する。

段階 1608 では、プライベートセッションに関して、プライベートセッション要素を指定可能である。そうしたプライベートセッション要素として想定できるものは例えば、プライベートセッションの参加者が利用可能な信販（クレジット）の指定、プライベートセッション中に利用可能なエリアの指定、プライベートセッション中に購入可能な商材の指定、プライベートセッションに関与する出品者の指定、プライベートセッションに関与するストアの指定、およびプライベートセッションに関する値つけの指定、といったものがある。プライベートセッション要素の指定に関する実施形態例については、以降でさらに詳しく説明してゆく。

段階 1610 では、ひとつ以上のユーザー対話を処理できる。或る実施形態例では、段階
514 （図５参照）での作業を、段階1610 にて実施可能である。段階 1610 では例えば、プライベートセッションに関し、連絡、カーソル移動要求、指示要求、実行要求、および注文要求を処理できる。

段階 1612 では、プライベートセッションの参加者に関して、完了規準が満たされているかどうかを判断できる。プライベートセッションの参加者に関して完了規準が満たされていなかったならば、方法 1600 を段階 1610 へと回帰させられる。或る参加者について完了規準が満たされていたならば、段階 1614 にて、完了規準を満たしたその参加者をプライベートセッションから除外できる。

判断段階 1616 では、一名以上の参加者が、プライベートセッションに残っているかどうかを判断できる。プライベートセッションに参加者が残っていた場合には、方法 1600 を段階 1610 へと回帰させられる。判断段階 1616 で参加者が残っていなければ、方法 1600 を終了できる。

図１７では、或る実施形態例にかかる、セッション要素を指定するための方法 1700 を示してある。或る実施形態例では、方法 1700 を段階 1608 （図１６参照）にて実施可能である。

段階 1702 にて、ひとつ以上のプライベートセッション要素選択（private session parameter selections）へアクセスできる。

判断段階 1704 では、信販を指定できるかどうかの判断を下すことができる。そうした信販には例えば、プライベートショッピングセッションの複数の参加者の各々が利用可能な貯蓄対価物（同じ信販もしくは異なる信販など）を含めることができる。信販が指定されることになったならば、段階 1706 にて、セッションの参加者に対してその信販を指定できる。判断段階 1704 にて信販を指定しない旨の判断がなされた場合、もしくは、段階
1706 の作業の完了に際して、方法1700 を判断段階 1708 へと進めることができる。

判断段階 1708 では、エリアを指定するかどうかの判断を下すことができる。エリアを指定することになったならば、段階 1710 にて、セッションに対するエリアを指定できる。例えば段階 1710 で、プライベートセッション中に買いものをするための場所に関するひとつ以上のエリアを指定可能である。判断段階 1708 にてひとつ以上のエリアを指定しないことになった場合、もしくは、段階 1710 での作業の完了に際して、方法 1700 を判断段階 1712 へと進めることができる。

判断段階 1712 では、ひとつ以上の商材を指定するかどうかの判断を下すことができる。ひとつ以上の商材を指定することになったならば、段階 1714 にて、セッションに対するひとつ以上の商材を指定できる。例えば、プライベートセッション中に購入可能なものとしてひとつ以上の商材を指定可能である。判断段階 1712 にてひとつ以上の商材を指定しないことになった場合、もしくは、段階 1714 での作業の完了に際して、方法 1700 を判断段階 1716 へと進めることができる。

判断段階 1716 では、一名以上の出品者を指定するかどうかについての判断を下すことができる。一名以上の出品者を指定することになったならば、段階 1718 にて、セッションに対して一名以上の出品者を指定できる。例えば段階 1718 では、プライベートセッション中に購入可能な商材を販売できる一名以上の出品者を指定可能である。判断段階 1716 にて一名以上の出品者を指定しないことになった場合、もしくは、段階 1718 での作業の完了に際して、方法 1700 を判断段階 1720 へと進めることができる。

判断段階 1720 では、ひとつ以上のストアを指定するかどうかの判断を下すことができる。ひとつ以上のストアを指定することになったならば、段階 1722 にて、セッションに対してひとつ以上のストアを指定できる。例えばひとつ以上のストアが、プライベートセッション中に購入可能なひとつ以上の商材を販売できる。判断段階 1720 にてひとつ以上のストアを指定しないことになった場合、もしくは、段階 1722 での作業の完了に際して、方法 1700 を判断段階 1724 へと進めることができる。

判断段階 1724 では、プライベートセッションでの値つけを指定するかどうかについての判断を下すことができる。値つけを指定することになった場合は、段階 1726 にて、プライベートセッションでの値つけを指定できる。例えば段階 1726 では、商材に対して特価（割引価格や無料など）をつけることができる。判断段階 1724 にて値つけを指定しないことになった場合、もしくは、段階 1726 での作業の完了に際して、方法 1700 を判断段階 1728 へと進めることができる。

判断段階 1728 では、アクセスすべきさらなる選択があるかどうかの決定をすることができる。アクセスすべきさらなる選択があったならば、方法 1700 を段階 1702 へと回帰させられる。さらなる選択がなかったならば、方法 1700 を終了できる。

図１８では、或る実施形態例にかかる、共同的セッションを実施するための方法 1800 を示してある。或る実施形態例では、方法 1800 を、段階 406 （図４参照）にて実施してもよいし、かつ／あるいは、ショッピングセッション・アプリケーション 234 （図２
参照）で実施してもよい。

段階 1802 では、共同的セッション（共同的ショッピングセッションなど）を開始できる。共同的セッションには例えば、共通インターフェイス上で対話する複数の参加者を含めてもよい。

段階 1804 では、共同的セッションの主参加者を選択できる。主参加者として想定されるものとしては例えば、共同的セッションのスポンサー、共同的セッション中に購入された商材のいずれかについての支払の責任を負うユーザー、別のユーザーへ向かって実演をしてみせるユーザー、保護者、および著名人、といったものが挙げられる。

段階 1806 では、完了規準を指定できる。完了規準として想定されるものとしては例えば、セッション中に所定の数の商材を（ユーザーが支払った対価物で、および／もしくは、商材の適正市場価格で）購入したこと、セッション中に或る任意の商材を購入したこと、セッション中に総額で特定の対価物でひとつ以上の商材を購入したこと、セッションに対して設定された期間が満了したこと、ならびに、所定の時刻、といったものがありえる。

段階 1808 では、一名以上の副参加者を選択できる。副参加者として想定されるものとしては例えば、共同的セッションの被後援ユーザー、共同的セッション中に購入された商材のいずれかについての支払の責任を負わないユーザー、別のユーザーからの実演を受けるユーザー、児童、および著名人のファン、といったものが挙げられる。

段階 1810 では、（主参加者および／もしくは副参加者などからの）複数のユーザー対話を処理可能である。或る実施形態例では、段階 514 （図４参照）の作業を、段階 1810
にて実施可能である。段階 1810 では例えば、共同的セッションに関し、連絡、カーソル移動要求、指示要求、実行要求、および注文要求を処理できる。

段階 1812 では、完了規準が満たされているかどうかを判断できる。完了規準が満たされていなかったならば、方法 1800 を段階 1810 へと回帰させられる。段階 1812 で完了規準が満たされていたならば、段階 1814 にて、副参加者を共同的セッションから除外できる。例えば、完了規準が満たされたときに、共同的セッションの参加者に対して、共同的セッションを終了させることができる。

判断段階 1816 では、別の副参加者がいるかどうかについての判断を下せる。別の副参加者がいれば、方法 1800 を段階 1808 へと回帰させられる。別の副参加者がいなければ、方法 1800 を終了できる。

図１９では、或る実施形態例にかかる、セッションを作成するための方法 1900 を示してある。或る実施形態例では、方法 1900 を、クライアント機 110, 112 上および／もしくはサードパーティサービス 130 上で実行できる（図１参照）。

段階 1902 では、セッションについて、ユーザー規準、および／もしくは一名以上のユーザーを指定できる。例えばそうしたユーザー規準および／もしくは一名以上のユーザー（についての情報）を、ショッピングセッション・アプリケーション 234 （図２参照）に与えることが可能である。段階1904 では、セッションに対してセッション要素を指定できる。段階 1906 では、完了規準を確認できる。

段階 1910 では、セッションに関連づけられたユーザーへと、セッションのことを通知できる。例えばユーザーに、セッションへアクセスするためのパスワードおよび／もしくは他の情報を提供可能である。段階 1910 での作業が完了したら、方法 1900 を終了できる。

図２０には、コンピュータシステム2000 の形態例内の機械を模式的に表現したブロック図である。このコンピュータシステム 2000 内で命令の組を実行することで、本明細書にて述べる方法のうちのひとつ以上を機械に実施させることが可能である。別の実施形態では、機械がスタンドアローンな装置として動作することもできるし、あるいは、他の機械に接続（ネットワーク接続など）するようにしてもよい。ネットワーク的構成を採る場合には、そうした機械を、サーバ-クライアントネットワーク環境内でサーバの役割もしくはクライアント機の役割を与えて動作させることもできるし、あるいは、ピアツーピア（もしくは分散型）ネットワーク環境内でピア機として動作させてもよい。こうした機械としては、サーバコンピュータ、クライアントコンピュータ、パーソナルコンピュータ（PC）、タブレットPC、セットトップボックス（STB）、パーソナルデジタルアシスタント（PDA）、携帯電話、webアプライアンス、ネットワークルーター、スイッチ、もしくはブリッジ、または、機械がとる動作を指定する命令の組を（逐次的にかその他のやりかたで）実行可能な任意の機械、といったものを想定できる。さらに言えば、単独の機械のみを説明してはいるが、「機械」という語には、本明細書にて説明した方法論のいずれかひとつ以上を実施するための命令の組（もしくは複数の組）を、個別にかまたは連帯して実行できる機械の任意の集合体をも含めるよう解釈すべきである。

例示的なコンピュータシステム2000 には、プロセッサ 2002 （中央処理装置（CPU）
、画像処理装置（GPU）、もしくはその双方、など）と、メインメモリ 2004 と、静的メモリ 2006 と、が含まれており、これらの要素は互いにバス 2008 を介して連絡している。コンピュータシステム 2000 にはさらに、ビデオディスプレイ装置 2010 （液晶ディスプレイ（LCD）もしくはブラウン管（CRT）など）を含めてもよい。また、コンピュータシステム 2000 にはさらに、英数入力装置 2012 （キーボードなど）と、カーソル操縦装置2014 （マウスなど）と、ドライブユニット 2016 と、信号発生装置 2018 （スピーカーなど）と、ネットワークインターフェイス装置 2020 とが含まれる。

ドライブユニット 2016 は、機械可読媒体 2022 を含む。この機械可読媒体 2022 には、本明細書に記載した方法もしくは機能のうちのいずれかひとつ以上を具現化できる命令のひとつ以上の組（ソフトウェア 2024 など）が格納される。また、ソフトウェア 2024 は、コンピュータシステム 2000 によって実行されている最中、完全にか少なくとも部分的に、メインメモリ2004 および／もしくはプロセッサ 2002 の中にも存在できる。つまりメインメモリ 2004 およびプロセッサ 2002 もまた、機械可読媒体をなすというわけである。

さらにソフトウェア 2024 を、ネットワークインターフェイス装置 2020 を用い、ネットワーク 2026 を介して送信もしくは受信することも可能である。

或る実施形態例においては機械可読媒体 2002 を単独の媒体として示してはあるが、「機械可読媒体」という語は、命令のひとつ以上の組を格納する単独または複数の媒体を含むと解釈されたい。そうした媒体としては例えば、集約型もしくは分散型のデータベース、ならびに／または、関連するキャッシュおよびサーバ、などがある。なお「機械可読媒体」という語は、機械により実行できる命令の組を格納、符号化、もしくは担持でき、かつ、その機械に本発明の方法のうちのいずれかひとつ以上を実施させる、という任意の媒体をも含むと解釈されたい。つまり「機械可読媒体」という語は、固相メモリ、光メディアおよび磁気メディア、ならびに搬送波信号、を含むと解釈されるべきであるが、それらに限定もされない。

以降の説明はショッピングセッションに関する用語を以って説明しているが、ショッピング以外の目的に対しても、共同的セッション、プライベートセッション、および派生的セッションを実行可能であることを理解されたい。

以上、支払のための方法とシステムを説明してきた。本発明を説明するにあたっては、特定の実施形態例に関連して行ってはきたが、本発明のより広汎な本質から逸脱することなく、さまざまな変形例と変更例を想到できるのは明らかであろう。つまり、本願明細書および図面は、あくまで例示のためのものであって、限定的な意味を持つものではない。

本開示の要約書は、37 C.F.R. §1.72(b) に従い、読者が手早く技術開示の本質を掴めるようにするための要約を提供するものである。本要約書の提出は、請求項の範囲や意義を解釈したり限定するためには使われないという理解の下で行われている。また、前掲した『発明を実施するための形態』の項においては、本開示を合理化する目的を以って、種々の特徴を単独の実施形態にまとめて示してあることがわかるだろう。しかしこうした開示手法から、請求する実施形態が、各請求項にて明示的に参照している特徴よりも多くの特徴を必要とするのだと言いたいわけではない。そうではなくて、以降に記載する請求項からもわかるように、特許性を有する構成要素たちは、開示した単独の実施形態が持つすべての特徴よりも数少ないのである。つまり、後述する請求項は、その各々が個別の実施形態であるかのようにして、『発明を実施するための形態』の項に包摂されるのである。

Claims (1)

1. 命令を含んだコンピュータ可読媒体であって、前記命令はコンピュータにより実行されると、前記コンピュータに、
   ネットワークシステムにおいて支払いを行うための、複数の支払元及び該複数の支払元の優先度を定義する、支払明細要求を受信するステップと、
   前記支払明細要求において、前記ネットワークシステムを介して行われるトランザクションに対して複数のユーザーから供出される対価物の量の一部に関する割合配分を指定する支払充当法が受信されたかどうかを判定するステップと、
   前記支払明細要求において前記支払充当法が受信されていないと判定されたことに基づいて、前記複数のユーザーから供出されるデフォルトの支払充当法を識別するステップと、
   前記支払明細要求において指定された前記優先度に基づいて、前記複数の支払元のうちの少なくとも１つから、少なくとも前記量の前記一部の支払を行うステップと、
   を含む処理を行わせることを特徴とする、コンピュータ可読媒体。