CN101755480A

CN101755480A - 使用简明消息发送、路由以及接收信息的方法和系统

Info

Publication number: CN101755480A
Application number: CN200880025382A
Authority: CN
Inventors: 斯蒂芬·格罗莫尔; 肯尼思·M·兰泽塔
Original assignee: Individual
Current assignee: Individual
Priority date: 2007-05-21
Filing date: 2008-05-21
Publication date: 2010-06-23
Anticipated expiration: 2028-05-21
Also published as: WO2008150713A2; ZA200909040B; CA2699421A1; HK1143709A1; AU2008260261B2; US9202213B2; AU2008260261A1; EP2153671A4; CA2699421C; US8457043B2; WO2008150713A3; EP2153671A2; CN101755480B; US20080291899A1; US20130262268A1

Abstract

提供了一种系统和方法，其用于通信装置和与互联网域名和服务器相关的内容提供者之间的通信。所述系统包括网络，所述网络具有用户接口、互联网连接、以及对所述内容提供者的互联网域的接口。通信装置用户输入简明消息请求，所述简明消息请求包括信道、指示符并可选地包括请求命令。所述信道和所述指示符的组合指定路由命令驻留互联网中的位置，以响应于所述简明消息请求，并生成用于输出到所述通信装置的简明消息响应。可生成简明消息文档以通过SMS实现诸如购买和支付的金融交易。CMRL也可用于通过内容提供者的互联网域来路由人对人的消息发送，用户可在此互联网域注册。

Description

使用简明消息发送、路由以及接收信息的方法和系统

相关申请

本申请要求2007年5月21日递交的第60/939,296号U.S.临时申请、以及2007年10月29日递交的第60/983,554号U.S.临时申请的优先权，上述两案通过引用在此并入。

发明领域

本申请涉及使用通过各种媒体发送的简明消息的信息传播和信息获取的方法，所述消息包括移动电话文本消息发送(messaging)。特别地，本发明使得简明消息内容对于用诸如移动电话的通信装置搜寻信息的人来说可用并且易于得到。

发明背景

在美国，移动电话在过去的十年中变得普遍。作为“文本消息发送”被广泛知晓的SMS(短消息服务)，在过去的几年中大受欢迎，成为应用最广泛的移动电话功能之一。推测估计2008年每月有800亿条SMS消息被发送。结果，设法通过SMS(和其他媒体)为移动电话用户提供有用简明信息的服务开始出现，例如天气预报，体育比分等。由于很多移动电话为小显示屏和受限的输入机制所限制，快速且简单定位简明内容的方法引起移动电话用户的兴趣，并因此引起设法进入和服务于移动市场的内容提供者的兴趣。

解决这一需求的一种方法是通过创建有用信息库并通过某种搜索引擎使有用信息可用，来为终端用户提供服务。这样的模型已被短码$INFO(44636)下的4info.net的SMS服务、短码GOOGLE(466453)下的

的SMS服务、以及其他服务所采用。例如，被发送到4info.net短码4INFO的文本消息请求“天气90210”可能返回邮政编码90210对应地区的天气预报。这个方法的主要局限是该方法需要服务提供者提供终端用户可能感兴趣的所有可能信息。但是，如果终端用户希望找到特定年代的葡萄酒(wine)的评鉴而4info.net和

都不提供葡萄酒的评鉴，用户将会失望。覆盖全人口的移动电话的广泛使用和在互联网上可得到的大量各种信息，表明这一方法可能仅是部分解决方案。

解决这一需求的第二种方法是允许内容提供者通过移动媒体提供内容。这是由例如Mobivity.com所采用的方法，Mobivity.com允许内容提供者在Mobivity.com“共享的”短码95495下保留SMS“关键词(keywords)”。例如，新闻机构可能保留关键词“news”并返回突发新闻标题作为对被发送到短码95495的文本消息请求“news”的响应。这个方法有若干局限性。第一，没有在不同共享短码中搜寻内容的方法，终端用户也没有办法用他们的移动装置搜寻短码。例如，葡萄酒的评鉴可能被提供在一个共享短码上，突发新闻标题被提供在另外的共享短码上。即便如果用户可以在第一个地方找到短码，则他们也可能被要求记住哪个是那个。其次，由于越来越多的内容成为可用，共享短码下的内容的逻辑结构变得越来越难，尤其是当不同的内容提供者开始提供相似类型的内容时。例如，如果一个新闻机构要保留关键词“cnn”，终端用户可能合理地预料“cnn”是指新闻机构

，而实际上，它可能是指某个其他新闻机构。CNN应该保留关键词“cnn”、关键词“news”、或其他某个关键词吗？再次，共享短码没有准备好允许内容的多个作者身份。共享短码服务可提供单个关键词到诸如大学的大机构，但没有提出任何机制用于允许大学里的成千上万的学生、教师和职工使他们的内容在大学关键词下可得到。最后，这个方法通常对不同媒体如SMS和声音独立对待，要求内容提供者通过完全不相关的机制为每个媒介分别地准备他们的内容。

类似的问题出现在移动支付系统的领域内，例如由OBOPAY^TM和

以及

RFID技术提供的移动支付系统。这些支付系统典型地使得支付款直接被发到移动电话运营商(“Premium Billing”)或从一个移动电话用户发到另一移动电话用户或商家的账户上。

对于这些支付系统，很多相关技术集中于通过单一标识符来识别收款人。例如，移动允许任何用户通过SMS用句式“从y获得x(get x from y)”从任何其他用户请求金钱，其中x是数目，y是电话号码或电子邮件地址。发送文本消息“从4085552388获得5(get 5 from4085552388)”到短码PAYPAL(729725)可以通过

支付系统将对5.00美元的请求发到电话号码408-555-2388。其他相关技术允许从由鉴别账户的词所指定的用户请求移动支付，或将移动支付指向由鉴别账户的词所指定的用户。例如，通过SMS的支付请求可能读为“gpayStarbucks3573.50”。本例中，收款人通过词“Starbucks357”被识别，并且要支付的数目为3.50美元。

现存支付系统如

移动或OBOPAY的一个主要问题出现在移动商务(“m-commerce”)领域。特别地，较大的机构如STARBUCKS咖啡连锁可能希望用标识符如“starbucksXXX”来识别每家店，其中XXX为店号。但是谁拥有管理“starbucks”标识符的权力呢？相关技术未提供清楚的机制来分配和管理带有

和

特许咖啡的这些标识符的所有权，或从保留的“starbucksYYY”给出与

无关的某一个，其中YYY为非保留(或尚且不存在的)

店。标识符“amazon”是指在线商家

还是指某个其他商家？标识符“buy”是指在线商家Buy.com还是指某个其他商家？这里的问题与之前描述的关于关键词“cnn”和“news”的所有权的不明确是相似的。

当现存的方法与移动商务相关联时，由于以下事实，即，这些方法没有为将一次支付与例如在一个销售点位置的一项特别事务处理相关联做好准备，现存方法的第二个问题出现。例如，特定的

的特许企业可能想使得用户文本输入对于已被输入进收银机的订单的支付。但是，在收银机上的订单和被用户所发送的支付之间没有之前连接。因此，现有方法只提出了支付钱的问题，而未对销售产品提供出更全面的解决方法。

当现有方法与移动商务相关联时，其第三个难题是需要在请求或发送支付时公开个人信息，如电话号码、电子邮件地址、或账户名。例如，为了允许业务使用

系统请求用户支付(例如，如果在收银机上注册了订单)，用户可能被要求公开他们的电话号码，以使得该业务可以发送请求给那个用户。

最后，当现存的方法与移动商务相关联时，其被典型地设计为以人对人的方式使用，并且通常不为计算机(例如收银机)提供综合的方式来为特定交易(transaction)向移动用户请求支付或接收支付。

先前的技术中一个独立但相关的难题出现在人对人通信领域中。现有的人对人移动电话通信，包括文本消息发送和声音，要求一人将他的移动电话号码透露给其他移动电话用户。尽管这在一些情况下是可接受，但是，如果用户希望允许更广泛的受众用他们的移动电话联系他们，这就变得不可接受了，因为不存在“撤销”或“不公开”已被公开(例如，在互联互联网网站上)的电话号码的方法。现存的移动电话人对人通信在管理来到的消息或呼叫的许可的措施方面是非常受限的。另外，移动电话用户可能保留若干不同的身份(如在

知

的不同账户)。先前的技术没有为将这些不同身份转至移动电话通信中做好准备。最后，移动电话通信以及特别是文本消息发送，没有为一对多和多对多消息发送提供内在机制，并且需要定制的和专有的解决方法，例如Twitter.com提供的服务。诸如TWITTER^TM的服务的难题是其不允许内容提供者提供加有该内容提供者印记的解决方法。例如，Twitter没有为允许

用户用他们的myspace.com账户向其他

用户广播消息做好准备。

现有技术中的这些难题表明了需要一种通用的、灵活的、并且标准的方法和系统，其允许拥有互联网域名的任何人向移动电话用户传播内容。

因此，对于更加多样化的方法的需求依然存在，所述方法用于通过移动电话搜寻和传播信息，并用于提供使用移动电话提供管理金融交易的途径，以解决那些不仅仅在声音通信上依赖他们的电话的、数目一直增长的移动电话用户的需求。

发明概述

根据本发明，提供了一种方法和系统，其用于使用消息发送系统例如带有SMS文本消息发送的移动电话，向拥有互联网域名的任意个人、企业实体或组织发送信息和从其接收信息。

在本发明的一方面，提供了一种系统和方法，其用于在与互联网域名和服务器相关的内容提供者和通信装置之间的通信。所述系统包括网络，所述网络具有用户接口、互联网连接、以及对所述内容提供者的服务器的接口，所述用户接口从所述通信装置接收简明信息请求并向所述通信装置发送简明消息响应。通信装置用户输入简明信息请求，该简明信息请求包括信道、指示符并可选地包括请求命令。所述信道和所述指示符的组合指定路由命令驻留在所述互联网中的位置，以响应所述简明消息请求，并生成简明消息响应以输出到所述通信装置。

在本发明的一个实施方式中，所述通信装置是具有短消息服务功能的移动电话，并且所述信道是与顶级互联网域相对应的短码。另一实施方式中，所述信道提供对所述网络的访问途径，且所述指示符包含全部互联网域名。所述简明消息文档以一种称作简明消息路由语言(CMRL)的语言写成。可生成简明消息文档，用于通过SMS实现诸如购买和支付的金融交易。CMRL也可用于通过内容提供者的互联网域来路由人对人的消息发送，用户可能在该互联网域注册。

本发明提供一种多媒体内容组织和传播系统。提供了一种机制，通过此机制，可能具有多重源的内容(multiply-authored content)的用户或实体(总称为“内容提供者”)可以通过SMS/MMS(短消息服务/多媒体消息服务)、声音、或其他媒体在与“订户”交互或列入计划表的基础上传播他们的内容。所述系统提供了直观的接口，该接口允许订户定位并访问感兴趣的内容。本发明还提供一种机制，订户可通过这种机制被记账；还提供一种机制，订户通过这种机制可以发送消息给其他订户；还提供一种机制，用于将广告合并到简明消息内容中并且追踪广告效果。

根据本发明的系统和方法通过引入新的内容组织方案以及“简明消息请求”的思想，实现了以上所指出的目标及更多。用这两个思想，本发明实现了一种系统，由此，用户可以通过从他们的移动电话寻址并将简明消息请求发送给内容提供者，而从特定的内容提供者请求得到内容。进一步地，所述系统和方法允许来自内容提供者的内容被编索引并因此利用简明消息请求来进行搜索，而未被直接寻址到特定内容提供者。

本发明的一个重要方面是内容组织。本发明的一个实施方式提供了一个简明消息发送内容的组织结构，其复制了互联网域名结构。在SMS文本消息发送的示范性实施方式中，并非是让每个内容提供者(或有互联网域名的其他实体)选择用户可通过SMS发送到SMS短码(如相关技术中典型的做法)的SMS关键词，而是以这样一种方式将关键词指配给内容提供者：所采用的短码和关键词一起唯一地识别内容提供者(“简明消息请求接收者”)的互联网域名。例如，控制域名“weather.com”的天气新闻和信息的内容提供者，在用户发送由包含词“天气”的文本消息组成的简明消息请求到短码DOTCOM(对应于标准移动电话键盘上的368266)时，可以使内容可被获取。这里，简明消息中短码DOTCOM(368266)和词“天气”的组合指定了简明消息请求的“地址”，并且唯一地识别域名weather.com。

本发明的一个重要方面是用标准化和开放式的语言去描述简明消息服务的思想。所述语言的一个实施方式，可以可选地被称为CMML即“简明消息标记语言”的简明消息路由语言(CMRL)为内容提供者提供了一种途径，使得内容提供者以一种能够不依赖于用于请求和传播简明消息内容的媒体的方式来描述他们的简明消息内容，并可以以被索引和被搜索的方式描述他们的简明消息内容。所述语言通过提供简明消息重定向的想法，允许内容有多重源。这些重定向指示系统在可能被另一内容提供者管理的另一个CMRL文档中寻找内容。CMRL和简明消息重定向形成了简明消息内容的有向图(directed graph)结构。这个有向图的属性通过基于订户简明消息请求的内容在文档图中寻找最可能的路由，使得内容由简明消息请求来定位。

所述组织结构和系统使得简明消息购买或支付请求被发送到所述系统并且按照所述内容提供者的指定被正确路由到合适的账户。这种组织结构提供了与相关技术有关的关于通过应用本发明的路由方法识别收款方(例如，一个特定的

特许企业)的难题的解决方法。特别地，本发明实行互联网域名和简明消息请求地址之间的一对一映射，并且只允许互联网域的所有者指定在简明消息请求被路由到内容提供者时所采取的行为或所返回的内容。例如，这就仅允许控制starbucks.com的

在短码DOTCOM(368266)上的关键词“starbucks”下，来分配其特许标识符，并且保证订户以短码DOTCOM(368266)将请求寻址到“starbucks”时访问域名“starbucks.com”的所有者。在本例中，

可能为特定的

特许企业分配标识符“store123”。订户于是可以通过发送假定的简明消息请求“starbucksstore1234.99”到DOTCOM(368266)来向那个特许企业付款4.99美元。

本发明的另一方面提供一种内在机制，用于允许内容提供者将支付与特定的交易相关联，而无需订户透露个人信息。因为交易是由订户通过简明消息请求启动的，所以订户无需直接向所述内容提供者泄露个人信息(例如，移动电话号码、电子邮件地址、账户名等)。所述系统提供一种机制，内容提供者通过这种机制可以在交易被订户启动、完成、和/或停止时，指定要被调用的URL(“引擎”)。例如，所述内容提供者经营的商店或饭店的收银员要用收银机记录一项购买，收银员可以随即通过SMS指示收银机接收一项支付款，并且给顾客相应的购买号码。顾客于是可以通过本发明的系统，通过寻址到内容提供者的简明消息，发送所述购买号码，以完成所述支付。这一功能，即，提供将支付与特定交易相关联的具体方式的功能，使得本发明的系统对于人对计算机(例如，销售点)的交易来说特别有用。

根据本发明，交易的所有方面都可被处理，这些方面包括：识别被请求的商品；告知购买者他们的请求中的任何不清楚的地方；告知购买者与他们选择要买的商品有关的价格、可用性以及其他信息；证实或者可能请求购买者的记账信息和/或账户信息；向购买者证实购买；记入购买者账户、信用卡、银行账户、或其他支付方式的借方；对所述购买记入所述内容提供者的贷方；记录交易的所有方面的日志，并且可能使得所述购买者、内容提供者或购买者和内容提供者两者能够使用此信息的部分或全部。

本发明的另一方面还提供一种途径，其利用此处所描述的简明消息路由系统提供一种基于移动电话的、无需参与者透露他们的移动电话号码的人对人消息发送系统。通过允许所述简明消息请求地址可选择地包括与域名相关的账户名，用户可以通过将简明消息请求发送给订户在特定的域的用户名，来使用本发明彼此相互发送消息。例如，在本发明的一个实施方式中，通过发送寻址到“subscriber2@myspace”的简明消息请求到DOTCOM(368266)，由在网络站点myspace.com的网络站点账户subscriber1标识的订户可以与由在myspace.com的网络站点账户subscriber2标识的第二订户联系。这种形式的通信避免了公布人们的移动电话号码这一不足之处，并且加强了用户对接入他/她的移动电话的呼叫或文本消息的人的控制。当订户希望接收或不希望接收消息时(即，一天中的几个时刻，一周中的几天，等)，所述系统使得订户准予、撤销、或以其他方式管理许可，该许可与他们希望从其接收消息的人有关，并且与他们希望通过什么媒体(例如，声音、SMS、电子邮件、基于网络的账户，等)接收消息有关。

本发明的相关方面是同一系统使得用户在一对一、一对多、和多对多基础上交换消息，并且允许消息发送系统集成到其他的现有消息发送系统中，所述其他的现有消息发送系统包括即时消息发送系统和电子邮件。例如，除先前所描述的一对一操作(一对一)之外，一个订户可以通过发送单个简明消息请求来联系多个“追随者”(一对多)，并且很多订户可通过发送单个简明消息请求来联系多个“追随者”(多对多)。或者，例如，在本发明的一个实施方式中，由在

网站myspace.com的网络站点账户subscriber1标识的订户可以通过发送寻址到“subscriber2@myspace”的简明消息请求到DOTCOM(368266)，而与由在

网站myspace.com的网络站点账户subscriber2标识的第二订户联系，如果myspace.com确定subscriber2当前被记录进其即时消息发送系统，所述简明消息请求可以使用由myspace.com控制的即时消息系统被传送到subscriber2。可选地，所述消息可通过电子邮件或其他由myspace.com指示的处理方式被传递到subscriber2。

附图概述

图1为简明消息请求的结构图；

图2为本发明的内容提供者接口和内容实现部分的一个实施方式的框图；

图3为订户网络接口的一个实施方式的框图；

图4为根据本发明的一个示范性CMRL文档图。

本发明的详细描述

本发明的系统接受来自订户的以“简明消息请求”形式的对于内容的请求。响应于简明消息请求所返回的内容被称为“简明消息内容”。简明消息内容可以包括文本、音频、视频、或其他多媒体内容的任意组合。在一个实施方式中，简明消息请求是具有图1所示形式的对内容的请求。在这个实施方式中，简明消息请求由至少两部分组成，“信道”和“指示符”，跟随着可选的“命令”，该命令可以由下列项中的一个或多个组成：“路径(path)”、“参量(argument)”、“指令(directive)”、以及“指令参量(directive argument)”组成。信道是消息被系统接收所使用的机制。例如，如果简明消息请求作为发送到短码DOTCOM的文本消息被接收，那么该信道可以指定DOTCOM。可选地，如果简明消息通过用户向系统进行声音呼叫而被表述，则信道可以指定所述请求为在特定电话号码上的声音请求。所述指示符是简明消息请求的一部分，其用于指定消息以其为目的地的内容提供者。在文本消息发送的一个实施方式中，指示符是文本消息体中的第一个无空格字符的字符串。

综合起来说，信道和指示符完全指定了简明消息请求的“接收者”，该“接收者”被唯一地映射到互联网域名。在一个实施方式中，对于SMS文本消息发送可用的短码包括DOTCOM(368266)、DOTEDU(368338)、DOTGOV(368468)、DOTNET(368638)、以及DOTORG(368674)。在这个实施方式中，带有主体“google”、被发送到短码DOTCOM的文本消息可能具有信道DOTCOM、指示符“google”，并且可能被映射到互联网域名“google.com”。类似地，带有主体“wikipedia james brown”、被发送到短码DOTORG的文本消息可能具有信道DOTORG、指示符“wikipedia”、以及命令“james brawn”。在这种情况下，信道和指示符可能被映射到互联网域名“wikipedia.org”。最后，被发送到短码DOTEDU的文本消息“google.com”可能具有信道DOTEDU、指示符“google.com”，并且可能被映射到互联网域名“google.com”。在这一实施方式中，如果指示符明确地指定顶级域，这个顶级域优先于与该信道相关的顶级域，因此该信道独自执行启动与系统通信的功能。因此，当信道与指示符的结合提供了将文本消息映射到内容提供者google.com的方式时，该指示符独自地提供完整的互联网域名。

另外，指示符可以可选择地指定与域有关的账户信息。在一个实施方式中，指示符的形式为“user@domain”。内容提供者于是就可以指定指示符中带有可选账户信息的简明消息请求如何逐账户处理。例如，为google.com建立的路由命令可以指定带有指示符“support@google”的所有请求都通过常规的电子邮件被传送到特定的电子邮箱地址，并指定对google域的所有其他账户请求导致SMS文本消息被传送给特定用户。指示符可以在紧随域名之后包括额外的字符串例如“+”，以表示额外功能。

简明消息请求的其余部分，即，“路径”、“参量”、“指令”、以及“指令参量”，在本文后面有详细论述。重要的是，注意到用户可能能够或不能够明确指定简明消息请求的一些部分或全部，这依赖于创建简明消息请求所用的装置。例如，使用移动电话的标准文本消息发送功能的用户，可以在文本消息的允许长度和字符集所导致的限制内，选择信道(这里指短码)并完全指定简明消息请求的所有其他部分。但是，定制的应用，例如运行在诸如

iPhone或其他移动电话上的应用所发起的简明消息请求，可以提供更丰富的用户接口，以限定信道、指示符、路径、参量、指令、和/或指令参量，或可以对一些或所有这些组成部分的可能选择进行限制。所述装置可以例如自动发送简明消息请求到DOTCOM信道的指示符“starbucks”上，用户无需去明确地选择该指示符/信道对。

一旦简明消息请求的信道和指示符被映射到互联网域名，系统就参阅与互联网域名相对应的内容，以进一步处理该请求。在一个实施方式中，采用也可称为CMML的简明消息路由语言(CMRL)来表达此内容，该语言是本发明的系统用于描述简明消息路由和内容的语言。在这个实施方式中，一个或多个CMRL文档可以驻留在web-、ftp-的预定位置上、或由互联网域名标识的其它互联网服务器上。例如，由域名“google.com”产生的信道和指示符可能导致位于google.com的URL的CMRL文档“index.cmrl”被取回和处理。作为选择，如果内容提供者预先已经通过基于web的内容提供者接口上载了CMRL，则该CMRL文档可以从另一预先指定的地点被取回，或者从本发明的系统的服务器取回。另外，CMRL可以可选择地被加密。

在示范性的实施方式中，CMRL是一种基于XML的语言，其定义简明消息内容和路由信息。CMRL的一个基本方面是层级的定义，其指定简明消息请求命令中预期的模式(pattern)。模式的层级形成用于将进入的简明消息请求路由到简明消息响应的CMRL文档结构。通过“重定向”语句，CMRL文档可以包括其他CMRL文档，有效地将文档进行结合以形成单个CMRL文档结构。当文档被有效结合时，重定向语句还允许与移动商务、广告、和所要管理的内容传播的其他方面有关的许可。CMRL的这些方面对多重源的内容是至关重要的。

CMRL语言的一个实施方式中所用的关键元素、节点、和标记(tag)被定义如下：

“anchor”——anchor元素定义简明消息内容中的简明消息链接。当该内容被发送给用户时，anchor元素被替换为包含在anchor标记内的文本，如果有，则其后还跟随一括弧里的数字，该括弧里的数字与用户应该发送以跟踪所述链接的回复相对应。当用户用这个链接文本回复时，anchor里的终止节点(terminating node)被评估。

例如：

<content>Read<anchor>our blog<rss

href＝“http://www.example.com/rss.xml”/></anchor></content>

</message>

</match>

本例将发送消息“Read our blog(1)”到用户。如果用户回复消息“1”，则他们将收到RSS标记的结果(即，RSS馈送的记事(story)列表)。

“a”——a元素是评估查询的锚标记的快捷方式。如果链接被跟踪，查询属性指定要执行的查询。例如：

<content>Get help on<a query＝“example.com

help”>Example</a>.</content>

</message>

</match>

在本例中，message会被显示为例如“Get help on Example(1)”。如果用户响应对应于链接的号码(这里为1)，那么查询“example.com help”就会被执行，就像用户已经直接输入文本一样。

“block”——block元素是允许不同的“helper”标记关联到另一个终止节点的终止节点。block必须明确地包含一个终止节点，但可能还包含另外的CMRL节点，包括零个或一个keywords标记或者零个或多个set标记。block允许终端匹配，以执行多于一个的语句。例如，下面的匹配：

<block>

</keywords>

</block>

</match>

导致在set和keywords被评估之后调用引擎。

“br”——br元素指定换行符。

“cmrl”——cmrl标记是对于CMRL文档的根标记。

“content”——content节点被包括在message内并指定消息的内容。

“engine”——engine元素用于调用外部程序(即，CGI脚本)。外部引擎程序仅有的需求是它确实打印出终止节点。engine标记必须包含属性href，其指定该引擎的URL。

“follow”——follow标记允许用户向一查询将其电话号码注册为“追随者(follower)”。注册为查询的追随者的用户会接收输入的简明消息请求的参量，该简明消息请求产生查询并紧随指示符包括“+”。例如，跟踪查询“facebook partyline”的用户在简明消息请求“facebook+partylinehello”被路由时会收到消息“hello”。类似地，跟踪查询“news@myspace”的用户在简明消息请求“news@myspace+No news today”被路由时会收到消息“No news today”。

“forward”——forward标记指定简明消息请求的参量被发送到已注册到该查询的相应的register标记上的用户。另外，如果“+”紧随简明消息查询中的指示符之后出现(见follow标记)，forward标记也将该查询的参量发送给该查询的所有追随者。

“get”——get元素用于插入会话变量的内容(其用set或input设置)。例如：

<content>Welcome<get name＝“first name”/><get

name＝“last name”/>！</content>

</message>

</match>

如果，例如，set已用于将变量first name设定为“Eduardo”并将变量last name设定为“Geminga”，那么这个消息可能作为“Welcome EduardoGeminga！”被发送给用户。

“input”——input元素提供一种从用户那里获得任意响应并且可选择地将其存储在会话变量中的途径。name属性指定要设定的变量的名字，input中的终止节点指定input的结果应被发送至哪里。例如，匹配

<match pattern＝“login”

<content>Reply with your first name.</content>

</input>

</content>

</message>

</match>

将消息“Replay with your first name”发送到用户。用户发送的下一条消息被解释为输入并且会被用于设定变量“full name”。最后，在本例中，engine会被调用，并且结果会被发送给用户。

“keyword”——keyword标记为block定义可允许的关键词。关键词被包括在keywords标记中。关键词指定简明消息参量在执行block中的终止节点前如何被纠正。这在下面有所详述。关键词必须被包括在keywords标记中。

“keywords”——keywords标记是keyword标记的容器。

“m-buy”——m-buy标记是终止节点，其允许CMRL文档指定终端用户能够购买的商品。m-buy标记和其子标记在后面的“移动商务”部分有更详细的讨论。

“m-pay”——m-pay标记是终止节点，其使得CMRL文档指定从终端用户到内容提供者能够进行的支付。这可用于允许终端用户为所提供的服务付款，或例如，允许终端用户进行销售点购买。m-pay标记和其子标记在后面的“移动商务”部分有更详细的讨论。

“match”——match标记提供了CMRL的基本结构。match标记定义了一种模式，其被匹配于进入的简明消息请求。例如，下面的CMRL片段：

<message><content>My name is John Smith.</content></message>

</match>

指定在进入的简明消息请求中的匹配“john smith”的标志(token)会产生响应“My name is John Smith”。Match标记只能包含另外的match标记或明确地只包含一个终止节点。例如，

<message><content>My name is John Smith.</content></message>

</match>

<message><content>My office is located in room

233.</content></message>

</match>

这个CMRL片段指定查询“john smith”仍会返回“My name is JohnSmith”，但查询“john smith office”现将返回响应“My office is located inroom 233”。

特定的可允许的匹配模式是“”(空匹配，对应于查询中没有另外的标志)，以及“*”(默认匹配，对应于如果没有找到其他合适的匹配时的匹配)。另外，特定的匹配模式可被指定去匹配指示符账户信息。例如，匹配

<message><content>Stefan is on vacation</content></message>

</match>

可被用于匹配指示符“stefan@domain”中的账户信息“stefan@”。类似地，匹配

</match>

可被用于匹配被指定为指示符的一部分的任意账户，也可用于从引擎取回响应或者请求实施信息。

如果松散(loose)属性不设为“0”(或如果其被省略)，CMRL语法分析程序将使用松散语法分析算法以灵活的方式匹配查询。例如，如果匹配模式是“john smith”，那么解释程序可能匹配“john”、“jsmith”、“js”，或“ion”，如果这些可以用该模式清晰地指定的话。注意，用于例如口令的匹配模式应将松散属性设为0，使得必须进行精确匹配。

“message”——message标记是用于定义被发送到用户的消息的终止元素。消息必须明确地有一个content标记，以及可选择地，可以包括零个或一个input元素以读取来自用户的响应。message元素是终止节点。

“query”——query元素是终止节点。其可被用于返回另一查询的执行结果，或可被置于anchor或input中，以用于指定用户输入的目标查询。query标记应该包括文本字符串，其为要被执行的查询。

“redirect”——redirect标记允许CMRL文档包括另一CMRL文档的内容。

“register”——register标记使电话号码(或其他的用户联系标识，如电子邮件地址)与特定的查询相关联。查询可以只有一个注册的电话号码。注册用户将接收通过位于该查询的终止节点的forward标记发送的消息。

“rss”——rss标记是用于作为格式化的消息返回RSS馈送的终止节点。可能包括的属性有href、story、以及link。href属性指定RSS馈送的http目标网址。如果story和link都未被指定，则rss以消息的形式返回RSS馈送中的记事菜单。story属性是对应于馈送中的条目标记的、以1为基准的索引。如果story被指定，那么RSS馈送中用于RSS记事的链接即被显示出来。如果link和story都被指定，那么与记事相对应的链接就通过WAP push被推至电话。依靠电话，如果支持的话，这可能导致记事在电话的web浏览器中自动打开。

“set”——set元素设定会话变量。属性name指定是哪个会话变量被设定。会话变量可以通过无值的设定被复位。

“url”——url标记用于将URL替换为简短的安全SMS版本。例如，下面的消息：

<message><content>For more information visit

<url>http://www.example.com/sdflj/lksdfd？bsdf＝123032-123322-123132&prod＝39482342&output＝2342341234</url></content></message>可生成消息如

For more information visit http://dotgo.com/2vrb3f

当终端用户访问所得到的URL时，将会被自动地重定向到url标记所指定的URL上。建议所有的URL都以这种方式编码，几个理由是：(1)有些URL包含字符(如～)，其在默认GSM 7位字母表中不出现(并因此可能被除去)；以及(2)这个标记生成了在消息之间优先地不被分裂开的URL。

图1示出了添加内容和对内容执行简明消息请求的结构和处理过程，图1提供了本发明系统100的一个示范性实施方式的方框图。如图中所示，内容提供者102通过分布式网络例如互联网104访问内容提供者接口106。内容提供者接口106提供一种机制用于内容提供者与系统连接。例如，他们可以管理其账户信息、上载CMRL文档、用CMRL前端工具创建CMRL文档、确定内容的定价、管理和支付媒体使用费、以及处理内容创建和传播的所有其他方面。当内容(直接通过CMRL上载或通过内容提供者接口CMRL前端工具)公布后，其被加到CMRL数据库。在计划表中要被传播的任何事件都被加到事件数据库118。

为处理预订内容，事件处理器120定期轮询事件数据库118以确定列入计划表中的事件是否需要被处理。如果事件需要被处理，则事件处理器120询问预订数据库(DB)116以确定该事件适用于哪个订户、查询用户配置文件数据库130，以读取用户传送偏好(例如不包括一天中的某些时间)，以及为每个用户创建消息并将其发送到格式化模块150。

通过CMRL数据库108，意味着可以被交互访问(或“点播(ondemand)”)的内容对于请求处理器114成为可用。当简明消息请求被简明消息接口122通过SMS、电子邮件、声音、或其他媒介接收时，其由请求媒介被转换为标准格式，如以下将要描述的，顶级查询模式被前置，并且消息被传递到请求处理器114。请求处理器114访问用户配置文件数据库130，以确定这个用户和其他用户的先前请求历史记录，并然后构造CMRL文档图(例如图4)。请求处理器114接着使用匹配算法将请求匹配到完整的文档图，该匹配算法考虑请求中的错误拼写、请求标志的轮流排序、用户偏好、以及使用历史记录。如果结果十分模糊，则请求处理器114发送响应到格式化模块150，其具有关于用户怎样能使请求清楚的指示。如果结果返回十分可能的结果但其他结果也有可能，则请求处理器114发送消息到格式化模块150，包含最可能的路由结果和所建议的可选项。如果没有找到匹配，相应的消息被发送到格式化模块以传递到终端用户。

如果文档图上的请求路由产生URL、RSS馈送、或其他网络服务，则请求处理器114从互联网服务器124取回由匹配所指定的内容。这个匹配可能被缓存，以改善性能(例如，对于RSS馈送)。如果匹配导致引擎(基于网络的CGI脚本)，则系统运行，调用引擎，并评估所得到的CMRL。(引擎必须返回终止节点，使得当系统调用引擎时，其得到响应中的CMRL(终止节点)，并评估该终止节点。)

格式化模块150首先传送消息到定制模块132，该模块基于包含在用户配置文件数据库130中的用户配置文件定制消息。例如，消息可能包含特殊标记<get name＝“firstname”>，定制模块132将把该标记替换为第一个用户名字。或者，它可能包含特殊标记<function name＝“dusk”>，定制模块132将把该标记替换为计算出的用户邮政编码区域内当地黄昏时刻的时间。如果消息包含广告标记，则定制模块132在定制消息之前从广告模块134取回广告。通过这种方式，就可以为终端用户定制广告。广告是基于用户配置文件信息，如地址、用户偏好、使用历史记录等，从广告数据库136选取的。

然后格式化模块150获取被定制的消息，并根据用户偏好将其格式化为适当的媒介。偏好可能包括例如在为音频传播合成消息时或所使用的声音类型或对于SMS的最大文本消息长度。如果消息指某种特殊多媒体(例如，用于音频传播的音频文件，或用于电子邮件传播的图像)，则格式化程序从媒体数据库140将其取回。当格式化程序150完成对消息的格式化时，其被传递到简明消息接口122，以传送到终端用户。

订户202也能够通过网络管理他们的账户信息(可直接通过互联网获得，或通过支持WAP、无线应用协议的移动装置获得)。图3说明了这样一个订户网络接口的例子。订户网络接口208允许用户查看和管理他们在预订数据库210中的预订，并且编辑他们的配置文件信息、编辑他们的账单信息，以及复查并有可能对被发送至存储在用户配置文件数据库212中的其账户的账单交易提出质疑。

例1：CMRL文档结构

图4提供了CMRL文档结构的例子。图4中，圆形代表CMRL文档，矩形代表匹配模式，圆角矩形代表消息，五边形代表引擎。匹配模式是匹配到简明消息请求路径的一个或多个字符的序列(可能包括标点符号或空格)。引擎是基于网络的应用程序(其可接受可选的参量)。从图4中显然可看出消息和引擎是CMRL文档结构的终止节点。

简明消息请求是根据(1)请求、(2)CMRL文档结构、(3)用户偏好、和(4)使用历史记录来被路由的。基于这些因素，请求的响应可以通知用户未找到匹配、找到精确匹配、找到可能的匹配(可能有其他可能的匹配)、或找到太多匹两。

作为一具体例子，考虑以互联网域“stonybrook.edu”为宿主的文档“index.cmrl”和其他文档，并考虑与图4中的CMRL文档结构有关的“DOTEDU”短码上的请求“stonybrook”。因为该请求通过“DOTEDU”短码接收，系统检查互联网域“stonybrook.edu”的CMRL文档“index.cmrl”。该文档包括七个条目：一个以消息“Welcome to StonyBrook”终止，四个条目链接匹配模式“astronomy”、“physics”、“ast101”、和“ast102”到文档“physics.cmrl”，以及两个条目链接匹配模式“biology”和“bio101”到文档“biology.cmrl”。因为该请求没有匹配模式相匹配，系统在“空匹配”下解析至消息“Welcome to Stony Brook”。

接下来考虑“DOTEDU”短码上的请求“stonybrook astronomy lanzettaoffice”。如先前所述的例子中，系统检查互联网域“stonybrook.edu”的CMRL文档“index.cmrl”，但在这里，系统匹配“stonybrook”文档中的匹配模式“astronomy”，其与文档“physic.cmrl”相链接。系统接下来检查文档“physics”并匹配匹配模式“lanzetta”，其与文档“lanzetta.cmrl”相链接。

系统接下来检查文档“lanzetta”并匹配匹配模式“office”，其终止于消息“Office is 456ESS”。系统返回消息“Office is 456ESS”。

接下来考虑“DOTEDU”短码上的请求“stonybrook office”。如前述的两个例子，系统检查互联网域“stonybrook.edu”的CMRL文档“index.cmrl”，但系统不能匹配“index.cmrl”文档中的任何匹配模式。因为整个CMRL结构是可用的，系统在结构中搜索对匹配模式“office”的匹配。这样的匹配只出现在文档“lanzetta.cmrl”中，其终止于消息“Officeis 456ESS”。系统再次返回消息“Office is 456ESS”。

如果匹配模式“office”在CMRL结构的“stonybrook”部分下不是唯一的，例如，如果匹配模式“office”出现在文档“yahil”和文档“lanzetta”中，会怎样呢？在这种情况下，系统求助于用户偏好和使用历史记录，以试图消除模糊并基于可能性确定最佳路径。例如，如果用户有访问匹配模式“lanzetta”的历史记录而没有访问匹配模式“yahil”的历史记录，那么系统将把较大的可能性归于匹配模式“lanzetta office”并将较低可能性归于匹配模式“yahil office”，并返回简明消息“Office为456ESS。出现在lanzetta office。回复[1]了解更多内容。(Office is 456ESS.Foundunder lanzetta office.Respond[1]for more.)”如果用户没有访问匹配模式“lanzetta”或“yahil”的历史记录，系统返回简明消息“找到两条结果。回复[1]了解lanzetta，回复[2]了解yahil。(Two results found.Respond[1]forlanzetta and[2]for yahil.)”以这种方式，系统允许用户缩短请求。

接下来考虑“DOTEDU”短码上的请求“stonybrook ast101 gradesexamp 11234”。如前述的例子中，系统沿着“stonybrook astronomy lanzettaast101”路由该请求，其链接到匹配模式“grades”、“schedule”、和“ezipsky”。系统匹配匹配模式“grades”，该匹配模式终止于引擎“grades.cgi”。系统将请求(即，“stonybrook ast101 grades exam1 1234”)和标志化的版本(tokenized version)的请求(即，“stonybrook”、“ast101”、“exam1”、和“1234”)传递到该引擎所指定的URL。该URL向系统返回响应(可能是标识号为1234的学生在考试1中得到的成绩)，并且系统返回这一响应。

接下来考虑短码“DOTEDU”上的请求“stonybrook ezipsky 11787”。如前述例子中，系统沿着“stonybrook astronomy lazetta ast101”路由请求。系统匹配该匹配模式“ezipsky”，其终止于引擎“ezipsky.cgi”。系统将请求(即，“stonybrook ezipsky11787”)和标志化版本的请求(即，“stonybrook”、“ezipsky”和“11787”)传递到该引擎。该引擎向系统返回响应(可能是有关邮政编码为11787地区的夜空的信息)，并且该系统返回这一响应。

匹配模式以一种允许有拼写错误和可能(在一种实施方式中)不按规则排列的可能性的方式，随机地被匹配到请求上。例如，图4的文档结构的匹配模式可能被匹配到错误拼写的请求“stonybook astronomy lanzettaoffice”和不按规则的请求“stonybrook astronomy office lanzetta”上，同样地，他们可能被匹配到请求“stonybrook astronomylazetta ast101”上。

下列代码提供了图4所描述的示例性文档lanzetta.cmrl的CMRL。

<cmrl>

<content>Welcome to Lanzetta.</content>

</message>

</match>

<content>Office is 456ESS.</content>

</message>

</match>

<content>Office hours are MW 2-3.</content>

</message>

</match>

</match>

</match>

<content>Class meets MWF 11-12.</content>

</message>

</match>

</match>

</cmrl>

下面的例子描述本发明的系统的一种实现。

例2：系统

本发明的一个实施方式通过World Wide Web在名“DOTGO^TM”下被公布。为使用DOTGO^TM，移动电话用户发送以一个互联网域名开头的文本消息到电话号码DOTCOM(368266)——或者视情况发送到电话号码DOTEDU(368338)、DOTGOV(368468)、DOTNET(368638)、或DOTORG(368674)中的一个。简单的三步操作是：

1.构造一个新的文本消息到电话号码368266，在大多数移动电话键盘上拼写为“D-O-T-C-O-M”。

2.键入互联网域名“cnn”作为消息的主体。

3.发送消息。几秒钟之后会出现响应。

在这种情况下，响应就是来自cnn.com的新闻标题列表。用户可以回复文本消息“1”来选择第一标题“Top Stories”。响应就是来自cnn.com的“Top Stories”里的记事列表。回复文本消息“1”选择了第一个记事，回复文本消息“2”选择了第二个记事，等等。

另一个例子是，编辑文本“nytimes”到电话号码DOTCOM(368266)，产生一个来自nytimes.com的新闻记事列表的响应。记事就可以像在前述的例子中一样被浏览。

很多服务还接受额外的输入，允许用户具体指定寻找什么信息。例如，编辑文本“wikipedia dog”到电话号码DOTORG(368674)提供了来自wikipedia.org的关于狗的信息。或者，用户可以编辑文本“weather”+当地邮政编码到电话号码DOTCOM(368266)，以获得来自weather.com的一个特定地区的最近天气预报。在另一例子中，用户可以编辑文本“ezipsky”+邮政编码+夜空中的天体(例如行星、恒星，或星座的名字)到电话号码DOTCOM(368266)，以得到来自ezipsky.com的关于怎样观看该天体的最新说明。

DOTGO^TM利用本发明以上所描述的原则：消息的第一个词指定互联网域名，电话号码指定顶级域。一般说来，DOTGO^TM复制互联网的组织结构，但是，DOTGO^TM所提供的信息通常是互联网上的可用信息的子集——移动环境中最有用且相关的子集。文本消息短，允许用户用移动电话快速发送和接收少量信息。实质上，DOTGO^TM是移动电话文本消息发送的互联网扩展。

例3：DOTGO样本文档1

下面的例子从发行人试图实施一项移动服务的角度描述DOTGO^TM系统。

对于拥有互联网域名并有权在该互联网域名下定制由DOTGO^TM返回的内容的内容提供者，其将称为“index.cmrl”的文件放置于其网络服务器的根目录下。文件index.cmrl包括描述怎样通过移动电话的文本消息发送来分发内容的命令，很像“index.html”文件包括描述怎样通过网络分发内容的命令。这些命令可以简单也可复杂，执行包括返回静态或动态内容、提供或收集信息、出售或购买产品等的操作。

包括在文件index.cmrl中的命令以之前描述过的CMRL书写。CMRL对DOTGO^TM所起的作用与HTML对互联网所起的作用相同——描述内容。区别是，CMRL被具体指定以“路由”短的查询和与移动电话文本消息发送相适应的响应。简明结构对于描述意图在移动环境中获得的内容是非常理想的，而缓慢的数据传输率常常使得在移动电话浏览器上浏览互联网成为一种失望的体验。

如果没有文件index.cmrl，DOTGO^TM就设法尽可能地在移动电话文本消息发送的限度内呈现文件index.html。例如，参照一个或多个RSS馈送的任何页都以如此的方式被呈现，使那些RSS馈送可用。其他情况下，结果可能不那么有用。但这一功能确保了DOTGO^TM总会对任何互联网域名的任何请求提供某种类型的响应。事实上，DOTGO^TM会对任何URL的任何请求响应一些内容。

DOTGO^TM优于其他实现独立移动服务的方法的地方，例如，通过获得专用的或共享的短码，是实质性的：(1)内容提供者可以立即将它的互联网域名的品牌知名度延伸到它的移动服务上。如果用户知道在网上去哪里到内容提供者，他们就会知道使用DOTGO^TM在哪里找到他们。(2)因为没有初装费，没有月费，并且没有每条消息费，内容提供者节省了钱。(3)内容提供者不需要购买或保留昂贵的硬件——移动服务在DOTGO^TM服务器上运行。(4)内容提供者可以立即利用DOTGO^TM软件结构的好处来构造新颖的移动内容。

考虑下面的CMRL文档：

<？xmlversion＝“1.0”encoding＝“UTF-8”？>

<content>Hello world！</content>

</message>

</match>

</cmrl>

逐行看文档：

第1行：<？xmlversion＝“1.0”encoding＝“UTF-8”？>

这行表明文档为XML文档，其是必然的，因为CMRL是XML的一种。任何XML文档都需要这样一个开始行，因此任何CMRL文档也是如此。

第2行：<cmrl xmlns:dotgo＝“http://dotgo.com/cmrl/1.0”>

这行表明文档为CMRL文档。任何CMRL文档都需要这样一行。

第3行：<match pattern＝“*”>

这行引入了匹配标记，匹配标记是CMRL的基本部分。一个匹配指定一种模式，查询与这种模式相比较以确定该查询如何被路由和解析。在本例中，匹配模式为“默认”匹配模式(用通配符“*”代表)并且在这文档中没有指定其他的匹配模式，因此任何出现在这文档中的查询都将满足这一匹配。

第4行：<message>

这行引入消息标记，消息标记是CMRL另一基本部分。每个终止匹配都必须包括一个(且只有一个)终止节点，其最简单的例子就是一条消息。一条消息必须包括内容(即，消息的主体)且还可以包括其他结构。

第5行：<content>Hello world！</content>

这行包括消息的主体。在这种情况下，内容是由开头<content>和结尾</content>标记所界定的简单文本字符串“Hello world！”。

第6行：</message>

这行关闭了在第4行开放的<message>标记。

第7行：</match>

这行关闭了在第3行开放的<match>标记。

第8行：</cmrl>

这行关闭了在第2行开放的<cmrl>标记。

为安装本文档，内容提供者将该文档移至其网络服务器的根目录下，即，移至包含其网络站点的根“index.html”的相同的目录下。该文档应被命名为“index.cmrl”，并且可以设置许可，以允许对该文档的恰当访问。

为使文档生效，内容提供者设置网络浏览器到http://dotgo.com./support/cmrlvalidator/并且将其域名输入到“Validate by URI”下的输入框。点击按钮“Validate”可以生成表明index.cmrl文件可用的响应。如果不是，可以检查该文档以确认其确实与上述所列的相匹配，确认文档名称为“index.cmrl”，并确认设置许可以允许对该文档的恰当访问。

最后的步骤是测试文档，这涉及以文本编辑互联网域名到电话号码DOTCOM(368266)——或者视情况以文本编辑到电话号码DOTEDU(368338)、DOTGOV(368468)、DOTNET(368638)、或DOTORG(368674)中的一个。例如，为访问互联网域“example.com”，编辑文本“example”到电话号码DOTCOM(3682266)。响应应为“Hello world！”

为实现这一结果，系统使用查询的第一个词“example”以及用来接收该查询的电话号码DOTCOM(368266)来确定该查询应被路由到example.com。然后，系统从example.com取回文件index.cmrl。最后，系统将查询的余下的部分(即，“example”后的任何东西，这种情况下为空字符串)与在文件index.cmrl中指定的匹配模式相比较，以解析查询。在这种情况下，文件index.cmrl中只有一个指定的匹配模式——默认指定模式——其解析为系统所返回的消息“Hello world！”

例4：DOTGO^TM样本文档2

下面提供了程序的另一个例子，内容提供者可通过这个程序用DOTGO^TM系统创建文档，以访问其站点上的内容：

考虑下面的CMRL文档：

<？xml version＝“1.0”encoding＝“UTF-8”？>

<content>Welcome to the DOTGO example.</content>

</message>

</match>

<content>You have selected a red circle.</content>

</message>

</match>

<content>You have selected a red square.</content>

</message>

</match>

<content>You have selected a green circle.</content>

</message>

</match>

<engine href＝“http://dotgo.com/cgi-

bin/examples/current time.cgi”/>

</match>

<rsshref＝“http://dotgo.com/support/documentation/example2/

example.rss”/>

</match>

<content>Nothing relevant

here.</content>

</message>

</match>

</cmrl>

输入后，文档被存为“index.cmrl”，被安装并生效，如在前面的例子中所描述的。

作为例子，使用互联网域“example.com”，查询“example”生成响应“Welcome to the DOTCOM example”。系统再次使用查询的第一个词“example”以及用来接收该查询的电话号码DOTCOM(368266)来确定该查询应被路由到example.com。系统再次从example.com取回文件index.cmrl，并将查询的余下的部分(还是空字符串)与在文件index.cmrl中指定的匹配模式相比较，以解析查询。在这种情况下，空字符串被匹配到“空”匹配模式(即，空字符串)，其解析为消息“Welcome to the DOTGOexample”。

查询“example red circle”生成响应“You have selected a red circle”。在这种情况下，该查询的第二个标志被匹配到匹配模式“red”，并且查询的第三个标志被匹配到匹配模式“circle”，因此匹配是清晰的。

查询“example circle”产生响应“Did you mean‘red circle’(1)or‘green circle’(2)？”在这种情况下，该查询的第二个标志被匹配到较低级别的匹配模式“circle”，但在较高级别匹配模式“red”与“green”之间是模糊的，因此该匹配是模糊的，并且系统试图解决这一模糊的问题。

该查询还说明了DOTGO^TM的“超链接(hyperlink)”功能。在对上述响应的回答中，查询“1”相当于查询“example red circle”。类似地，查询“2”相当于查询“example green circle”。在这种情况下，尽管CMRL允许指定任意超链接，但是超链接由系统自动生成。

查询“example square”产生响应“You have selected a red circle”。在这种情况下，查询的第二个标志被匹配到匹配模式“square”，由于到“square”的匹配是清晰的，所以跳过较高级别的匹配模式“red”。

查询“example green cirkel”和查询“example gc”都产生响应“Youhave selected a green circle”。在这种情况下，该查询被匹配到匹配模式“green”和“circle”。通常，系统试图使用语音和缩写词以及通过直接的比较(尽管可能关闭这一功能，需要精确匹配)获得匹配。

查询“example engine”产生一个类似于“It is 9:18 UTC on April 12，2008)(但时间和日期是当前的)的响应。在这种情况下，查询被匹配到匹配模式“engine”，该匹配模式终止于“engine”标记，该标记指运行在DOTGO^TM服务器上的cgi程序。引擎是任意基于网络的应用程序，并可以响应于任意输入来返回任意输出。这里，引擎简单地返回当前时间和日期。

查询“example rss”产生响应“DOTGO新闻和博客。回复(1)了解最近的新闻条目。回复(2)了解最近的博客条目。(DOTGO News andBlog.Reply(1)for latest news entry and(2)for latest blog entry.)”在这种情况下，查询被匹配到匹配模式“rss”，该匹配模式终止于“rss”标记，该标记指以DOTGO^TM服务器为宿主的rss馈送。

查询“example encyclopedia”产生响应“Nothing relevant here.”在这种情况下，查询不匹配任何指定的匹配模式，因此其匹配到默认匹配模式。文档不需要有默认匹配，但是，通常，一种好的想法是包括一个默认匹配，以处理用其他方法不能解析的查询。

以上描述的框架可用于写丰富的内容：例如，通过增加任意匹配，在匹配中嵌套匹配，以及用<engine>和<rss>标记返回动态内容。另外，任意超链接都可被指定，并且用户输入可以被接受。在每用户的基础上存储信息的“会话变量”可被设定和请求，并且“关键词”可被指定用于将用户输入“纠正”到标准标志列表。在下面的例子中描述并举例说明了元素。

例5：关键词

CMRL中的关键词被用于将用户输入“纠正”到在特定的匹配下在以某种方式“期望的”的标准标志列表中。关键词提供了一种处理错误拼写、缩写、以及其他在文本消息输入中常见的十分普遍的模糊的途径。

为了举例说明，引擎在互联网域名“example”和与在主要的东海岸城市Boston、New York、Philadelphia，和Washington，D.C之间的旅行相关的匹配“travel”下实施。将这些城市中的两个作为参量，引擎可能被下面的CMRL片段引用：

</match>

可能的查询可以是

example travel New York Washington，D.C.

问题是可能有准确表述相同意图的很多其他查询，包括例如

example travel new york washington，d.c.

example travel new yorke washingtun，d.c.

example travel ny wash

example travel nyc dc

也就是说，问题是查询可能包含错误拼写和缩写，错误拼写和缩写必须被处理以使引擎在实际中有用。

一种方法是处理引擎中所有可能的错误拼写和缩写，但是，更实用的途径是使用语音和缩写以及通过直接比较而得到匹配，以将用户输入“纠正”到标准标志列表。这个功能通过使用<block>标记里的<keywords>和<keyword>标记来实现。例如，关键词“Boston”、“New York”、“Philadelphia”，和“Washington，D.C.”可以通过下面的CMRL片段与以上所描述的引擎相关联：

<block>

<keyword>Boston</keyword>

<keyword>Philadelphia</keyword>

<keyword>Washington，D.C.</keyword>

</block>

</match>

通过这一构建，对于第二部分中所讨论的所有查询，引擎可能被传递了“New York”和“Washington，D.C.”。查询

example travel los angeles seattle

可能不被纠正，并且引擎可能被传递了“los”、“angeles”，和“seattle”。查询

example travel los angeles nyc

可能被部分地纠正，并且引擎可能被传递了“los”、“angeles”，和“NewYork”。

<block>标记是允许不同的“helper”标记被关联到另一个终止节点的CMRL终止节点。<block>标记应该明确包含一个终止节点(其在这种情况下是<engine>标记)并且可能包含不同的其他的标记，包括零个或一个<keywords>标记(和零个或多个在这个文档范围之外的<set>标记)。<keywords>标记可能包括零个或多个<keywords>标记，该标记列出了在特定匹配下以某种方式所“期望的”标准标志。

系统将纠正后的参量post为参数“sys_corrected_argument”。系统将已知的(因为它们被成功匹配到关键词)纠正后的标志post为参数“sys_corrected_argument_known[n]”(这里n是以零为基准的索引)，并将这种标志的数目post为参数“sys_num_corrected_argument_known”。系统将未知的(因为它们未被成功匹配到关键词)纠正了的标志post为参数“sys_corrected_argument_unknown[n]”，并且将这种标志的数目post为参数“sys num_corrected_argument_unknown”。并且系统将(已知的和未知的)纠正了的标志(一起按原始顺序)post为参数“sys_corrected_argument[n]”，并且将这种标志的数目post为参数“sys_num_corrected_argument”。

注意到关键词持续存在是很重要的。例如，以下面的CMRL片段开始：

<block>

<keyword>green</keyword>

</block>

</match>

如果这个CMRL片段要被替换为下面的CMRL片段：

</match>

只要第一个CMRL片段被访问过至少一次，在第一个CMRL片段中设定的关键词“red”、“green”，和“blue”都将持续存在。

这一功能允许关键词在CMRL文档中或在引擎中被设定。例如，上述第一个CMRL片段中所描述的关键词的另一种设定方式可以是使在那个片段中所引用的引擎返回下面的CMRL片段：

<block>

<keyword>green</keyword>

<content>Thanks for selecting one of red，green，or

blue</content>

</message>

</block>

在这种情况下，关键词“red”、“green”，和“blue”可能在引擎被第一次调用时被设定，并将保持持续存在，除非被改变或清除。关键词与CMRL文档的终止节点相关联(或相关存储)。

这样的功能是有用的，因为在某个大的CMRL文件中列出这样大数目的关键词是很繁琐的。类似地，对于引擎，每次被调用时都返回这样大数目的关键词可能是不实际的。解决办法就是使引擎只在被具体指示的时候才返回关键词，例如，对“重置(reset)”请求进行响应时。例如，下面的CMRL片段可被插入到CMRL文档中：

</match>

引擎可能返回如下的CMRL片段以响应重置请求

<block>

<keyword>Aaronsburg</keyword>

<keyword>Abbeville</keyword>

<keyword>Abbotsford</keyword>

.

<keyword>Zwolle</keyword>

<content>Keywords have been reset</content>

</message>

</block>

任何时候当引擎返回的关键词被修改时，通过以重置请求调用引擎而将关键词保持为最新的。

为清除所有关键词，可以使用空的<keywords>标记，即，不包含<keyword>标记的<keywords>标记。

例6：会话变量：

CMRL中的会话变量被用于以每个用户为基础(例如，用户偏好、使用历史记录、账户身份识别等)存储信息。会话变量类似于网络上的cookies：它们使得为个人用户定制服务变得容易。

举例说明，如果有人在互联网域名“example”和返回基于邮政编码的天气预报的匹配“weather”下实现一引擎，该引擎可能在下面的CMRL片段中被引用：

</match>

其中“weather.cgi”是基于网络的CGI程序，其返回给定邮政编码的天气预报。特定用户第一次访问这个服务时，该用户必须提供邮政编码。对于这一服务的后续查询，可通过使用会话变量将邮政编码设置为默认成为以前的值。会话变量用于以每个用户为基础存储信息——像邮政编码。假如基于网络的CGI程序“weather.cgi”包括下面的Perl程序(还有某个未指定的功能“forecast”，该功能返回给定邮政编码的天气预报)：

#！/usr/bin/perl

use CGI qw(:standard)；

use strict；

$argument＝～m/(\d\d\d\d\d)/；

my $current_zip_code＝$1；

my $argument＝param(“sys_argument”)；

my $las_zip_code＝param(“last_zip_code”)；

my $content；

if($current_zip_code){

$content＝forecast($current_zip_code)；

$last_zip_code＝$current_zip_code；

}elsif($last_zip_code){

$content＝forecast($last_zip_code)；

}else{

$content＝“Please supply a five-digit zip code--try again”；

}

print header；

print<<EOF

<block>

<content>$content</content>

</message>

</block>

EOF；

通过这一构建，邮政编码的前一个值，如果有这个值的话，就被存储在会话变量“last zip code”中。特定的用户第一次访问这个服务时，查询“example weather”产生响应“请提供五位数字邮政编码——再试一次”(“Please supply a five-digit zip code try again”)，而查询“exampleweather 90210”产生邮政编码90210的天气预报作为响应。一旦邮政编码被指定，同一用户下一次以及后续访问该服务的时候，查询“exampleweather”则产生邮政编码90210的天气预报作为响应。

使用这个命令，会话变量“last zip code”，如果该会话变量存在的话，在每次引擎被调用的时候被post给该引擎。在Perl程序的下列行中，引擎将会话变量“last zip code”的值分配到Perl变量“$last zip code”:my $last_zip_code＝param(“last_zip_code”)；

如果没有提供邮政编码，并且如果邮政编码有先前的值，那么引擎用邮政编码的先前值产生天气预报。在每次使用<block>标记中的<set>标记调用引擎时，该引擎设置会话变量“last zip code”的值。<block>标记是CMRL终止节点，其允许不同的“helper”标记与另一个终止节点相关联。<block>标记必须明确包含一个终止节点(其在这种情况下是<message>标记)并可以包含不同的其他标记，包括零个或多个<set>标记(以及超出这个文档范围的零个或一个<keywords>标记)。<set>标记应该包含属性名称，该名称为要设置的会话变量的名称(在这种情况下为“lastzip code”)，并且必须包含文本字符串，该文本字符串为要分配给会话变量的值(这种情况下为Perl变量“$last zip code”的值)。

会话变量根据用户并根据CMRL文档被存储。当特定的用户访问特定的CMRL文档时，为该用户和该CMRL文档所定义的所有会话变量都对该CMRL文档可用(并且被post给该CMRL文档所引用的引擎)。

<get>标记用于从CMRL中获得会话变量的值。在上述情况下使用下面的CMRL片段：

<content>Default zip code:<get name＝“last_zip_code”/></content>

</message>

</match>

在这一构建下，如果会话变量“last zip code”不存在，那么查询“example show default”产生响应“Default zip code:”，而如果会话变量“last zip code”存在，查询“example default”产生响应“Default zip code:90210”。

<input>标记可用于设置会话变量的值。在互联网域名“example“下使用下面的CMRL片段：

<content>Reply with your first name</content>

<content>Thanks<get name＝“first name”/></content>

</message>

</input>

</message>

</match>

在这一构建下，查询“example name”产生响应“Reply with your firstname”。回复“Sally”就产生响应“Thanks Sally”。<input>标记在<message>标记中使用。<input>标记必须明确包含一个终止节点(这种情况下其为另一个<message>标记)并且可以包含属性名称，该属性名称为要设置的会话变量的名称。如果<message>标记包含<input>标记，那么用户发送的回复与正常的回复相比被区别对待；特别地，它作为参量被直接传递到<input>标记的终止节点。如果<input>标记的终止节点是<message>标记，那么回复就没有效果(因为<message>标记不能解释参量)。但是，如果<input>标记的终止节点是<engine>标记，回复就作为参量被直接传递到引擎，且系统不进行其他处理。用这种方式，<input>标记可被用于将任意用户输入指向引擎。如果<input>标记的名称属性被指定，那么名称属性指定的会话变量的值就被设置到回复。用这种方式，<input>标记可被用于在会话变量中存储任意用户输入。

两个或多个<input>标记可被嵌套，允许多个会话变量被顺序地设置。例如，考虑下面的CMRL片段：

<content>Reply with your first name</content>

<content>Now reply with your last name</content>

<content>Thanks<get name＝“first_name”/><get

name＝”last name”/></content>

</message>

</input>

</message>

</input>

</message>

</match>

在这个命令下，查询“example name”产生响应“Reply with your firstname”。回复“Sally”则产生响应“Now reply with your last name”。回复“Jones”则产生响应“Thanks Sally Jones”。

例7：锚

CMRL中的锚用于建立与内容的链接。锚与网络上的锚相似，因为它们使得为用户创建导航内容层级的方式变得容易。

举例说明，下面的互联网域名“example”下CMRL片段被使用：

<content>Welcome to example.com<br/>

Reply # for result<br/>

<a query＝“example circle”/>Circle<br/>

<a query＝“example square”/>Square<br/>

<a query＝“example triangle”/>Triangle</content>

</message>

</match>

<content>You have selected a circle</content>

</message>

</match>

<content>You have selected a square</content>

</message>

</match>

<content>You have selected a triangle</content>

</message>

</match>

这里，查询“example circle”产生响应“你选择了一个圆形(You haveselected a circle)”，查询“example square”产生响应“你选择了一个方形(You have selected a square)”，而查询“example triangle”产生响应“你选择了一个三角形(You have selected a triangle)”。查询“example”产生响应：

对于结果，回复号码

(1)圆形(Circle)

(2)矩形(square)

(3)三角形(triangle)

紧跟有回复“1”的查询“example”(正是在下一个文本消息中)产生响应“你选择了一个圆形(You have selected a circle)”。类似地，紧跟有回复“2”的查询“example”产生响应“你选择了一个方形(You haveselected a square)”，并且紧跟有回复“3”的查询“example”产生响应“你选择了一个三角形(You have selected a triangle)”。

“空”匹配包含<message>标记，该<message>标记包含<content>标记，该<content>标记包含三个<a>标记。该<a>标记用于<content>标记中。<a>标记必须包含属性查询，并且可包含文本字符串。系统将<content>标记中的<a>标记转到链接，系统对其进行枚举、格式化、以及显示。如果<content>标记包含<a>标记，那么用户发送的回复就受到与常规相比不同的对待。特别地，如果回复与所枚举的一个链接相匹配，被相应的<a>标记所指定的查询即像接收进来的查询一样被执行。(如果用户发送的回复不与所枚举的链接相匹配，其将作为常规查询被对待。)

<a>标记是类似但更普遍的<anchor>标记的缩写版。下面的在互联网域名“example”下的CMRL片段用于举例说明：

<content>Today sunny，H 72<br/>

Reply<anchor>

<content>Today will be sunny and fair with a high of 72 deg

F</content>

</anchor> for details<br/>

<br/>

Tonight clear，L 47<br/>

Reply<anchor>

<content>Tonight will be clear and cool with a low of 47 deg

F</content>

</message>

</anchor> for details</content>

</message>

</match>

这里，查询“example weather”产生响应：

今天晴，H72(Today sunny，H72)

回复(1)了解详细内容(Reply (1) for details)

今天夜间晴，L47(Tonight clear，L47)

回复(2)了解详细内容(Reply (2) for details)

回复“1”产生响应“今天晴朗明媚，最高气温72华氏度(Today willbe sunny and fair with a high of 72 deg F)”，而回复“2”产生响应“今天夜间晴朗凉爽，最低气温47华氏度(Tonight will be clear and cool with a lowof 47 deg F)”。

像<a>标记一样，<anchor>标记用于<content>标记中，系统将<content>标记中的<anchor>标记转到链接，系统对其进行枚举、格式化、以及显示。<a>标记与<anchor>标记的不同是<a>标记可仅指查询，而<anchor>标记可指任何CMRL终止节点。具体地，<anchor>标记必须明确包含一个终止节点(这种情况下其为<message>标记)，如果回复与相应的所枚举的链接相匹配，则其被解析给终止节点。

为进一步举例说明<a>标记和<anchor>标记之间的相似性，使用下面的互联网域名“example”下的CMRL片段：

<content>He was able to<a query＝“example

elucidate”>elucidate</a>

the subject</content>

</message>

</match>

<content>elucidate-verb<br/>

to make lucid or clear；throw light upon；explain</content>

</match>

上述片段与下面的在互联网域名“example”下的CMRL片段相等同：

<content>He was able to<anchor><query>example elucidate</query>

elucidate</anchor>the subject</content>

</message>

</match>

<content>elucidate-verb<br/>

to make lucid or clear；throw light upon；explain</content>

</match>

在这两种情况中，查询“example”产生响应：

他能够解释(1)主题(He was able to elucidate (1) the subject)

回复(1)产生响应

解释-动词，使之清楚或明白；阐明；解释

(elucidate-verb to make lucid or clear；throw light upon；explain)

总之，通过建立到指定内容的链接，锚使得为用户创建导航内容层级的途径成为可能。

例8：实现DOTGO^TM引擎

DOTGO^TM引擎是基于网络的应用程序，其接收来自DOTGO^TM的输入并向DOTGO^TM返回输出。该引擎可用于创建动态移动服务，将DOTGO^TM连接到互联网、数据库、以及其他基于计算机的服务。因为该引擎是基于网络的应用程序，其可以用任何网络程序语言来编写(例如，Perl、PHP、Java、Python，等)——关于该引擎的仅有的条件是，其必须以指定的格式接收输入并且必须以指定的格式返回输出。

再次利用在互联网域“example.com”下实现的可能发生的移动服务，该移动服务通过发送以互联网域名“example”开头的文本消息到电话号码DOTCOM(368266)而被访问，对于该电话号码，CMRL文件和基于网络的应用程序以互联网域“example.com”为宿主。

考虑下面的CMRL文档：

<？xml version＝“1.0”encoding＝“UTF-8”？>

</match>

</cmrl>

以及下面的Perl程序：

#！/usr/bin/perl

use CGI qw(:standard)；

use strict；

my $color＝param(“sys_argument”)；

my @red_things＝(“Apples”，“Lips”，“Hearts”)；

my @green_things＝(“Frogs”，“Shamrocks”，“Olives”)；

my @blue_things＝(“Jeans”，“Blueberries”，“Blue jays”)；

my $thing；

if($color eq“red”){

$thing＝$red_things[int(rand($#red_things+1))]；

}elsif($color eq“green”){

$thing $green_things[int(rand($#green_things+1))]；

}elsif($color eq“blue”){

$thing＝$blue_things[int(rand($#blue_things+1))]；

}

my $content；

if($thing){

$content＝“$thing are $color”；

}else{

$content＝“Try red，green，or blue”；

}

print header；

print<<EOF

<content>$content</content>

</message>

EOF

；

查询“例举红色的事物(example something red)”(随机地)产生响应“苹果是红色的(Apples are red)”、“嘴唇是红色的(Lips are red)”，或“心是红色的(Hearts are red)”中的一个。类似地，查询“例举绿色的事物(example something green)”产生响应“青蛙是绿色的(Frogs aregreen)”、“三叶草是绿色的(Shamrocks are green)”，或“橄榄是绿色的(Olives are red)”中的一个，以及查询“例举蓝色的事物(examplesomething blue)”产生响应“牛仔裤是蓝色的(Jeans are blue)”、“蓝莓是蓝色的(Blueberries are blue)”，或“蓝色松鸟是蓝色的(Bluejays are blue)”中的一个。

这一结果可通过发送文本消息“example something red”到电话号码DOTCOM(368266)以访问服务而获得。首先，系统使用查询的第一个词“example”以及用来接收该查询的电话号码DOTCOM(368266)来确定该查询应被路由到example.com。其次，系统从example.com检索文件index.cmrl。接下来，系统将查询的其余部分(即，“example”后的所有部分，在这里为字符串“something red”)与文件index.cmrl中指定的匹配模式相比较，以解析查询。在这种情况下，文件index.cmrl中只有一个指定的匹配模式——匹配模式“something”，其被字符串“something red”的第一个标志“something”匹配，并且解析给<engine>标记。接下来，系统调用<engine>标记所引用的引擎something.cgi，将查询的其余部分(即，“something”后的所有部分，在这里其为字符串“red”)post给引擎作为参数“sys_argument”。引擎使用参数“sys_argument”的值来构造响应，引擎将该参数值分配给变量“$color”，响应被分配有变量“$content”。最后，引擎打印CMRL<message>标记中的变量“$content”的值，其产生由系统返回的消息“Apples are red”(或类似消息)。

从本例中可以得出几点：

1.请求由不同的几部分组成：一部分(在这里为电话号码DOTCOM(368266)加“example”)指定作为index.cmrl文件宿主的互联网域，一部分(这里为“something”)指定与由CMRL文档指定的匹配模式相比较的路径，还有一部分(这里为“red”)指定被传递到引擎的参量。

2.在路径和参量之间没有明确的分隔符。请求必须被系统路由(通过与某CMRL文档相比较)，以确定该请求的哪个部分是匹配以及请求的哪个部分是参量。

3.参量作为参数“sys argument”被post给引擎。其他参数也被post给引擎(如以下所述)。

4.引擎返回CMRL“终止节点”，最简单的例子是其<message>标记。

总之，DOTGO^TM引擎通过以下过程工作：系统通过将请求与某CMRL文档中指定的匹配模式相比较，从该请求中提取参量，系统将该参量(和其他参数)post给引擎，而该引擎返回CMRL终止节点。

图1中示出了请求的命名结构。请求是与DOTGO^TM进行交互的基本单元。请求由信道和查询组成。信道是通过其接收请求的物理装置的规范。为了描述的目的，信道是电话号码DOTCOM(368266)、DOTEDU(368338)、DOTGOV(368468)、DOTNET(368638)、或DOTORG(368674)中的一个。查询是用户发送的文本字符串。查询由指示符和可选的命令组成。指示符是查询的第一个词。指示符是互联网域名(具有或没有顶级域的明确规范)或URL。信道和指示符共同指定CMRL文件的位置。命令是查询的(指示符之后的)其余部分。命令由可选的路径、可选的参量、可选的指令，以及可选的指令参量组成。路径是查询的一部分，其被匹配到CMRL文件中指定的匹配模式上。路径由一个或多个匹配模式(其可包含空格)组成。参量是在匹配之后且在指令之前的部分。参量包括一个或多个关键词(其可包含空格)。指令是DOTGO^TM保留词。在CMRL的1.0版本中，DOTGO^TM保留词是“follow”、“unfollow”、“register”、“unregister”、“stop”、“subscribe”，以及“unsubscribe”。指令参量是查询的其余(指令之后的)部分。指令和指令参量由系统处理并且从不被传递到引擎。

作为具体例子，考虑指令“subscribe”。这个指令允许用户通过简明消息、通过订户网络接口、或通过内容提供者网站或经由基于互联网应用程序接口(API)访问本发明的系统的应用，请求启动查询的预订的创建。当进行预订请求后，通过请求预订证实的简明消息来联系用户。一经证实用户的请求，就产生预订。一旦订户预订查询，查询就按照时间表或指令参量指定的条件定期被执行。例如，形式为“starbucks news subscribe mwf9am eastern”的到短码DOTCOM的请求可从用户请求证实，并且基于成功的证实，可以导致查询“starbucks news”在每个星期一、星期三、和星期五的东部标准时间9点钟被执行。类似地，请求“starbucks newssubscribe daily 5:30pm”可导致同样的查询在每天的下午5:30被执行。最后，请求“starbucks news subscribe on update”可导致每当作为用户的查询的结果而返回的简明消息内容改变时，该查询被执行且响应发送给用户。指令“subscribe”的指令参量可指定不同的时间或条件规范，包括时间间隔、指定的时间和日期、随时间的变化量(例如“黄昏”)、内容条件(例如“更新”)、或用于定期规范的其它内容。

将路径与参量中分离只能够通过将请求与某CMRL文档中指定的匹配模式相比较而进行。也就是说，请求的哪部分被post给引擎依赖于请求的哪部分被匹配到CMRL文档中指定的匹配模式。

在以上(利用具有颜色的项)描述的例子中，参量通过参数“sys argument”被post给引擎。其他可被post给引擎的参数在表1中列出：

表1

引擎返回CMRL“终止节点”，<message>标记是其最简单的例子。在CMRL1.0版中，有五个CMRL终止节点：<message>标记、<engine>标记、<rss>标记、<block>标记，以及<query>标记，其中的每一个都在之前的关键元素列表中有所描述。

这里所描述的框架和前述的例子可被用于用CMRL写丰富的内容。还可包括另外的匹配，匹配可在匹配中被嵌套。动态内容可通过使用<engine>和<rss>标记被返回。

移动商务

本发明的系统还包括允许内容提供者和终端用户进行移动商务，即，“m-commerce”。交易包括“m-buy”，即，通过用户的移动电话使用CMRL购买一件商品，以及“m-pay”，即，使用CMRL和用户的移动电话进行资金转移，该交易可通过网络如图2中示出的网络使用本发明的系统来实现。

本发明的系统的结构是这样的：发送给系统的简明消息购买或支付请求，可如内容提供者所指定的被正确路由到恰当的账户上。这个组织结构提供了与现存系统如

有关的关于通过使用本发明的路由方法来识别收款人(例如，特定的特许企业)的难题的解决方法。具体地，本发明实行简明消息请求信道/指示符对和互联网域名之间的严格映射，这样就使得仅互联网域名的所有者才可管理相应的域名CMRL并且因此确定移动商务所使用的(一个或多个)账户。用这种方式，就可对终端用户保证他们的简明消息请求被路由到特定域名的所有者。

例如，

域starbucks.com的所有者，拥有对位于starbucks.com URL上的CMRL文件的完整并清晰的控制权。只有域starbucks.com的所有者可以创建和管理这个CMRL文件。在本发明的系统的一个实施方式中，starbucks.com的所有者还是在文本消息发送短码DOTCOM的指示符/信道对“starbucks”的确切所有者。在这个实施方式中，考虑到位于starbucks.com的URL的所包含的CMRL文件“index.cmrl”，带有在DOTCOM的指示符/信道对的所有简明消息请求都被路由和实现。这个实施方式在其自身范围之内和作为其自身的构成解决了相关技术的一个难题，即，如何清晰地识别交易的收款人。另外，由于

控制CMRL，该CMRL用于以在DOTCOM的指示符/关键词对“starbucks”实现请求，其可以适当地在他们的顶级CMRL文档中分配店号给特许企业，解决相关技术的其他问题，即，使关键词的所有权的分配和管理清晰。在这种模型中，用户可能通过文本消息发送简明消息请求：“starbucks 332 buy grande latte”。查询可被路由至starbucks.com的CMRL文档，该文档可能有输入“332”，重定向到

店号332的CMRL。这个CMRL文档于是通过使用m-buyCMRL标记描述可以在

332号店购买的所有商品，连同这些商品的价格、应纳税状态、以及定购选项(例如，“grande”)。用这种方式，starbucks.com的所有者(即

公司)拥有对于其如何选择来路由被寻址到在DOTCOM的指示符/信道对“starbucks”的所有请求的完全控制(通过其顶级CMRL文档)，其包括代表向适当的特许企业发出请求的能力。

本发明的另一方面提供了一种内在机制，其允许内容提供者使支付与特定的交易相关联，而无需订户公开个人信息。因为交易是由订户通过简明消息发起并发送到本发明的系统，所以订户无需泄露个人信息例如移动电话号码、电子邮件地址、账户名等给内容提供者。本发明的系统提供一种机制，通过这种机制，在交易被订户发起、完成、和/或终止时，内容提供者可以指定要调用的URL(“引擎”)。例如，如果收银员要在收银机为某人记录

咖啡的定购，收银员就可以指示收银机通过SMS接收支付，并且给顾客相应的购买号码。顾客随即可以通过本发明的系统，经由寻址到

咖啡的简明消息发送这个购买号码，以实现支付。例如，顾客可以文本编辑查询“starbucks.com 332 194F56”，其中332是店号，194F56是收银员给顾客的购买号码。

系统在被

的332号店的CMRL指示时，可以通过互联网或其他网络查询一URL，以请求与购买号码194F56相关的价格和交易信息。交易和价格可以随后被顾客证实和完成。当用户完成交易时，交易的最终细节可被发送到所述URL，该URL可允许例如收银机将支付标记为已接受。这一功能，即，提供将支付与特定交易相关联的具体方式的功能，使得本发明的系统对“人对计算机(例如，销售点、交易)尤其有用。

本发明允许两类功能用计算机语言表达：“m-buy”和“m-pay”(即“移动-购买”和“移动-支付”)。“m-buy”语言块允许内容提供者定义用户可购买的商品。内容提供者可在计算机文本文件(即CMRL文件)编写“m-buy”块，以定义要出售的商品和对于商品可用的选项。这些选项可以影响也可以不影响商品的价格，如，其是否应被征税、或其规格、颜色等。本发明利用包括硬件和软件的系统来解释这些CMRL文件(优选地通过网络)，并且使得这些商品通过一个或多个媒体利用简明消息请求成为可用。用户可发送简明消息请求(例如，通过移动电话SMS文本消息)，请求购买商品。根据本发明，交易的所有方面都可被处理，包括：识别内容提供者“m-buy”块和被请求的商品；告知购买者他们的请求中的任何不清楚的地方；告知购买者与他们选择要买的商品有关的价格、可用性以及其他信息；确认或可能从购买者请求记账信息和/或账户信息；与购买者确认购买；记入购买者账户、信用卡、银行账户、或其他支付方式的借方；对购买记入内容提供者的贷方；将该交易的所有方面记入日志并且可能使得购买者、内容提供者或这两者能够使用此信息的部分或全部。

“m-pay”语言块允许内容提供者定义更通用的简明消息支付。这可以在当内容提供者不希望像在“m-buy”块中一样确定特定商品，或事先不知道交易价格的时候来使用。例如，“m-pay”块可被用于允许移动用户对被记入收银机的发货票付款，在用户指定捐赠数目时发送捐款到慈善机关，或更普遍地，发送任意数目的钱款到内容提供者。“m-pay”块可包括URL的引用，该URL可用于查询交易价格，也用于以通知交易的成功完成或终止。例如，这个URL可用于在支付被执行后通知收银机。注意到，“m-pay”块可被内容提供者用于实现人对人方式的支付。

本发明所提供的移动商务交易在下面的例子中被说明。

例9：移动商务——购买交易

下列代码提供了用CMRL表示的m-buy(移动-购买)块的可能发生的例子，如同其在starbucks.com域可能被实施的一样。这个文件可被上载到本发明系统的服务器，并被关联到starbucks.com域，或者，其可被命名为“index.cmrl”并被置于starbucks.com互联网服务器的根网络目录。

<cmrl>

<message><content>Welcome to Starbucks.Text a store number，

“buy”，and some items to make a purchase.<br/>

Ex:“buy 332 small coff sgr lf mlk”</content></message>

</match>

<message><content>Starbucks store 332 is located at 123 Main

Street，Cambridge，MA，02139.</content></message>

</match>

<m-buy account＝“starbucks332”taxrate＝“0.085”>

</options>

</item>

</m-buy>

</buy>

</match>

</cmrl>

在本例中，内容提供者定义了一个“空匹配”模式，其响应消息：“欢迎来到Starbucks。文本编辑店号、‘购买(buy)’、和所希望购买商品的简单描述，以实现购买。例如：‘buy 332 small coff sgr 1f mlk’”。当被路由到这个文件的查询没有其他标志时，即查询“starbucks”或“starbucks.com”时，这个“空匹配”被返回。在本例中，内容提供者也定义了到模式“332”的匹配。在“332”匹配中，内容提供者定义了两个另外的匹配模式：“位置|地址”(location |address)，和“购买(buy)”。“|”操作符指定了匹配模式应匹配包含标志“location”或标志“address”的查询。例如，查询“starbucks 332 location”和“starbucks 332 address”两者可导致消息“Starbucks store 332位于123 Main Street，Cambridge，MA，02139”被发送到用户。另外，查询“starbucks address”和“starbuckslocation”也将导致相同的响应消息，这是因为系统使用允许匹配级别在可能的情况下被跳过(这里为“332”)的算法。查询“starbucks addr”，和“starbucks 332 lcn”还可导致相同的消息，因为系统所用的匹配和路由算法考虑账户部分匹配和语音匹配、缩写、标点符号消除、以及首字母简略词。

在“332”匹配模式下所列的以上代码的第二个匹配用于匹配查询模式“buy”，终止于m-buy块而不是终止于message。这个m-buy块定义了账户，在一个实施方式中，该账户是在本发明的系统中通过内容提供者网络接口创建的，该账户以支付(“starbucks332”)以及销售所用的税率(8.5％)被记入贷方。注意到以下内容是重要的，即，该账户名(“starbucks332”)完全对用户隐藏，收款人由用户通过简明消息请求来指定，该简明消息请求通过根本上由互联网域名所有者所管理的良好定义的层级被路由到收款人的m-buy块(并因此被路由到账户)。

m-buy块也可包括销售所需的其他信息，例如货运信息或各州的税的信息。列出的以上代码中的m-buy块包括销售的单个商品，“coffee”，其被定义为应被征税的(即，税率将被用到)。在本例中可得到两种“类型”的咖啡：“小的”，价格为1.99美元，大的，价格为2.99美元。类型说明了商品的互斥的限定。在本例中，查询“starbucks 332买小咖啡(starbucks332 buy small coffee)”和“starbucks 332买咖啡小(starbucks 332 buy coffeesmall)”都可导致对于小咖啡的定购。查询“starbucks 332买大小咖啡(starbucks 332 buy large small coffee)”可导致错误，因为“大”和“小”是此两种类型，因此不能对于单个商品同时出现。最后，因为“大”类型被标记为默认类型，所以查询“starbucks 332买咖啡(starbucks 332 buycoffee)”等同于“starbucks 332买大咖啡(starbucks buy large coffee)”。

所列的示例代码中的<options>标记允许将另外的选项添加到商品。在本例中，定义了三个选项：“糖”、“普通牛奶”，和“低脂牛奶”。与类型不同，选项不是互斥的，且查询中可出现多于一个的选项。

当终止于m-buy块的查询被发送到本发明的系统时，系统首先确定是否可通过在用户的数据库搜寻该用户的记账信息来给用户记账，这些信息例如为，信用卡号码、银行账户号码、或其他信用信息，通过此信息可实现用于支付的资金转拨。如果用户查询被成功匹配到在“m-buy”块中的商品，并且用户在文件上没有记账信息，用户就会被指示经由网络站点，通过SMS，通过电话，也可以通过其他媒介，提供其记账信息。如果用户在文件上确有记账信息，系统给用户发送证实消息，如“您的定购总共为2.16美元。回复[1]证实您从

332的定购：小咖啡糖低脂牛奶”。如果用户证实这一消息(例如，通过回复“1”)，系统中文件上的用户的账户就作为借方被计入该定购的费用。于是使用以m-buy标记的“account”属性标识的商家账户(本例中为“starbucks332”)中指定的传送选项，完整的订购信息连同系统分配的交易ID一起被传送到内容提供者。这可能包括电子邮件传送、互联网IP传送(例如，通过HTTP“POST”或“GET”)、或其他方式。这个传送方法和/或目的地和/或其他传送细节也可以可选择地在m-buy块本身中指定。定购完成消息被发送到用户，其包括交易ID。证实消息可为，例如，“您已经完成购买，且您的订单已被发送到332。您的交易ID是2D38484”。用户随后可在

332号店出示这个交易ID以接收其订货。注意到，以下内容也是可能的，即，m-buy块指定支付可以或必须用其他方式来进行，如通过销售点或通过互联网的方式，而不是通过把存储在本发明的系统中的用户账户信息记入借方的方式。

例10：移动商务：购买交易

下列代码提供了CMRL文档的另一个例子，其使用m-buy块为UNO

餐馆外卖出售pizza，即，饭店连锁店的临近地区。本例可通过将其上载到本发明的系统的服务器上而使用，或可以通过将其放在unos.com即Pizzeria Uno Corporation的公共网站上的文件“index.cmrl”中而使用。这一操作可通过一个或多个短码由SMS、通过一个或多个电话号码由声音、以及可能地通过一个或多个电子邮件地址由其他包括电子邮件的媒体使其马上成为可用。

<cmrl>

<message><content>Welcome to Pizzeria Uno.Text a store

number or location you′d like to pick up your order at and what you′d like to

buy.</content></message>

</match>

<m-buy account＝“unos456”taxrate＝“0.085”>

</options>

</style>

</options>

</style>

</item>

</m-buy>

</match>

</cmrl>

在本例中，查询“unos”或“unos.com”可导致空匹配欢迎消息：“欢迎来到Pizzeria Uno。文本编辑您想获得定购的店号或位置以及您想购买的东西”。第二个匹配模式匹配例如查询“unos456”。第二个匹配也表明了用于将查询匹配到响应的动态功能的使用。也就是说，如果该查询包含可被解释为位置的任何字符串，且该位置被确定为在邮政编码为11790的地区的8英里距离范围内，则在本实施方式中考虑以“&”符号被标明为功能的功能“location_near”来匹配该查询。本例中，功能“location_near”的第三个参量给出了呈现给用户的名字，以便如果有多于一个的匹配模式要匹配时来消除模糊(例如，消息“您意思是指‘56Main大街’还是‘88Pine大街’？”)。这种类型的功能允许复杂的匹配和CMRL的简单扩展。

以上所列的代码还提供了允许每个类型中不同选项块的例子。这考虑了每个类型的不同选项，或每个类型的不同选项属性，例如价格。本例中，查询“unos 456小pizza pepp”会产生对pizaa的定购，pizaa具有“小的”类型并具有选项“意大利腊香肠”(“pepperoni”)，总共13.01美元(11.99美元加税)。注意到，类型可包含另外的类型，允许多个互斥的限定(qualifier)，例如，“大的深盘子pizza”。

例11：移动商务：支付交易

下列代码提供了m-pay(移动-支付)块的例子，如在Red Cross(redcross.org)的可能具有的CMRL文档中表达的。

<cmrl>

<message><content>Welcome to the Red Cross SMS site.Text

“donate”to donate.<br/>Ex:“redcross donate 15”<br/>

Or，text“donate”and a cause to donate to a specific

charity.<br/>

Ex:“redcross donate tsunami”</content></message>

</match>

<m-pay account＝redcross”/>

</match>

<m-pay account＝“redcross”href＝“http://redcross.org/cgi-

bin/inv”/>

</match>

</cmrl>

这个例子中，空匹配返回欢迎消息“欢迎来到Red Cross SMS站点...(Welcome to the Red Cross SMS site....)”。其响应于指示符/信道对无参量的简明消息请求而被返回，例如，“redcross”返回到文本消息发送短码DOTORG，或“redcross.org”返回到任何文本消息发送短码。匹配“donate”的第二个匹配模式包含m-pay块。这个m-pay语句指示系统将以来自用户的查询中所包含的数目贷记到名为“redcross”的账户。例如，如果用户发送查询“redcross donate 15”到系统，系统可能将该查询路由到这个m-pay语句。如果用户不可被记账，如上所述，系统响应以消息，指示用户通过网络、文本消息、声音、或其他方式提供其记账信息。如果用户可被记账，系统响应以例如“回复[1]证实您在redcross.org的15美元的支付”的消息。如果用户以查询“1”响应，那么系统将15美元记入用户账户的借方，并且将15美元记入系统的名为“redcross”的贷方(可能从被记入借方的账户中扣除交易服务费)。然后用户接收包括交易ID的用于证实支付的消息，如“您已经发送支付款15美元。您的支付ID是5F3489”。如同m-buy一样，使用存储在账户“redcross”的内容细节(或者，如果在m-pay块中被直接指定，使用联系细节)，完整的交易细节也被发送到内容提供者。

所列代码中的第三个匹配模式(对于“发票”)示出了动态地从内容提供者取回支付信息的例子。在这个例子中，查询“redcross.org发票8U8348”在“发票”匹配模式下被路由到m-pay块。如果用户不可被记账，该用户就被指示提供记账信息，像以上所描述的一样。如果用户可被记账，系统用参数“8U8348”查询Red Cross URL的发票目录脚本，以给定的参数“8U8348”取回定价和其他信息。交易以与在之前描述的例子中类似的方式，使用脚本返回的价格和其他信息得以完成。此功能允许多个操作，包括允许用户在内容提供者的商店进行购买、获得发票号码、并直接从其移动设备支付此发票而不泄露其移动电话号码、账户号码、或对收银员的其它联系消息。应注意到，移动商务消息的此动态查询也可用在m-buy块中(例如，用于查询商品价格或商品使用性)。

m-buy和m-pay块两者都可默认用户的货币，但也可支持另外的货币。例如，用户可查询“redcross.org捐款12欧元”以支付12欧元到redcross账户。

例12——DOTGO^TM消息发送

目前，人对人蜂窝电话文本消息发送有多个局限：

1.一旦蜂窝电话号码被公开，其就不能被撤回和再次成为秘密。

2.已给出的蜂窝电话号码能被文本发送给任何人(或被任何人呼叫)，不仅仅是那些其被明确给予的人。

3.已给出的蜂窝电话号码能在一天中的任何时间被文本发送(或被呼叫)。

4.蜂窝电话号码代表了单一身份；并没有允许文本消息只来自于朋友、或只来自于合作者的概念。

这些限制使很多人不情愿与家庭成员、朋友或信任的商业合伙人以外的任何人分享他们的移动电话号码，并且可能尤其使人们不情愿在网络站点上公开他们的蜂窝电话号码。

根据本发明的系统提供了对前述问题的解决方法，其方式是在本系统的基本组织机构上直接建立。这个功能的特征在于DOTGO^TM系统的下面几个方面：

1.简明消息请求指示符可选择地例如以句法user@domain包括账户信息的可能性。

2.CMRL的下面三个命令：register、forward、和follow。

CMRL的这两个方面允许内容提供者快速且简单地定义账户且使得用户间可发送消息。这准许用户简单地通过发送例如“joe@example最近怎么样？”的消息到DOTCOM，经由移动电话文本消息发送来相互联系。本发明的系统的消息发送的组成包括下面的特征：

1.账户定义：域上的用户账户的详细信息完全由内容提供者在SMS站点的CMRL中指定。内容提供者可以通过增加一个到三个简单语言标记，在几秒钟内将功能用户账户增加到他们的域以用于文本消息发送。

2.隐私：用户可以仅通过到本发明的系统的简明消息请求来将他们的移动电话号码注册到账户上。该电话号码不被内容提供者分享，且用户可以在任何时间内注销该注册。

3.许可：基于用户的和基于域的白清单和黑清单都被支持。例如，facebook.com的用户可以选择阻止特定的

用户给他们发送文本消息，可以选择只允许特定的朋友或朋友群给他们发送文本消息，或者可以选择阻止来自facebook.com的所有消息。

4.一对多文本消息发送：用户可以选择“跟踪”另一个用户，接收那个用户发送的所有消息。这允许如example.com的网络站点实现他们所拥有的微型博客服务(类似于Twitter.com提供的服务，通过交换快速、频繁的消息使朋友、家庭、和合作者通信并保持联系的服务)。

5.多对多文本消息发送：用户可以选择“跟踪”“公共”查询。被消息的跟踪者发送到该查询的消息被分发到所有其他跟踪者，实质上提供了基于文本消息发送的聊天室。

6.消息路由：用户可选择将消息路由到他们的电话，或者可选择另一种传送方法，如电子邮件、即时消息账户、或内容提供者提供的另一个目的地址(例如，作为消息传送到他们的

消息发送账户)。另外，消息路由偏好可被设置成阻止或者允许消息在一天中的特定时间、一周中的特定几天、或其他规定时间内被接收。

CMRL提供的消息发送功能建立了人对人文本消息发送和互联网之间的更紧密的结合，并使得文本消息发送成为更安全和更灵活的通信形式。这一性能使得例如大学教授和高级中学老师能够使他们的学生以安全和可控的方式发送文本消息给他们，使得社交网络如

或

可以彼此发送文本消息，为每个互联网域的所有者提供与他们的用户接触和通信的新方式。

本发明的系统和方法通过包括移动电话文本消息发送的不同途径允许移动电话用户得到信息，并允许内容提供者提供信息。本发明的系统复制互联网的组织结构，使用户通过简明消息请求容易地找到所期望的信息，以及允许内容提供者传播他们使之在互联网上可用的信息的任何子集——在移动环境中最有用和相关的信息。简明消息一般来说比较短，本发明的系统使得用移动电话发送和接收小量的信息变得容易且快速。系统的文本消息发送的组织原则是，可能与消息所发送到的电话号码相结合的文本消息请求的第一个词指定了正被请求的互联网域名。

一种称为“简明消息路由语言”或“CMRL”的语言对本发明的系统所起的作用与HTML语言对万维网(world wide web)所起的作用相似——其描述内容。但是，CMRL被特定地指定为提供内容“路由”信息，使用诸如移动电话文本消息发送的途径，使得简明消息请求能够被有效且高效地路由到来自适当的内容提供者的响应。这使得描述意欲在移动环境中被访问的内容变得理想，在所述移动环境中，低的数据传输率常常使得在移动电话浏览器上浏览互联网成为令人失望的体验。本发明的组织提供了在个人或团体之间进行金融交易和通信的方法，而无需公开个人和私人信息。

本领域技术人员通过本发明的这些描述和这里所提供的例子，将会容易想到本发明的其他实施方式、应用和修改。因此，本发明的范围仅由下面的权利要求所限定，当结合之前的说明和附图来查看时，所述权利要求包括所有这样的其他实施方式和修改。

Claims

1.一种方法，其用于通信装置和与互联网域名相关联的内容提供者之间的通信，所述方法包括：

提供网络，所述网络包括用户接口以及对所述互联网域的接口，所述用户接口用于从所述通信装置接收简明消息请求并发送简明消息内容到所述通信装置；

分配至少一个信道，用于通过所述用户接口来访问所述网络；

在服务器上存储与所述内容提供者对应的路由命令组，所述路由命令组包括至少一个查询响应；

接收由所述通信装置生成的请求，其中，所述请求包括所述至少一个信道和一指示符的组合，所述组合包括所述内容提供者的完整的互联网域名，用于将所述请求映射到所述路由命令组，所述请求可选地包括请求命令；

按照所述路由命令组所指示的来路由所述请求，以生成对所述请求的响应；以及

发送简明消息内容到所述通信装置，所述简明消息内容包括对所述请求的响应。

2.如权利要求1所述的方法，其中，所述通信装置包括具有短消息服务功能的移动电话，并且所述至少一个信道包括与一顶级互联网域对应的短码。

3.如权利要求2所述的方法，其中，所述顶级互联网域从由com、gov、edu、org、biz、net、info以及pro组成的组中选出。

4.如权利要求1所述的方法，其中，所述指示符包括所述内容提供者的完整的互联网域名。

5.如权利要求1所述的方法，其中，所述请求命令包括从由路径、参量、指令、和指令参量所组成的组中选出的一个或多个命令。

6.如权利要求5所述的方法，其中，指令和指令参量包括由所述网络中的请求处理器所执行的动作。

7.如权利要求1所述的方法，其中，所述请求不包括请求命令，并且对该请求的响应包括消息。

8.如权利要求1所述的方法，其中，所述请求命令包括指定商业交易的文本字符串，并且所述网络还包括用于响应于所述查询命令而转拨资金的记账模块。

9.如权利要求1所述的方法，其中，所述查询命令包括指定商业交易的文本字符串，并且所述路由命令组包括可供购买的商品的清单。

10.如权利要求9所述的方法，其中，所述路由命令组还包括与可供购买的商品对应的选项的清单。

11.如权利要求1所述的方法，其中，所述路由命令组包括简明消息文档，所述简明消息文档包括至少一个匹配标记，该标记定义与所述查询命令相比较的模式。

12.如权利要求11所述的方法，其中，比较包括识别等效模式，所述等效模式包括拼写错误的词、部分匹配和语音匹配、缩写词、标点符号缺失、和首字母简略词中的一个或多个。

13.如权利要求1所述的方法，其中，所述指示符还包括由所述内容提供者定义并与所述互联网域名相关联的用户的账户信息。

14.如权利要求1所述的方法，其中，所述通信装置包括用于生成定制的简明消息请求的程序设计，所述程序设计自动地指定该简明消息请求的一个或多个部分。

15.如权利要求1所述的方法，其中，所述请求命令包括参量，并且所述路由命令组将所述参量转送到一个或多个其他用户。

16.如权利要求15所述的方法，其中，所述一个或多个其他用户中的每一个用户向所述内容提供者注册有唯一的联系标识符，其中，当所述简明消息请求包括对经注册的唯一的联系标识符的匹配时，所述参量被转送到所注册的用户。

17.一种系统，其用于在通信装置和与互联网域名和服务器相关联的内容提供者之间的通信，所述系统包括：

网络，所述网络包括用户接口、网络连接、和对所述内容提供者的服务器的接口，所述用户接口用于从所述通信装置接收简明消息请求并发送简明消息响应到所述通信装置；

其中，通信装置用户输入一简明消息请求到所述通信装置中，该请求包括信道、指示符并可选地包括请求命令，其中，所述信道和所述指示符的组合指定引擎在互联网上的位置，该引擎包括对所述网络的路由命令，用于对所述简明消息请求进行响应并生成供输出到所述通信装置的简明消息响应。

18.如权利要求17所述的系统，其中，所述通信装置包括具有短消息服务功能的移动电话，且所述至少一个信道包括与顶级互联网域对应的短码。

19.如权利要求18所述的系统，其中，所述顶级互联网域从由com、gov、edu、org、biz、net、info以及pro组成的组中选出。

20.如权利要求17所述的系统，其中，所述指示符包括所述内容提供者的完整的互联网域名。

21.如权利要求17所述的系统，其中，所述请求命令包括从由路径、参量、指令、和指令参量所组成的组中选出的一个或多个命令。

22.如权利要求21所述的系统，其中，指令和指令参量包括由所述网络中的请求处理器所执行的动作。

23.如权利要求17所述的系统，其中，所述请求不包括请求命令，并且对该请求的响应包括消息。

24.如权利要求17所述的系统，其中，所述请求命令包括指定商业交易的文本字符串，并且所述网络还包括用于响应于所述查询命令而转拨资金的记账模块。

25.如权利要求17所述的系统，其中，所述查询命令包括指定商业交易的文本字符串，并且所述路由命令组包括可供购买的商品的清单。

26.如权利要求25所述的系统，其中，所述路由命令组还包括与可供购买的商品对应的选项的清单。

27.如权利要求17所述的系统，其中，所述路由命令组包括简明消息文档，所述简明消息文档包括至少一个匹配标记，该标记定义与所述查询命令相比较的模式。

28.如权利要求27所述的系统，其中，比较包括识别等效模式，所述等效模式包括拼写错误的词、部分匹配和语音匹配、缩写词、标点符号缺失、和首字母简略词中的一个或多个。

29.如权利要求17所述的系统，其中，所述指示符还包括由所述内容提供者定义并与所述互联网域名相关联的用户的账户信息。

30.如权利要求17所述的系统，其中，所述通信装置包括用于生成定制的简明消息请求的程序设计，所述程序设计自动地指定该简明消息请求的一个或多个部分。

31.如权利要求17所述的系统，其中，所述请求命令包括参量，并且所述路由命令组将所述参量转送到一个或多个其他用户。

32.如权利要求31所述的系统，其中，所述一个或多个其他用户中的每一个用户向所述内容提供者注册有唯一的联系标识符，其中，当所述简明消息请求包括对经注册的唯一的联系标识符的匹配时，所述参量被转送到所注册的用户。

33.一种系统，其用于在具有短消息功能的移动通信装置和与互联网域名和服务器相关联的内容提供者之间的通信，所述系统包括：

网络，所述网络包括用户接口、网络连接、和对所述内容提供者的服务器的接口，所述用户接口用于从所述通信装置接收短消息并发送短消息到所述通信装置；

其中，通信装置用户输入简明消息请求到所述通信装置中，所述简明消息请求包括信道、指示符并可选地包括查询命令，其中所述信道和所述指示符的组合指定一文档在互联网上的位置，该文档包括对所述网络的路由命令，以对所述简明消息请求进行响应并生成到所述通信装置的输出。