CN101828196A - 虚拟商店街管理系统 - Google Patents

Abstract

提供在虚拟商店街服务中，将接受订购后的订购内容的修正妥当的情况作为记录保留的结构。虚拟商店街管理服务器(10)从加盟店终端(40)接受订购内容的修正时(S615)，计算变更前后的差额。在判定为差额是规定金额以上时(S620为“是”)，生成结账处理的委托页并发送到加盟店终端(40)(S625a)。在从加盟店终端(40)接受结账处理的委托信息时，对会员终端(30)发送委托对于金额变更的承认的电子邮件(S630a)。在对于金额变更的承认与否的选择页中，从会员终端(30)接受对于金额变更的承认或者否认的响应时(S635a)，判定是承认还是否认(S640a)。在判定为来自会员终端(30)的响应是承认时(S640a为“是”)，判断为订购内容的修正是妥当的，在确定订购内容的变更后，对银行委托户头转账处理(S645a)。

Description

虚拟商店街管理系统

技术领域

本发明涉及支持经由网络销售商品的商人的买卖交易业务的系统，特别涉及管理运营虚拟商店街的系统中的订购内容的修正。

背景技术

在经由网络买卖商品等时，大多利用用于支持买卖交易的系统的虚拟商店街。

在利用虚拟商店街的交易中，在交易的当事人之间(销售者和购买者)接受订购后(结账完成前)修正订购内容时，通常在交易的当事人之间通过电话、邮件等直接进行交涉，管理运营虚拟商店街的虚拟商店街管理系统并没有参与其中。

<以往例>

使用图1～图3说明在以往的虚拟商店街管理系统中接受订购后订购内容被修正的情况下的处理流程。

(1)以往的系统结构

图1例示管理运营虚拟商店街的以往的系统结构。

如图1所示，以往的系统由统一管理虚拟商店街的虚拟商店街管理服务器10、经由互联网等网络20与虚拟商店街管理服务器10连接的虚拟商店街的会员终端30以及虚拟商店街的加盟店终端40构成。会员终端30以及加盟店终端40具有浏览器，能够经由网络20从虚拟商店街管理服务器10接受服务。

(2)基于以往的系统的接受订购处理

下面，使用图2的时序图说明通过以往的系统接受商品的订购时的处理流程。

如图2所示，虚拟商店街管理服务器10首先对会员终端30发送商品的选择页，使会员选择应订购的商品(S205)。会员在该选择页中选择应订购的商品。

在上述选择页中选择了商品时，虚拟商店街管理服务器10对会员终端30发送登录页，对成为订购者的会员进行认证(S210)。会员对该登录页输入ID以及口令等从而接受认证。

另外，当商品的购买者没有注册时，对会员终端30发送会员注册信息的输入页，要求购买者进行会员注册。

在完成了经由上述登录页的会员认证时，虚拟商店街管理服务器10对会员终端30发送结账方法的选择页，使会员选择结账方法(S215)。会员在该选择中选择结账方法(例如，银行汇款、货到付款、信用卡等)。

在上述选择页中选择了结账方法时，虚拟商店街管理服务器10对会员终端30发送订购内容的确认页，请求会员确认订购内容(S220)。会员确认在该确认页中显示的订购内容是否有错。

在上述确认页中确认了订购内容时，虚拟商店街管理服务器10对会员终端30发送订购的完成页，将接受了订购的情况与订购号等一起对会员进行提示(S225)。

(3)基于以往的系统的订购内容的变更处理

下面，使用图3的时序图说明在以往的系统中接受订购后订购内容被修正的情况下的处理流程。

另外，图3的时序图表示在通过图2所示的处理订购了商品之后的处理。

如图3所示，虚拟商店街管理服务器10基于所选择的商品的信息等而进行订购的接受处理(S305)。这里，对每个订购号(由图2的S225赋予的号)生成规定的订购信息，并将其存储在规定的数据库中。

在订购的接受处理完成时，虚拟商店街管理服务器10对会员终端30以及加盟店终端40发送表示接受了订购的确认邮件，并对会员(购买者)以及加盟店(销售者)通知接受了订购的情况(S310、S315)。另外，对于会员终端30以及加盟店终端40的电子邮件几乎同时被发送。

在接受上述通知时，加盟店(负责人)利用加盟店终端40登录到虚拟商店街管理服务器10，并请求订购内容的确认页。在从加盟店终端40有确认页的请求时，虚拟商店街管理服务器10对加盟店终端40发送订购内容的确认页，并要求加盟店确认订购内容(S320)。加盟店(负责人)在接收到的订购内容的确认页中，确认订购内容。

然后，在因某种理由而在订购内容(金额)中产生了变化时，在加盟店(负责人)和会员之间，不经由虚拟商店街管理服务器10，而通过电话、邮件等直接进行交涉(S325)。该直接交涉以加盟店侧的事情(例如，规定的运费的相加)、会员侧的事情(包装的追加、订购数的变更)的任一个为起因。

在通过上述直接交涉决定修正内容(修正金额)时，加盟店(负责人)利用加盟店终端40登录到虚拟商店街管理服务器10，并请求订购内容(金额)的修正页。在从加盟店终端40有修正页的请求时，虚拟商店街管理服务器10对加盟店终端40发送订购内容的修正页，并接受来自加盟店终端40的订购内容(金额)的修正(S330)。

在接受了订购内容(金额)的修正时，虚拟商店街管理服务器10进行订购内容的变更处理(S335)。这里，使通过订购的接受处理(S305)生成的订购信息原样反映接受的修正。

在订购内容的变更处理完成时，虚拟商店街管理服务器10对会员终端30以及加盟店终端40发送表示变更了订购内容的电子邮件，对会员以及加盟店通知变更了订购内容的情况(S340、S345)。另外，对于会员终端30以及加盟店终端40的电子邮件几乎同时被发送。

在以上的处理完成时，接受的订购将成为可根据变更后的金额进行结账。之后，在会员和加盟店之间，以在结账方法的选择处理(图2的S215)中所选择的方法来进行货款的结账。

(4)以往的系统的问题点

这样，在利用虚拟商店街的交易中，在接受订购之后修正订购内容时，采用了在交易的当事人之间通过电话、邮件等直接进行交涉的方法。因此，即使与索取金额的大幅增额相关的情况下，订购内容被修正的过程也不会作为记录留在管理运营虚拟商店街的系统中。这样的状况成为围绕交易的当事人之间的交易内容的纠纷的温床。

特别，在结账方法的选择处理(图2的S215)中，选择了经由结账机构且会员(购买者)不会主动参与金钱的支付的结账方法(例如，信用卡等)时，会员没有用于保留或者拒绝货款的支付的选择机会。因此，若按照修正后的金额进行结账，则存在购买了商品的会员会蒙受难以预料的不利的顾虑。

发明内容

发明要解决的课题

本发明的课题在于，提供一种在虚拟商店街服务中，将接受订购后的订购内容的修正妥当的情况作为记录保留的结构。

用于解决课题的方案

为了解决上述课题，本发明是用于支持虚拟商店街的加盟店和会员之间的交易的虚拟商店街管理系统中的订购信息的修正处理，其特征在于，包括：修正信息接收部件，从所述加盟店的终端接收与所述订购信息有关的修正信息；委托承认变更邮件发送部件，在基于所述修正信息而判定为在索取金额上产生了超过规定金额的变更时，发送用于对所述会员的终端委托对于超过该规定金额的变更的承认的电子邮件；承认与否信息接收部件，从所述会员的终端接收对于超过所述规定金额的变更的承认信息或者否认信息；以及订购确定部件，在所述承认与否信息接收部件接收到承认信息时确定所述订购信息的修正，在接收到否认信息时取消所述订购信息。

所述承认与否信息接收部件在规定期间内没有接收承认信息或者否认信息时，所述订购确定部件也可以取消所述订购信息。

所述承认与否信息接收部件在规定期间内没有接收承认信息或者否认信息时，所述委托承认变更邮件发送部件也可以再次发送用于对所述会员的终端委托对于超过所述规定金额的变更的承认的电子邮件。

在所述虚拟商店街管理系统中，也可以还包括：结账处理委托部件，在所述订购确定部件确定了所述订购信息的修正时，对规定的结账机构委托关于所述交易的结账处理。

此外，本发明是支持虚拟商店街的加盟店和会员之间的交易的虚拟商店街管理系统中的订购信息的修正方法，其特征在于，包括：修正信息接收步骤，从所述加盟店的终端接收与所述订购信息有关的修正信息；委托承认变更邮件发送步骤，在基于所述修正信息而判定为在索取金额上产生了超过规定金额的变更时，发送用于对所述会员的终端委托对于超过该规定金额的变更的承认的电子邮件；承认与否信息接收步骤，从所述会员的终端接收对于超过所述规定金额的变更的承认信息或者否认信息；以及订购确定步骤，在所述承认与否信息接收步骤中接收到承认信息时确定所述订购信息的修正，在接收到否认信息时取消所述订购信息。

使计算机将所述虚拟商店街管理系统的各个部件作为功能来实现的程序也是本发明。

发明效果

本发明的虚拟商店街管理系统对于与索取金额的大幅变更相关的订购内容的修正，要求购买者的承认。由此，能够将对于订购内容的修正已得到购买者的承认的信息作为记录来保留。

作为其结果，能够将围绕交易的当事人之间的交易内容的纠纷防患于未然。此外，即使实际发生了纠纷，也能够通过活用记录内容，从而避免成为不可收拾的事态。

附图说明

图1是表示以往的系统的结构例的图。

图2是表示经由以往的系统接受商品的订购时的处理流程的时序图。

图3是表示以往的系统中的接受订购后，订购内容被修正的情况下的处理流程的时序图。

图4是表示本实施方式的系统的结构例的图。

图5(a)是表示会员信息的主要项目的图，图5(b)是表示加盟店信息的主要项目的图，图5(c)是表示商品信息的主要项目的图，图5(d)是表示订购信息的主要项目的图。

图6是表示在本实施方式的系统中与索取金额的大幅变更相关的订购被修正，从而对会员请求对于金额变更的承认时的处理流程的时序图。

图7是表示基于本实施方式的系统中的虚拟商店街管理服务器的处理细节的流程图。

图8是表示订购内容的修正页的例子的图。

图9(a)是表示在判定为变更前后的差额为规定金额以上时发送到加盟店终端的结账处理的委托页的例子，图9(b)是表示在判定为变更前后的差额不是规定金额以上时发送到加盟店终端的结账处理的委托页的例子的图。

图10是表示对于金额变更的承认委托邮件的例子的图。

图11是表示购买历史的确认页的例子的图。

图12是表示对于金额变更的承认与否的选择页的例子的图。

图13是表示对于金额变更的承认委托邮件(发往移动终端)的例子的图。

图14是表示购买历史的确认页(移动终端用)的例子的图。

图15是表示对于金额变更的承认与否的选择页(移动终端用)的例子的图。

标号说明

10虚拟商店街管理服务器

11会员信息数据库

12加盟店信息数据库

13商品信息数据库

14订购信息数据库

20网络

21专用线

30会员终端

40加盟店终端

50银行服务器

800订购内容的修正页

900a在判定为变更前后的差额为规定金额以上时所发送的结账处理的委托页

900b在判定为变更前后的差额不是规定金额以上时所发送的结账处理的委托页

1000对于金额变更的承认委托邮件

1100购买历史的确认页

1200对于金额变更的承认与否的选择页

1300对于金额变更的承认委托邮件(发往移动终端)

1400购买历史的确认页(移动终端用)

1500对于金额变更的承认与否的选择页(移动终端用)

具体实施方式

下面，参照图4～图12说明本发明的实施方式的一例。

本实施方式的系统对于与索取金额的大幅增额相关的订购内容的修正，要求商品购买者的确认。

作为前提，本实施方式的系统所提供的虚拟商店街服务是以在进行利用注册的用户(会员)和进行分店注册的店铺(加盟店)之间进行的交易作为对象。另外，这是运用的一个方式，也可以扩大成为服务对象的交易(例如，扩大为将未注册的用户作为当事人的交易)。

以下的说明利用在确定了订购内容(索取金额)的变更后，通过会员有着户头的银行而进行基于户头转账的结账的情况的例子。户头转账是经由结账机构(银行)进行的结账方法，在交易成立后货款从会员的户头被自动地扣除这一点上，相当于“会员(购买者)不会主动参与金钱的支付”的结账方法。

另外，在本实施方式中，将从会员(购买者)的银行户头汇出货款，从对加盟店(销售者)的银行户头缴纳货款的结账方法称为“户头转账”。

<本实施方式的说明>

(1.本实施方式的系统结构)

使用图4以及图5说明本实施方式的系统结构。

本实施方式的系统结构除增加了银行的服务器之外，基本上与图1所示的以往的系统结构相同。这里，详细说明虚拟商店街管理服务器中所构筑的数据库。

(1-1.虚拟商店街管理服务器)

在图4中，虚拟商店街管理服务器10是统一管理从订购的接受至交易完成为止的服务器。这里，关于本实施方式的系统，说明必要的部分。

(1-2.会员信息数据库)

在图4中，会员信息数据库11是存储利用本实施方式的系统所提供的服务而购买商品的用户的信息(以下，称为“会员信息”)的数据库。这里，关于本实施方式的系统，说明必要的部分。

另外，在本实施方式中，将会员信息数据库11构筑在内置于虚拟商店街管理服务器10的存储装置中，但如果能够读出存储的信息，则也可以构筑在其他独立的存储装置中。

图5(a)表示会员信息数据库11的主要项目。

在图5(a)中，“会员ID”是进行利用注册的会员的唯一的识别信息。“口令”是在该会员的认证中使用的口令。“邮件地址”是该会员使用的会员终端30(后述)的邮件地址。“个人信息”是该会员的个人信息(例如，姓名、性别、住所、电话号码等)。

另外，会员的认证(登录)中，利用会员信息的项目中的“会员ID”以及“口令”。

(1-3.加盟店信息数据库)

返回图4，加盟店信息数据库12是存储对本实施方式的系统所提供的服务设立分店而销售商品的店铺的信息(以下，称为“加盟店信息”)的数据库。这里，关于本实施方式的系统，仅说明必要的部分。

另外，在本实施方式中，将加盟店信息数据库12构筑在内置于虚拟商店街管理服务器10的存储装置中，但如果能够读出存储的信息，则也可以构筑在其他独立的存储装置中。

图5(b)表示加盟店信息数据库12的主要项目。

在图5(b)中，“加盟店ID”是进行分店注册的店铺的唯一的识别信息。在本实施方式中，作为加盟店ID而使用该加盟店的域名。“认证密钥”是该加盟店的认证所使用的密钥。“邮件地址”是该加盟店所使用的加盟店终端40(后述)的邮件地址。“负责人ID”是该加盟店中的接受订货管理业务的负责人的识别信息，至少注册有一个。“店铺信息”是该加盟店的店铺的信息(例如，名称、刊登了店铺的细节的网页的URL等)。

另外，在加盟店的认证(登录)中，使用加盟店信息的项目中的“加盟店ID”、“负责人ID”以及“认证密钥”。

(1-4.商品信息数据库)

返回图4，商品信息数据库13是存储在本实施方式的系统所提供的服务中受理的商品的信息(以下，称为“商品信息”)的数据库。这里，关于本实施方式的系统，仅说明必要的部分。

另外，在本实施方式中，将商品信息数据库13构筑在内置于虚拟商店街管理服务器10的存储装置中，但如果能够读出存储的信息，则也可以构筑在其他独立的存储装置中。

图5(c)表示商品信息数据库13的主要项目。

在图5(c)中，“商品码”是在本实施方式的系统所提供的服务中受理的商品的唯一的识别信息。“名称”是该商品的名称。“单价”是对该商品所设定的单位数量的价格。“商品关联信息”是与该商品关联的信息(例如，受理店铺的ID(加盟店ID)等)。

(1-5.订购信息数据库)

返回图4，订购信息数据库14是存储在本实施方式的系统所提供的服务中接受的订购的信息(以下，称为“订购信息”)的数据库。这里，关于本实施方式的系统，仅说明必要的部分。

另外，“订购信息”中附有“会员信息”、“加盟店信息”以及“商品信息”。

此外，在本实施方式中，将订购信息数据库14构筑在内置于虚拟商店街管理服务器10的存储装置中，但如果能够读出存储的信息，则也可以构筑在其他独立的存储装置中。

图5(d)表示订购信息数据库140的主要项目。

在图5(d)中，“订购号”是利用了本实施方式的系统所提供的服务的订购的唯一的识别信息。“订购日期时间”是接受该订购的日期时间。“会员ID”是进行了该订购的会员的识别信息，在订购信息中附上会员信息。“加盟店ID”是接受该订购的加盟店的识别信息，在订购信息中附上加盟店信息。

同样地，在图5(d)中，“商品码”是该订购中的商品的识别信息，在订购信息中附上商品信息。“数量”是该商品的订购数目。“索取金额”是在该订购中索取的金额的合计值。“结账方法”是该订购的结账方法(例如，银行汇款、货到付款、信用卡、户头转账等)。“接受订货处理状态”是表示该订购的接受订货处理的进展状况的区分(例如，“新接受”、“等待寄送”、“完成”、“取消”等)。“结账处理状态”是表示该订购的结账处理的进展状况的区分(例如，“未处理”、“等待转账委托”、“未承认”、“等待确认余款”、“准备缴纳中”、“不能转账”、“完成”、“不能缴纳”等)。另外，在本实施方式中，将“接受订货处理状态”的初始值设为“新接受”，将“结账处理状态”的初始值设为“未处理”。

同样地，在图5(d)中，“修正日期时间”是对该订购信息进行了修正的日期时间。“修正金额”是该订购信息的修正后的索取金额。“金额变更承认标记”是表示对于该金额变更是否从会员得到承认的标记。

另外，“修正日期时间”、“修正金额”、“金额变更承认标记”是只在接受了订购内容的修正时设置的项目，在没有修正时不设置这些项目。此外，在多次修正了订购内容时，每当该修正时设置“修正日期时间”、“修正金额”以及“金额变更承认标记”。

(1-6.会员终端)

返回图4，会员终端30是利用本实施方式的系统所提供的服务而购买商品的用户(会员)所使用的终端。在本实施方式中，例如设为个人计算机或移动电话等具有通信功能的终端。

会员终端30具有浏览器，通过经由互联网等网络20与虚拟商店街管理服务器10连接，从而能够经由本实施方式的系统对任意加盟店订购商品。

(1-7.加盟店终端)

加盟店终端40是利用本实施方式的系统所提供的服务而销售商品的店铺(加盟店)所使用的终端。在本实施方式中，例如设为个人计算机或移动电话等具有通信功能的终端。

加盟店终端40具有浏览器，通过经由互联网等网络20与虚拟商店街管理服务器10连接，从而能够经由本实施方式的系统来管理商品的订购。

(1-8.银行服务器)

银行服务器50是在本实施方式的系统中进行基于户头转账的结账处理的银行的服务器。银行服务器50经由专用线21与虚拟商店街管理服务器10连接，关于结账处理与虚拟商店街管理服务器10协作。此外，在银行服务器50和虚拟商店街管理服务器10之间，对数据进行加密而发送接收。

另外，在本实施方式中，虚拟商店街管理服务器10和银行服务器50经由专用线21连接，但只要能够通过加密等安全地发送接收数据，则也可以经由互联网等的网络20连接。

(2.基于本实施方式的系统的处理流程)

使用图6的时序图说明在本实施方式的系统中与索取金额的大幅变更相关的订购内容被修正，从而对会员要求对于金额变更的承认时的处理流程。

基于本实施方式的系统的订购内容的修正处理与基于图3所示的以往的系统的处理相比，主要在以下两点有所不同。

(a)本实施方式的系统在接受订购后从加盟店接收到与索取金额的大幅变更相关的订购内容的修正时，对进行了该订购的会员要求承认(S630a～S635a)。

(b)本实施方式的系统在从加盟店接受了结账(户头转账)处理的委托后要求会员承认，在从会员获得承认时无需对加盟店再次确认而开始结账(户头转账)处理(S625a～S645a)。

另外，图6的时序图表示通过图2所示的处理订购了商品之后的处理。此外，假设在结账方法的选择处理(图2的S215)中选择了户头转账。

(2-1.订购的接受)

如图6所示，虚拟商店街管理服务器10基于所选择的商品的信息等进行订购的接受处理(S605)。这里，对每个订购号(通过图2的S225赋予的号)生成订购信息(参照图5(d))，并将其存储在订购信息数据库14中。

在订购的接受处理完成时，虚拟商店街管理服务器10对会员终端30以及加盟店终端40发送表示接受了订购的确认邮件，对会员以及加盟店通知接受了订购的情况(S6101、S6102)。

(2-2.修正的接受)

在有上述通知时，加盟店(负责人)利用加盟店终端40登录到虚拟商店街管理服务器10，请求订购内容的确认页。在从加盟店终端40有确认页的请求时，虚拟商店街管理服务器10对加盟店终端40发送订购内容的确认页，并要求加盟店确认订购内容。加盟店(负责人)在该确认页中确认订购内容，如果有必要则从该确认页请求修正页。

在从加盟店终端40有修正页的请求时，虚拟商店街管理服务器10对加盟店终端40发送订购内容的修正页，从加盟店终端40接受订购内容的修正信息(S615)。加盟店(负责人)对该修正页输入必要的修正。

另外，在接受订购内容的修正之前，有时也与以往例(图3的S325)同样地，在加盟店(负责人)和会员之间，通过电话、邮件等直接进行交涉。这是因为，如上述那样，作为与索取金额的大幅变更相关的订购内容的修正，考虑到各种各样的起因(加盟店侧的事情、会员侧的事情)。

(2-3.结账处理的委托的接受)

在接受订购内容的修正信息时，虚拟商店街管理服务器10对加盟店终端40发送结账处理的委托页，对加盟店(负责人)要求基于修正后的金额的结账处理(在本实施方式中为户头转账处理)的委托(S625a)。加盟店(负责人)根据接收到的结账处理的委托页，委托基于修正后的金额的结账处理(户头转账)。

另外，本实施方式的系统在从加盟店有结账处理的委托时，进行用于从会员获得承认的处理。因此，在有与索取金额的大幅变更相关的订购内容的修正时，无一例外地对加盟店求基于修正后的金额的结账处理的委托。

(2-4.承认的委托)

在从加盟店终端40接受到基于修正后的金额的结账处理的委托时，虚拟商店街管理服务器10对会员终端30发送表示接受了与索取金额的大幅变更相关的订购内容的修正的电子邮件，并对会员委托对于金额的变更的承认(S630a)。

接受上述委托的会员利用会员终端30登录到虚拟商店街管理服务器10，请求购买历史的确认页。在从会员终端30有确认页的请求时，虚拟商店街管理服务器10对会员终端30发送购买历史的确认页，并对会员要求对于金额变更的承认与否的响应(S635a)。会员在该购买历史的确认页中确认修正内容，并响应对于金额变更的承认与否。

(2-5.订购内容的变更和结账处理的开始)

在从会员终端30有对于金额变更的承认响应时，由于虚拟商店街管理服务器10从会员获得了确认，因此在确定订购内容的变更后，对银行服务器50委托规定的户头转账处理(S645a)。这里，对于会员具有户头的银行的服务器50，委托规定的户头转账处理。

这样，本实施方式的系统在从会员获得对于金额变更的承认时，无需要求加盟店(负责人)再次确认而开始结账(户头转账)处理。因此，加盟店(负责人)通过利用本实施方式的系统，能够节省用于确认关于订购内容的修正是否从会员获得了承认的时间。

在订购内容的变更处理完成时，虚拟商店街管理服务器10对会员终端30以及加盟店终端40发送表示变更了订购的电子邮件，对会员以及加盟店通知变更了订购的情况(S650a1、S650a2)。

(3.基于本实施方式的系统的处理细节)

使用图7的流程图以及图8～图12的页/邮件的例子来说明基于本实施方式的系统中的虚拟商店街管理服务器的处理细节。

在本实施方式中，将作为是否达到索取金额的大幅变更的基准的阈值(规定金额)设为“1000日元”。另外，该阈值可以适当变更。

下面，使用图7的流程图说明基于虚拟商店街管理服务器的处理流程。另外，图7中表示应参照的其他附图的号。此外，在图6和图7中标号一致的处理分别是相同的处理。

(3-1.订购的接受)

如图7所示，虚拟商店街管理服务器10基于所选择的商品的信息等而进行订购的接受处理(S605)。这里，将订购号(由图2的S225赋予的号)作为关键字而生成订购信息(参照图5(d))，并将其存储在订购信息数据库14中。此外，将订购信息的“接受订货处理状态”设为初始值的“新接受”，将“结账处理状态”设为初始值的“未处理”。

在订购的接受处理完成时，虚拟商店街管理服务器10对会员终端30以及加盟店终端40发送表示接受了订购的确认邮件，并对会员以及加盟店通知接受了订购的情况(S610)。另外，对于会员终端30以及加盟店终端40的电子邮件几乎同时被发送。

(3-2.修正的接受)

在有上述通知时，加盟店(负责人)利用加盟店终端40登录到虚拟商店街管理服务器10，并请求订购内容的确认页。在从加盟店终端40有确认页的请求时，虚拟商店街管理服务器10对加盟店终端40发送订购内容的确认页，并要求加盟店确认订购内容。加盟店(负责人)在接收到的确认页中确认订购内容，如果必要则请求订购内容的修正页。

在从加盟店终端40有修正页的请求时，虚拟商店街管理服务器10对加盟店终端40发送订购内容的修正页，并从加盟店终端40接受订购内容的修正信息(S615)。加盟店(负责人)对该修正页输入必要的修正。

图8中例示订购内容的修正页。修正页800是用于单独确认/修正订购号为“123456-20070601-123456”的订购内容的页。

修正页800由订购内容的确认修正栏810以及按钮820构成。

在订购内容的确认修正栏810中表示与订购号对应的订购信息。这里，表示了附在订购信息上的会员信息以及商品信息、“数量”、“索取金额”等。

在变更订购内容时，对要变更的项目的显示栏中输入变更后的内容，并点击表示为“以该内容进行保存”的按钮820。

返回图7，在从加盟店终端40接受订购内容的修正时，虚拟商店街管理服务器10根据接受的修正内容，更新通过订购的接受处理(S605)而生成的订购信息。这里，追加“修正日期时间”、“修正金额”以及“金额变更承认标记”的项目，并将“结账处理状态”设为“等待转账委托”。另外，在这一时刻，“金额变更承认标记”没有建立。

此外，根据接受的修正信息计算变更前后的差额，并判定该差额是否成为规定金额(1000日元)以上(S620)。

(3-3.结账委托的接受)

在判定为变更前后的差额是规定金额(1000日元)以上时(S620为“是”)，虚拟商店街管理服务器10生成结账处理的委托页并将其发送到加盟店终端40，对加盟店要求结账处理的委托(S625a)。在这时发送的结账处理的委托页中，显示在结账处理之前对会员通知了对于金额变更的承认的委托的意旨。

另一方面，在判定为变更前后的差额不是规定金额(1000日元)以上时(S620为“否”)，虚拟商店街管理服务器10在建立订购信息的“金额承认标记”后，生成结账处理的委托页从而将其发送到加盟店终端40，对加盟店要求结账处理的委托(S625b)。在这时发送的结账处理的委托页中，不显示在结账处理之前对会员通知了对于金额变更的承认的委托的意旨。

图9(a)例示在判定为变更前后的差额是规定金额(1000日元)以上时对加盟店终端40所发送的结账处理的委托页。

结账处理的委托页900a由订购信息显示栏910a以及用于委托结账处理的按钮920a构成。

在订购信息显示栏910a中显示了成为结账处理的对象的订购信息的“订购号”以及“结账处理状态”。此外，通过在显示为“对用户有金额确认”的栏911a上显示图标(icon)，从而显示在结账处理之前对会员通知了对于金额变更的承认的委托的意旨。

在结账处理的委托页900a中，若显示为“委托户头转账”的按钮920a被点击，则虚拟商店街管理服务器10如后述那样对会员终端30发送对于金额变更的承认的委托邮件(后述的S630a)。

图9(b)例示在判定为变更前后的差额不是规定金额(1000日元)以上时对加盟店终端40所发送的结账处理的委托页。结账处理的委托页900b与结账处理的委托页900a相同。但是，在与上述的显示为“对用户有金额确认”的栏911a对应的栏911b上没有显示图标。

在结账处理的委托页900b中，若显示为“委托户头转账”的按钮920b被点击，则由于虚拟商店街管理服务器10不从会员获得对于金额变更的承认，因此直接开始结账处理(后述的S645a)。

(3-4.承认的委托)

返回图7，在判定为变更前后的差额是规定金额(1000日元)以上时(S620为“是”)，若从加盟店终端40接受结账处理的委托信息，则虚拟商店街管理服务器10对会员终端30发送表示接受了与金额的大幅变更相关的订购内容的修正的电子邮件，对会员委托对于金额变更的承认(S630a)。这时，将订购信息的“结账处理状态”设为“未承认”。

另外，在本实施方式中，以定期的批处理(例如，每5分钟的批处理)来进行该处理，但也可以在其他定时进行。

图10中例示对于变更金额的承认委托邮件。承认委托邮件1000是，加盟店(负责人)在修正页800(图8)中对数量显示栏811输入“2”而点击了按钮820之后，在发送来的结账委托的委托页900a(图9(a))中通过点击显示为“委托户头转账”的按钮920a而进行了结账处理的委托时对会员终端30发送的邮件。

在承认委托邮件1000中，在地址栏1010中显示会员终端30的邮件地址。邮件地址从订购信息上所附的会员信息取得。在主题栏1020中显示容易判别是对于金额变更的承认委托的意旨的主题。

在正文栏1030中显示成为承认对象的订购的识别信息(1031)、承认的委托文(1032)、承认的步骤(1033)、问询处等注意事项(1034)等。此外，在本实施方式中，在对于金额变更的承认上设置期限(这里，从接受修正起3日以内)，显示用于表示在期限内没有承认时取消(cancel)订购的注意(1035)。

另外，在订购的识别信息(1031)的“订购细节”、或者承认的步骤(1033)的[1]中显示的URL成为对委托对象的订购的确认页的链接。因此，会员只要在会员终端30上点击该链接，就能够接收委托对象的订购的确认页。

返回图7，接受上述委托的会员利用会员终端30登录到虚拟商店街管理服务器10，并请求购买历史的确认页。在从会员终端30有确认页的请求时，虚拟商店街管理服务器10对会员终端30发送购买历史的确认页。会员在该购买历史的确认页中确认订购内容，并从会员终端30请求对于金额变更的承认与否的选择页。

在从会员终端30有对于金额变更的承认与否的选择页的请求时，虚拟商店街管理服务器10对会员终端30发送对于金额变更的承认与否的选择页，并从会员接受对于金额变更的承认或者否认的响应(S635a)。会员在该购买历史的确认页中确认修正内容，并响应对于金额变更的承认与否。

图11例示该购买历史的确认页。确认页1100是，在承认委托邮件1000(图10)的订购的识别信息(1031)的“订购细节”、或者承认的步骤(1033)的[1]中显示的URL被点击时，对会员终端30发送的页。

确认页1100由金额等显示栏1110、订购信息显示栏1120以及用于请求对于金额变更的承认与否的选择页的按钮1130构成。

在金额等显示栏1110中显示商品信息以及订购信息的“数量”、“索取金额”等。在订购信息显示栏1120中除了订购信息的“订购号”、“订购日期时间”、“结账方法”之外，显示订购者的信息。

当会员点击显示为“结账金额的确认”的按钮1130时，从会员终端30对虚拟商店街管理服务器10请求对于金额变更的承认与否的选择页。

图12例示对于金额变更的承认与否的选择页。选择页1200是在确认页1100(图1)中按钮1130被点击时对会员终端30所发送的页。

选择页1200由金额等显示栏1210、金额承认按钮1220a以及订购取消按钮1220b构成。

在金额等显示栏1210中显示订购时的金额、变更后的金额以及差额。在本实施方式中，假设在该差额为规定金额(1000日元)以上时要求会员的承认。

会员点击显示为“金额承认”的按钮1220a时，从会员终端30对虚拟商店街管理服务器10发送对于金额变更的承认响应。另一方面，在会员点击显示为“取消”的按钮1220b时，从会员终端30对虚拟商店街管理服务器10发送对于金额变更的否认响应。

另外，在本实施方式中，将金额的否认作为订购的取消(cancel)来处理，因此不准备只承认金额的变更的选择项。

(3-5.户头转账处理的委托和订购的取消)

返回图7，在从会员终端30接收响应时，虚拟商店街管理服务器10判定是否被承认(S640a)。

在判定为来自会员终端30的响应是承认时(S640a为“是”)，虚拟商店街管理服务器10判断为订购内容的修正是妥当的，在确定订购内容的变更后，对银行服务器50委托户头转账处理(S645a)。

这里，将通过订购的接受处理(S605)而生成的订购信息更新为修正后的内容的同时，将“接受订货处理状态”设为“等待寄送”，将“结账处理状态”设为“等待确认余款”。此外，建立“金额变更承认标记”。

在确定订购内容的变更时，虚拟商店街管理服务器10对会员终端30以及加盟店终端40发送表示变更了订购的电子邮件，对会员以及加盟店通知变更了订购的情况(S650a)。另外，对于会员以及加盟店的通知例如通过每日分批处理而在次日一并发送。

另一方面，在判定为来自会员终端30的响应是否认时(S640a为“否”)，虚拟商店街管理服务器10判断为订购内容的修正是不妥当的，并进行订购的取消处理(S645b)。这里，将通过订购的接受处理(S605)而生成的订购信息的“接受订货处理状态”设为“取消”。不建立“金额变更承认标记”。

此外，在规定期间(例如，3日期间)没有从会员终端30接收响应时，虚拟商店街管理服务器10也判断为订购内容的修正是不妥当的，并进行订购的取消处理。这时，虚拟商店街管理服务器10在每次批处理时检索订购信息数据库14，读出尽管订购内容有修正却在没有获得会员的承认的状态下经过规定时间的订购信息(在“接受订货处理状态”为“等待发货”，“结账处理状态”为“未承认”，并且没有建立“金额变更承认标记”的信息中，从“修正日期时间”经过规定时间的订购信息)。然后，对于读出的订购信息，进行与上述的订购的取消处理(S645b)同样的处理。

在订购的取消处理完成时，虚拟商店街管理服务器10对加盟店终端40发送表示订购已被取消的电子邮件，对会员以及加盟店通知订购已被取消的情况(S650b)。另外，对于会员以及加盟店的通知通过每日批处理而在次日一并发送。

<其他实施方式1>

在上述的实施方式中，假设在从加盟店有结账处理的委托时，对会员进行用于获得委托的处理。这是因为经由结账机构而进行结账时，在订购内容(索取金额)内变更后会员没有用于保留或者拒绝货款的支付的选择机会，因此为了以修正后的金额安全地进行结账，事先从会员获得承认的处理比较有效。

相对于此，也可以设为在从加盟店终端40接受了订购内容的修正信息时，对会员进行用于获得承认的处理。

这时，例如在图7所示的处理中，若从加盟店终端40接受订购内容的修正信息(S615)，并判定修正前后的索取金额的变更额是否为规定金额以上(S620)，则不进行接受结账处理的委托的处理(S625a)，而对会员终端30发送用于委托金额变更的承认的电子邮件(S630a)。由此，在从加盟店接受了订购内容的修正信息时，能够对会员进行用于获得承认的处理。

<其他实施方式2>

在上述的实施方式中，假设了会员终端30或者加盟店终端40为个人计算机等的终端的情况。相对于此，也可以设为当会员终端30或者加盟店终端40为移动电话等移动终端时，根据其性质而提供与个人计算机等的终端不同的页以及邮件。

图13～图15例示的邮件或者页都是以会员终端30或者加盟店终端40为移动电话等移动终端的情况为前提，整体上为小型。

图13例示发往移动终端的对于金额变更的承认委托邮件。承认委托邮件1300与承认委托邮件1000(图10)相对应。

在承认委托邮件1300中，地址栏1310中显示会员终端30的邮件地址。邮件地址根据订购信息上所附的会员信息而取得。主题栏1320中显示容易判别是对于金额变更的承认委托的意旨的主题。

在正文栏1330中显示承认的委托文(1331)以及在期限内没有承认时取消(cancel)订购的注意(1332)。

另外，在承认的委托文(1331)的下方显示的URL不是成为委托对象的订购的确认页，而是对购买历史的首页的链接。这是因为若设为对成为委托对象的订购的确认页的链接，则URL会变长。

图14例示移动终端用的购买历史的确认页。确认页1400与确认页1100(图11)对应。另外，确认页1400是，经过在承认委托邮件1300(参照图13)的承认的委托文(1331)的下方显示的URL被点击时对会员终端30发送的登录页中的会员认证，请求了成为委托对象的订购的购买历史的确认页时，对会员终端30发送的页。

确认页1400由金额等显示栏1410、订购信息显示栏1420以及用于请求对于金额变更的承认与否的选择页的按钮1430构成。

金额等显示栏1410中显示商品信息以及订购信息的“索取金额”等。在订购信息显示栏1420中除了显示订购信息的“订购号”、“订购日期时间”、

“结账方法”之外，还显示订购者的信息。

当会员点击显示为“结账金额的确认”的按钮1430时，从会员终端30对虚拟商店街管理服务器10请求对于金额变更的承认与否的选择页。

图15例示对于金额变更的承认与否的选择页。选择页1500与选择页1200(图12)相对应。另外，选择页1500是在确认页1400(图14)中按钮1430被点击时对会员终端30发送的页。

选择页1500由金额等显示栏1510、金额承认按钮1520a以及订购取消按钮1520b构成。

在金额等显示栏1510中显示订购时的金额、变更后的金额以及差额。在本实施方式中，假设该差额为规定金额(1000日元)以上时要求会员的承认。

当会员点击显示为“金额承认”的按钮1520a时，从会员终端30对虚拟商店街管理服务器10发送对于金额变更的承认响应。另一方面，当会员点击显示为“取消”的按钮1520b时，从会员终端30对虚拟商店街管理服务器10发送对于金额变更的否认响应。

另外，在本实施方式中，将金额的否认作为订购的取消(cancel)来处理，因此不准备只否认金额的变更的选择项。

<其他实施方式3>

在上述的实施方式中，虚拟商店街管理服务器10在接受了与索取金额的大幅变化相关的订购内容的修正后，接受了结账处理的委托时，对会员终端30仅发送一次用于委托对于金额变更的承认的邮件。相对于此，也可以设为在规定期间(例如，24小时)内从会员终端30没有响应时，再次发送用于委托对于金额变更的承认的邮件，催促会员承认金额变更。另外，该“在没有响应时用于判断是否催促承认金额变更的基准的期间”，设为比上述的“在没有响应时用于判断是否进行订购的取消处理的基准的期间”短的期间。

这时，虚拟商店街管理服务器10在上述的每日批处理时检索订购信息数据库14，读出尽管订购内容有修正却在没有获得会员的承认的订购信息(在“接受订货处理状态”为“等待发货”，“结账处理状态”为“未承认”，并且没有建立“金额变更承认标记”的信息中，从“修正日期时间”经过了规定时间的订购信息)。然后，根据读出的订购信息而确定进行了该订购的会员，并对该会员的会员终端30再次发送对于金额变更的承认的委托邮件。

Claims (7)

1.一种虚拟商店街管理系统，用于支持虚拟商店街的加盟店和会员之间的交易，在该虚拟商店街管理系统中进行订购信息的修正处理，该虚拟商店街管理系统的特征在于，包括：

修正信息接收部件，从所述加盟店的终端接收与所述订购信息有关的修正信息；

委托承认变更邮件发送部件，在基于所述修正信息而判定为在索取金额上产生了超过规定金额的变更时，发送用于对所述会员的终端委托对于超过该规定金额的变更的承认的电子邮件；

承认与否信息接收部件，从所述会员的终端接收对于超过所述规定金额的变更的承认信息或者否认信息；以及

订购确定部件，在所述承认与否信息接收部件接收到承认信息时确定所述订购信息的修正，在接收到否认信息时取消所述订购信息。

2.如权利要求1所述的虚拟商店街管理系统，其特征在于，

所述承认与否信息接收部件在规定期间内没有接收承认信息或者否认信息时，所述订购确定部件取消所述订购信息。

3.如权利要求1或2所述的虚拟商店街管理系统，其特征在于，

所述承认与否信息接收部件在规定期间内没有接收承认信息或者否认信息时，所述委托承认变更邮件发送部件再次发送用于对所述会员的终端委托对于超过所述规定金额的变更的承认的电子邮件。

4.如权利要求1所述的虚拟商店街管理系统，其特征在于，还包括：

结账处理委托部件，在所述订购确定部件确定了所述订购信息的修正时，对规定的结账机构委托关于所述交易的结账处理。

5.一种虚拟商店街管理系统中的订购信息的修正方法，该虚拟商店街管理系统支持虚拟商店街的加盟店和会员之间的交易，该方法的特征在于，包括：

修正信息接收步骤，从所述加盟店的终端接收与所述订购信息有关的修正信息；

委托承认变更邮件发送步骤，在基于所述修正信息而判定为在索取金额上产生了超过规定金额的变更时，发送用于对所述会员的终端委托对于超过该规定金额的变更的承认的电子邮件；

承认与否信息接收步骤，从所述会员的终端接收对于超过所述规定金额的变更的承认信息或者否认信息；以及

订购确定步骤，在所述承认与否信息接收步骤中接收到承认信息时确定所述订购信息的修正，在接收到否认信息时取消所述订购信息。

6.一种程序，使计算机将权利要求1～4的任一项所述的虚拟商店街管理系统的各个部件作为功能来实现。

7.一种记录介质，其特征在于，以计算机可读取方式记录了权利要求6所述的程序。

Images