2006年10月18日星期三

国际域名相关仲裁政策

  本文介绍ICANN(互联网名称与数字地址分配机构)发布的两个关于域名仲裁的政策法规,想要炒域名的同学们请尽快补习一下,以免日后吃亏。

统一域名争议解决政策(UDRP)

  (由ICANN于1999年8月24日通过,1999年10月24日批准实施)

  说明:

  1、本政策业已生效。有关实施时间表,可参见网址 www.icann.org/udrp/udrp-schedule.htm.

  2、本政策已为所有由ICANN认可的、负责为以.com、 .net、.org结尾的域名提供注册服务的注册商(registrars)所采纳,亦为某些国家顶级域名(如.nu、 .tv、 .ws等)的管理者所采纳。

  3、 本政策是域名注册商(或者某些国家顶级域名的注册机构)和其客户(域名持有人或注册人)之间的约定。因此,本政策以"我方"或"我们的"指称域名注册商,而以"你方"或"你们的"指称域名持有人。

统一域名争议解决政策

(由ICANN于1999年10月24日批准实施)

  1、目的:

  本统一域名争议解决政策("政策")已经由互联网络名称和数码分配公司(ICANN)所采纳,并以附件的形式并入你方的注册协议。该政策为你方与我方(域名注册商)以外的任何其他方之间因你方所注册的互联网络域名的注册及使用而引发的有关争议设定了条款和条件。本政策第4条所规定的解决程序将根据《统一域名争议解决政策之规则》(《程序规则》)(该《程序规则》可见诸于网址 www.icann.org/udrp/udrp-rules-24oct99.htm)和选定的行政争议解决服务提供者的《补充规则》而进行。

  2、你方的陈述责任:

  你方申请注册某一域名或要求我方保留或更新某一域名注册时,即向我们陈述并保证:(a)你方注册协议中所作的陈述是完整的和准确的;(b)就你方所知,域名的注册将不会侵害或妨碍任一第三方的权益;(c)该域名的注册并非出于某种不法目的;以及(d)你方不会在明知违反有关可适用的法律或法规的情况下使用该域名。你方有责任判断你方域名注册行为是否侵害或妨碍他人权益。

  3、撤销、转让和变更:

  在下列情况下,我方将撤销、转让和变更域名注册:

  (a)根据本《政策》第8条的规定,我方收到你方或你方授权代理人提交的书面的或适当电子形式的通知,要求采取此类行动;

  (b)我方收到有管辖权的法庭或仲裁机构作出的裁定,指令采取此类行动;

  (c) 我方收到行政专家组在依据本《政策》或依据为ICANN所采纳的本《政策》以后版本而进行的、以你方为一方当事人的任何行政程序中所作出的裁决,要求采取此类行动。(见以下第4(9)条和第4(11)条)

  我方也可根据域名注册协议的条款或其他合法要求撤销、转让和变更域名注册。

  4、强制性行政程序

  本条限定了你方应交由强制性行政程序解决的争议类型。该程序将由网址 www.icann.org/udrp/approved-providers.htm 中所列明的行政争议解决服务提供者(所列明的均为行政争议解决服务提供者,以下简称"争议解决机构")之一进行。

  a. 适可的争议 一旦第三方(投诉人)根据《程序规则》,向一适格的争议解决机构提出如下主张时,你方有义务加入该强制性的行政程序:

  (i) 你方域名与投诉人享有权利的商品商标或服务商标相同或混淆性相似;且

  (ii) 你方对该域名并不享有权利或合法利益;且

  (iii) 你方对该域名的注册和使用具有恶意。

  投诉人在行政程序中必须举证证明以上三种情形同时具备。

  b. 恶意注册和使用域名的证据 针对第4(a)(iii) 条,尤其是如下情形但并不限于如下情形,如经专家组发现确实存在,则构成恶意注册和使用域名的证据:

  (i) 该情形表明,你方注册或获取域名的主要目的是为了向作为商品商标或服务商标所有人的投诉人或其竞争对手出售、出租或转让域名,以获取直接与域名注册相关费用之外的额外收益者;或者,

  (ii) 你方注册行为本身即表明,你方注册该域名的目的是为了阻止商品商标和服务商标的所有人以相应的域名反映其上述商标者;或者,

  (iii) 你方注册域名的主要目的是为了破坏竞争对手的正常业务者;或者,

  (iv) 以使用域名的手段,为商业利益目的,你方通过制造你方网站或网址上所出售的商品或提供的服务与投诉人商标之间在来源者、赞助者、附属者或保证者方面的混淆,故意引诱网络用户访问你方网站或其他连机地址者。

  c. 如何在答辩中证明你方对域名拥有权利及合法利益 你方在收到投诉书后,应根据《程序规则》第5条的规定来决定你方应如何准备答辩。针对第4(a)(ii) 条,尤其是如下情形但并不限于如下情形,如由专家组在对所提交的证据进行全面认定基础上得以证实,则表明你方对该域名拥有权利或合法利益:

  (i) 在接到有关争议通知之前,你方在提供商品或服务的过程中已善意地使用或可证明准备善意地使用该域名或与该域名相对应的名称者;或者,

  (ii) 你方(作为个人、商业公司或其他组织)虽未获得商品商标或有关服务商标,但因所持有的域名业已广为人知者;或者

  (iii) 你方正非商业性地合法使用或合理地使用该域名,不存有为获取商业利益而误导消费者或玷污争议商品商标或服务商标之意图者。

  d.争议解决机构的选择 投诉人应从业经ICANN认可的争议解决机构中选择一争议解决机构,并向该争议解决机构提交投诉书。除第4(f)条所规定的合并审理的情形外,该争议解决机构将管理案件程序性事项。

  e. 程序的启动和行政专家组的指定 有关案件的启动程序、案件进行程序及裁决争议的专家组("行政专家组")的指定程序由《程序规则》另作规定。

  f. 合并审理 如果你方与投诉人之间存有多个域名争议,你方或投诉人均可请求将这些争议交由一个行政专家组合并审理。该请求应向最初被指定负责双方间在审争议的行政专家组提出。该专家组有权决定将此类争议部分或全部予以合并审理,只要这些合并审理的争议受本《政策》或为ICANN采纳的本《政策》以后的版本所约束。

  g. 费用 争议解决机构根据本《政策》就提交专家组解决的争议而收取的所有费用均由投诉人承担,但你方根据《程序规则》第5(b)(iv) 条的规定选择将行政专家组成员由一名专家扩充为三名专家的情形除外。在这种情形下,全部费用由你方和投诉人平均分担。

  h. 我方在行政程序中的介入 我方不参与管理由行政专家组所进行的任何程序。此外,我方对因专家组裁决而产生的结果不承担责任。

  i. 救济措施 投诉人通过行政专家组程序可获得的救济措施应限于要求注销你方域名或将你方注册域名转移给投诉人。

  j. 通知和公布 争议解决机构应通知我方由行政专家组针对你方注册的域名所作出的任何裁决。所有根据本《政策》所作裁决均全文在互联网上予以公布,但专家组在特殊情形下决定裁决中不宜公布的部分除外。

  k. 司法程序的可行性 第4条规定所要求的强制性行政程序并不排除你方或投诉人在该强制性行政程序开始之前或结束之后将争议提交有管辖权的法院独立解决。如果行政专家组裁定你方域名应予注销或转移,我们将在得到有关争议解决机构行政专家组的裁决通知后、在执行该裁决之前,等待十(10)个工作日(以我方主营业机构所在地时间为准)。然后,我们将执行裁决,除非我们在该十(10)个工作日的等待期内收到你方在投诉人根据《程序规则》第3(b)(xiii) 条提出投诉的地域针对投诉人提起司法诉讼的正式文件(如盖有法院职员归档印鉴的的起诉书副本)。(一般情况下,该地域是我们主营业机构所在地或者我方Whois数据库所记载的你方地址所在地。详细信息参见《程序规则》的第1条和第3(b)(xiii) 条)。如果我们在十(10)个工作日期间内收到了上述文件,直至我们收到(i)令我们确信双方已解决争议的证据;(ii)令我们确信你方诉讼请求已被驳回或撤销的证据;或者,(iii)法院有关驳回你方诉讼请求或裁定你方无权继续使用域名的裁定副本,我们将不执行行政专家组的裁决,也不采取进一步的进行。

  5、 其他争议及诉讼 所有你方与除我方之外的他方当事人之间的其他并非根据本《政策》第4条强制性行政程序规定而提起的有关你方因域名注册而引起的争议,均由你方与该方当事人通过法院诉讼、仲裁和其他可适用的程序予以解决。

  6、 我方有关争议的介入 我方不以任何方式参加你方与除我方之外的他方之间因你方注册及使用域名而产生的任何争议。你方不得在任何此类程序中将我方列为当事人之一方或以其他方式使我方介入该程序。一旦我方在此类程序中被列为当事人之一方,我们则保留进行适当辩护以及采取其他必要行动以维护我方利益的权利。

  7、 维持现有状态 除前述第3条所规定的情形外,我方将不对根据本《政策》注册的域名予以撤销、转让、使之生效或失效,或以其他任何措施改变域名现有状态。

  8、争议期间的转让

  a. 将域名转让给新持有人 你方不得在下列期间将注册域名转让给另一持有人:(i)在根据第4条而提起的行政程序进行期间,或该程序终结后15个工作日内(以我方主营业机构所在地时间为准);或者(ii)在针对你方域名注册而提起的法院诉讼程序或仲裁程序进行期间,除非接受域名转让的一方当事人书面同意接受法院判决或仲裁裁决的约束。我方保留对违反该条款规定所进行的域名转让予以注销权利。

  b. 变更注册商 你方在根据第4条而提起的行政程序进行期间或该程序终结后15个工作日内(以我方主营业机构所在地时间为准)不得将注册域名转移给另一注册商。只要你方在我处注册的域名能够继续成为在依据本《政策》条款针对你方而提起的程序中的争议标的,你方可在法院诉讼或仲裁程序进行期间将注册域名转移给另一注册商管理。如果你方在法院诉讼或仲裁程序进行期间将域名转移给我们管理,则有关该域名的争议仍应适用原注册商的域名争议解决政策。

  9、本政策的修订 我们有权在征得ICANN的同意后适时对本《政策》予以修订。我们将至少在修改后的政策生效前30日将其在上予以公布。如果本《政策》已为投诉人在向争议解决机构提交的投诉书中所援引,则你方应受投诉人援引时有效的政策文本约束。除此之外,无论是域名争议产生在修订文本生效之前、生效之时抑或生效之后,所有的这些修改之处均对你方具有约束力。如果你方对本《政策》的修改之处不予接受,你方唯一的救济方式是取消在我处的域名注册,但你方无权要求返还你方业已向我方支付的任何费用。业经修订的政策文本直至你方注销域名注册时为止对你方均予适用。

  [ 2000年7月24日 ]

统一域名争议解决政策之规则

(由ICANN于1999年10月24日通过)

  根据由ICANN采纳的《统一域名争议解决政策》而进行的争议解决行政程序受本《规则》及管理案件程序的争议解决机构通过其网站发布的《补充规则》所约束。

  1、定义

  在本《规则》中:

  投诉人指就有关域名注册提起投诉的一方当事人。

  ICANN指互联网络名称及数码分配公司。

  交互管辖法域指,(a)注册商主营业机构所在地的法院管辖(只要域名持有人在其注册协议中已规定将有关因域名的使用而 产生的争议交付该法域法院司法管辖)或,(b)投诉提交争议解决机构之时注册商Whois数据库中域名注册信息所显示的域名持有人的地址所在地的法院管辖。

  专家组指由争议解决机构指定的审理有关域名注册投诉的行政专家组。

  专家指由争议解决机构指定的作为专家组成员的专家。

  当事人指投诉人或被投诉人。

  《政策》指《统一域名争议解决政策》。该《政策》通过援引而被并入并成为注册协议的一部分。

  争议解决机构指由ICANN所确认的争议解决服务提供者。机构名单可查阅网址www.icann.org/udrp/approved-providers.htm.

  注册商指为被投诉人提供争议域名注册服务的公司。

  注册协议指注册商与域名持有人间所签订的域名注册协议。

  被投诉人指针对其据以提起投诉的注册域名持有人。

  反向域名侵夺指恶意地利用《政策》中的有关规定以企图剥夺注册域名持有人持有域名的行为。

  《补充规则》指有权管理案件程序的争议解决机构制定的本《规则》之补充规则。

  2、送达

  (a) 在向被投诉人送达投诉书时,争议解决机构有责任采取合理可行的措施,确保被投诉人实际收到投诉书。实际收到投诉书,或争议解决机构为使被投诉人实际收到投诉书而实施以下行为后,该项责任即行解除:

  (i)按(A)注册商Whois数据库域名注册资料中记载的注册域名持有人及其技术联系人、管理联系人以及,(B)注册商向争议解决机构提供的域名注册缴费联系人的所有邮政通讯及传真地址,将投诉书发送被投诉人的;及

  (ii)、通过电子邮件向以下地址传送电子形式投诉书(包括可按照电子形式传送的附件)的:

  (A)域名注册技术联系人、管理联系人及缴费联系人的电子邮件地址;

  (B)postmaster@<争议域名>;及

  (C)如果域名(或www.后紧接该域名)解析至一个有效网页(该网页并非争议解决机构所确认的由注册商或ISP所预留的、可搁置由多个域名持有人所注册的域名的一般性网页)时,该网页所显示的任何电子邮件地址或该网页所能链接的任何电子邮件地址;

  (iii)按照被投诉人自行选择并通知争议解决机构的任何地址,及在可行的范围内向由投诉人根据第3(b)(v) 条向争议解决机构提供的所有其他地址发送投诉书的。

  (b) 除第2 (a) 条规定的情形外,依本《规则》向投诉人和被投诉人传送的任何书面文件均应分别根据投诉人和被投诉人选定的方式为之(见第3 (b) (iii)条和第5 (b) (iii)条),或在没有这种指示时

  (i)通过带有传输确认的传真方式传送;或

  (ii)预付邮资并通过带有收据的邮寄或快递方式发送;或

  (iii)在能获得传送记录的情况下,通过互联网以电子形式传送。

  (c)向争议解决机构或专家组提交的任何文件均应按争议解决机构《补充规则》所规定的方法和方式(包括分数)提交。

  (d)文件应以第11条所规定的语文制作。如果可行的话,电子文件应以简易文本传送。

  (e)任何一方当事人均可通知争议解决机构和注册商,以更新其详细联络信息。

  (f)除非本《规则》另有规定,或专家组另有决定,根据本《规则》所提交的所有文件于下列情形下应视为已经送达;

  (i)通过传真方式传送的,以传送确认书上显示的日期为准;或

  (ii)通过邮寄或快递方式发送的,以收据上标注的日期为准,或

  (iii)通过互联网络传送的,在传送日期可予验证的情况下,以该文件传送日期为准。

  (g)除非本《规则》另有规定,所有本《规则》所规定的文件提交开始的期间应当从依第2(f) 条之规定文件最早视为业已提交的日期开始计算。

  (h)任何文件,

  (i)凡由专家组传送给任何一方当事人者,必须同时向争议解决机构和另一方当事人传送文件副本;

  (ii)凡由争议解决机构传送给任何一方当事人者,必须同时向另一方当事人传送文件副本;以及

  (iii)凡由一方当事人提交者,必须同时向另一方当事人、专家组以及争议解决机构传送文件副本。

  (i)文件传送方有义务为其传送的文件保留记录,以记载有关文件传送的具体事实和情况,供有关当事方查阅,并用以制作相应的报告。

  (j)如果传送文件的一方当事人收到告知未收到其所传送文件的通知,该当事人应立即将有关情况通知专家组(或者,如果专家组尚未指定,通知争议解决机构)。有关文件传送和回复的进一步程序均应依照专家组(或争议机构)的指示而为之。

  3、投诉

  (a)任何个人或企业均可依据《政策》及本《规则》向经ICANN认可的争议解决机构提出投诉以启动行政程序。(由于资质限制或其他原因,争议解决机构受理投诉的资格可能会暂时中止。在这种情况下,争议解决机构应拒绝受理投诉。有关个人或企业可向另一争议解决机构提请投诉。)

  (b)投诉书应以有形书面文件形式及电子文件形式(无法获得电子格式的附件除外)提交,并且应当:

  (i)载有有关投诉应根据《政策》和本《规则》予以裁决的请求;

  (ii)提供投诉人及其行政程序授权代表的姓名、通讯及电子邮件地址以及电话和传真号码;

  (iii)确定在行政程序中就(A)电子文件材料和(B)包含有形书面文件的材料与投诉人联络的首选通讯方式(包括联系人、联系方式及联络地址);

  (iv)决定投诉人是选择一人专家组裁决纠纷,还是三人专家组裁决纠纷。如果投诉人选择由三人专家组裁决纠纷,则应提供将会被指定作为案件专家组成员之一的三位候选专家的姓名和详细的联络信息(三位候选专家可从任何一个业经ICANN确认的争议解决机构的专家名单中选定);

  (v)提供被投诉人(域名持有人)的名称及为投诉人所知的如何联络被投诉人及其代表的包括投诉前双方协商过程中的联络信息在内的所有信息(包括所有的通讯及电子邮件地址以及电话和传真号码),上述信息应详细具体足以允许争议解决机构将投诉书按第2(a)条所述方式发送被投诉人;

  (vi)明确作为投诉标的的域名;

  (vii)确定投诉提起之时注册域名的注册商;

  (viii)明确据以提出投诉的商品商标或服务商标。就每一商标而言,如果有的话,则应说明据以使用商标的商品或服务(投诉人亦可分别说明在投诉提起之时被投诉人意欲将来使用该商标的商品及服务);

  (ix)根据《政策》规定,说明据以提起投诉的理由,尤其应包括:

  (1)争议域名与投诉人享有权利的商品商标或服务商标相同或混淆性相似;及

  (2)被投诉人(域名持有人)对争议域名不享有权利或不具备合法利益的原因;及

  (3)争议域名被认为系属恶意注册和使用的理由。

  (就第(2)项和第(3)项而言,投诉人应讨论应予适用的《政策》第4(b)条和第4(c)条所规定的各个方面。有关说明的字数应符合争议解决机构《补充规则》有关字数或文件页数的限制。);

  (x)根据《政策》规定,明确所寻求的补救方式;

  (xi)说明任何其他已经开始或业已终止的与争议域名相关的司法程序;

  (xii)声明已经根据第2(b)条的规定,连同争议解决机构《补充规则》所规定的格式封面,向被投诉人(域名持有人)发送或传送了投诉书副本;

  (xiii)声明投诉人如对行政程序关于取消或转移域名的裁决有任何异议,将把有关争议提交至少一个确定的交互管辖法域的法院予以管辖;

  (xiv)投诉书的结尾应附有下列声明,并由投诉人或其授权代表签署:

  "投诉人同意,其有关域名注册、争议或争议解决的投诉及救济主张仅针对域名持有人,该投诉及救济主张不涉及(a)争议解决机构及专家,但故意不当行为除外,(b)注册商,(c)注册官员,及(d)互联网络名称和数码分配公司,以及上述机构的董事、官员、雇员及代理商。"

  "投诉人确认,投诉书所载信息就其所知是完整的和准确的。本投诉并非出于诸如讹诈等任何不正当目的。投诉人保证投诉书有关主张是依据本《规则》和应予适用的法律而提出,犹如其现存状态或可由善意及合理抗辩而展延之状态。"

  (xv)包括争议域名应予适用的《政策》副本及投诉赖以依存的注册商标和服务商标在内的任何文件或其他证据应作为附件提交,并应同时提供上述证据的目录索引表;

  (c)投诉人可对多个域名提出投诉,只要这些域名为同一域名持有人所注册。

  4、投诉通知

  (a)争议解决机构应对投诉书予以行政审查。如果投诉书符合《政策》及本《规则》规定,争议解决机构将在收到投诉人根据第19条交纳的费用后3个历日内依第2(a)条所规定的方式将投诉书(连同争议解决机构《补充规则》所规定的说明性格式封面)送达被投诉人。

  (b)如果争议解决机构发现投诉书存有形式缺陷,则应立即将该缺陷通知投诉人和被投诉人。投诉人应在收到通知后5个历日内对该缺陷予以修改。投诉人未能在上述期限内对投诉书形式缺陷予以修改者,行政程序将视为撤回,但并不妨碍投诉人提出另一不同的投诉。

  (c)争议解决机构依第2(a)条完成向被投诉人送达投诉文件职责之日即为行政程序开始之日。

  (d)争议解决机构应立即将行政程序开始日期通知投诉人、被投诉人、有关注册商及ICANN.

  5、答辩

  (a)被投诉人应在行政程序开始之日起20日内向争议解决机构提交答辩。

  (b)答辩应以有形书面文件和电子文件(没有电子格式的附件除外)形式提交,并应当:

  (i)对投诉书中的陈述和主张予以具体反驳,并申明被投诉人(域名持有人)保留域名注册和继续使用争议域名的所有依据和具体理由(答辩书该部分字数应当符合争议解决机构《补充规则》所规定的字数或页数限制);

  (ii)提供被投诉人(域名持有人)及其授权行政程序代理人的姓名、通讯及电子邮件地址以及电话和传真号码;

  (iii)确定在行政程序中就(A)电子文件材料和(B)包含有形书面文件的材料与被投诉人联络的首选通讯方式(包括联系人、联系方式及联络地址);

  (iv)如果投诉人在投诉书中选择一人专家组审理案件(见第3(b)(iv)条),则应声明被投诉人是否选择将争议交由三人专家组裁决;

  (v)如果投诉人抑或被投诉人选择了三人专家组,则应提供将会被指定作为案件专家组成员之一的三位候选专家的姓名和详细的联络信息(这些候选专家可从任一经ICANN确认的争议解决机构专家名单中选定);

  (vi)明确与争议域名有关的已经开始或业已终止的任何其他司法程序;

  (vii)声明已经依照第2(b)条之规定向投诉人发送或传送了答辩书副本;

  (viii)答辩书的结尾应附有下列声明,并经被投诉人或其授权代表签署:

  "被投诉人确认,答辩书中所含信息就其所知是完整的和准确的。该答辩并非出于诸如讹诈等任何不正当目的。被投诉人保证答辩书有关主张是依据本《规则》和应予适用的法律而提出,犹如其现存状态或可由善意及合理抗辩而展延之状态。"

  (ix)任何答辩赖以依存的文件或其他证据应作为附件提交,并应同时提供上述证据的目录索引表。

  (c)如果投诉人选择将争议交由一人专家组裁决,而被投诉人选择将争议交由三人专家组裁决,被投诉人则应承担争议解决机构《补充规则》所规定的三人专家组费用的一半。该费用应在向争议解决机构提交答辩时一并交付。如所应收取的费用未能应要求交付,争议将由一人专家组审理。

  (d)应被投诉人请求,争议解决机构可在个别案件中延长提交答辩的期限。该期限亦可因当事人之书面约定而展延,只要该约定获经争议解决机构批准。

  (e)如果被投诉人未提交答辩,如无特殊情形,专家组应依据投诉书裁决争议。

  6、专家组的指定及裁决期限

  (a)每个争议解决机构应制定并公布包括专家姓名及其适格性在内的专家名册。

  (b)如果投诉人和被投诉人均未选择三人专家组(第3(b)(iv)条和第5(b)(iv)条),争议解决机构将在收到被投诉人答辩或答辩期限届满后5日内从其专家名册中指定一名独任专家。一人专家组费用应全部由投诉人承担。

  (c)如果投诉人或被投诉人之一方选择将争议交由三人专家组裁决,争议解决机构应根据第6(e) 条所规定的程序指定三位专家。三人专家组费用应全部由投诉人承担,但三人专家组由被投诉人选择者除外。在后一种情形下,所涉费用应由双方各半分担。

  (d)除非投诉人已经选择三人专家组,投诉人应在收到有关被投诉人选择三人专家组的答辩书后5个历日内,向争议解决机构提交将被指定作为案件专家组成员之一的三位候选专家的姓名和详细联络信息。这些候选专家可从经ICANN认可的任一争议解决机构的专家名单中选定。

  (e)如果投诉人或被投诉人之一方选择三人专家组,争议解决机构应尽量从投诉人及被投诉人提供的候选专家名单中各自指定一名专家。如果争议解决机构未能在5个历日内按其惯常条件从双方候选专家名单中各自指定一名专家,则争议解决机构将从其专家名册中予以指定。第三名专家应由争议解决机构从其提供给当事人的五位候选专家名单中指定。争议解决机构在指定第三名专家时,应尊重当事人双方在争议解决机构向其提交五位候选专家名单后5个历日内所可能作出的选择,合理地平衡双方当事人的意愿,。

  (f)专家组一经指定,争议解决机构应将指定的专家及如无特殊情况专家组应将有关投诉的裁决提交争议解决机构的日期通知双方当事人。

  7、独立与公正

  专家应独立公正,并应在接受指定前向争议解决机构披露对其独立公正产生合理怀疑的任何情形。如果在行政程序进行过程中的任何阶段出现了可导致对其独立公正产生合理怀疑的新情况,则该专家应立即将该情形向争议解决机构予以披露。在这种情况下,争议解决机构有权指定替代专家。

  8、当事人与专家组之间的联络

  任何一方当事人或其代理人均不得与专家组进行单方联络。当事人一方与专家组或争议解决机构间的所有联络均应通过争议解决机构根据其《补充规则》之规定方式指定的案件经办人进行。

  9、案件移交专家组

  当专家组由一人组成时,该专家一经指定,或当专家组由三人组成时,最后一位专家一经指定,争议解决机构即应将案件移交专家组。

  10、专家组一般性权利

  (a)专家组应以其根据《政策》和本《规则》而认为适当的方式进行行政程序。

  (b)在所有案件中,专家组应确保平等地对待双方当事人,并保证每一方当事人均拥有平等的机会陈述案情。

  (c)专家组应确保行政程序快速进行。专家组可应一方当事人请求或自行决定在特殊情形下延长本《规则》或专家组所确定的时限。

  (d)专家组有权决定证据的可接受性、关联性、实质性和重要性。

  (e)专家组可根据《政策》和本《规则》规定应一方当事人的请求决定对多个域名争议合并审理。

  11、程序所使用的语文

  (a)除非当事人另有约定或注册协议另有规定,以及专家组根据行政解决程序的具体情形另有决定,行政程序所使用的语文应是注册协议所使用的语文。

  (b)专家组可裁定要求当事人提交的任何非以行政程序所应使用的语文制作的文件均应全部或部分地附具行政程序所应使用语言的译文。

  12、进一步陈述

  除投诉书和答辩书外,专家组可自行决定要求当事人一方就所涉案件提供进一步的陈述或提交相关文件。

  13、当庭听证

  除非专家组在特殊情形下自行决定,当庭听证对裁决争议确有必要,正常情况下不举行当庭听证(包括以电话会议、视频会议及网络会议所进行的任何听证)。

  14、缺席

  (a)当事人一方,如无特殊情形,不遵守本《规则》或专家组所确定的任何时限,专家组将继续进行行政程序,直至就所涉投诉作出裁决。

  (b)当事人一方,如无特殊情形,不遵守本《规则》之规定或要求或专家组的任何指令,专家组应以其认为适当的情形对此予以推论。

  15、专家组裁决

  (a)专家组应基于当事人所提交的陈述及证据,根据《政策》、本《规则》以及可予使用的法律规则和原则裁决争议。

  (b)如无特殊情形,专家组应在根据第6条被指定后14日内将有关投诉之裁决提交争议解决机构。

  (c)如果是三人专家组,裁决应以多数意见作出。

  (d)专家组裁决应为书面,说明裁决理由,注明裁决作出日期,并写明专家姓名。

  (e)专家组裁决及有关不同意见通常应符合争议解决机构《补充规则》关于文件长度的要求。任何不同意见均应载入以多数意见所作之裁决。如果专家组认为所涉争议不属于《政策》第4(a) 条所规定之范围,则应予以说明。如果专家组经审阅当事人所提交之文件后认定投诉具有恶意,例如属于反向域名侵夺之情形或其本意在于讹诈域名持有人,专家组应在裁决中宣布,投诉具有恶意并构成对行政程序的滥用。

  16、裁决送达当事人

  (a)争议解决机构应在收到专家组提交的裁决后3个历日内将裁决书全文发送各方当事人、有关注册商及ICANN.有关注册商应立即将根据《政策》之规定执行裁决的日期告知各方当事人、争议解决机构和ICANN.

  (b)除专家组另有决定外(见《政策》第4(j)条),争议解决机构应将裁决全文及其执行日期在一公开网站上予以公布。无论何种情形,裁决中有关投诉构成恶意的部分均应予以公开。

  17、和解或其他终止程序的事理

  (a)如果在专家组作出裁决之前,当事人达成和解,专家组应终止行政程序。

  (b)如果在专家组作出裁决之前,因其他原因行政程序已无必要继续进行或不可能继续进行,专家组应决定终止行政程序,除非一方当事人在专家组规定的时间内提出合理的反对理由。

  18、司法程序的效力

  (a)如果在行政程序开始之前或进行的过程中已就争议域名提起了司法程序,专家组有权自行决定中止或终止行政程序,或继续行政程序,直至作出裁决。

  (b)如果一方当事人在行政程序进行期间就争议域名提起了司法程序,其应立即通知专家组和争议解决机构。见上述第8条。

  19、费用

  (a)投诉人应根据争议解决机构《补充规则》之规定,按规定的时间和金额,向争议解决机构支付固定的基本费用。如果被投诉人根据第5(b)(iv)条之规定选择将争议交由三人专家组裁决,而不是交由投诉人选择的一人专家组裁决,则三人专家组费用的一半应由被投诉人承担,并由其向争议解决机构支付(见第5(c)条)。在其他情形下,争议解决机构所有费用应由投诉人承担,但第19(d)条规定的情形除外。专家组一经指定,争议解决机构应根据争议解决机构《补充规则》的规定,将适当比例的基本费用,如果有的话,返还给投诉人。

  (b)在投诉人未根据第19(a)条之规定向争议解决机构缴纳基本费用前,争议解决机构不应就有关投诉采取行动。

  (c)如果争议解决机构在收到投诉后10个历日内未收到有关费用,视投诉视为撤回,行政程序予以终止。

  (d)在特殊情形下,例如举行当庭听证,争议解决机构应要求当事人双方另外付费。该费用应经协商当事人双方和专家组后确定。

  20、责任排除

  除故意不当行为外,争议解决机构抑或专家均不就与根据本《规则》而进行之行政程序有关的任何行为或疏忽向一方当事人承担责任。

  21、修改

  有关行政程序适用向争议解决机构提交投诉之时有效的本《规则》之文本。本《规则》只有在得到ICANN明示书面确认后方可予以修订。

  (原文见:http://www.icann.org/udrp/udrp-rules-24oct99.htm

  [ 2000年7月24日 ]

2006年10月17日星期二

Web2.0网站需要解决的问题

  提到Web2.0,我们需要先说一说Web1.0。

  Web1.0是门户网站的天下,其特点就是大型网站,编辑众多,大量的职业编辑可以保证网站每天更新成百上千条记录,更新快,内容也不错,读者也就多,访问量自然就很大。

  这种模式也有一些问题,例如成本较高(网站编辑的工资、管理层运作成本等等),盈利模式较为单一(网络广告收入等等),因此需要搞一些“短信”、“彩铃”、“网络游戏”之类的“副业”,这些副业往往盈利能力非常强(虽然大多使用流氓手段),因此,网站也乐于将其流量转向这类内容。

  Web2.0是近年来流行的一个概念,优势是用户提供内容,降低了编辑的人力资源成本,但是这也会带来一个严重的问题,用户发布的内容,无论从质量还是数量上讲,都无法和职业编辑发布的内容相比,这会导致网站的整体质量难以和Web1.0相抗衡,如何提高用户提交信息的质量,是建立Web2.0网站需要解决的一个问题。

  对于提交质量的问题,有些人采用Digg的方法,由其他用户来评分,好的内容就会得分高,不好的内容得分就低,但是如何保证评分的用户的准确度呢?比如通过人工或程序的方法恶意评分,这些都是较难控制的。评分还需要不断激励用户来评分,否则很难有用户能坚持长期为某个网站评分。

  另一个问题是,用户凭什么为你提交高质量的内容?网站编辑提交高质量的内容,因为公司会给他发工资奖金,普通的上网用户凭什么给Web2.0网站提交高质量内容?有人给发工资吗?显然没有。要求用户长期地为网站提交好内容,显然是非常困难的事情。因此建立Web2.0网站还要解决如何激励用户提交高质量内容的问题。

  对于激励用户的问题,我觉得比较好的方法是,使用某些方法,将用户提交的信息和用户自己的利益结合在一起,用户提交的信息越好,用户个人得到的利益就越高。比如有一些Digg网站将用户提交的信息附加用户自己的Adsense广告,这就是一个很好的思路,用户的内容访问量越大,其Adsense收入也就越大,这是一个激励用户的很好思路。

  还有一个问题是Spam。用户可以提交内容了,看似降低了人力成本,但是垃圾广告信息也可以来提交了,如果不处理的话,Web2.0整体内容质量会极速下降,但是越大的网站,垃圾广告信息也越多,处理这些广告的人力成本也会越来越大,这一点在Web1.0上就不存在,网站编辑是不会发送垃圾广告信息到网站上的。

  解决垃圾广告的这个问题很复杂,很难有全面的解决方法,目前只能采取一些程序的方法自动删除某些垃圾广告,以减少人力删除的成本,比如WordPress的Akismet插件可以通过中心服务器数据库自动捕获和拦截垃圾信息,我以前也写过一个Z-Blog反垃圾留言过滤插件,都可以通过程序来阻止垃圾信息,但其也面临准确度和误判等问题。

  这里是我想到的关于现在的Web2.0面临的问题和解决方法,如果你有什么其他问题以及更好的解决方法,请也留言告诉我。

2006年10月15日星期日

使用Google进行时间管理

  本文主要讲的是工作方法的一个重要内容—“时间管理”,并且介绍了一个使用Google个性化主页来进行时间管理的简易方法。前一阵我们公司的相关时间管理的培训给了我很大启发,促使我将这个好观念介绍给更多的人,同时结合我自己使用的Google工具来实现时间管理的方法,如果你想改善自己的工作效率,那么请继续往下看。

  时间管理的理论知识我就不介绍了,市场上关于这方面的书非常多,相关的培训也很多。简而言之,时间管理是就是如何更有效地安排自己的工作计划,掌握重点,合理有效地利用工作时间,其本质是管理个人,是自我的一种管理。时间管理的方法是通过良好的计划来完成的。

  时间“规划”

  提高工作效率最关键的部分是规划。规划你自己的工作计划和过程,充分利用有限的时间,这是高效完成自己工作的有效方法。

  时间规划一般分为长期规划和短期规划,一般可以在年初制定本年计划,月初制定月计划,周一制定周计划。每天的工作计划一般也可以预先制定,但是由于工作内容的复杂性以及临时随机任务,每天的计划会非常难以管理。

  时间规划的难点是一天时间的规划和分类,一天一共24小时,除了上班时间外就是个人业余时间,上班时间的工作一般是一些日常工作或者临时任务,而业余时间则是思维期,一些事情可以吃饭睡觉都在想,这些事情一般不是紧急事情,往往思考累计到一定阶段就可以水到渠成,轻松完成。下面我们主要讲讲工作时间的事务细分。

  时间“四象限”法

  时间“四象限”法是目前很时髦的一种时间管理理论,我参加的培训主要讲的就是这方面的内容。“四象限”法是美国的管理学家科维提出的一个时间管理的理论,把工作按照重要和紧急两个不同的程度进行了划分,基本上可以分为四个“象限”:既紧急又重要(如客户投诉、即将到期的任务、财务危机等)、重要但不紧急(如建立人际关系、人员培训、制订防范措施等)、紧急但不重要(如电话铃声、不速之客、部门会议等)、既不紧急也不重要(如上网、闲谈、邮件、写博客等)。

  重要紧急的事马上做,例如处理客户投诉、处理服务器故障等突发性问题,尽量以最短最快的时间内完成这些事情。

  其次是做重要而不紧急的事,这一类的事情影响深远,例如学习新知识、新技能等,这类事情的效益是中长期的,科维提出的时间管理理论的的重点是把主要的精力和时间集中地放在处理重要但不紧急的工作上

  紧急但不重要的事,要学会说“”。一个人的时间和精力是有限的,对于自己不重要的事情,能不做就不做,想办法将事情推脱给其它部门,拒绝或推脱工作要讲究技巧,不要直截了当,要委婉,用让上级觉得确实是合理的理由来拒绝这个新增派的任务。一个人只有学会说“不”,他才会得到真正的自由。当然这并不等于推卸责任,如果确实需要自己来完成,那么就使用最短的时间完成这些工作。

  对于不重要也不紧急的事,尽量不去做。如果确实需要做,那么要严格限定时间,比如写博客,限定一个小时,时间一到就立刻停止写作,千万不要被无聊的人和无关重要的事缠住。

  因此,只要我们把精力主要放在重要但不紧急的事务处理上,合理安排时间,我们就能做到自己的长远规划,工作效率就会大幅提升,一段时间过后,等待你的就会是升职和加薪。

  利用“Google个性化主页”进行时间管理

  时间管理需要一个简单而有效的工具来实现,通过我对于Google在工作上的一些应用后发现,Google的个性化主页就可以完成时间管理。

  我们需要的时间管理工具必须是基于网络的服务,因为我们上班和家庭使用的不是一台电脑,但我们需要看到同一个服务界面,通过Google帐户登录Google的个性化主页就可以实现这个功能。

  首先使用一个Google帐号登录个性化主页,将页面上默认的内容全部删除,然后点击“为本页添加更多内容”,搜索添加“天气”,“便条纸”,“书签”,“待办事项”,然后把地址栏的zh-CN修改为en后找“Google Calendar”添加。这里最重要的一项是“待办事项”,请添加3个待办事项,分别命名为“重要事务”、“不重要事务”和“业余思考”,其中前两个是工作时间处理的事务,在工作时间,每当接到一个新任务,都要按照“四象限”法将其分为重要且紧急,重要不紧急,不重要且紧急,不重要不紧急,添加一个新项目后,将其级别调整为“高”则代表“紧急”,调整为“低”则代表“不紧急”,这时候我们看到的“Google个性化主页”应该是如下图的界面,这就是我们的网络工作平台。

使用Google进行时间管理

  左边的“Google Calendar”可以用来写年计划、月计划、周计划等,中间的部分是当天的日工作计划,右边是一些杂项栏目,查看天气情况用来安排出行,便条纸可以用来记录“临时事情”,书签用来记录临时看到的网址。

  在中间的当天工作计划中,优先处理上面的重要事务,其次是下面的不重要事务,要善于对“不重要事务”说“不”。

  这个工作平台是网络平台,在公司和家中都可以看到同一个界面,是一个简单有效的时间管理工具。当然我们应该清楚,Google只是一个工具,不要指望Google能主动改变你的工作效率,关键在于个人,个人的观念能否转变,计划能否坚持。合理规划自己的工作,充分合理地利用每个可利用的时间,实现高效地工作就不是一件难事。

  最后,本文介绍的Google时间管理工具是一个较为简单的工具,如果你有什么更好更高效的工具,欢迎介绍给我们。

  参考文献:如何提高你的工作效率 

2006年10月14日星期六

将Feed和del.icio.us结合在一起

  这又是一个Z-Blog的插件代码。

  这个代码是在上次介绍的RSS优化插件Better Feed For Z-Blog的基础上,增加的一个美味书签的插件。在每一个文章后面,显示个人在美味书签上收录的相关文章。

  使用这个插件前,需要对Blog和del.icio.us的Tag进行一些同步或者修改,使得两者的Tag名称基本相同,这样,根据名称可以获取到文章在于del.icio.us上的同Tag文章,使得Feed的显示的内容量更多,而且都是相关的内容。

  同步完Tag之后,在RSS优化插件的后面加入以下代码,即可得到strDeliciousTag为美味书签的相关文章列表。

    Dim strDeliciousTag
    strDeliciousTag = GetDeliciousTag (Trim(strTagName))
    If strDeliciousTag<>"" then
     strDeliciousTag="<br/><br/><a href='http://del.icio.us/williamlong/" + Trim(strTagName) + "'>相关网摘</a>:" + strDeliciousTag
    End If

    Function GetDeliciousTag(strTag)
        Dim Retrieval
        Set Retrieval = Server.CreateObject("Microsoft.XMLHTTP")
        With Retrieval
        .Open "GET", "http://del.icio.us/html/williamlong/" + strTag + "?count=5&tags=no&rssbutton=no", False, "", ""
        .Send
        GetDeliciousTag = .ResponseText
        End With
        Set Retrieval = Nothing
    End Function

2006年10月13日星期五

纽约小飞机撞楼事故的Google Earth地标文件

  据美国《侨报》报道,一架单引擎私人小飞机于当地时间11日下午撞上纽约市曼哈顿上东城72街一幢42层楼的高级公寓楼,造成两人死亡,至少15人受伤。这家私人小飞机是纽约洋基棒球队投手赖德尔(Cory Lidle)的,他和他的飞行教练斯坦格遇难。

纽约小飞机撞楼事故

  Google Earth Blog今天也发布了一个纽约撞机KMZ地标文件,在Google Earth中打开这个地标文件,可以很清晰地看见相关的纽约市曼哈顿的公寓楼,据其介绍,因为该地点没有建筑物的“3D Buildings”图层,因此我们对这个地区的鸟瞰图可能会有一些变形。

纽约小飞机撞楼

  Google Earth Blog给出的该地点的坐标是:40°45'56.30"N  73°57'7.81"W。

  前些天Google收购了YouTube,我现在想,以后有没有可能突发事件刚发生,Google Earth上就能出现类似这次的撞机的视频,这种媒体传播模式是否会发生巨大变化。

2006年10月12日星期四

Z-Blog的RSS优化插件Better Feed

  我开发的这个Z-Blog的Better Feed插件的主要功能是扩展现有Z-Blog生成的Feed的内容。

  开发这个插件的起因很偶然,因为前几天我在网上看到Wordpress的Better Feed插件,非常羡慕这个功能(Wordpress的好用插件可真多啊),于是手开始发痒,也做一个类似的插件,应用到我目前使用的Z-Blog系统上。

  目前主要做的功能是在Feed上增加“相关文章”功能。由于我的Feed是使用全文RSS输出,因此损失了不少Web流量,不过,如果在Feed的功能上进行一些扩展和优化,不但可以有利于读者更全面了解文章内容,还可以弥补损失的流量,做到了双赢。

  首先的功能是根据文章的内容,在Feed底部增加一个“相关文章”的功能,这样有兴趣的读者可以很方便地阅读相关内容的文章。

  其次的功能是在Feed底部增加“发表评论”的链接,这样,如果读者看到这篇文章,并且想要发表自己的意见的时候,可以点这个链接进去留言。(为了方便FeedBurner统计点击数,这个链接我暂时没加,有兴趣的可以自己添加一下)

  再次,做为预留功能,我还可以在Feed里面增加广告功能,显示和内容相关的匹配文字广告。

  因此我相信,实现了这些功能之后,做为全文RSS输出的不少缺点就都解决了,这样,很多人就更愿意使用全文RSS输出,方便读者,也不会对自己造成太大冲击。  

  具体的修改方法是,对于Z-Blog 1.6,打开c_system_event.asp文件,找到Function ExportRSS()函数,如果是全文RSS,就将objArticle.HtmlContent替换为objArticle.HtmlContent+getRelateList(objArticle.ID,objArticle.Tag),如果是摘要输出,则替换objArticle.HtmlIntro。最后,在c_system_event.asp文件尾部加入以下代码即可。

'*********************************************************
' 目的:相关文章的生成,用于优化Feed
'*********************************************************
Function getRelateList(intID,strTag)

If (intID=0) Then Exit Function
If strTag<>"" Then

 Dim strCC_Count,strCC_ID,strCC_Name,strCC_Url,strCC_PostTime,strCC_Title
 Dim strCC
 Dim i
 Dim j
 Dim objRS
 Dim strSQL
 Dim strOutput

 strOutput=""
 Set objRS=Server.CreateObject("ADODB.Recordset")

 strSQL="SELECT top 10  [log_ID],[log_Tag],[log_CateID],[log_Title],[log_Intro],[log_Level],[log_AuthorID],[log_PostTime],[log_Url] FROM [blog_Article] WHERE ([log_Level]>2) AND [log_ID]<>"& intID &" "

 Dim aryTAGs
 If InStr(strTag,"}{") > 0 Then
  aryTAGs = Split(strTag,"}{")
 Else
  ReDim aryTAGs(0)
  aryTAGs(0) = strTag
 End If
 strSQL = strSQL & " AND ("
 For j = 0 To UBound(aryTAGs)
  If Not (IsNull(aryTAGs(j)) Or IsEmpty(aryTAGs(j)) Or aryTAGs(j) = "" Or Len(aryTAGs(j)) < 1) Then
   aryTAGs(j) = Replace(Replace(aryTAGs(j),"}",""),"{","")
   If IsNumeric(aryTAGs(j)) Then
    If j > 0 Then strSQL = strSQL & " OR "
    strSQL = strSQL & "([log_Tag] Like '%{"&aryTAGs(j)&"}%')"
   End If
  End If
 Next
 strSQL = strSQL & ")"
 strSQL = strSQL + " ORDER BY [log_PostTime] DESC "

 Set objRS=Server.CreateObject("ADODB.Recordset")
 objRS.CursorType = adOpenKeyset
 objRS.LockType = adLockReadOnly
 objRS.ActiveConnection=objConn
 objRS.Source=strSQL
 objRS.Open()
 If (not objRS.bof) And (not objRS.eof) Then

   For i=1 To 5 '相关文章数目,可自行设定

    strCC_Count=strCC_Count+1
    strCC_ID=objRS("log_ID")
    strCC_Url=objRS("log_Url")
    strCC_PostTime=objRS("log_PostTime")
    strCC_Title=objRS("log_Title")

    Application.Lock
    strCC=Application(ZC_BLOG_CLSID & "TEMPLATE_ARTICLE_Mutuality")
    Application.UnLock

    If IsNull(strCC_Url) Or IsEmpty(strCC_Url) Or strCC_Url="" Then
    strCC_Url=strCC_ID
    end if

    strCC=Replace(strCC,"<#article/mutuality/id#>",strCC_ID)
    strCC=Replace(strCC,"<#article/mutuality/url#>",ZC_BLOG_HOST & ZC_STATIC_DIRECTORY & "/" & CStr(strCC_Url))
    strCC=Replace(strCC,"<#article/mutuality/posttime#>",strCC_PostTime)
    strCC=Replace(strCC,"<#article/mutuality/name#>",strCC_Title)

    strOutput=strOutput & strCC

  objRS.MoveNext
  If objRS.eof Then Exit For
   Next

 End if

 objRS.Close()
 Set objRS=Nothing

End If

strOutput=Replace(strOutput,vbCrlf,"")
getRelateList="<br/>----<br/><br/>相关文章:<ul>" + strOutput + "</ul>  "

End Function

Z-Blog大访问量异常的解决方法

  Z-Blog是一个很好的单用户Blog系统,我不止一次这么说了,特别是当访问量很大的情况下,Z-Blog的表现也是可圈可点的,唯一的问题可能还是和数据库有关。

  Z-Blog之所以可以应付大访问量的负载,主要是因为其缓存(Cache)技术,在重建页面的时候,将大量数据以缓存文件的方式放在Include目录下,这样对于访客的访问就基本可以不连接数据库,而真正可能出问题的瓶颈,显然就是数据库。

  Z-Blog是基于ASP+ACCESS的,ACCESS数据库存在的问题是非常严重的,当外部连接数增大的时候,ACCESS数据库的处理能力飞快的下降,数百个同时在线连接就可以让ACCESS数据库处于死锁的状态,从而导致网站崩溃。因此,如果你的BLog日访问量有几万IP,那么你使用Z-Blog必须要面对这个数据库性能问题。

  目前Z-Blog 1.5存在的性能问题,就是对于数据库访问的问题(1.6版本已经进行了部分修改)。单个页面中,页面计数器存在对于数据库的直接访问,并且是Update方法的访问,这个访问是会带来麻烦的,由于这个计数器的存在,当在线连接数猛增的时候,Z-Blog的文章页面将出现类似死锁的界面,因为数据库会死掉。同时还会发生的事情是,所有评论留言都会死锁,因为那也是访问数据库。进而所有访问数据库的功能都会死锁。

  当然,这个问题可以使用换SQL Server来解决,不过需要修改Z-Blog的相关代码,而且如果是企业用户,需要购买价格不菲的SQL Server。ACCESS无法解决这个问题,因为其本身有不可调和的内部问题。

  如果不使用换数据库的方法,就只有在代码上下功夫了。根据我的观察,对于数据库的直接访问应该就只有计数器这个部分,我目前想到一个思路,就是将计数器的内容也当作文件写入Cache,系统读计数器,全部从Cache中读取,当进行索引重建的时候,再将Cache中的数据写入ACCESS数据库中,这样就可以做到大部分访问都脱离数据库,当在线连接数很大的时候,性能问题也有可能得到一定的解决。

  当然,这样的功能需要写不少程序代码,如果不想写代码,而又遇到异常的大访问量,那么修改Z-Blog模板删除页面计数器功能,也可以临时解决一些问题,代价是文章无法统计点击数了。