发现Cookies信息和其它客户信息的方法及系统 相关申请
本发明与申请号为(28049/35344)的美国专利申请所揭示的发明相关。
发明的技术领域
本发明涉及cookies(网络服务器传递给浏览器的信息)信息和其它客户信息的发现。
【发明背景】
本发明被证明是一种将信息从Web站点分发到客户的有效的、流行的机理。在许多情况下，Web站点由各种组织(例如，商业机构、政府部门、教育机构和类似的机构)操作，客户一般是使用通常位于其住处的计算机来访问由Web站点提供的内容地消费者。但是，客户也可能是其它的商业机构、政府部门、教育机构和类似的机构。
Web站点的操作员有兴趣知道访问其Web站点的客户的人数和那些客户的人数统计特性。例如，这类信息的作用是：向广告商提供保证，知道其广告有足够多的客户，他们对广告商提供的产品或服务感兴趣，以确保将广告与Web站点安置在一起。这类信息还对Web站点操作员为某个特殊的目标观众创建网页(web pages)有指导性的作用。
根据本发明，cookies和/或其它客户信息能够提供有关其客户使用一个Web站点的有用的信息。cookies通常从Web站点被下载给访问它们的客户。在客户的计算机上执行任务的一个web浏览器为该客户访问的每个Web站点服务器留出少量的存储器(通常是0~4千字节)。相应地，当客户从一个Web站点接收到一个cookie时，该客户的web浏览器将该cookie存储在为那个Web站点留出的存储器中。存储器的内容和保存它的时间长度由该Web站点指定。
Web站点使用一个cookie，来将web浏览器/客户彼此区分开来。换言之，一个cookie允许一个Web站点确定：一项客户要求是从以前提出另一项要求的同一位客户那里收到的，还是从与以前提出要求的客户完全不同的一位客户那里收到的。简而言之，cookies为web浏览器提供了客户申请的独特性。这种独特性对于一个Web站点了解许多客户要求中每项客户要求的状况的能力很重要。所以，cookies使一个Web站点能够把一个客户与另一个客户区分开来，能够区分一个单独的客户使用的各段时间，以及能够了解一个客户的计算机上的内容显示的其它许多重要的方面。
Cookies被加到HTTP传递协议的头部。本质上说，当一个客户提出一个Web站点的一项要求时，该Web站点可能会在其响应于客户要求的头部发出一个存储指令。这种指令可能会如下所示：
Set-Cookie：顾客＝WILE_E_COYOTE；截止日期＝星期三
格林尼治标准时间1999年11月9日23:12:40
在上面的例子中，在客户的计算机上进行操作的浏览器将“顾客＝WILE_E_COYOTE”存储到1999年11月9日。但是，一个Web站点不需要为cookie指定任何截止日期，在这种情况下，当客户的浏览器被退出时，cookie期满。
无论何时客户后来再次对相同的Web站点提出一个要求时，在原来设置cookie之日期直至其期满时间范围内，客户的浏览器将在这种要求的头部包括以下字符串：
Cookie：顾客＝WILE_E_COYOTE
一个Web站点能够重写一个cookie，使它设置在一个客户的计算机上。而且，一个Wed站点可以在一台客户计算机上存储多个Cookies。在这种情况下，当客户提出一个要求时，客户的浏览器将把以下的一般陈述放置在要求的头部中：
Cookie：名称1＝字符串1；名称2＝字符串2；……
在设置一个cookie的过程中，一个服务器使用的一般句法如下所示：
Set-Cookie
名称＝值
[；期满＝数据值]
[；域＝域名]
[；路径＝路径名]
[；安全]
以上描述了在一个cookie中使用“期满”条目(clause)的情况。一个cookie中的“域”条目是任选的，被用来指定应该访问cookie内容的一个“域”中的一组机器。如果Web站点不为这个条目指定一个“域”名，则“域”条目默认发出Set-Cookie指令的Web站点的名称，以便只有这个Web站点可以访问对应的cookie。换言之，客户将只把一个cookie(与由设置该cookie的一个特殊的Web站点指定的“域”相匹配)发送到一个HTTP要求的头部中的那个Web站点。相应地，这个“域”条目是cookies安全的基础，因为一个Web站点不能访问另一个Web站点的cookies。
cookie中的“路径”条目是任选的，很少被使用。“路径”条目对cookie信息何时从客户被发送到Web站点作了进一步的限制。只有所指定的“域”的“路径”内的要求包含要求的HTTP头部中的cookie。
cookie中的“安全”条目也是任选的，如果设置该条目，则可确保cookie在一个“安全”的套接会话(socket session)上传递。如果没有设置cookie中的“安全”条目，则认为cookie数据可以访问符合其它“域”和“路径”匹配属性的任何文件或CGI程序。
目前，许多Web站点用cookies来跟踪访问者到他们的服务器。这种跟踪可容易地实现，例如，通过为访问一个站点的每个新客户设置一个唯一的cookie(如一个被计数的序列或一个数据/时间标记)来实现。在以前设置cookies的截止时期内，不重新标记老客户。因此，站点可以将来自一个客户的要求与来自另一个客户的要求区分开来。
但是，除了客户以前的访问信息外，Web站点一般没有关于其客户的其它信息。所以，Web站点通常没有有关访问它们的客户的人数统计信息。
本发明针对一种安排：其中，可以由第三方来发现cookies和/或其它客户信息，然后，如果需要的话，第三方能够将所发现的cookies和其它信息与人数统计信息相匹配。
发明概述
根据本发明的一个方面，一个系统包括在一个网络中互相联系的第一方、第二方和第三方。第一方是Web站点，第二方是Web站点的客户，第三方是一个中心设备。该中心设备被安排用于启动发现来自第一方和第二方中的至少一方的客户信息。
根据本发明的另一个方面，一种发现有关客户访问多个Web站点的的客户信息的方法，包括以下步骤：a)每个客户访问存储在一个中心设备的一张网页，其中，该网页包含每个Web站点的一个URL；以及b)将客户已存储的并对应于这些URL的任何客户信息从每个客户传递到对应于该网页的URL的每个Web站点或中心设备。
根据本发明的另一个方面，一个计算机可读存储介质上存储了程序编码。当一个客户的计算机操作该程序编码时，程序编码执行以下任务：a)读取由多个Web站点传递给客户的cookies；以及，b)将cookies传递到一个中心设备。
附图简述
通过结合附图详细考察本发明，将更加清楚地了解本发明的这些和其它的特征和优点。在这些附图中：
图1表示可以在其中实践本发明的一个网络；
图2表示本发明的第一个实施例；
图3表示根据本发明第一个实施例的由一个客户的计算机执行的功能；
图4表示根据本发明第一个实施例的可以由一个Web站点处的一个中心设备子服务器执行的一个程序的流程图；
图5表示根据本发明第一个实施例的由一个中心设备的一个服务器执行的功能；
图6表示本发明的第二个实施例；
图7表示根据本发明第二个实施例的由一个客户的计算机执行的功能；以及，
图8表示根据本发明第二个实施例的由中心设备的一个服务器执行的功能。
详细描述
图1中表示一个客户信息发现系统10。客户信息发现系统10包括多个Web站点12、多个客户14和由一个网络18互相联系的一个中心设备16。每个客户14拥有一台连接到网络18的对应的计算机，Web站点12被安排通过网络18为其客户14提供内容。
客户14可以包括Web站点12的所有客户或Web站点12的子集客户。在后一种情况下，子集中的每个客户12可位于一个对应的用统计方法选择的站点20。这些用统计方法选择的站点20的数量和位置，例如，可以取决于统计学取样方法，以便选择足够数量的用统计方法选择的站点20，从而提供表示有兴趣的人口部分的数据。
例如，网络18可能是互联网。我们知道，互联网通常是通过公共电话网络来被访问的。但是，网络18可以包含其它的布置(例如，局域网、电缆网络、卫星网络和用电子方法分发内容的其它网络)。
中心设备16被安排来启动发现客户信息。中心设备16可以从Web站点12和/或从客户14获得此客户信息。为了以下描述的目的，认为此客户信息包括由Web站点12存储在客户14的计算机中的cookies。但是，应该理解，客户信息可以包括附加于cookies之上或代替cookies的信息。例如，客户信息可以包括数据传递要求的日期与时间、要求类型、URL、结果编码、被传递的数据字节的数目、完成一次数据传递所需的时间、优先项目和/或其它相关信息。而且，为了本发明的目的，cookies可能意味着全部cookies信息，或者其所需的部分信息。
为了发现cookies，一个中心设备子服务器实际上可以被加到每个Web站点12的服务器库(server pool)。然后，通过在位于中心设备16的一个服务器上的一张网页中所包括的对每个Web站点12上的材料的适当参照，可以引导客户14向分布在正在被测量的Web站点12中的每个中心设备子服务器发出HTTP要求。因此，这张网页配备了对位于Web站点12的服务器上的中心设备子服务器的参照。每个这样的参照是一个完全合格的URL。以下是这种网页的一个例子：
<html>
<head><title>欢迎客户</title></head>
<body>
请等待该网页完全装载
<iframe宽度＝468 高度＝60
src＝”http：//sub-server.domainl.com/clientID＝12345”>
<iframe宽度＝468 高度＝60
src＝”http：//sub-server.domain2.com/clientID＝12345”>
<iframe宽度＝468 高度＝60
src＝“http：//sub-server.domain3.com/clientID＝12345”>
<iframe宽度＝468 高度＝60
src＝“http：//sub-server.domain4.com/clientID＝12345”>
<iframe宽度＝468 高度＝60
src＝“http：//sub-server.domain5.com/clientID＝12345”>
<iframe宽度＝468 高度＝60
src＝“http：//sub-server.domain6.com/clientID＝12345”>
</body>
</html>
注意，以上的网页包括对六个中心设备子服务器的参照，其中，六个中心设备子服务器中的每个子服务器位于六个Web站点12(被识别为域1-域6)中的一个对应的Web站点。但是，这张网页可以根据要被测量的Web站点的数目包含对中心设备子服务器的或多或少的参照。还要注意，应该为每个客户14动态地生成上面的网页，以便当客户访问这张网页时，该网页中包括独特地识别客户14中一个对应的客户的每个ID。有了这种布置，客户14的ID与cookies配对，并被包括在客户14向Web站点12提出的任何要求中。这样，中心设备子服务器可以发现由Web站点12存储在客户14的计算机上的cookies。中心设备16还可以存储有关对应于其ID的客户14的人数统计信息。
把中心设备子服务器放置在正在被测量的每个Web站点12，该系统构造的外貌如图2所示。在图2中，正在被测量的每个Web站点12作为一个对应的域被示出，每个域具有一个表示为子服务器域的中心设备子服务器22。注意，图2所示的系统构造中只表现了两个Web站点12。但是，这个系统构造应该利用客户14包括像正在由中心设备16测量的那样多的Web站点12。
根据图3、4和5中展示的流程图，利用图2所示的系统构造来发现cookies。图3所示的流程图表示由每个客户14的计算机执行的功能。图4所示的流程图表示由装载在Web站点12的服务器上的每个中心设备子服务器22执行的功能。图5所示的流程图表现由中心设备16处的服务器(即计算机)执行的功能。
如图3所示，方框30处的一个客户访问以上描述的被保存在中心设备16的网页。例如，该访问可能是定期的(如一月一次)，也可能是一次性访问。作为该访问的结果，被保存在中心设备16处的网页由中心设备16下载，在方框32处由访问客户接收。
在方框34处，该客户查寻对应于所下载的网页中包含的第一个URL的Web站点12的名称。如果cookie存在于那个客户的计算机的存储器中，则这种名称查寻允许(方框36)客户发送对应于在URL中被识别的Web站点12的cookie。如果客户将一个cookie传递给那个Web站点12，则方框36处，客户也传递包含于所下载的网页(具有该cookie)中的它的ID。然后，为包含于所下载的网页中的其它每个URL重复方框34和36的功能。
这样，如果Web站点12中的Web站点1以前已将cookie“A”存储在客户1的计算机上，并且，如果被下载到客户1的网页包含Web站点1的一个URL，那么，在方框36处，客户1将cookie“A”和该客户的ID发送给Web站点1。此外，如果Web站点12中的Web站点2以前已将cookie“B”存储在客户1的计算机上，并且，如果被下载到客户2的网页包含Web站点2的一个URL，那么，方框36处，客户1将cookie“B”和该客户的ID发送给Web站点2，如此类推。
方框30处，由客户执行的功能是一项由客户按中心设备的命令执行的手工操作。这样，方框30处，客户将具有中心设备的URL的一个HTTP要求输入该客户的计算机，并在网络16上发送HTTP要求。方框32-36处执行的功能是一个浏览器的正常操作。因此，本发明很少要求或不要求侵扰客户12。
如图4所示，方框40，每个Web站点12处的中心设备子服务器监听进来的消息。方框42，当中心设备子服务器检测到一个包含一对cookie/ID的消息时，方框44，中心设备子服务器将该cookie和ID保存在该消息中。相应地，发现了由Web站点12存储在客户12的计算机上的cookies。
如图5所示，方框50，如果中心设备16从客户14中的一个客户接收到一个访问保存在中心设备16处的网页的要求，则方框52，中心设备16将该客户独特的ID插入具有URL的那张网页并将该网页传递给提出要求的客户。方框50和52处所执行的功能大部分是一个服务器的正常操作。但是，必须结合方框52来提供编码，以便当一个客户要求上述的网页时，中心设备16的服务器在将该网页下载给客户之前把该客户的ID插入该网页。然后，中心设备16可以选择从Web站点12获得被发现的cookies和/或其它客户信息。
中心设备子服务器22位于Web站点12处的服务器上不是强制性的。例如，如图6所示，中心设备子服务器22实际上可以位于中心设备16的服务器上的合适的防火墙后面。在此布置中，中心设备子服务器22的名称被加到Web站点12的“域名系统”的项目表中。相应地，每个Web站点12的“域名系统”在中心设备子服务器22的名称(例如，子服务器域)与中心设备16处的服务器的IP地址之间建立配对(pairings)。这样，只要Web站点12的“域名系统”表格指向中心设备16处的服务器的IP地址，客户的cookie/ID对就将被发送到中心设备16。
这样，图2所示的系统构造可以被简化，因为能够为“域名系统”中的一个单独的IP地址建立多个名称。因此，可以将Web站点使用测量系统10的系统构造简化成图6所示的那样。中心设备子服务器22被存储在中心设备16的服务器上。中心设备服务器22的名称与中心设备16的服务器的IP地址之间的配对被存储在Web站点12的“域名系统”中。
图6所示的系统构造中的客户14根据图7所示的流程图来进行操作。如图7所示，方框60，一个客户访问以上描述的并保存在中心设备16处的网页。方框62，作为该访问的一个结果，保存在中心设备16的网页由中心设备16下载，并由访问客户接收。
在方框64处，客户查寻对应于所下载的网页中包含的第一个URL的Web站点12的名称。因为“域名系统”包括第一个URL中包含的中心设备子服务器的名称和中心设备18处的服务器的IP地址，“域名系统”将那个IP地址返回给客户。作为接收这个IP地址的一个结果，如果cookie存在于该客户的计算机的存储器中，则方框66，客户的浏览器将对应于在URL中被识别的Web站点12的cookie发送到中心设备18的IP地址。方框66，如果客户将一个cookie传递给中心设备18，则方框66，客户也可以传递具有该cookie的所下载的网页中包含的它的ID。然后，为所下载的网页中包含的其它每个URL重复方框34和36的的各项功能。
如图3的情况，方框60，由客户执行的功能是由该客户按中心设备的命令执行的一项手工操作。这样，方框60，客户将具有中心设备的URL的一个HTTP要求输入客户的计算机并在网络16上发送HTTP要求。方框62-66处所执行的功能是一个浏览器的正常操作。因此，本发明又很少要求或不要求侵扰客户。
中心设备16处的服务器根据图8所示的流程图来进行操作。这样，方框70，如果中心设备16从一个客户接收到对存储在中心设备16处的网页的一个要求，则方框72，中心设备16将提出要求的客户的ID插入该网页并把该网页发送给提出要求的客户。
方框74，如果中心设备16响应方框72由中心设备16发送给客户14的网页，而从客户14中的一个客户接收cookie/ID对，则方框76，中心设备16将保存cookie/ID对。
以上讨论了本发明的某些修改。熟悉本发明领域的人也可以作出其它的修改。例如，代替上述的发现客户信息的方法，可以将一个程序安装在每个客户的计算机上。当执行这个程序时，可以安排它读取存储在客户的计算机上的cookies并将这些cookies传递到中心设备16。
此外，以上通过举例已经描述了位于中心设备16的服务器上的一张特殊的网页。换句话说，可以设计其它的网页来实施本发明。例如，可以轻易提供一张HTML页，该HTML页使用JavaScript来控制图象或与人数统计特性数据集一致的框架装载。
而且，本发明不必通过利用中心设备16将ID插入网页来识别客户14。
相应地，本发明的描述只是起说明的作用，是为了教导该技术领域的技术人员实施本发明的最佳模式。细节可能会有所改变，但实质上不脱离本发明的精神，并且保留了对所附权利要求的范围内的所有修改的独家使用。