用于管理模拟体育和其他比赛中用户之间的直接挑战和选手替换的系统的制作方法

优先权

本申请主张于2014年12月19日提出申请的美国临时申请62/094,661的优先权利。

本申请也是于2015年10月29日提出申请的美国专利申请第14/927,445号的部分接续申请并主张其优先权利，美国专利申请第14/927,445号是于2014年4月30日提出申请的pct/us2014/036241的接续案，pct/us2014/036241主张(1)于2014年2月6日提出申请的美国临时申请61/936,501和(2)于2013年5月1日提出申请的美国临时申请61/818,028号的优先权利。

所有上述申请均特此以引用方式全文并入本文中。

某些所公开的实施例涉及模拟体育(fantasysport)系统和方法领域。

背景技术：

目前可用的模拟体育系统禁止比赛中的选手替换，这限制了用户的乐趣并使得用户无法更多地像现实体育队的教练和拥有者那样发挥作用。目前之所以存在这些限制，至少部分是由于设计和实行交互程度更高的选手替换系统带来许多种技术和逻辑上的挑战。然而，许多模拟用户强烈期望更多的交互(interaction)和灵活性(flexibility)，尤其在其选手正参与现实世界的体育赛事时的模拟对战期间。因此，业内需要改善用于模拟体育系统和方法的名册管理和选手替换应用程序。

目前可用的模拟体育系统监测并记录个别选手的表现作为用于对模拟球队之间的竞赛进行评分的手段的一部分。由于球队结果部分地由个别选手的表现推动，因此许多模拟用户非常密切地关注个别的选手。许多模拟体育用户强烈期望一种在模拟体育的背景中在与其他用户的竞技中更主动地应用和使用他们对个别选手的了解的方式。因此，业内需要改善比赛系统和竞技应用程序，从而允许用户在至少部分地是基于个别选手的表现的竞技中与其他用户进行竞争。

新手选手是模拟体育中最大的风险之一。许多新手或者表现不佳或者在他们的第一赛季中有许多时间待在替补席上。目前可用的模拟体育系统要求用户像任何其他选手那样对待新手。然而，许多用户强烈期望以不同及更现实的方式处理新手的模拟系统。因此，业内需要对适应与新手选手相关联的风险和利益的名册管理系统做出改善。

技术实现要素：

本发明提供用于创建比赛和比赛式应用程序(包括用于在用户之间建立正面交锋(head-to-head)挑战的直接挑战应用程序)的交互式系统和方法。一种用于建立和管理多个直接挑战的系统包括应用程序服务界面、多个用户界面、挑战应用程序以及用于在例如体育赛事等现实世界事件期间追踪进展及选手表现的多个外部数据服务。本发明也公开一种允许用户在真人体育赛事进行期间改变或修改其模拟选手阵容的系统和方法。

在一些实施例中，用于管理在比赛应用程序用户之间的多个直接挑战的系统包括：应用程序服务界面，包含数据库和与多个外部数据服务进行通信的外部数据读取器；多个用户界面，用以方便访问所述应用程序服务界面；以及挑战应用程序，包括非暂时性计算机可读介质以及计算机系统的一个或多个处理器，所述非暂时性计算机可读介质包含用于管理在用户之间的多个直接挑战和/或多个单个选手挑战的程序指令，所述一个或多个处理器耦合至非暂时性计算机可读介质以用于执行所述程序指令以：(a)接收所述第一用户所选择的参与第一直接挑战的第一竞赛者；(b)接收第二竞赛者以在所述第一直接挑战中用作所述第一竞赛者的竞争对手；(c)接收所述第一直接挑战的表现参数；(d)接收所述第一直接挑战的时间段；(e)接收来自第二用户的接受，并且做出响应，部署所述第一直接挑战；(f)指令所述外部数据读取器自所述多个外部数据服务中的至少一者收集所述时间段期间所述第一竞赛者的第一组实际表现数据，以及所述时间段期间所述第二竞赛者的第二组实际表现数据；(g)计算所述第一直接挑战的得分，其中所述得分是基于对所述第一组实际表现数据与所述第二组实际表现数据的比较；(h)向所述第一用户和所述第二用户报告所述得分；以及(i)将得分存储在数据库中。

所述一个或多个处理器还可执行程序指令以：在显示上向第二用户呈现第一直接挑战；为第二用户提供选项以提交响应，所述响应由选自由接受、拒绝和还盘(counteroffer)组成的群组的指示符(indicator)组成；接收来自第二用户的响应；以及响应于接收等于还盘的响应，向第二用户呈现第一直接挑战的一个或多个属性供核查和修改。

第一竞赛者可包括第一球队，且第二竞赛者可包括第二球队。

第一竞赛者可包括由两个或更多个参加者组成的第一组，且第二竞赛者可包括由两个或更多个参加者组成的第二组，其中第二组的参加者数量与第一组相同。

挑战可涉及现金、模拟美元(fantasydollars)或虚拟货币(virtualcurrency)的担保品。所述一个或多个处理器还可执行程序指令以：接收与第一直接挑战相关的担保品数量的选择；并基于得分将担保品数量应用至第一直接挑战。

应用程序服务界面还可包括挑战报告工具，用于向同伴用户(fellowuser)中的一个或多个用户显示按日期排列的多个直接挑战。

应用程序服务界面还可包括社交报告引擎，用以在与应用程序服务界面交互的预定子集期间针对同伴用户的至少第一子集在用户数据库中收集和存储用户数据，用户数据包括人口统计事实(demographicfact)和比赛上场行为(game-playbehavior)。

在其他实施例中，用于多个比赛式活动的交互式系统包括：(a)内容管理系统，包括多个比赛模板、与多个外部数据服务进行通信的比赛内容数据库；(b)多个应用程序服务，与内容管理系统进行通信，包括一个或多个比赛式应用程序；以及(c)一个或多个用户界面，用以方便访问用于多个用户的所述多个应用程序服务，其中所述一个或多个比赛式应用程序包括挑战应用程序。

所述交互式系统还可包括社交报告引擎，与内容管理系统进行通信，用于在与所述多个应用程序服务交互的预定子集期间针对多个用户的至少第一子集在用户数据库中收集和存储用户数据，用户数据包含人口统计事实和比赛上场行为表现。

本发明包括一种用于管理比赛中替换的系统。所述系统包括模拟球队名册上的选手的计算机数据库。所述数据库包括由用户指定在模拟对战中上场比赛的选手的活跃选手数据集、以及未由所述用户指定在模拟对战中上场比赛的选手的未选选手数据集。比赛中替换软件模块用以为所述用户呈现图形用户界面，所述图形用户界面列出由所述用户指定在所述模拟对战中上场比赛的多名选手；对所述用户向所述图形用户界面的输入做出响应，所述输入为选择所述用户期望在模拟对战期间换出所述活跃选手数据集的由所述用户指定在所述模拟对战中上场比赛的所述多名选手中的一名或多名选手；为所述用户呈现图形用户界面，所述图形用户界面列出由所述用户指定不在所述模拟对战中上场比赛的多名选手；对所述用户向所述图形用户界面的输入做出回应，所述输入为选择所述用户期望在模拟对战期间换入所述活跃选手数据集的未被所述用户指定在所述模拟对战中上场比赛的所述多名选手中的一名或多名选手；更新所述活跃选手数据集，以替代所述用户期望在模拟对战期间换出所述活跃选手数据集的由所述用户指定在所述模拟对战中上场比赛的所述多名选手中的一名或多名选手；以及更新所述活跃选手数据集，以添加所述用户期望在模拟对战期间换入所述活跃选手数据集的由所述用户指定不在所述模拟对战中上场比赛的所述多名选手中的一名或多名选手。

本发明还包括一种在现场模拟竞赛期间管理选手交换的方法。所述方法包括：在所述用户的图形用户界面上列出用户为模拟竞赛所选择的活跃选手的名册。所述系统通过自所述活跃选手名册替代被所述用户选择变为不活跃选手的活跃选手而对所述用户经由所述图形用户界面选择要变为不活跃选手的所述用户为所述模拟竞赛所选择的所述活跃选手中的一名或多名选手做出响应。在所述图形用户界面上列出能够被换入所述活跃选手名册的不活跃选手名册。所述系统通过将被所述用户选择变为活跃选手的所述不活跃选手添加至所述活跃选手名册而对所述用户经由所述图形用户界面选择被所述用户选择要变为活跃选手的所述不活跃选手中的一名或多名选手做出回应。

本发明也包括一种在模拟比赛系统中进行直接用户对用户挑战的方法。所述方法包括由第一用户创建直接模拟比赛挑战。创建所述挑战包括在第一图形用户界面上选择第一模拟执行者及第二模拟执行者；在所述第一图形用户界面上选择所述第一模拟执行者与第二模拟执行者中的每一者共用的表现参数；在所述第一图形用户界面上选择挑战时间段；在所述第一图形用户界面上选择挑战担保品；由所述第一用户自在所述第一图形用户界面上指示的潜在对立第二用户清单中选择为所述挑战的目标的对立第二用户；在第二图形用户界面上将所述挑战呈现给所述对立第二用户。经由所述第二图形用户界面接收来自所述对立第二用户的输入，所述输入指示所述挑战是被接受、被拒绝还是对所述挑战提出修改。经由所述第一图形用户界面将来自所述对立第二用户的所述输入呈现给所述第一用户。基于在所述挑战时间段中的所述表现参数对所述挑战的结果进行评分。将评分结果报告给所述第一用户和第二用户二者。在数据库中存储所述挑战以及所述挑战的评分结果。

以上概述并不旨在限制本发明的范围，或描述本发明的每一实施例、方面、实施方式、特征或优点。本发明的具体技术和优选实施例结合附图在以下段落中描述，以供所属领域的技术人员很好地了解所主张的发明的特征。应理解，上文所述的特征以及下文所述的特征不仅可以以所规定的组合使用，而且可以其他组合使用或单独使用，此并不背离本发明的范围。

附图说明

所公开的各实施例的特征将在详细说明中变得更显而易见，其中参照附图，在附图中：

图1为根据各实施例在一个实例性平台架构中所示的用于比赛创建和管理的系统的示意图；

图2为根据各实施例用于在模拟体育或其他应用程序中管理正面交锋挑战的系统的示意图；

图3至图13为根据各实施例的用于建立和管理直接挑战的系统的具有交互式用户界面的一系列显示样本；

图14为根据各实施例的直接挑战清单的显示样本；

图15至图32为根据各实施例的在显示上用于执行名册管理系统的一系列交互式用户界面；

图33至图37为根据各实施例的用于正面交锋挑战的系统架构各方面的图；

图38例示根据各实施例的在现场比赛进行期间用于选手交换的用户界面；

图39至图43例示根据各实施例的各种不同类型的比赛主题；

图44和图45例示根据各实施例的用于在直接挑战比赛中交换选手的用户界面；

图46例示根据各实施例的用于在进行挑战或交换之前搜索选手的用户界面；

图47例示根据各实施例的示出来自特定对手的历史数据的正面交锋记录弹窗；

图48例示根据各实施例的全阵容挑战特征。

具体实施方式

在以下说明中，将参照各实例性实施例对本发明进行解释。然而，这些实施例并不旨在将本发明限制于本文中所述的任何具体实例、环境、应用或特定实作方式。因此，提供对这些实例性实施例的说明仅用于例示目的而非限制本发明。

通过参照以下详细说明、实例、图式和以上权利要求以及其之前和之后的说明，更容易理解本发明的系统和设备以及方法。然而，在对本发明的装置、系统和/或方法进行公开和描述之前，应理解除非另有规定，否则本发明并不限于所公开的具体装置、系统和/或方法，同样地，所公开的具体装置、系统和/或方法当然可以变化。还应理解，本文中使用的术语仅用于描述特定方面的目的，而非旨在进行限制。

以下说明和图式通篇中，相同的部件用相同的参考编号标记。所述图式可不成比例，且为了清楚、简洁以及传递信息，某些特征可依比例增大示出或以稍微示意的格式示出。

提供以下对本发明的说明，以能够在本发明最佳的目前已知的实施例中对本发明进行教示。为此，相关领域中的技术人员将认识并了解，可对本文中所描述的本发明的各个方面做出许多改变，同时仍获得本发明的有益结果。还应理解，本发明的一些期望的有益效果可通过选择本发明的一些特征而不使用其他特征而获得。因此，所属领域中的从业人员将认识到，可以对本发明进行许多修改和改编，并且在某些情形下这些修改和改编实际上是所期望的且为本发明的一部分。因而，提供以下说明是为了举例说明本发明的原理而非对其进行限制。

除非上下文另有明确说明，否则通篇使用的单数形式“一(a，an)”和“所述(the)”包括复数指称。因而，举例来说，除非上下文另有说明，否则提及一个组件时可包括两个或更多个此类组件。

在本文中范围可表达为自“约”一个特定值和/或至“约”另一个特定值。当表达此种范围时，另一方面包括自所述一个特定值和/或至所述另一特定值。类似地，当值以约数表示时，通过使用先行词“约”，应理解所述特定值形成另一方面。还将理解，所述范围中每一范围的端点在与另一端点的关系中以及独立于另一端点方面都很重要。

本文中使用的用语“可选的(optional)”或“视需要(optionally)”意指随后描述的事件或情形可以发生或者可以不发生，且所述描述包括其中所述事件或情形发生的情况以及所述事件或情形不发生的情况。

比赛(games)

本文中使用的用语比赛是指所进行的用来进行比赛或娱乐的活动，以及用于便于对具体对象或目的进行追求的比赛式交互式活动。广义上，本文中描述的比赛使得用户既能够与比赛内容本身进行交互，又能够与比赛相关的插入内容或请求(有时称作行动召唤(callstoaction))进行交互。本文中所述的比赛和比赛式交互式系统，包括用于创建比赛超集的比赛系统在内，使得用户与比赛之间的参与度更深。本文中使用的用户参与度是指进行比赛的频率、进行比赛的持续时间以及与比赛内容和/或行动召唤进行交互的深度。更深的用户参与度增加比赛的价值，尤其是在商业背景中。通过本文中所述的比赛系统所创建和管理的比赛与现有的比赛系统相比成本低、部署快，并且易于管理。

模拟体育比赛(fantasysportsgames)。模拟体育是一项竞赛，其中每个用户选择并管理由特定体育运动的真实选手构成的虚构的或模拟的球队。每个用户根据每名选手的现实世界表现积累得分。通常，用户担任球队管理者或教练的角色，根据每个特定联盟的规章制度集，在草案过程(draftprocess)中选择选手，对选手进行交易，确立活跃名册和不活跃(替补)名册，改变名册等。

目前可用的模拟体育系统禁止比赛中的选手替换，这限制了用户的乐趣并使得用户无法更多地像真实的体育队的教练和拥有者那样发挥作用。目前之所以存在这些限制，至少部分是由于设计和实施交互程度更高的选手替换系统带来许多种技术和逻辑上的挑战。然而，许多模拟用户强烈期望更多的交互和灵活性，尤其在其选手正在参与现实世界的体育赛事时的模拟对战期间。

非体育比赛(non-sportsgames)。尽管许多本文中所述的系统和方法是在模拟橄榄球的背景中讨论，但是本文中所公开的技术对于各种体育运动和其他可量化表现也是有用和适用的。举例来说，图39例示与公司的股票业绩、职业曲棍球、纳斯卡赛车(nascar)和全美大学篮球联赛(ncaabasketball)相关的比赛游戏实例。图40例示真实电视节目结果的比赛游戏实例。图41例示职业橄榄球队的冲球码数(rushingyard)以及音乐唱片销量的比赛游戏实例。图42例示政治和新闻结果的比赛游戏实例。图43例示天气预报和例如美国、世界、政治和公平等类别的一批新闻事件的游戏实例。

系统(system)

图1为根据具体实施例的用于比赛创建和管理的系统100的示意图。如图所示，系统100可包括各种相互通信的元件，包括内容管理系统200、应用程序服务300、用户界面400和社交报告引擎500。系统100也可包括比赛内容数据库220、活跃比赛-游戏数据库(activegame-playdatabase)320、用户数据库520、外部数据来源380。外部数据来源380可包括外部内容来源382和外部应用程序388。

图1还例示实例性系统平台架构。本文中所述的比赛系统和方法可使用自服务平台提供，所述自服务平台通过一组友好的用户界面400方便比赛的创建和管理。根据各实施例的系统架构可包括图1中所示的组件和模块。

如图所示，应用程序服务界面300可包括restapi370以对独立的模块进行召唤。表述性状态转移(representationalstatetransfer；rest)是一类针对例如因特网等分布式系统的软件架构。restapi370能够实现可扩缩性改善、对组件和相关规则的控制、界面的开发以及额外组件的部署。

根据具体实施例的事件处理程序(eventhandler)460包括用户界面，所述用户界面使得不熟练的用户或管理员能够在无任何技术编程协助的情况下创建、编辑、修改和更新各种各样的行动-事件组合。用户界面包括访问各种各样的存储在程序库(library)中的资产(asset)—例如具有可点击链接的社交-媒体标志的图库-照片图像等—以供用户从中选择。用户界面还允许用户或管理员以用户友好格式填入(populate)整个系列的事件-行动关系。举例来说，用户界面可包括一系列下拉式菜单，所述下拉式菜单具有用于行动、事件以及与每一者相关联的规则(例如包括使用计数器、时间/时钟计数器等)的选项。事件处理程序460接受用户输入并建立一系列计算指令(例如决策树等)以供比赛使用。

所述比赛引擎或系统以及用户的计算装置可以是包括处理器、非暂时性内存和存储在所述内存上的软件代码的计算装置，所述软件代码用于执行相应的比赛引擎、系统和用户计算装置中的每一者的具体功能和特征。

社交报告引擎(socialreportingengine)。在另一方面，根据具体实施例的比赛系统100被设计成通过以下方式来便于比赛超集的创建和开展：提供多种比赛类型和类别并且使用称为社交报告引擎500的模块积极地收集比赛的整个超集中的用户数据。根据具体实施例的社交报告引擎500搜集用户数据(包括在比赛系统的注册及使用期间、在比赛进行期间、在相关交互(例如回答调查及对其他类型的行动召唤做出响应)期间以及在社交媒体行动(进入喜欢(likes)、分享内容等)期间的用户行为—跨多个比赛，在较长的一段时间中，)从而致使对可能为数百万的用户数据个人资料(profile)进行填入和更新，所述用户数据可存储在用户数据库520中。

用户数据包括由用户自愿提供的初始个人资料数据，通常开始于共享facebook个人资料、twitter账户、foursquare历史或其他集成式第三方应用程序中早已包含的信息。比赛系统供应商也可以通过检索或者以其他方式在会员期间随时搜集用户数据。用户数据还包括按所开展的具体比赛的比赛表现；包括，例如，用户在具体的体育运动中是否做出准确的预测，以及用户是否始终如一地喜欢或偏爱某个产品、服务或公司。在优选实施例中，将对用户数据进行汇总，以便以不会出卖或公开可识别的个人信息的方式得出商业智慧和其他有用信息。用户数据可以汇总或匿名的格式提供；然而，此类用户数据是有价值的，因为由本发明的比赛系统收集和存储的用户数据包含各种各样的有用的人口统计信息，以及在所述比赛系统和相关活动中用户行为的历史，如本文中所述。人口统计信息与实际用户行为的这种组合使得由所述比赛系统收集和存储的用户数据具有价值。

正面交锋挑战(head-to-headchallenges)

本文中所述的系统和方法包括正面交锋或直接挑战应用程序和系统，有时在本文中称为“manoemano”。本文中使用的正面交锋或直接挑战是指例如比赛或模拟体育应用程序等应用程序的两名个人用户之间的直接挑战。

根据具体实施例的挑战应用程序可被配置成允许第一用户创建对战、向第二用户发送挑战、监测对战的结果、处理挑战、识别获胜者、计算和公布得分以及更新排行榜。如果适用/当适用时，可对担保品进行处理。

挑战者(第一用户)和第二用户不需要进行排程以在发送、接受挑战的时间或在为挑战主题的活动将要进行时让彼此的球队上场比赛。举例来说，在发送挑战时，挑战者可在不同的联盟中作为第二用户，或完全没有联盟。因而，挑战可以是在模拟对战比赛的正常时间表之外的“单方挑战(sidechallenge)”。第一用户与第二用户之间的挑战可涉及任何努力领域，包括体育、政治、娱乐、时事等。

挑战可根据以下一般格式构建：“a将在[此事件或时间段]期间在[努力领域]以[给定表现][胜过或击败]b(awill[outperformorbeat]bin[givenperformance]in[fieldofendeavor]during[thiseventortimeperiod])”。对战的结果可以根据具体情况由现实世界比赛或竞赛中每一个竞争对手的统计表现决定。

可使用如本文中所述的挑战应用程序来选择挑战主题或竞争对手(“a”和“b”)并创建例如这样一个挑战：“在这个周日的橄榄球赛期间，barrysanders冲球的总码数将比marcusallen多”。结果可基于所选阶段(周日橄榄球赛)期间的现实世界表现(冲球总码数)确定或进行评分。

根据具体实施例的manoemano挑战应用程序可被配置成允许用户通过从清单、数据库或外部内容来源中选择选手或竞争对手来创建对战。

根据具体实施例，图2为用于在比赛应用程序的用户之间产生和管理多个直接挑战的挑战系统1100的示意图。如图所示，挑战系统1100可包括多种相互通信的元件，包括应用程序服务界面1300、多个用户界面1400和社交报告引擎1500。挑战系统1100还可包括数据库1220、用户数据库1520以及一个或多个外部数据服务1280。外部数据服务1280可包括例如体育运动馈送(feed)a1282、内容apib1284以及体育运动馈送b1286。

在替代实施例中，挑战系统1100可包括与图1中所绘示的系统类似的内容管理系统。

所示应用程序服务界面1300可包括restapi1370，以对独立的模块进行召唤。表述性状态转移(rest)是一类用于例如因特网等分布式系统的软件架构。restapi1370能够实现改善的可扩缩性、对组件和相关规则的控制、界面的开发以及额外组件的部署。

在逻辑层面，所示的在具体实施例中的应用程序服务界面1300包括用于评分和排行榜(scoringandleaderboards)的模块、用户管理器(usermanager)、挑选引擎(picksengine)1340、对战逻辑(matchuplogic)1310和事件数据处理程序(eventdatahandler)1360。在数据层面，所示的在具体实施例中的应用程序服务界面1300包括持久性管理器、设置管理器、人工数据界面以及一个或多个外部数据读取器1380。

根据具体实施例的挑战应用程序可使用编程计算机实作。直接挑战可以是在例如体育、政治或娱乐等各种努力领域中的任一领域中的竞争者或竞争对手(或所感知的竞争对手)之间的竞赛。挑战可以按以下一般格式构建：“在[此事件或时间段]期间[第一竞赛者]将[根据此表现参数胜过][第二竞赛者]([firstcompetitor]will[outperformaccordingtothisperformanceparameter]the[secondcompetitor]during[thiseventortimeperiod])”。挑战的结果或得分可通过比较每一竞赛者的实际表现确定；例如在现实世界比赛或竞赛中。挑战应用程序使得用户能够使用动态和用户友好的界面建立直接挑战的每一要素。挑战应用程序可包括本文中所述的比赛系统的特征和功能中的任一者或全部。举例来说，挑战应用程序可包括访问可由所述系统存取的比赛内容或其他数据；例如一个或两个竞赛者的照片。

在淘汰赛(bracketgame)的背景中，第一竞赛者和/或第二竞赛者可以是选自在淘汰赛中进行竞赛的球队中的任一者的选手。表现参数可以是获得更多得分。时间段可以是在联赛的每一相应竞赛者的第一比赛中的第二段上场比赛时段。如图2中示意性所示，应用程序服务界面1300可包括对战逻辑1310。根据具体实施例的对战逻辑1310可包括用于对战数据的规则、逻辑、限制以及标准表示法(representation)。以上实例的对战数据可包括用以完成此样本挑战语句的数据或属性：在“联赛的每一相应竞赛者的第一比赛中的第二上场时段”期间“第一竞赛者”将比“第二竞赛者”“获得更多得分”。

根据具体实施例的挑选引擎1340用以在显示上呈现选项并且能够提供供用户进行挑选的选择。在另一方面，挑选引擎340还可包括供用户做出选择的规则、逻辑、限制以及标准表示法。举例来说，用于特定比赛的挑选引擎340可根据规则和相关条件(例如此用户是否已选择时间段)而向用户显示选项，且可限制用户的选择(例如一旦提交便不允许改变挑选)。挑选引擎1340包括每一挑战的数据表示法和具体过程，如对战逻辑1310所定义。

根据具体实施例的事件数据处理程序1360用以管理来自外部数据服务1280中的每一者的输入数据。每一外部数据服务1280可具有其自己的与其他外部数据服务不同的数据编排。事件数据处理程序1360包括一组特定的语意，用来将来自外部数据服务1280中的每一者的输入数据根据对战逻辑1310映射至对应的数据位置。在此方面，事件数据处理程序1360解析、分类、命名、映射以及以其他方式协调根据对战逻辑1310所处理的输入对战数据。

举例来说，事件数据处理程序1360可包括用于对关于例如针对如体育赛事或竞赛的现实世界事件的“开始名册”等参数的输入数据进行映射的语义。由于在直接挑战中的两个竞赛者可在不同的比赛中在不同的日期上场比赛，因此事件数据处理程序1360可用以接收和分析例如“开始名册”等数据以便于直接挑战的建立。

举例来说，事件数据处理程序1360可包括用于对关于例如类似体育比赛的现实世界事件的“开始时间”等参数的输入数据进行映射的语义。由于在直接挑战中的两个竞赛者可能不在现实世界比赛中相互竞争，且由于他们各自的比赛可在不同的时间上发生，因此事件数据处理程序1360对开始时间和其他参数进行处理以便于对关于直接挑战中的每一相应竞赛者的数据进行准确搜集和评分。

根据具体实施例的对战数据可具有以下用于描述和处理直接挑战的属性。举例来说，每一挑战可具有这些属性：事件日期(eventdate)、状态(status)(暂停、进行中、完成、处理)以及来源(source)(用于建立挑战以及在后来对挑战进行评分的数据馈送或内容服务)。每一挑战可包括具有以下这些属性的问题(question)：标题(title)、映射模式(mappingpattern)(用于计算得分的规则，例如表现参数和时间段)、正确答案(包括提到赢得挑战的竞赛者)以及得分(规定赢得挑战的得分)。

根据具体实施例的manoemano挑战应用程序可被配置成允许用户通过自清单、数据库或外部内容来源选择竞赛者而建立直接挑战。关于即将来临的竞赛和比赛的信息可从各种外部数据来源1280获得并在下拉式清单或其他用户友好的界面中作为选项呈现给用户。挑战应用程序可使用人工数据界面，以使得用户不参考外部数据而建立挑战。

在另一方面，挑战应用程序可用以在各竞赛者之间和之中自动选择和创建许多直接挑战，并且随后向用户建议将此类挑战用于对同伴用户的直接挑战中。

在具体实施例中，每一外部数据来源可具有其自己的对应外部数据读取器，所述读取器继而使用其自己的对应事件数据处理程序。在此方面，所述系统可包括多个外部数据读取器1380，且事件数据处理程序1360可包括多个一起工作来收集和组织数据的数据处理程序。

正面交锋挑战比赛(head-to-headchallengegameplay)

以下说明和各图描述了建立直接挑战或正面交锋挑战的过程的一个实例。直接挑战可用下面的一般格式构建：“在[此事件或时间段]期间[第一竞赛者]将[根据此表现参数胜过][第二竞赛者]([firstcompetitor]will[outperformaccordingtothisperformanceparameter]the[secondcompetitor]during[thiseventortimeperiod])”。在下面的实例中，第一用户(kehoesabe队)向第二用户(dragonarmy队)发送直接挑战，断言第一竞赛者(knowshonmoreno)在一整天期间取得的总码数将大于第二竞赛者(mattforte)，以500模拟美元的数量下了非现金担保品，并且支付了99分的费用来包括这两名选手。

在替代实施例中，第一用户可以向他所有的好友、向特定组或类别中的所有用户、或向整个系统中的所有用户发送直接挑战。在此方面，可构建直接挑战并将其作为竞赛邀请发给选定的用户组。

图3例示显示10并且包括用以开始建立直接挑战的过程的开始按钮20(标注为manostart)。接下来，当选择了按钮20时，根据具体实施例的挑战应用程序可打开显示，所述显示示出球队或对手(或组、联盟中的其他用户或用户联系人)的清单30，如图4中所示。在此实例中，每一球队代表一个模拟体育队，是由特定用户选择的一批选手。在此方面，球队清单30实际上代表用户清单。

在此实例中，第一用户为拥有kehoesabe队的用户。第一用户可选择对手—此处，他选择dragonarmy队——之后，根据具体实施例，挑战应用程序打开显示，所述显示列出挑战的属性40，如图5中所示。属性40包括我的选手(myplayer)41(或者第一竞赛者)、你的选手(yourplayer)42(第二竞赛者)、统计数据(stat)43(表现参数)、时段(timeframe)44(时间段)、模拟美元(fantasydollars)45(结果上可选的非现金担保品)或现实世界现金担保品、选项(options)46(用于向直接挑战特征的供应商或者另一参与实体进行付款)以及发送挑战(sendchallenge)47(用于一旦已选择所有属性后发送直接挑战)。

如图6中所示，响应于选择我的选手41，根据具体实施例，挑战应用程序打开可选择作为所述直接挑战的第一竞赛者的(第一用户自己的球队上的)竞赛者的显示。在此实例中，第一用户选择名为knowshonmoreno的选手。竞赛者的清单可限于早已在所述用户的球队上的竞赛者，或者所述清单可包括选手的通用池，包括所有选手。也可为用户提供对可用选手清单的每一成员进行研究的能力。研究屏幕的实例示于图46中。

如图7中所示，响应于选择你的选手41，根据具体实施例，挑战应用程序打开可选择作为所述直接挑战的第二竞赛者的(在对立第二用户球队上的)竞赛者显示。在此实例中，第一用户选择名为mattforte的选手。

如图8中所示，响应于选择统计数据43，根据具体实施例，挑战应用程序打开统计数据或可用于此特定竞赛的其他表现指标的显示。在此实例中，可用的指标包括触地得分(touchdowns)、接发球(receptions)及码数(yards)。在此实例中，第一用户选择码数。对于篮球竞赛，举例来说，可用的指标可包括篮板球(rebounds)、罚球(freethrows)及三分球(three-pointgoals)。

如图9中所示，响应于选择时段44，根据具体实施例，挑战应用程序打开时间段、持续时间或可用于此特定竞赛的其他暂时限定的参数的显示。在此实例中，可用的时段包括节(quarter)、半场(half)、天(day)及周(week)。在此实例中，第一用户选择天(day)。

如图10中所示，响应于选择模拟美元45，根据具体实施例，挑战应用程序打开非现金担保品数量的显示。在此实例中，可用的担保品包括$100、$500、$1000及$这是我所拥有的全进(iownthisallin)。在此实例中，第一用户选择$500。

如图11中所示，响应于选择选项46，根据具体实施例，挑战应用程序打开支付选项的显示。在此实例中，可用的支付选项包括$.59/选手或$.99包括两名选手(coverbothplayers)。在此实例中，第一用户选择$.99包括两名选手。

如图12中所示，响应于选择发送挑战47，根据具体实施例，挑战应用程序显示通知50，通知50确认直接挑战已发送至第二用户(dragonarmy队的拥有者)。如果尚未选择第二用户，那么挑战可作为竞赛邀请向所选的用户子集或所有用户公布或显示。

图13例示根据挑战应用程序的具体实施例向第二用户呈现直接挑战。如图所示，挑战应用程序可显示两个竞赛者(以及相关信息)、挑战指标(“总码数”)、时间段(日期)以及模拟担保品。显示还可包括关于由哪一用户支付费用的消息。

如图13中所示，根据具体实施例的挑战应用程序包括回复属性60的显示以供第二用户在接收到直接挑战时使用。回复属性60包括接受(accept)61、拒绝(decline)62和还盘(counter)63的可选择图标。响应于选择接受61，挑战应用程序向第一用户发送通知，所述通知告知所述挑战已被接受且无改变。响应于选择拒绝62，挑战应用程序向第一用户发送通知，所述通知告知所述挑战已被拒绝。响应于选择还盘63，挑战应用程序向第二用户提供一系列显示以及对所述直接挑战的属性做出改变的可选择图标。当完成时，挑战应用程序为第二用户提供“发送挑战(sendchallenge)”图标，以将修改后的挑战(所述还盘)发送回第一用户供考虑。

图14例示在显示上的挑战清单70。响应于选择标记为挑战的图标22，挑战应用程序显示挑战清单70以及一个或多个过滤器(filter)或类别。在此实例中，清单70包括对立用户(第二用户)的名称、挑战的标题、得分、日期、状态(赢或输)，以及担保品数量(如果存在)。还可向用户提供正面交锋记录弹窗，如图47中所示，所述弹窗示出来自特定对手的相关历史数据。用户还可提交全阵容挑战，如图48中所示。

二对二直接挑战及以上(two-versus-twodirectchallengesandmore)

根据具体实施例的挑战应用程序可被配置成允许用户建立二对二挑战；亦即，在两个第一竞赛者与两个第二竞赛者之间进行竞赛。在此方面，第一竞赛者可以是由两个或更多个参加者组成的组，且第二竞赛者可以是由两个或更多个参加者组成的组，其中这两个组具有相同数量的参加者。在此实施例中，每一对对立竞赛者可具有其自己的表现参数(例如冲球码数或总码数)，每一对可具有其自己的担保品和/或费用，且时间段可长至足以包括若干现实世界比赛。在此方面，挑战应用程序可用以帮助在每一对立方建立具有三个或更多个竞赛者或整个队的挑战。

用于挑战的社交报告引擎(socialreportingengineforchallenges)

在另一方面，根据具体实施例的挑战系统1100被设计成便于创建和进行多个直接挑战，以及使用称为社交报告引擎1500的模块主动地收集用户间挑战的整个超集中的用户数据，如图2中所示。根据具体实施例的社交报告引擎1500搜集用户数据—包括在比赛系统的注册和使用期间、在比赛进行期间、在交互期间、在社交媒体行动期间以及在挑战期间的用户行为—跨多个比赛，在较长的一段时间中，从而致使对可能为数百万用户数据个人资料进行填入和更新，所述用户数据可存储在用户数据库1520中。

用户数据包括由用户自愿提供的初始个人资料数据。挑战系统和/或比赛系统供应商也可以通过检索或者以其他方式随时搜集用户数据。用户数据还包括按所进行的具体比赛的比赛表现；包括，例如，用户在具体的体育运动中是否做出准确的预测，以及用户是否始终如一地喜欢或偏爱某个产品、服务或公司。在优选实施例中，将对用户数据进行汇总，以便以不会出卖或公开可识别的个人信息的方式得出商业智慧和其他有用信息。用户数据可以汇总或匿名的格式提供；然而，此类用户数据是有价值的，因为由本发明的比赛系统收集和存储的用户数据包含各种各样的有用的人口统计信息，以及在所述比赛系统和相关活动中用户行为的历史，如本文中所述。人口统计信息与真实用户行为的这种组合使得由所述比赛系统收集和存储的用户数据具有价值。

来自挑战的群体智慧(crowdwisdomfromchallenges)

在另一方面，根据具体实施例的社交报告引擎1500包括群体智慧模块，所述模块用以按主题在预定的时间段内对大量正面交锋挑战进行分析和评级，以识别关于特定主题的群体智慧。在使用中，所述模块可识别关于特定主题最经常是正确的挑战的子集，并建立关于顾客子集的报告。

在此方面，群体智慧模块的任务是探索特定主题(体育、电影奖等)，识别关于所述主题最经常是正确的挑战者，以及在一段时间内分析所述预测以实现一致性和准确性。由于挑战系统1100包括在较长的一段时间里参与多个正面交锋挑战的大量选手，因此最经常是正确的挑战者代表使用所述挑战系统的所有选手的群体智慧。在商业背景中，群体智慧具有价值，因为其代表在各种背景下有用的可付诸实施的商业智慧。

用于挑战的群体大师(crowdguruforchallenges)

在相关的方面，根据具体实施例的社交报告引擎1500包括群体大师模块，用以在预定时间段中按用户以及按主题对大量正面交锋挑战进行分析和评级，以识别最经常赢得关于特定主题的挑战的用户专家子集(即，群体大师(crowdguru))。在使用中，群体大师模块可识别最经常赢得关于特定主题的挑战的用户，并且可以向顾客报告所述识别或那些大师。

在此方面，群体大师模块找出那些最经常赢得关于特定主题(体育、电影奖等)的挑战的用户并将每一个这样的用户识别为群体大师。根据具体实施例，随时间按主题对每一用户的挑战进行分析，以确定最经常赢得挑战的一个或多个用户。由于所述比赛系统包括在较长的一段时间里参与多个正面交锋挑战的大量选手，因此最经常赢得挑战的用户可以被识别为关于所述特定主题的群体大师。在商业背景下，由群体大师或群体大师的子集进行的比赛挑战具有价值，因为其代表在个种背景下有用的可付诸实施的商业智慧。群体大师模块将就在特定行业(verticals)中赢得挑战的数量对用户进行评分，并汇集由顶级专家(基于最新的结果为滚动清单的成员的群体大师执行者)进行的挑战，使用社交报告引擎1500和其他工具分析数据，并使用所述数据产生群体大师数据供商业销售，呈现在例如商业智慧报告控制台中，如本文中所述。

根据具体实施例的群体大师模块用以通过随时间按类别或按其他所选的指标汇集挑战得分和胜利来识别每一比赛类别中的最佳表现用户，并维护顶级执行者的滚动子集。例如，周一橄榄球之夜挑战的前5％优胜者，三月疯狂挑战的前10％优胜者等。

在此方面，挑战系统1100和社交报告引擎1500可用于基于其在关于所述话题的正面交锋挑战子集中的实际赢/输表现来识别：(a)与特定话题相关的群体智慧，和/或(b)群体大师执行者。不像有时称为预测引擎的现有工具，群体智慧模块和群体大师模块将基于正面交锋挑战中的实际表现。

比赛中名册变动(in-gamerostermoves)

目前可用的模拟体育系统包括球队名册(由用户在正式草案过程或包括交易、弃权和自由球员选取等用于建立或改变用户名册的其他过程期间选择)。在即将到来的比赛或比赛子集之前，用户在最后期限之前自球队名册为活跃名册选择一组选手。其余的未被选择的选手仍留在用户的替补名册(benchroster)上。在即将到来的比赛子集期间，模拟体育系统可在每一选手参加的每一现场比赛期间跟踪并评估活跃名册上选手的表现，标出与选手成就相关的得分。

活跃后备队(activereserves)。本文中所述的名册管理系统和方法包括活跃后备队。根据特定实施例，活跃后备队清单描述了选自用户的球队名册、可在现场现实世界体育赛事或比赛期间供替换的选手的清单。

在一个实施例中，活跃后备队可包括由用户在所述比赛的子集开始之前自替补名册中选择的一名或多名选手的子集。作为另一选择，活跃后备队清单可包括替补名册上的所有选手，不需用户提前选择。提供所述活跃后备队清单使得用户的表现更像教练或管理者在真实比赛期间的表现。

在操作中，名册管理系统可包括比赛中替换模块，所述比赛中替换模块被配置成允许用户在模拟对战正在进行期间用选自活跃后备队的一个替补选手、多个替补选手或球队替代一个活跃选手、多个活跃选手、一组选定选手或者整个球队。

由于来自活跃名册的活跃选手可能在不同的时间上参与不同的现场比赛，因此比赛中替换模块可用以首先识别和选择目前正在进行中的模拟对战—换句话说，其中用户的活跃名册上的选手之一目前正在现场比赛中参赛的模拟对战。举例来说，在nfl的模拟联盟中，比赛的子集可包括在特定周末期间；在周四夜晚与接下来的周一夜晚之间进行的橄榄球比赛。来自模拟活跃名册的活跃选手可在此时段期间的不同时间参与不同的橄榄球比赛。比赛中替换模块可用以监测和控制替换的时机以与每一活跃选手在现场比赛中的参与一致。在各种实施例中，所述模块可接收一个或多个主动信息馈送，所述馈送在本文中称为馈送数据25并在下文中描述。

系统架构包括服务界面400，服务界面400将使得模拟联盟运营商能够容易地将名册管理系统(包括比赛中替换)整合到他们现有的模拟体育应用程序中，例如由yahoo！、cbs、espn、nfl等提供的模拟体育应用程序。使用服务界面400的名册管理系统也可作为分开的或独立式模拟体育系统的一部分操作。

用于进行替换的活跃名册同样可应用至非体育事件，例如股票、商品、演员/奖项、时事、政治、电影以及其他可按人和事情进行量化的表现类型。

活跃名册功能可允许随时而非在确立的中断(break)、预定的中断或其他规定的时间窗口进行替换。活跃名册功能也可应用至定期比赛以及在某些实施例中应用至直接挑战。

图44和图45例示用于在直接挑战比赛中交换选手的用户界面。图44例示用户选择一个按钮来访问他们的挑战清单。然后在图45的上部，用户选择“交换”按钮来交换他们的参与挑战的选手。然后出现选择屏幕，以提供交替选手的选项。所提供的交换特征可不收取费用或者收取额外的成本，如图45中所示。然后用户确认他们的选择。系统可提供交换结果消息，例如在图45中的下方屏幕中。交换同样也可在定期联盟比赛中进行。

图15为交互式装置上的图形用户界面和显示的截屏，用户可通过所述用户界面和显示来接收信息、识别和选择选手以及执行替换。显示10可包括各种来自各种来源的关于一项或多项模拟体育活动的有用信息中的任一种，例如得分清单、关于比赛和选手的新闻馈送、以及用于访问和执行本文中所述名册管理系统的多种要素的多个菜单和子菜单。

图16例示包括我的球队(myteam)40在内的选项的菜单。图16中所示的对我的球队40的显示可包括例如由用户针对即将到来的比赛子集而选择的活跃名册清单。如此实例中所示，活跃名册可包括作为四分卫的drewbrees、作为跑卫的mccoy和charles等。图17中的显示还可包括活跃后备队图标50(在此实例中使用星号和字母“ar”例示)。当被选择时，图标50允许用户访问本文中所述的活跃后备队特征。

根据具体实施例的为活跃后备队清单选择选手的过程可包括例如通过指触或鼠标点击选择ar图标50的步骤100。图18例示更小的窗口60，窗口60用来邀请用户选择并激活(步骤110)单个选手或整个替补名册且然后确认所述选择(步骤115)。图19至图20例示此实施例中呈现的选项。注意，各屏幕示出进行交换所收取的费用。然而，交换费用是可选的。或者，在给定联盟中的用户在收取费用之前可接收给定数量的免费交换。

根据具体实施例的替换模块例示于自图21开始的所述图中。如图所示，我的球队(myteam)的显示可包括当被选择时允许用户访问本文中所述的系统的比赛中替换特征的按钮或图标。在图21中所示的实例中，按钮70标注有“编辑阵容(editlineup)”且其可通过使用指触、鼠标点击或其他指点和选择装置来选择。

如图22中所示，交互式装置上的下一个屏幕显示可包括由单个用户选择的模拟联盟名称20和/或球队名称清单30。根据具体实施例，选择联盟名称20中的一个可导致系统显示与其他用户进行的一个或多个活跃竞赛的状态，包括用户的活跃名册的清单，如图23中所示。如所述显示中所示，联盟名称为“州际橄榄球联盟(interstatefootballleague)”且竞赛是在称为“kitchenskrue”和“kehoesabe”的用户之间进行。在此实例中，叫kehoesabe的用户可以称为主用户，因为他的用户具有访问和操作这些图中所示的交互式装置的权限。主用户的球队名称(kehoesabe)突出显示。kitchenskrue的活跃名册或“先发球员(starters)”在左列中列出；kehoesabe的活跃名册在右列中列出。根据具体实施例，主用户的活跃名册中目前正在参与现场比赛的选手可以突出显示。如图21中所示，突出显示的选手包括右列中的“d.breesqb”和“j.charlesrb”。如图所示，所述显示可包括关于这些选手的统计数据或表现信息。由于突出显示的选手目前正在参与现场比赛，因此比赛中替换特征可被配置成允许用户进行替换；即，用自活跃后备队选择的选手替代所选择的活跃选手。

根据具体实施例，选择图23中突出显示的选手中的一者(步骤210)可使系统显示各种关于所选选手的信息(如图24中所示)。所述显示可包括一般信息、统计数据、新闻、其他人的评论、关于正在进行中的比赛的信息、以及关于所选选手的各种其他类型的信息中的任一者。在此实例中，图24显示关于drewbrees的信息。

如图25中所示的显示可包括一系列图标或按钮，包括交换图标72(在此实例中使用具有箭头的圆形符号和词“交换(swap)”例示)。点击或以其他方式选择交换图标72表示主用户希望选择此选手在现场比赛中进行替代。

如图26中所示，所述比赛中替换模块然后可显示选择窗口74，根据具体实施例，选择窗口74包括来自活跃后备队清单的既有能力又可用于替代所选选手的选手清单。有能力的替补(substitute)是在所述体育运动中扮演相同位置或角色的替补。举例来说，仅跑卫可以是用于替代跑卫的有能力的替补。如图26中所示，所选择的被替代的选手为drewbrees(四分卫)，因此比赛中替换模块用以在选择窗口74中显示在用户的活跃后备队清单上可用的四分卫的清单(此处，四分卫andrewluck和jaycutler可用)。根据具体实施例，选手可用性根据下文更详细讨论的预定条件集确定。

如图26及图27中所示，用户可选择并激活这些选手中的一者(步骤230)且然后确认所述选择(步骤235)。在此实例中，主用户选择jaycutler。进行所述替换后，系统然后可显示主用户的更新后的活跃名册或“先发球员”，如图28中所示(其中“j.cutlerqb”现在出现在右列中)。图30和图31中例示对跑卫的选择和替代进行例示的类似实例。

根据具体实施例，报告是所述比赛中替换模块的另一方面。如图29中所示，用户可点击由替补选手所获得的得分(步骤300)—在此实例中为j.cutlerqb—以查看显示关于所述替换事件的数据的消息窗口76。如图所示，消息窗口76可包括所获得的得分或者关于替换中所涉及的选手的其他数据，以及关于所述替换的后果的消息(例如，所述替换是否是好的召唤)。消息窗口76还可包括各种其他信息，包括与所述替换相关的统计数据、真实得分、模拟得分、时间戳、以及其他信息。例示跑卫的替换结果的报告的类似实例示于图32中。

可用性条件(availabilityconditions)。根据具体实施例，名册管理系统根据预定条件集判断某些选手是否可用于比赛中替换。

大多数体育赛事根据许多时间段进行，可能有加时赛时段。替换发生于当活跃选手被替补选手替代时，受可用性条件集的制约。

符合条件的活跃选手必须(1)目前在用户的活跃名册上，以及(2)目前正在还未进入最终比赛时段的现实世界比赛中进行比赛。换句话说，所述活跃选手目前必须正在模拟对战(两个模拟球队之间的比赛)中进行比赛。在上述实例中，四分卫drewbrees在显示10中作为可用的活跃选手突出显示，因为他在用户的活跃名册上并且目前正在尚未进入最终时段的橄榄球比赛中进行比赛。

符合条件的替补选手在某些实施例中可被限于以下的选手：(1)与活跃选手打相同的位置，(2)在最后期限之前被放在活跃后备队清单上，以及(3)目前正在还未进入最终比赛时段的现实世界比赛中进行比赛或者计划在尚未开始的现实世界比赛中进行比赛。在上述实例中，两个四分卫—andrewluck和jaycutler—显示在替补选手选择窗口74中，因为每一选手(1)打四分卫，(2)在用户的活跃后备队清单中，以及(3)或者目前正在还未进入最终时段的橄榄球比赛中进行比赛或者计划在还未开始的即将到来的橄榄球比赛中进行比赛。潜在替补选手的池也可扩展至包括可用的自由球员。

可设定最终时段条件，以符合有限制的替换机会，如下文中更详细地描述，可能要求替换仅在比赛时段结束时进行。在此方面，如果活跃选手目前正在他早已进入最终比赛时段的比赛中进行比赛，那么将没有更多的替换机会。

本文中所使用的最终时段可以是常规或规定比赛时段之后的额外比赛时段，例如橄榄球赛和其他体育运动中的加时赛、棒球中的额外回合(extrainnings)、曲棍球中的点球决胜(penaltyshootout)以及足球中的‘伤停补时(injurytime或stoppagetime)’时段。如果在常规赛的最终时段需要进行替换，那么所述系统可被配置成允许替换在下一次机会期间进行，即在常规赛结束以及加时赛开始后。如果需要进行替换且没有加时，那么系统可以针对所述请求向用户发放一个信用(issueacredit)。

持续时间(duration)。活跃后备队清单可在各种时间段中的任一者期间使用。举例来说，在模拟赛季，相关时间段包括：(a)整个赛季，跨越许多周，包括季后赛时段(playoffperiod)，(b)赛季中整个的常规赛集，不包括季后赛(playoffgame)，(c)所述赛季内的比赛的子集(例如，在某一天、一个周末期间、单个周或许多周期间进行的所有比赛)，以及(d)在单个比赛期间的时间子集(一个时段；例如，橄榄球赛中的节，或棒球赛中的半局)。名册管理系统可用以管理和协调活跃后备队特征可供用户使用的持续时间或时间段。

费用(fees)是所述名册管理系统的另一方面。举例来说，活跃后备队和比赛中替换特征可由特定联盟运营商或其他管理者免费提供、每一时间段收取一次费用、或者收取一些其他与使用相关的费用。例如，联盟运营商可每时间段(例如，整个赛季、比赛的子集、单项比赛、单个时段)收取单次费用，以无限制地使用活跃后备队和比赛中替换特征。举例来说，联盟运营商可对预定数量的替换x收取第一费用，然后对每一后续替换y收取第二费用。联盟运营商还可决定对例如优秀选手或关键位置收取更高的费用。在此方面，如本文中所述的名册管理系统可被配置成允许联盟运营商能够针对使用本文中所述的特征和功能而确立各种费用系统中的任一者。

所允许替换事件的数量(numberofallowedsubstitutionevents)是所述名册管理系统中可根据联盟运营商或其他管理者配置和定制的另一方面。举例来说，所述系统可被配置成允许数量无限制的替换事件。对于包括8名选手的活跃后备队清单，举例来说，用户在场现场比赛期间可用的每次机会时可最多执行8次替换。当活跃选手被替代时，他变成活跃后备队的一部分且因而可在下一次机会时参加替换。类似地，如果活跃后备队选手被激活且后来成为替补，那么所述选手在下一次机会时可再次参加替换。在此方面，为活跃后备队清单选择8名选手在每一次替换机会时创建了一个8个替换事件的集，涉及任何活跃选手和/或任何活跃后备队选手。

在不同的实例中，名册管理系统可被配置成允许有限数量的替换事件。对于包括8名选手的活跃后备队清单，举例来说，可限制用户在任何单个现场比赛期间总共有8个替换事件，没有再多的替换事件。系统也可限制选手的重复使用；举例来说，如果一个活跃选手被代替时，系统可将他放在替补名册上而非活跃后备队清单上，因而使得他不可以参加替换。类似地，如果一个活跃后备队选手被激活且后来被替代，那么所述选手便被放在替补名册上，不可再参加替换。

替换机会(substitutionopportunities)。根据所述名册管理系统的具体实施例，替换机会的数量可以限于预定的清单。换句话说，所述名册管理系统可被配置成允许替换事件仅在一个或多个预定的时间期间发生。举例来说，系统可允许替换事件在比赛时段(当然是除了最终时段，由于比赛已结束)结束时发生。替换机会时间窗口将在比赛时段结束时启动，并且在下一比赛时段开始时停止。根据具体实施例，执行替换的请求可以随时提出，如下所述。

在nfl橄榄球赛中，举例来说，系统可被配置成允许替换事件在每一节结束时发生。替换机会时间窗口将在一节结束时开启，并且在下一节开始时停止。

本文中使用的最终时段可以是常规或规定比赛时段之后的额外比赛时段，例如橄榄球和其他体育运动中的加时。在为加时的情形中，时间窗口将在最终常规比赛时段结束后开始，并且将在加时时段结束而不是开始时(vs.thebeginning)结束，除非用户进行另一替换。替换持续到他们的比赛结束时或持续到他们被换出，换入另一选手。

在替代实施例中，名册管理系统可被配置成允许实时替换事件—在正在进行的比赛期间在现场比赛中替代选手；例如，在四分卫传球(snap)后但是在他扔出超身球之前替换他和/或当橄榄球正传球(intheair)中时替换外接手。

此方面被例示用于图38中所绘示的用户界面中淘汰赛类型的比赛。左侧屏幕涉及橄榄球，而右侧屏幕涉及ncaa篮球，然而无论主题体育运动或事件是是哪种，根本的概念是相同的。用户选择要改变的选手，然后会被呈现与针对图45所讨论类似的交换屏幕。用户做出他们的替换挑选并确认所述交换。可能会针对进行所述交换收取额外的费用。

作为另一选择，所述系统可被配置成仅允许一个替换事件—在比赛期间在一个预定的时间或事件发生时或期间(例如在中场休息时)。

系统还可用以在比赛期间提供许多替换机会；例如，在任何暂停期间，在官方时钟停止时的任何时段期间，在持有任何改变后，在任何商业广告插播期间，或者在名册管理系统识别为有限或离散时间窗口的任何时段上。在此方面，名册管理系统在一定程度上依赖于(来自现实世界体育赛事的)输入数据馈送的可获得性以及在每一此类数据馈送中所包含的细节层次。在另一实施例中，系统可被配置成允许替换事件在比赛中的两个离散事件之间发生。在nfl橄榄球赛中，举例来说，系统可允许在进攻发球的开始与进攻发球的结束之间替换防守选手，等等。

替换请求(requestsforsubstitution)，根据具体实施例，在将来的替代机会之前，本文中所述的名册管理系统可随时接收和处理替换请求。换句话说，名册管理系统可被配置成使得用户可随时提交请求，指示系统在将来的替换机会出现时执行特定的替换—可以是下一次可以获得的机会(例如下一次比赛时段的末尾)，或在某一将来的机会(例如，在中场休息期间，或在规定比赛的最终时段结束时(在这种情形中，请求将仅在有加时赛时段时执行))。

举例而言，在nfl比赛中开赛的前几分钟期间，用户可提交请求，使系统在下一次可用的机会(可以是在第一节结束时)时执行四分卫替换。目前的四分卫将完成比赛的第一节，且系统将执行所述替换，从而当第二节开始时替换四分卫开始比赛。在此方面，名册管理系统为用户提供一次在所有比赛时段期间主动指导的体验，并且仅在预定的替换机会时间期间执行所述替换。

如果适当地配置，名册管理系统将对用于提交替换请求的时间窗口进行限制。举例来说，系统可被配置成要求用户不迟于比赛时段结束前一分钟提交请求。在此最后期限，系统将停止接收对所述时段进行替换的请求。“迟交的(late)”请求将在将来的机会执行；或者在下一个可用的机会或者在用户选择的将来的机会。

通知(notifications)。名册管理系统可用以监测现实世界事件并向用户发送通知。如图33中所示，服务界面400可包括通知引擎420，通知引擎420用以访问用户的名册数据，接收、解析以及以其他方式处理来自馈送数据25的输入现实世界信息，以及准备并向用户发送包含相关信息的各种通知。所述通知可包括关于用户的活跃名册、替补名册、或活跃后备队清单上的选手(或关于另一用户的选手)的信息，例如所述选手的表现或目前的统计数据。

通知引擎420还可用以处理数据并生成通知，以向用户报告关于相关选手或比赛的目前信息，并且建议进行替换。在此方面，此类通知可充当由所述名册管理系统做出的主动式建议，所述主动式建议旨在促使用户考虑做出选手替换。通知引擎420可用以基于各种现实世界事件中的任一者做出此通知，现实世界事件包括例如选手受伤(用户的选手和对手的选手)、比赛得分、选手表现趋势、天气、选手处罚情况、被换下场或拒绝的选手、选手状况(例如过去的上场时间、投球数(pitchcount)、尝试的攻击(shottaken)等)。

使用nfl橄榄球赛作为实例，如果且当一个队所取得的大比分领先另一队时，指导决策通常会改变。落后的队通常更多地传球，更少地冲球，从而创建其中接球队员(passingreceiver)具有更多机会得到模拟得分以及其中跑卫有更少机会得到模拟得分的场景。在此场景中，模拟用户(如落后队的教练)可决定进行替换，并且举例来说使得他的最强的接球队员成为活跃选手。

大的得失分差(pointdifferential)也可以导致领先队的教练将一个或多个首发选手换下场。在换下场时，所述选手不能获得模拟得分，因此用户可能希望自他的活跃后备队进行替换，以确保他的模拟队具有得分的能力。

选手受伤也会影响指导决策，有时影响非常大。当选手受伤时，所述选手不能获得模拟得分，因此用户可能希望进行替换。并且，选手受伤可能生成对于对立选手的通知。举例来说，如果主要负责防止接球手(widereceiver)接到传球的关键防守选手受伤，那么天赋较低的防守选手将最有可能代替他上场。这一变化可能影响模拟用户关于替换一个或多个接球手的决策，这些接球手现在更有可能能够在剩余的比赛期间得分。在此方面，接收关于单名选手或事件的通知可能不仅影响用户关于所述选手的决策，而且也影响关于对立选手的决策。

通知引擎420还可用以基于各种模拟相关的事件中的任一者创建通知，所述模拟相关的事件包括但并不限于其中模拟用户可能具有特定的机会来获得额外得分的情况。举例来说，假定在模拟对战中，模拟用户的对手已经使他所有选手上场且他在这周的比赛结束了。所述模拟用户的一名或多名选手可能还没有上场。通知引擎420可计算赢球所需的得分并向所述模拟用户发送像这样的通知：“sanderzon’的队已取得136分，他本周的比赛已结束。要赢得你与sanderzon的对战，你需要从你剩余的选手a和b(或从他们的代替者，如果你进行替换的话)中取得至少34分”。在此方面，系统提供通知，使得参与的模拟用户有机会结合一个或多个现实世界事件做出积极的指导决策(包括替换)，以改善他们赢得模拟对战的机会。

在真实比赛中可能出现各种可能的场景中的任一者而促使通知引擎420生成并发送通知至选择用户。根据具体实施例，通知引擎420可用以响应于在现实世界比赛中或在模拟对战中通常将对现役教练(activecoach)做出的决策具有影响的任何事件而生成通知。在此方面，系统提供通知，以便参与的模拟用户有机会响应于活跃比赛期间发生的现实世界事件做出积极的指导决策，包括替换。

评分(scoring)。名册管理系统可用以监测和记录由参与模拟对战的所有各个选手所取得的模拟得分。如图33中所示，服务界面400可包括模拟得分处理程序440，模拟得分处理程序440用以根据规则集执行评分功能。

在替换的背景中，一般来说，活跃选手将因为他在执行替换之前在任何时段期间的表现而挣得模拟得分。替补选手然后将基于他在剩余的比赛时段(或直到所述选手被另一替补替代)的表现而挣得得分。然而，对于在不同时间发生的比赛，模拟得分处理程序440可用以根据包括当某些事件发生时的精确时间在内的各种因素来调整评分。

允许模拟对战中的比赛中替换的特征—当所述选手通常不同时上场时，或者在同一现实世界比赛中—创建许多数据处理挑战，包括选手可用性条件(在上文中描述，包括所述真实比赛是否已进入最终比赛时段)、替换机会以及时间窗口(在各比赛时段之间，例如如上所述)以及模拟得分的评分。

根据上述可用性条件的时间要求要素，活跃选手通常只有当目前正在尚未进入最终比赛时段的现实世界比赛中进行比赛时才是符合条件的。然而，所述选手不一定目前正在比赛才被替换。系统可容纳冻结、中性以及交叉交换—无论比赛是同时、一个在另一个之前或者相反。并且如果同时比赛时钟并不重要—那么系统便在时段/节结束时进行交换。主要的通用规则是，用户不能针对节/时段及时换回，仅针对未来的节/时段—即用户仅能替换尚未开始用户想将他们换入的时段的选手。

替补选手只有当(a)目前正在尚未进入最终比赛时段的现实世界比赛中进行比赛或(b)计划要在尚未开始的现实世界比赛中进行比赛时才符合要求。这一条件集创建了三个可能的场景。

第一个场景在替补选手计划在尚未开始的现实世界比赛(称为比赛2(gametwo))中进行比赛时发生。用户发出替换比赛1(gameone)中的活跃选手的请求。模拟得分处理程序440同时在真实世界时间中以及相对于比赛1时钟(gameoneclock)记录请求时间。举例来说，当在比赛1中时段2期间在时钟上已过去2分钟30秒时发出请求。在此实例中的比赛1时钟可以记录为2:02:30(时段2：02分钟：30秒)。

在仅在时段结束时执行替换的名册管理系统中，活跃选手的替换直到比赛1中的时段3开始时才生效。所述活跃选手将继续获得模拟得分，直到时段2结束。对于比赛2(尚未开始)，出于评分目的，如由模拟得分处理程序440控制，替补选手直到比赛2中的时段3的首发新上场(firstnewplay)才‘开始’上场比赛并获得模拟得分。

在请求时执行替换的名册管理系统中，活跃选手的替换将在比赛1时钟经过2:02:30后随着下一新上场的开始‘立即’生效。出于得分目的，如由模拟得分处理程序440所控制，替补选手直到比赛2时钟经过2:02:30后的首发新上场才‘开始’上场比赛。在此方面，替换根据相应的比赛时钟是时间协调的，尽管当请求并执行替补时比赛2尚未立即开始。

第二个场景在替补选手目前正在比赛2中上场比赛时发生，(a)比赛2尚未进入其最终比赛时段，以及(b)比赛2比比赛1开始得晚和/或比赛2时钟上过去的时间比比赛1时钟上的少。用户发出替换比赛1中的活跃选手的请求。模拟得分处理程序440同时在真实世界时间中以及相对于比赛1时钟记录请求时间，所述请求时间可记录为2:02:30(时段2：02分钟：30秒)。在此场景中，与第一个场景中相同的得分规则将适用。

在仅在时段结束时执行替换的名册管理系统中，活跃选手的替换直到比赛1中的时段3开始时才生效。所述活跃选手将继续获得模拟得分，直到时段2结束。对于比赛2(其开始的晚并仍在进行中)，出于得分目的，如由模拟得分处理程序440控制，替补选手直到比赛2中的时段3的首发新上场才‘开始’上场比赛并获得模拟得分。在请求时执行替换的名册管理系统中，活跃选手的替换将在比赛1时钟经过2:02:30后随着下一新上场的开始‘立即’生效。出于得分目的，如由模拟得分处理程序440所控制，替补选手直到比赛2时钟经过2:02:30后的首发新上场才‘开始’上场比赛。在此方面，替换根据相应的比赛时钟是时间协调的，尽管当请求并执行替补时比赛2尚未立即开始。

第三个场景在替补选手目前正在比赛2中上场比赛时发生，(a)比赛2尚未进入其最终比赛时段，以及(b)比赛2比比赛1开始的早和/或比赛2时钟上过去的时间比比赛1时钟上的多。换句话说，比赛2首先开始和/或领先(furtheralong)且将大概更早结束。一般来说，模拟得分处理程序440可用以防止用户‘在时间上回去’以及获取来自替补选手的过去表现的得分。

用户在根据比赛1时钟的2:02:30时发出替换比赛1中的活跃选手的请求。举例来说，假定在比赛2中的时段3期间时钟上已过去4分钟50秒时执行替换。比赛2时钟可记录为3:04:50(时段3：04分钟：50秒)。

在仅在时段结束时执行替换的名册管理系统中，活跃选手的替换直到比赛1中的时段4开始时才生效。所述活跃选手将继续获得模拟得分，直到时段3结束。对于比赛2(其处在时段3的中间)，出于得分目的，如由模拟得分处理程序440控制，替补选手直到比赛2中的时段4的首发新上场才‘开始’上场比赛并获得模拟得分。

在请求时执行替换的名册管理系统中，活跃选手的替换将不会立即生效。活跃选手将继续获得模拟得分，直到当比赛1时钟到达3:04:50时发生的任何活跃比赛(activeplay)结束时。替补选手直到比赛2时钟经过3:04:50后的首发新上场才‘开始’上场比赛。在此方面，替换根据相应的比赛时钟是时间协调的。

报告(reporting)是名册管理系统的另一方面，如本文中所述。服务界面400可包括报告引擎450，报告引擎450包括灵活的且用户友好的报告界面。报告引擎450可用以当替换成功时(产生更多的得分或另一有利的结果)和/或当替换失败时向用户显示报告。报告引擎450可监测并报告在某一时间段(整个赛季、赛季的子集、一场比赛、一天、一周或周末、比赛的特定子集等，如上所述)期间发生的单个替换事件或者作为另一选择事件集的结果。可监测和报告与其他用户的比较，以示出在同一时段(同一比赛、同一时段等)期间用户的替换相对于由其他用户进行的替换的结果。

另外，报告引擎450可用以监测和报告由用户相对于某个人或子集做出的一个或多个替换事件的结果，包括例如用户的以下替换的报告：(a)相对于特定对立用户的替换，视需要包括他的替换的净效应，(b)相对于所选组或联盟中对立用户的子集，(c)相对于作为组的联盟中的每一用户的替换，和/或(d)相对于符合特定的标准集(例如地理位置、学校或工作场所附属机构、球队或粉丝团附属机构、在他们的活跃后备队清单上具有同一选手的用户、在特定时间窗口期间使用同一选手进行替换的用户)或任何其他标准集的其他用户的子集。

报告引擎450还可用以在例如数据库500等日志或数据存储中保持过去的报告的记录。在此方面，名册管理系统可提供由用户做出的众多替换事件的历史记录。系统还可包括有关其他用户的或相对于一些其他时间段或指标的对所述用户随时间进行的替换的分析。系统可向用户提供虚拟的(virtual)‘指导历史’，例如示出在某一周期间或在整个赛季期间做出的替换的数量，显示使得模拟得分改善的替换的百分率和数量，从而提供关于用户技能的指示。系统还可包括对用户的实际替换与一组原本可以请求的其他可用替换进行的比较，以及哪一替换原本会产生更多模拟得分的指示。

发展选手席。新手代表模拟体育中最大的风险之一。许多新手或者打得不好或者在其首个赛季许多时间都待在替补席上，挣得很少或未获得模拟得分，并且在名册上占一个席位。对于下一个赛季，用户必须决定是否在草案中再次选择所述新手，或是相反选择不同的选手。

目前可用的模拟体育系统要求用户像任何其他选手那样对待新手。然而，许多用户强烈期望可用不同且更现实的方式处理新手的模拟系统。

保留者(keeper)类型的模拟体育联盟允许用户将他们的模拟球队中的一名或多名选手自一个赛季保留至下一赛季。联盟规则确定可以保留的选手的数量，以及用户做出将选手保留在球队中的选择的成本或罚款。举例来说，规则可能允许选手对下一赛季保留最多六(6)名选手。

在另一方面，名册管理系统可包括对一名发展选手(developmentplayer)在替补名册上指定的坐席。根据具体实施例，发展选手坐席尤其可非常适合于保留者类型的联盟中的新手选手。在操作中，用户将在草案中选择一名新手并将所述新手分配至替补名册上的发展选手，所述新手必须在这里待整个第一赛季。在第一赛季结束时，在保留者类型的联盟中，用户将选择‘保留’所述新手并将所述新手移至活跃名册进行所述新手的第二赛季。

在一个实施例中，名册管理系统将向用户提供使用一(1)名额外保留者空挡(keeperslot)的选项，以将所述发展选手(新手)保留至他的第二赛季。举例来说，在其中规则允许用户保留最多六(6)名选手至下一赛季的联盟中，规则将允许用户也将所述发展选手(新手)作为第七名保留者进入下一赛季。在此方面，用户接受以下规则：所述发展选手在整个第一赛季期间一直留在替补名册上，以换来在所述赛季结束时作为‘一名额外的保留者(oneadditionalkeep)’使用所述发展选手的选项。

系统架构(systemarchitecture)

现在参照图33，服务界面400可以是应用程序界面(api)，通常规定和控制各种软件组件之间和之中的操作。除了访问数据库和计算机硬件外，api还可用于控制整个系统如何执行例程、建立和访问数据结构、进行服务以及向其他元件做出“api召唤”(例如为了提供数据或搜寻数据)。

所示的服务界面(api)400可包括与数据库500和馈送数据25连接的各种组件。数据库500可包括单个数据库、一组查找表、一组关系实数据库或用于存储和访问信息的任何其他结构。馈送数据25可包括许多含有各种关于体育运动的所有方面的信息的输入数据馈送。举例来说，馈送数据25可包括目前正在进行的比赛的清单、正在积极地参与每一比赛的选手的清单、选手状态(活跃、替补、受伤、移除、下场等)、比赛得分、球场位置、选手伤情报告、天气、受罚情况以及各种统计数据和表现信息中的任一者。

服务界面(api)400可以是一个或多个中央服务器机器的一部分，所述中央服务器机器与例如台式计算机、膝上型计算机、平板计算机以及手持装置等远程客户(client)装置交互。

名册管理程序(manager)410可用以处理名册数据以及接收和处理来自多个用户(多个客户)的请求。名册管理程序410可访问其他组件，包括例如馈送统计数据处理程序470，以访问和评估实时统计数据。名册管理程序410可用以处理替换请求(如下所述)并根据由名册管理系统的具体实施例施加的规则和条件执行选手替换。

通知引擎420可用以分析来自馈送数据25的球队名册数据和现实世界事件，并且基于所述分析来配置并向用户发送一个或多个通知。所述通知可包括关于所述用户的队员的信息，例如选手的表现或当前统计数据。并且，如下面更详细地描述，所述通知可包括对用户的一个或多个提示，报告关于相关选手或比赛的目前信息并建议进行替换。

用户管理程序430可用以设定和维护api设置，使得每一模拟体育供应商可管理其自己的规则集。

模拟得分处理程序440可用以基于所接收到的关于每一运动员的上场和表现的数据执行评分功能，并视需要奖励模拟得分。

报告引擎450为用户提供灵活的报告界面来查看他们的指导决策(即，选手替换)是如何影响他们的模拟对战的结果。报告界面可允许用户按替换的类型、按位置、按时间段、相对于某些对手等来筛选评论。

名册数据处理程序460可用以容纳名册管理系统的特定元件的逻辑，包括在数据库500上存储名册数据和替换过程。

馈送统计数据处理程序470可与为馈送数据25的一部分的一个或多个输入体育运动馈送服务整合在一起。处理程序470可以检索和解析来自馈送数据25的特定统计数据，在数据库500中存储相关数据。处理程序470还可用以管理相对高的数据请求频率和数量，以及用以使用所述名册管理系统维持所发生的事件的准确历史日志。

正面交锋挑战系统架构(head-to-headchallengessystemarchitecture)。参照图34至图37，将对与直接挑战或“manoemano”相关的系统架构进行讨论。图34绘示根据各实施例的直接挑战应用程序的服务界面600以及各种相关元件。

直接挑战应用程序可与例如一个或多个体育信息馈送等来自外部来源602的输入数据馈送进行通信。对于每一数据来源(内部或外部)，可以有一个事件数据处理程序604，所述事件数据处理程序604用以管理所述数据来源、竞赛者、由用户创建的对战、现实世界事件时间和结果、以及竞赛者的量化统计数据和表现。

服务界面600由用户通过各种用户界面606进行交互，用户界面606包括移动应用程序(例如在智能手机和平板计算机上)、网络应用程序、智能电视应用程序以及在游戏机(gamingconsole)上。还可提供与服务界面联网的计算机自助服务终端以允许用户与比赛系统交互。

参照图35，直接挑战系统可利用一个或多个外部数据读取器608(例如体育运动馈送a、b等)以及内容api来搜集自如体育运动馈送等外部数据服务和其他内容提供商获得的挑战数据。还可以手动将挑战数据馈送入统计数据库中。

参照图36，来自外部数据读取器608的导入挑战系统的数据可具有挑战系统所需的例如事件日期、竞赛者、量化统计数据等数据的特定格式化。可提供事件数据处理程序610翻译程序，以将来自此类外部来源的数据转化为由所述挑战系统使用的常用对战数据612格式。这可例如通过使用xml数据形式来实现。

对于每一数据来源均存在一个事件数据处理程序，所述事件数据处理程序管理数据来源并创建一系列可能和实际的对战、合并竞赛者、事件时间和量化统计数据。对战可由所述挑战系统基于系统业务逻辑自动创建并向用户建议这些对战。

参照图37，所述挑战应用程序可用以自起始点620开始，在起始点620中，用户a选择一名竞赛者(例如手动或使用挑择引擎)并选择所述竞赛者的竞争对手中的一者，由此确定一个对战。所述挑战应用程序还可被配置成允许用户a选择创建挑战622所必需的参数；例如，“[竞赛者]将在[此事件或时间段]期间在[此努力领域][胜过][竞赛者的竞争对手]([competitor]will[outperform][competitor’srival]in[thisfieldofendeavor]during[thiseventortimeperiod])”。一旦创建所述挑战，用户a可以使用所述挑战应用程序来选择一名同伴用户即用户b，且然后向用户b发送挑战。

用户b可接受或拒绝挑战624。如果接受挑战，那么随后正式创建挑战626。挑战应用程序用以监测竞赛者和竞争对手的表现，确认对战的获胜者628，处理挑战630，并且将得分发布到排行榜632。如果在挑战中涉及现金担保品，那么所述系统也可对现金担保品进行记录、收集和对账。

在另一方面，挑战应用程序可用以自动在各个竞赛者之间和之中选择和创建许多对战，且然后向用户建议这些对战供在挑战中使用。

虽然本文已经描述了若干实施例，但是所属领域的普通技术人员在受益于本发明的教示的情况下将理解和领会此技术的许多其他实施例和修改形式。因此，本发明并不限于本文中所公开或讨论的具体实施例，而是许多其他实施例和修改形式旨在被包括在随附权利要求或发明理念的范围内。此外，尽管在本文中以及在随后的权利要求或理念中偶尔使用特定用语，但是这些用语仅在一般性和描述性意义上使用，并且不应被解释为限制所描述的发明或随后的权利要求或理念。