CN1282102C - 用于未来的多播传送的时间窗口受约束的多播 - Google Patents

用于未来的多播传送的时间窗口受约束的多播 Download PDF

Info

Publication number
CN1282102C
CN1282102C CNB031206158A CN03120615A CN1282102C CN 1282102 C CN1282102 C CN 1282102C CN B031206158 A CNB031206158 A CN B031206158A CN 03120615 A CN03120615 A CN 03120615A CN 1282102 C CN1282102 C CN 1282102C
Authority
CN
China
Prior art keywords
client
time
trusted
server
incident
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
CNB031206158A
Other languages
English (en)
Other versions
CN1448858A (zh
Inventor
文卡塔·N·帕德曼纳翰
路易斯·菲利普·卡布莱拉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Corp
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Publication of CN1448858A publication Critical patent/CN1448858A/zh
Application granted granted Critical
Publication of CN1282102C publication Critical patent/CN1282102C/zh
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H04N21/6334—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

为提供发布的公正性，包含不计划在发布时间之前发布的信息的加密事件，可以在发布时间之前发送到客户端。于是，大量的信息可以向客户端传输，而不考虑传输的持续时间。在发布时间，可以利用多个网络路径从中心服务器或从多台服务器发送小的解密密钥，以确保每一客户端都以最小的延迟接收解密密钥的可能性最大。从而每一台客户端都可以在大致相同的时间访问信息，不管每一台客户端的带宽如何。此外，可以被信任不在合适的时间之前发布信息的受信任的边缘服务器，可以发送未加密的事件，或对加密事件进行解密并在发布时间之前或之后的确定的时间发送解密事件，以使解密或未加密的事件在与密钥到达其他客户端的大致相同的时间到达不能存储加密事件并对其进行解密的客户端。如此，每一台客户端都可以在大致相同的时间接收到信息，不管客户端的带宽或其存储信息和对其进行解密的能力如何。

Description

用于未来的多播传送的时间窗口受约束的多播
相关申请的交叉参考
本申请与同时与本申请提出的标题为“使用连接计划的时间窗口受约束的多播”美国申请系列No.(律师摘要号码213530)，该申请在此处全部加以引用。
技术领域
一般来讲，本发明涉及在网络上进行内容提供，更具体来说，涉及在给定时间帧内向多台客户端提供内容。
背景技术
在过去30年内，因特网已经从少数几台由政府和少数教育机构控制的服务器发展成巨大的由服务器和客户端组成的异种机网络。因特网上的服务器比以往任何时候都提供更多的功能，从汽车广告和销售到有关古希腊的教程。因特网的范围和影响由于至少三个相互关联的因素而稳定地发展：提高计算功率，增大带宽和增大用户数量。不幸的是，尽管一般来讲计算功率随着用户的需求而发展，用来发送大多数通信的有限的带宽有时可能被用户的数量的指数增长所掩盖。
尽管此问题可能在较小的Intranet和局域网中特别明显，但是它在因特网上变得更为严重。例如，诸如政府或法庭公告之类的重要新闻或娱乐新闻的发布，或者新音乐视频剪辑可能导致在发布的网站上每分钟有数百万次点击。由于服务提供商和Web服务器的带宽有限，这样大的需求可能会使一个站点瘫痪，通常花费几秒钟的下载可能需要花几分钟，甚至几个小时。随着用户的连接速度的提高，用户习惯了更快的下载，这种服务的延迟会显得特别严重。
解决此问题的一种方法是多播。多播是一种Internet协议，可以允许流式传输内容同时由只发送一个数据流的服务器向许多不同的用户发送。有特定的端口用于多播：服务器向此端口发送其流式数据，希望接收多播的客户端在指定的端口上“侦听”。通过使用此方法，正常的“单播”遇到的某些带宽问题可以被克服，用户可以以更及时的方式接收数据。不幸的是，如果大量的用户尝试侦听多播，甚至这种比较有效的方法可能会显得无济于事。此外，不同连接速度的用户同样地利用多播协议也是困难的。那些诸如通过拨号因特网服务提供商(ISP)与因特网建立了常见的模拟连接的用户，将在那些具有诸如电缆调制解调器或数字用户线(DSL)调制解调器之类的宽带因特网连接的用户之后稳定地接收数据。
因特网提供的某些信息还有另外的复杂性，在于，不仅许多用户尽可能快地下载内容重要；它们同时或在指定的时间量内接收到内容也同样重要。接收到信息的时间比较重要的一种情况是发布可能会影响金融市场的政府数据。在这种情况下，那些首先接收到该信息的人可以从那些尚未接收到该信息的人获益。另一个示例可以是从流行的音乐家或组合发布音乐视频剪辑。这种示例还有另外的问题，这样的发布的大小可能有许多兆字节，会使其发布变得更复杂。此外，一般来讲，最初发布政府数据或音乐视频剪辑时会有一个最初的时间。那么，问题就成为如何尽可能地接近于此发布时间向一组客户端发送一个事件，而不是在信息变得无用或陈旧之后的某个稍晚的时间。此问题从效率和公正的观点来看都是相关的。
完成此任务的一个难点是上文讨论的网络带宽问题。尽管大多数企业网络现在都通过高速主干网连接到因特网，但是仍有许多用户使用模拟调制解调器连接到因特网。如果通过诸如DSL连接之类的宽带连接连接到因特网的用户能够与通过56Kbps拨号连接进行连接的用户同时开始访问该信息，那么具有宽带连接的用户将在使用较慢的连接的用户之前很长时间接收完该信息。例如，如果要下载的事件是10MB大小，56Kbps连接大约需要24分钟才能下载完该事件，1Mbps的数字用户线连接只需80秒钟即可。
当前的内容发布方法没有提供工具用于促进尽可能公平地在给定时间帧内按需要向许多异型客户端发送一个事件。内容和服务提供商一般来讲会疏忽发布或在特定时间访问的公正性。因此，只有最快速的、最幸运的用户在较早的时间接收到内容，常常使他们不公平地占到那些较晚地接收信息的其他用户的便宜，具体情况取决于网络带宽和它们自己的连接速度。
发明内容
本发明提供一种方法、计算机可读的介质和系统，用于向具有不同带宽的客户端发布事件，通过在事件的发布时间之前发送一个加密事件，并发布一个小的、有效地传输的密钥以在事件的发布时间或在另一个时间将该事件解密，以使每台客户端在发布时间之后的大致相同的时间接收到该事件。
本发明进一步提供一种方法、计算机可读的介质和系统，用于向具有不同带宽的客户端发布事件，通过在事件的发布时间之前向连接到一个或多台客户端的受信任的服务器发送一个加密事件，发布一个密钥以在事件的发布时间或稍早一些将该事件解密，在服务器上将该事件解密，并在事件的发布时间或在另一个时间将该事件从服务器发布到连接的客户端，以使每台客户端在发布时间之后的大致相同的时间接收到该事件。
本发明还提供一种方法、计算机可读的介质和系统，用于确保内容分布的公正性，通过在事件的发布时间之前或在事件的发布时间发送一个加密事件，并发送一个小的、有效地传输的密钥以在一个时间帧的结束之前充分长的某个时间将该事件解密，在该时间帧之后该事件不再有用或者不再相关。
本发明还提供一种方法、计算机可读的介质和系统，用于通过多个单播或多播副本发送小的、有效地传输的密钥。这样的副本可以由单台受信任的服务器、专用于发送密钥的专门服务器或由多台受信任的服务器同时发送。通过经过诸如从不同的服务器之类的多个网络路径发送密钥，在适当的时间密钥的至少一个副本将被每一台客户端接收到的可能性大大地增大。
本发明还通过允许感兴趣的客户端在大致相同的时间接收在给定发布时间发布的事件，具有提供发布的公正性的机制，尽管客户端的连接带宽不同。连接带宽的差异可能是由于许多因素造成的，包括客户端连接到服务器的速度，服务器之间的连接的拥塞等等。至少一台始发服务器包含要发布的数据。始发服务器可以连接到许多受信任的边缘服务器，边缘服务器又进一步向非受信任的服务器和连接到受信任的边缘服务器的客户端提供内容。或者，始发服务器可以直接连接到非受信任的服务器或客户端。受信任的边缘服务器是可以被信任不在选择的发布时间之前发布信息的服务器。因此，受信任的边缘服务器位于包括受信任的服务器、至少一台始发服务器和它们之间的连接的传输网络的“边缘”。
在数据将被发布到客户端之前，加密数据可以从一台或多台始发服务器发布到可以本地存储数据并对其进行解密的客户端。随后，在发布时间，或发布之后，可以向客户端发送一个小的、有效地传输的密钥，该密钥可以对加密数据进行解密。由于密钥一般来讲充分小，每一台客户端或服务器都应该在很小的时间范围内接收到密钥，从而可确保每一台客户端都在大致相同的时间访问到该数据。
加密数据还可以在服务器上解密，然后以未加密的形式发送到客户端。如果执行解密的服务器是一台受信任的边缘服务器，那么加密数据和密钥可以在发布时间之前发送。受信任的边缘服务器可以对数据进行解密并在发布时间或在发布时间之前将数据发送到客户端以使客户端在发布时间接收到数据。或者，如果服务器不是一台受信任的边缘服务器，那么，数据仍可以在发布时间之前发送，但密钥可以在发布时间发送，可以尽可能快地或在协调时间将数据解密并发送到客户端。
本发明还设想：加密数据可以在发布时间或之后发送到客户端，但密钥不传输，直到这样的时间：将保证每一台客户端都在大致相同的时间接收到该密钥或有尽可能多的客户端在数据将要被传播的一个时间窗过期之前接收到该密钥。如果加密数据可以这样发送以使在时间窗过期之前传输到所有客户端，那么密钥的传输可以被延迟，直到每一台客户端都已经接收到加密数据。或者，如果加密数据不能在时间窗过期之前传输到每一台客户端，那么密钥可以在向每一台客户端传输完加密数据之前某个时间发送。同样，如果发布要求信息快速地传播比公平地传播更重要，那么密钥也可以在每一台客户端都已经接收到加密数据之前的较早的时间发送。
本发明进一步设想：使用多播协议最大限度地降低始发服务器或受信任的边缘服务器的传输负担。通过使用多播协议，服务器只需要发送少数几个副本，然后由路由器向其他服务器或客户端复制和重新传输。多播协议的特别合适的用途可以是传输密钥。由于密钥可以是非常小的数据，通过多播密钥的冗余副本，而不是等待来自客户端的重新传输请求，效率可以大大地提高。通过使用大量的冗余以避免重新传输请求，密钥还可以是具有纠错功能的多播。此外，可以由多台服务器传输密钥。可能的密钥服务器包括始发服务器、专门的中心密钥服务器、受信任的边缘服务器，或它们的任何组合。
本发明还进一步设想估计数据传输到客户端所达到的速度。可以监视或计算出始发服务器和受信任的边缘服务器，或受信任的边缘服务器和客户端，或沿着整个路径的连接的延迟。基于连接延迟的经验或理论的估算，可以编撰一个每一台客户端的传递时间的数据库。该传递时间可以被服务器用来确定多长时间之后它需要开始传输加密数据、解密数据或密钥。例如，受信任的边缘服务器可以在将事件将要被发布的时间减去所有客户端的最小传输时间所计算出的时间启动向没有能力本地存储数据或对数据进行解密的所有客户端传输解密数据。或者，受信任的边缘服务器可以在将事件将要被发布的时间只减去到每一台客户端的传输时间所计算出的时间启动向该特定客户端的事件传输，如此还要考虑单个连接的延迟。如果服务器可以执行此后一种操作，那么每一台感兴趣的客户端都在非常接近于事件将要被发布的时间接收到该事件，尽管前一操作产生可变性更大的到达时间。为进一步提高公正性和效率，客户端可以首先在服务器之间重新分布，以减少某些延迟源的影响，并且，在某些情况下，将具有类似的连接速度的客户端放在相同的服务器上(如此使错开传递更有效)。这可以使许多位于不同地点和连接的客户端根据它们的特定客户端-服务器传输时间几乎可以同时获得一个事件。
从下面参考附图对某些优选实施例的详细描述中，本发明的其他功能和优点将变得更加清楚。
附图说明
虽然所附的权利要求阐明了具有特殊性的本发明的功能，但是从下面结合附图进行的详细说明中很好地理解本发明，以及其目标和优点：
图1是一般性地显示了本发明驻留的示范计算机服务器的方框图；
图2是一般性地显示了本发明可以在其中应用的示范网络环境的方框图；
图3是一般性地显示了提供本发明设想的事件的方法的时间图表；
图4是一般性地显示了提供本发明设想的事件的方法的另一个时间图表；
图5是一般性地显示了提供本发明设想的事件的方法的另一个时间图表；
图6是一般性地显示了提供本发明设想的事件的方法的另一个时间图表；以及
图7是一般性地显示了提供本发明设想的事件的方法的另一个时间图表。
具体实施方式
本发明提供一种方法、计算机可读的介质和系统，用于以这样的方式向一台客户端集合发布事件：以使客户端尽可能同时接收到该事件，并且在一个时间帧的结束之前有尽可能多的客户端接收到该事件，在该时间帧之后该事件不再有用或者其中包含的信息失效。具体来说，本发明设想在事件将要被发布之前发送加密事件。加密事件可以存储在客户端上或者存储在服务器上。在事件将要被发布时，可以将解密密钥发送到每一台客户端或服务器。由于密钥都可能比较小，其传输时间相对来说比较短，并且每一台客户端都将接收到该密钥，如此对数据进行解密的能力大致也是同时的。如果客户端没有能力存储加密事件，或没有能力对其进行解密，则它可以存储在服务器上并在服务器上进行解密，然后发送到客户端。如果受信任的边缘服务器为客户端对事件进行解密，则它可以在发布时间之前发送密钥并可以在发布时间之前开始向客户端发送解密事件，并考虑客户端和受信任的边缘服务器之间的连接中的计算出的或测量的延迟。或者，如果为客户端对事件进行解密的服务器不是受信任的边缘服务器，则它可以在发布时间或之后接收密钥，一旦它完成了对事件的解密操作，便可以向客户端发送解密事件。如果加密事件不能充分早地发送以使每一台客户端都在发布时间之前接收完加密事件，那么密钥的传输可以被延迟，以允许客户端接收完加密事件。密钥可以在结束时间减密钥的传输时间所得出的时间发送。可以使用多播协议，以最大限度地减少独立的会话的数量。由于密钥相对比较小，可使用有效的冗余以确保甚至通过多播来相应地传递密钥。
请看图形，其中，类似的引用号码是指类似的元素，在下文中将在服务器计算环境的上下文中对本发明进行描述。虽然为了实施本发明不作要求，但是本发明是作为服务器或客户端计算设备执行的诸如程序模块之类的计算机可执行的指令实现的。一般来讲，程序模块包括例程、程序、对象、组件和执行特定任务或实现特定抽象数据类型的数据结构等等。
本发明还可以在服务器之外的计算机系统配置中实现。例如，本发明可以在路由器、多处理器系统、个人计算机、消费类电子产品、小型机、大型机等等中实现。本发明还可以在任务由通过通信网络链接在一起的远程处理设备执行的分布式计算环境中应用。在分布式计算环境中，程序模块可以位于本地和远程内存存储设备中。
虽然本发明可以如上文所建议的那样集成到许多类型的计算环境中，但是下面对本发明的详细描述是在传统的服务器20的形式的示范通用计算设备的上下文中进行的。
在对本发明进行详细描述之前，将结合图1描述可以在其中应用本发明的计算环境。服务器20包括一个处理单元21、系统内存22、连结包括系统内存的各种系统组件与处理单元的系统总线23。系统总线23可以是任何类型的总线结构，包括内存总线或内存控制器、外围总线，以及使用任何种类的总线体系结构的本地总线。系统内存包括只读存储器(ROM)24和随机存取存储器(RAM)25。ROM 24中存储了基本输入/输出系统(BIOS)26，里面包含帮助在服务器20内的各个元件之间如在启动过程中传输信息的基本例程。服务器20进一步包括硬盘驱动器27，用于从硬盘60读取和向其中写入，磁盘驱动器28，用于从可移动磁盘29读取和向其中写入，以及光盘驱动器30，用于从诸如CD ROM或其他光学介质之类的可移动光盘31读取或向其中写入。
硬盘驱动器27、磁盘驱动器28，以及光盘驱动器30分别由硬盘驱动器接口32、磁盘驱动器接口33，以及光盘驱动器接口34连接到系统总线23。驱动器以及与它们关联的计算机可读的介质为服务器20非易失性地存储计算机可读的指令、数据结构、程序模块和其他数据。虽然此处描述的示范环境使用硬盘60、可移动磁盘29，以及可移动光盘31，那些精通本技术的人可以理解，可以存储可被计算机访问的数据的其他类型的计算机可读的介质，如磁带、闪存卡、数字视盘、柏努利磁带盒、随机存取存储器、只读存储器等等也可以在示范操作环境中使用。
许多程序模块可以存储在硬盘60、磁盘29、光盘31、ROM 24或RAM 25中，包括操作系统35、一台或多台服务器36、其他程序模块37，以及程序数据38。用户可以通过诸如键盘40和指针设备42之类的输入设备向服务器20中输入命令和信息。其他输入设备(未显示)可以包括麦克风、游戏杆、游戏板、碟形卫星天线、扫描仪或类似的装置。这些和其他输入设备通常通过一个连接到系统总线的串行端口接46连接到处理单元21，但也可以通过诸如并行端口、游戏端口或通用串行总线(USB)之类的其他接口进行连接。监视器47或其他类型的显示设备也通过诸如视频适配器48之类的接口连接到系统总线23。
服务器20通过诸如路由器49之类的路由器和其他网络设备使用与一台或多台远程客户端50或其他服务器52的逻辑连接在联网环境中运行。远程客户端50可以是个人计算机(PC)、网络PC、对等设备、其他常见的网络节点或其他计算设备，通常包括上文在描述服务器20时所描述的许多元件。远程服务器52可以是邮件服务器、镜像服务器、Web服务器或其他常见的网络节点，通常包括上文在描述服务器20时所描述的许多或所有元件。网络路由器49可以是单臂路由器、边缘路由器、多播路由器、软件应用程序或其他常见的网络节点，并通常确定数据包应该被转发到其中的网络位于下一个点。图1描述的逻辑连接51可以是局域网(LAN)和/或广域网(WAN)。这样的网络环境在办公室、企业计算机网络、Intranet以及因特网中是常见的。
当服务器20在LAN或WAN网络环境中使用时，它通过网络接口或适配器53连接到网络51。在网络环境中，在描述服务器20时描述的程序模块，或者它的组成部分，可以存储在远程内存存储设备中，或通过网络路由器49对其进行访问。显然，这里显示的网络连接是示范性的，也可以使用其他装置在计算机之间建立通信链路。
在后面的描述中，除非特别声明，将参考一台或多台计算机执行的操作和操作的符号表示来对本发明进行描述。如此，可以理解，有时由计算机执行的操作包括以结构形式表示数据的电信号的计算机的处理单元执行的操作。这种操作转换数据或将它保存在计算机的存储系统中的位置，计算机重新配置或以那些精通本技术的人理解的别的方式改变计算机的操作。在其中保存数据的数据结构是具有由数据的格式定义的特定属性的内存的物理位置。然而，尽管是在前述的上下文中对本发明进行描述的，但是不作为限制，正如那些精通本技术的人理解的，在下文中描述的各种操作还可以以硬件来实现。
根据本发明的一个方面，在事件的发布时间之前向连接到网络的一组客户端提供加密事件，并在发布时间或之后提供解密密钥，用于对事件进行解密。事件可能比较大，发送到通过窄带连接进行连接的客户端需要较长的时间，尽管具有宽带连接的客户端可以比较快地接收到该事件。发布未加密的事件将是不公平的，因为宽带客户端将在窄带客户端之前访问到事件内包含的信息，并可以使用该信息，而对窄带客户端不利。然而，发布的公正性可以通过对事件进行加密并在发布时间之前发送来达到，因为每一台客户端都可以在较窄的时间跨度内接收到解密密钥，因为密钥相对比较小，其传输所花的时间非常短，甚至在连接速度的较宽的范围之间。如此，每一台客户端都可以在较窄的时间跨度内访问事件内包含的信息，从而使发布比较公正。
正如您可以看到的，为确保发布的公正性，加密事件应该在解密密钥之前接收到，或者客户端具有密钥，但没有事件可以解密。然而，这不能在所有的情况下得到保证。如此，本发明设想在发布时间发送解密密钥，或者如果需要，如果加密事件在可靠地发布到客户端之前足够长的时间就已经在始发服务器上的话，在发布时间之后发送。本发明还设想在发布时间之后，直到结束时间减传递密钥所需要的的传递时间所得出的时间的任何时间发送解密密钥。因此，密钥的发送可以被延迟，以允许尽可能多的客户端在发送密钥之前接收完加密事件。如此，如果始发服务器不能够，或者不被允许在足够早的时间发送加密事件以允许客户端在发布时间之前接收加密事件，密钥的发送可以按需要被延迟，以提供对事件内包含的信息的尽可能公正的访问。
根据本发明的另一个方面，加密事件可以发送到服务器并在被发送到客户端之前在服务器上解密。于是单台客户端不需要保存可能十分大的加密事件，它们也不需要通过对事件进行解密来加重它们的处理系统的负担。受信任的服务器是网络中的可以被始发服务器信任不在发布时间之前发布事件的服务器。受信任的边缘服务器是始发服务器和客户端之间的逻辑连接中可以被信任，因此可以被认为是受信任的网络的边缘的最后一台服务器。如果为客户端对事件进行解密的服务器是受信任的边缘服务器，则受信任的边缘服务器可以在发布时间之前被提供加密事件和密钥并可以在发布时间之前对事件进行解密。或者，如果为客户端对事件进行解密的服务器不是受信任的边缘服务器，那么可以在发布时间之后或者发布时间之前充分长的时间发送密钥，以允许服务器对事件进行解密并将它传输到客户端。然而，服务器不能被信任以保存解密事件并等待指定的时间。无论在哪一种情况下，可能会比较大的解密事件需要大量的时间才能传输到窄带客户端的问题依然存在。为最大限度地降低宽带客户端和窄带客户端接收事件的时间差，受信任的边缘服务器可以在发布时间之前向窄带客户端发送事件，以使客户端可以在大致相同的时间接收完事件。根据本发明的另一个方面，加密事件和解密密钥可以使用多播协议发送，以提高网络效率并分散传输的负担。正如那些精通本技术的人所知道的，在传输的数据丢失或者被破坏的情况下，多播通常不提供有效的请求重新传输的机制。由于密钥可能十分小，使用有效的冗余发送密钥比较有效，从而最大限度地降低将需要重新传输的可能性。例如，密钥的多个副本甚至可以向窄带客户端以可能仍十分小并可有效地传输的单个消息发送。或者，密钥的单个副本可以通过不同的网络路线进行发送，如从不同的密钥服务器，包括始发服务器、受信任的边缘服务器，专门的密钥服务器，或者它们的任何组合。
根据本发明，图2显示了一个示范网络环境。重要的是，本发明不仅限于任何特定网络协议的实现。它可以使用TCP/IP协议、AppleTalk协议、Novell协议以及内容传递网络等等协议来实现。当然，这些协议提供不同的功能级别。因此，在某些网络中，服务器的软件可以执行更多功能，而在其他网络中，服务器的软件可以依赖于基础协议以提供此功能。在描述本发明的示范实施例时，所需要的特定的信息或功能可以由基础协议或服务器或客户端上的软件提供。基础方法仍保持不变，并可以简单地集成现有的功能以完成所需要的任务。
图2显示了一个网络环境200，可以在其中描述本发明的示范实施例。始发服务器210连接到一个网络，该网络包括受信任的边缘服务器220、221和222和诸如服务器230、231和232之类的不受信任的其他服务器网络。该网络还包含个人计算设备(PC)形式的客户端，它们在逻辑上连接到客户端机器。例如，客户端50可以通过窄带连接238进行连接，客户端150可以通过宽带连接239进行连接。正如那些精通本技术的人所知道的，窄带连接一般来讲是以诸如56kbps或33.6kbps之类的通常使用的模拟调制解调器速度建立的拨号连接。宽带连接可以通过诸如电缆调制解调器、数字用户线(DSL)调制解调器或卫星调制解调器之类的许多技术来建立，一般来讲提供大于窄带连接的吞吐量。
在优选的实施例中，在始发服务器210上始发一个事件。事件可以是向客户端50和150传播的任何数据集合。例如，事件可以是简单得如政府财政局或部门发布的经济新闻，或者它可以更大，更复杂，如展示新产品发布或来自一个企业的服务的数字电影，或来自流行音乐家或组合的新音乐视频。一般来讲，事件具有这样的性质，在发布时间之前发布是不合适的。例如，如果政府经济数据在其发布时间之前传播，它可能会扰乱金融市场。同样，如果新音乐视频在其发布时间之前发布，视频的市场营销可能不会具有足够的时间产生需求，视频可能被看作一个失败。事件一般来讲还具有这样的性质：传递的公正性十分重要。如此，如果政府经济数据在其他客户端之前向某些客户端发布，接收到该数据的客户端可能使用它从尚未接收到它的客户端那里获益。同样，如果一台客户端组在另一个组之前接收新音乐视频，专注于发布的不公平性的任何媒体注意力都可能减损有关视频本身的质量的更有利的名声。如此，本发明设想信息或事件以公平的方式在不同带宽和计算容量的客户端之间进行传递。
发布到客户端的事件内包含的信息通常还有一个结束时间，超过该时间信息将会失效或无关。对于某些数据，如政府经济报告，信息可能在一个月或较长时间内有效，直到提供下一个报告。同样，新音乐视频可能会在几个星期内被视为最近的。或者，可以发布到客户端的某些数据可以会非常快地丧失其相关性。例如，显示一个给定区域的气象雷达慢速拍摄效果的电影的有效时间可能只有15分钟。本发明设想以公平的方式并在结束时间之前传递事件，在结束时间之后事件内包含的信息可能对客户端无用。
请看图3，该图显示了本发明设想的事件的时间系列。柱状图300表示特定服务器的客户端组。例如，该图形可以表示连接了窄带客户端50和宽带客户端150的受信任的边缘服务器221，或连接了窄带客户端50和宽带客户端150的外部(非受信任的)服务器232。虽然图2只显示了连接到服务器221和232的几个这样的客户端，但是可以理解，可以通过类似的网络连接来连接更多客户端。在柱状图300上，通常是连续函数的传递时间，被近似于分成所示的类别。如此，所示的距离左边最远的第一组客户端310将在大致5秒到15秒内的时间范围内接收消息，第二组312将在40秒到60秒的时间范围内接收信息，依此类推。值得注意的是，柱状图300所示的时间不是线性地增加的。这是因为传输时间只作为本发明的说明提供。
正如可以从柱状图300看到的，显示的服务器大致具有100台客户端与之相连接，包括宽带客户端和窄带客户端。柱状图300在服务器开始发送加密事件时的时间350开始。服务器可以在时间350开始发送加密事件，原因有多个。例如，时间350可以是服务器从诸如图2所示的始发服务器210之类的始发服务器接收加密事件的第一次。或者，时间350可以是服务器完成对事件加密的过程的第一次，如果它从始发服务器以未加密的形式接收到事件。此外，服务器可以由于来自始发服务器的显式指令在时间350开始发送加密事件。值得注意的是，由于加密事件的传输不需要等待一个特定时间，受信任的边缘服务器和非受信任的服务器都可用于发布事件。
接收事件的第一组客户端310，大致在时间350之后10秒钟完成此项工作，而最后一组客户端326大致在700秒钟内接收到事件。正如通过这样的大变化所看到的，一个简单地在发布时间发送到客户端的未加密的事件将导致诸如客户端326之类的客户端直到诸如客户端310之类的第一客户端已经接收到事件之后11分钟以上才能接收到事件。如果事件是发布政府经济数据，那么客户端310将有充足的时间从还没有接收到信息的客户端326获利。正如那些精通本技术的人所理解的，柱状图300显示了发布相对小的事件，因为它可以由宽带客户端在10秒钟内下载完毕。对于诸如展示新产品的视频之类的较大的事件，即使最快速的客户端310也可能不会在几分钟内接收到事件，最慢的客户端326可能要花好几个小时才能接收完事件。
如图3所示，服务器开始在发布时间360之前充分长的时间350发送加密事件，以使每一台客户端接收完加密事件。然后在时间370，该时间可以等于时间360，如图3所示，或者是比较晚的时间，如下文进一步所述的，服务器可以在时间350发送密钥以对加密事件进行解密。正如那些精通本技术的人所了解的，很难正好在一个给定时间执行一个功能，因为所有计算设备都以不连续的周期运行。尽管如此，在本发明中，紧随在发布时间360之后的时间被相应地视为等于发布时间360。由于密钥的大小比较小，甚至对于窄带客户端，接收到该密钥所花的时间几乎没有变化。如此，如图3所示，所有客户端330都可能几乎同时地接收到密钥。客户端组330显示了在组310到326中接收到加密事件的相同的100台客户端，只是在时间370向那些客户端发送了其他数据，即解密密钥，并且它们都在两秒钟内接收到它，如柱状图330所示。如此，每一台客户端都通过使用解密密钥来对事件进行解密，在发布时间360之后的不久大致相同的时间访问到事件内包含的信息。
由于事件是经过加密的，诸如受信任的边缘服务器221之类的受信任的边缘服务器，诸如非受信任的服务器232之类的非受信任的服务器，可用于在发布时间360之前发布事件。然而，正如下文比较详细地描述的，如果将要传输解密的或未加密的事件，那么事件可以在发布时间360之前由受信任的边缘服务器所保存。然而，非受信任的服务器可以在发布时间之前发布事件。对于加密事件，由于非受信任的服务器在发布时间之前发布事件，因此不会产生不公平，因为客户端没有访问事件内包含的信息所需要的密钥。然而，对于解密的或未加密的事件，单台服务器在发布时间之前发布可能会导致对事件内包含的信息不公平的访问。如此，正如您所看到的，只要数据出现，就可以发送到诸如客户端50和150之类的客户端。当这样的数据包括解密密钥、未加密的事件或允许客户端访问事件内包含的信息的其他数据时，它可以保存在最靠近的受信任的服务器上，以便在适当的时间发布。不能信任非受信任的服务器以保存数据，直到可以发布的适当的时间。如上文所讲述的，最靠近的受信任的服务器是受信任的边缘服务器。
解密密钥可以由密钥服务器发送。密钥服务器可以是发送密钥的任何服务器，并可以包括始发服务器、一台或多台受信任的边缘服务器、专门的中心密钥服务器，或分布式专门密钥服务器组，或它们的任何组合。中心密钥服务器，或分布式专门密钥服务器，还可以是网络环境200的组成部分，并可以在时间370直接向客户端传输密钥，或者可以在时间370之前的某个时间向受信任的边缘服务器221发布密钥，并提供有关密钥发送时间的指令。然而，非受信任的服务器232可以在时间370而不是在时间370之前发送密钥，因为服务器232在时间370之前不能被信任以保存密钥。为确保密钥尽可能有效地到达尽可能多的客户端，使用许多不同的网络路径向客户端提供密钥从诸如上文描述的那些服务器之类的多台服务器传输密钥是有用的。通过使用多个路径，任何单个路径可能被拥挤并延迟密钥的接收的风险降低。因为，如下文所述，密钥的传输可能取决于客户端接收加密事件的情况、服务器和中心密钥服务器之间的通信或者服务器和密钥服务器的网络之间的通信，因此可以协调向客户端发送密钥的情况。
用于对事件进行加密的加密方法可以任何一个流行的加密方法或它们的组合，包括数据加密标准(DES)、安全而快速的加密例程(SAFER)、国际数据加密算法(IDEA)、以及诸如Twofish、SERPENT、RC6、和MARS之类的高级加密标准(AES)候选标准中的任何一个。本发明设想使用可以由相对比较小的一个或多个解密密钥进行解密的任何加密方法，以便对于各种宽带和窄带客户端，传输时间没有太大的差异。
请看图4，柱状图400显示了一个事件发布过程。如在图3中，服务器可以是诸如受信任的边缘服务器221之类的受信任的边缘服务器，或者，由于发布的事件是经过加密的，诸如非受信任的服务器232之类的非受信任的服务器。正如您所看到的，服务器开始发送事件的时间450不是发布时间460之前的允许每一台客户端接收完加密事件的充分长的时间。时间450可能取决于服务器从始发服务器接收事件的时间。由于服务器在时间450开始发送加密事件的时间和发布时间460之间的时间缩短，客户端424和426在发布时间尚未接收完加密事件。在这种情况下，本发明设想延迟密钥的传输，直到所有的客户端都接收完加密数据。然而，密钥的传输不应该被延迟到这样的程度，以至于密钥在结束时间490之后接收。此外，还可以考虑实际情况。如此，尽管只有少部分用户尚未接收完加密数据，但是可以传输密钥以允许多数用户在靠近发布时间的某个时间接收到数据。这样的考虑在具有多台服务器的网络中公平地跨整个网络发布事件特别重要，正如下文比较详细地描述的。
如图4所示，本发明设想在发布时间460之后并在最后一组客户端426接收完加密事件之后的某个时间470发送解密密钥。发送密钥时的时间470也是结束时间490之前充分长的时间，以使每一台客户端430都可以在结束时间之前接收到密钥。虽然图4显示了发送密钥时的时间470在最后一组客户端426接收完加密事件之后不久，密钥可以在结束时间之前充分长的任何时间发送，以确保每一台客户端，或尽可能多的客户端，接收到密钥，从而可以在结束时间490之前访问事件包含的信息。
请看图5，如柱状图500所示的事件发布显示了本发明设想的另一个传输序列。如图5所示，甚至在结束时间590之后，加密事件仍由客户端组524和526接收。服务器，再次包括受信任的边缘服务器和非受信任的服务器，不会在时间550之前开始发送加密事件，该时间太晚，以允许所有的客户端都在结束时间590之前接收到加密事件。此外，时间550可能会由许多外部因素决定，如服务器从始发服务器接收事件时的时间。在图5中，发送时间550相当于发布时间560，但发送时间550可以在发布时间560之前或之后，仍可能导致客户端组不能在结束时间590之前接收完加密事件。
在这种情况下，本发明设想受信任的边缘服务器可以等待尽可能长的时间以发送解密密钥，以确保尽可能多的客户端接收完加密事件。如此，在结束时间590之前允许被客户端接收到密钥的充分长的某个时间570，受信任的边缘服务器可以开始发送密钥。如图5所示，受信任的边缘服务器可以在组524和526中的客户端接收完加密数据之前的时间570开始发送密钥。在结束时间590之前，每一台客户端都已经接收到解密密钥，但客户端524和526需要在它们可以使用密钥访问事件中发送的数据之前接收完加密事件。然而，客户端510到522的组已经在传输密钥之前在时间570接收完加密事件，并能够在结束时间590之前访问其中包含的数据。此外，客户端510到522中的每一台客户端都能够几乎同时访问此数据，在给定连接到受信任的边缘服务器的客户端的延迟的情况下，尽可能公平地发布信息。
可能会有这样的情况：图2所示的服务器的客户端50和150中的某些客户端可能没有足够的存储空间或处理功率用来存储加密事件或对其进行解密。此外，客户端的存储事件并对其进行解密的能力在不同的事件之间也可能不同。例如，诸如发布政府经济数据之类的相对小的事件，可以轻易地被存储和解密，很可能许多客户端都具有足够的存储空间和处理功率。然而，对于数字电影，或其他大的事件，许多客户端可能没有足够的存储空间或处理功率，包括那些能够处理较小的事件的客户端。
如此，本发明设想，服务器可以在发送加密事件之后发送解密密钥，或者受信任的边缘服务器可以在本地对事件进行解密，并传输事件的解密版本。或者，如果始发服务器发送未加密的事件，受信任的边缘服务器不能对事件进行加密并向那些缺乏存储或处理功率的客户端发送未加密的事件。正如那些精通本技术的人所知道的，未加密的事件包含与解密事件相同的信息。为确保事件的完整性，接收解密事件的客户端不应该在发布时间之前接收它。如此，受信任的边缘服务器可以在发布时间之前一直保存解密事件，或者受信任的边缘服务器可以确定需要服务器发送解密事件的客户端的延迟，并在发布时间之前开始发送解密事件以使那些客户端在发布时间接收到解密事件。
回到图2，受信任的边缘服务器221有一台通过宽带连接进行连接的个人计算设备150，和两台通过窄带连接进行连接的个人计算设备50。如果两台个人计算设备50缺乏足够的存储空间和处理功率用来存储加密事件并对其进行解密，加密事件可以由受信任的边缘服务器221进行解密，解密事件可以发送到计算设备50。
上面的图3显示了向诸如受信任的边缘服务器221之类的服务器的100台客户端传输加密事件。尽管图3设想使用非受信任的服务器，由于发送到客户端的事件被加密，图6设想使用受信任的边缘服务器。然而，如图2所示，诸如受信任的边缘服务器220和222之类的受信任的边缘服务器可以通过诸如非受信任的服务器230和231之类的其他非受信任的服务器与客户端进行通信。受信任的边缘服务器220和222远到可以保证未加密的事件可以在始发服务器210和最终客户端目标之间传输，同时通过在合适的时间发送未加密的事件来保持发布的公正性，正如下文所述。图6还只用作说明，显示了本发明设想的向连接到受信任的边缘服务器221的150台客户端的传输。具体来说，图6显示了向图3所示的相同的100台客户端发送加密事件和解密密钥的操作，此外，还显示了向没有足够的存储或处理功率的50台新客户端发送解密事件的操作。
图6包含柱状图600，显示了向100台能够存储加密事件并对其进行解密的客户端和另外50台不能并依赖于来自受信任的边缘服务器的解密事件的客户端传播信息的过程。正如上文结合图3所讲述的，客户端610到626的组在加密事件被服务器在时间650发送之后的某个时间接收它。然后，在时间670，受信任的边缘服务器可以发布解密密钥。如此，如图6的说明示例所示，具有存储加密事件并对其进行解密的能力的所有100台客户端都在大致相同的时间访问事件内包含的信息：在受信任的边缘服务器在时间670发送密钥之后两秒钟。
对于不具有存储加密事件并对其进行解密的其余50台客户端，受信任的边缘服务器可以对事件进行解密并在时间680发送解密事件。在图6的说明示例中，时间680是受信任的边缘服务器选择的，以使接收解密事件的第一组客户端640不会在发布时间660之前完成此项工作，但仍然尽可能在接近于发布时间660的时间接收到解密事件。其他客户端642、644和646的组可以在发布时间660之后的某个时间接收解密事件，具体情况视它们到受信任的边缘服务器的连接的延迟而定。正如您可以看到的，对于不能存储加密事件并对其进行解密的50台客户端，受信任的边缘服务器仍能够通过发送解密事件提供对事件中存储的信息的访问，并能够以比较公平的方式完成此项工作，因为50台客户端中的每一台客户端都在发布时间660之后不久与图3的原始100台客户端一起接收到解密事件。
图6的受信任的边缘服务器可以通过估计到客户端的连接的延迟来确定开始发送解密事件的时间680。正如那些精通本技术的人所知道的，延迟是传输数据的连接的能力的度量。本发明设想，受信任的边缘服务器可以维护一个数据库，该数据库包含与每一台客户端，或与代表性的客户端组进行通信的历史。这样的数据库可用于基于以往的经验数据确定期望的传输时间。数据库可以包含诸如数据速率、峰值数据速率、拥塞信息、连接失败之类的延迟的度量，以及其他从与客户端进行的以前的通信收集的此类网络信息。例如，可以使用历史数据速率的平均值，或者可以使用数据速率中的最新趋势来推断期望的传输时间的估计值。或者，可以使用数据速率信息结合其他信息派生或者改进估计的传输时间。除了基于经验观察的期望的传输时间，受信任的边缘服务器还可以使用网络功能来确定理论传输时间。例如，受信任的边缘服务器可以对客户端或一组客户端进行“ping”操作，并测量客户端响应所需要的时间来确定期望的传输时间。或者，更高级的网络环境可以具有更高级的网络协议，以便可以向受信任的边缘服务器提供有关到客户端的连接的延迟的其他信息。
通过将估计的传输时间减去发布时间，受信任的边缘服务器可以确定开始发送解密事件并允许接收解密事件的客户端在发布时间接收到它的发送时间680。正如那些精通本技术的人所知道的，估计的传输时间可以通过将事件的大小除以连接的延迟来确定。
然而，由于连接的延迟可能不同，并且因为，在某些情况下，没有客户端在发布时间之前访问到事件所传达的信息至关重要，受信任的边缘服务器可以通过使用期望的最小传输时间来确定发送时间；从而可以确保，即使对于最佳的条件，解密事件也不会在发布时间之前到达客户端。期望的最小传输时间可以基于存储在数据库中的最低数据速率，或者它可以基于通过网络功能获取的数据并考虑无法预料的事件的相应的乘数。例如，期望的最小传输时间可以简单地是使用理论计算值派生的期望传输时间的一半。通过使用期望的最小传输时间，受信任的边缘服务器可以确定充分晚的发送时间，以便没有客户端在发布时间之前访问到事件中包含的信息。
图7显示了本发明设想的另一种可能性：使具有最小的存储或处理能力的客户端能够访问事件内包含的信息。柱状图700显示了与上文结合图6描述的柱状图600类似的情况。然而，在图7中，受信任的边缘服务器可以在不同的时间780到786发送解密事件，以使请求解密事件的所有客户端都在大致相同的时间740接收到它。如此，对于在图6以最少的时间量接收到解密事件的客户端组640，受信任的边缘服务器可以在时间786发送解密事件。对于第二快的客户端组642，受信任的边缘服务器可以在时间784开始发送解密事件，并且同样，受信任的边缘服务器可以在时间782开始向客户端644发送事件，并在时间780向客户端646发送事件。通过交错向单台客户端或客户端组的发送时间，受信任的边缘服务器可以几乎同时地向在图7中所示的时间740需要解密事件的客户端提供解密事件。
图7的受信任的边缘服务器可以通过上文讨论的经验的或者理论的方法确定一台客户端或一组客户端之间的大致连接延迟，并可以使用估计值来确定向各台客户端发送解密事件的时间。此外，通过使用上文显示的方法，在该方法中，受信任的边缘服务器可以在发布时间760之前发送解密事件，受信任的边缘服务器还可以使组740中的客户端在大致与组730中的客户端相同的时间访问事件中包含的信息。有关上文描述的解密事件的发布时间之前的传输和向选择的客户端从时间上交错传输的其他信息，可以在与同时与本申请提出的标题为“使用连接计划的时间窗口受约束的多播”的共同待审批的申请(律师摘要号码213530)中找到，该申请在此处全部加以引用。
回到图2，网络连接218和228是直接连接，但正如那些精通本技术的人所知道的，这样的连接可以包括许多路由器、受信任的服务器、非受信任的服务器，以及其他网络路径。本发明设想一个叠加网络，在该网络中，下面所引用的受信任的服务器和连接不一定需要特定的硬件配置，或任何物理限制，而可以用在现有的硬件上运行的软件来实现。结果，下面将进一步详细描述的图2网络200，可以只表示在现有的物理网络上叠加的软件，或者它可以表示新网络的物理结构。
图2所示的到受信任的边缘服务器的连接218可以包括中间的非受信任的服务器。正如下面比较详细地讲述的，加密事件在发布时间从始发服务器210通过网络200发送。由于事件是经过加密的，它可以穿过连接路径218中的非受信任的服务器到达受信任的边缘服务器，而不会破坏事件发布的完整性。然而，如果将在发布时间之前向受信任的边缘服务器220、221和222提供解密密钥，那么可使用保护措施确保连接路径218中的非受信任的服务器不会在发布时间之前获得密钥并将它发布到客户端。可以用于本发明的保护措施的示例包括启用本技术中已知的虚拟专用网络(VPN)和点对点隧道协议(PPTP)的加密算法。于是，始发服务器210可以安全地向受信任的边缘服务器传达敏感的信息，包括解密密钥和解密或未加密的事件，正如下面详细地讲述的，而不会同时向连接路径218中的非受信任的服务器透露敏感的信息。
图2的网络200显示了受信任的边缘服务器222，宽带客户端150与它相连接。如此，受信任的边缘服务器222很可能可以在发布时间之前提供加密事件，如图3所示，并且宽带客户端具有存储事件并对其进行解密的能力。然而，显示为只具有窄带客户端50与之相连接的受信任的边缘服务器220可能不能够在充分早的发送时间发送加密事件，以使每一台窄带客户端50在发布时间之前接收到它，如图4所示。给定这样的网络情况，本发明设想受信任的边缘服务器222和220之间或受信任的边缘服务器220、221、222和始发服务器210中所有服务器之间的通信协调解密密钥的发布。如上文结合图4所述，受信任的边缘服务器可以在发布时间460和结束时间490之后的任何时间传输解密密钥。因此，密钥发送时间470可以对应于其他受信任的边缘服务器的密钥发送时间。如此，尽管受信任的边缘服务器222已经在发布时间之前提供加密事件，如图3所示，但是它可以延迟密钥发送时间370，以对应于如图4所示的密钥发送时间470，该时间在发布时间之后。
协调消息等等可以在受信任的边缘服务器之间或在受信任的边缘服务器和始发服务器之间发送以协调密钥的传输。或者，协调可以由上文描述的中心密钥服务器来执行。中心密钥服务器可以从受信任的边缘服务器或从客户端本身接收消息，并指出客户端接收到加密事件的程度。基于该信息，中心密钥服务器可以确定协调的密钥发送时间并在协调的密钥发送时间向客户端发送密钥，或者可以将它发送到受信任的边缘服务器以传递到客户端，在协调的密钥发送时间之前发送它，或者向受信任的边缘服务器提供指令以在协调的密钥发送时间发送密钥。此外，还可以发送协调每一台受信任的边缘服务器和始发服务器的时间设置的消息，以防止不适当的时间设置导致不适当的密钥传输。中心密钥服务器，或密钥服务器的网络还可以与受信任的边缘服务器协调它们的时间。协调所有服务器的时间设置或时钟的一种方法是使用网络时间协议将服务器与诸如政府标准设置机构提供的标准时间同步。作为一个保险措施，只要客户端准备好，每一台受信任的边缘服务器就都可以发送密钥，前提是发布时间已过，如果该受信任的边缘服务器不接收此协调的消息。
本发明还设想，即使当受信任的边缘服务器必须对事件进行解密并传输解密事件，也可以在受信任的边缘服务器、专门的中心密钥服务器、专门的分布式密钥服务器、始发服务器，或它们的组合之间的进行密钥发送时间协调。例如，回到上文描述的图2的网络环境，受信任的边缘服务器221可以具有与它相连接的客户端，这些客户端要求受信任的边缘服务器221对事件进行解密，并以如上文描述的图6或7所示的方式传输解密事件。如图6和7所示，受信任的边缘服务器可以在时间680或在时间系列780、782、784和786开始发送解密事件。此外，如上文所述，发送时间可以基于受信任的边缘服务器和客户端之间的估计的连接延迟来计算出。然而，上述计算值一般来讲在发布时间提供对解密事件的访问。如果受信任的边缘服务器或始发服务器在发布时间之后的某个时间协调了密钥的发送，发送解密事件的受信任的边缘服务器可以在计算中使用此协调的时间，而不是使用发布时间，来确定解密事件的发送时间。于是，接收解密事件的客户端不会在已经接收到解密事件并在等待密钥的客户端之前访问事件内包含的信息。
用于在受信任的边缘服务器之间协调密钥和解密数据的传输的一种方法可以基于事件从诸如始发服务器210之类的服务器传输到受信任的边缘服务器的接收时间。如果受信任的边缘服务器不充分早地从始发服务器接收事件，加密事件传输到客户端的过程可能不会在发布时间之前完成，如在图4所示的情况。然而，通过经验的或理论的估计，如上文描述的，受信任的边缘服务器可以获得到它们的客户端的连接的估计传输时间，从而可以估计加密事件完成到所有或多数客户端的传输所需要的传输时间。然后可以选择发送解密密钥的协调的时间，比加密事件传输将完成但是仍在结束时间之前的此估计时间更迟。一旦选择了协调的时间，发送解密事件的受信任的边缘服务器可以使用此时间，而不是使用发布时间，按照上文比较详细地描述的方式来确定开始发送解密事件的时间。
本发明设想使用有效的网络协议来跨网络环境200传输数据，包括加密事件、解密事件，以及解密密钥。一个这样的协议是使用Internet协议(IP)的网络上常见的多播协议。正如精通本技术的人所知道的，多播通信被发送到单个目标IP地址，但由多台IP主机接收和处理，不管它们在网络环境200中的位置如何。由于通信被发送到单个目标IP地址，多播避免了向每一台客户端或每一台受信任的边缘服务器发送单个副本的必要性。然而，与广播不同的是，多播只允许那些侦听特定的IP多播地址的网络设备接收和处理信息。一般来讲，主机组被定义为在预先确定的IP多播地址上侦听的主机组。对主机组的大小没有限制，并且其成员资格可以更改，并且是以别的方式呈现动态的形式。此外，主机组可以跨越路由器和多个网络段，并且计算设备不需要是主机组的成员，便可以向预先确定的IP多播地址多播信息。为了让应用程序接收多播，它可以通知相应的网络层，它将在预先确定的IP多播地址接收多播。
然而，由于多播的性质，优选情况下，在时间比较重要的情况下，所有的主机都要接收传输的数据，而不必请求重新传输。提高数据被正确地接收的可能性的一种方法是使用冗余，或其他纠错算法。对于诸如解密密钥之类的小的数据元素，冗余可能是最简单的解决方案。例如，解密密钥可能差不多几千字节或更小。即使实现10倍的冗余，消息的大小提高到大致30千字节。即使对于窄带连接，如以56kbps甚至以33.6kbps运行的传统的模拟调制解调器，30千字节也只需要10秒钟就可以下载完。如此，甚至通过使用大量的冗余，按照传统的标准，解密密钥的传输仍可以在很小的时间跨度内完成。
小的密钥可使多台服务器在整个网络200内传输密钥，而不显著地影响网络的延迟。通过利用多台服务器传输密钥，可使用多个网络路径向每一台客户端提供密钥。由于每一台客户端都可以通过多个网络路径接收密钥，拥挤的节点，或其他网络瓶颈影响到每一台客户端的传输时间的可能性显著变小，因为客户端可能通过一个非拥挤的路径接收至少一个密钥。
正如您可以看到的，本发明公平地向连接到受信任的服务器的客户端发布事件，不管客户端的带宽的差异如何。受信任的边缘服务器可以对事件进行加密并向客户端发布以便在发布时间或在结束时间之前通过传输的密钥进行解密，或者受信任的边缘服务器可以在发布时间之前开始传输事件的解密版本以使它在发布时间或在结束时间之前到达客户端。于是尽可能多的客户端可以在大致相同的时间访问一个事件。
此处的所有引用，包括任何专利、专利申请和出版物，都全部加以引用。
考虑到可以应用本发明的原理的许多可能的实施例，应该承认，此处参考附图描述的实施例只作说明，不应该限制本发明的范围。例如，那些精通本技术的人将承认，软件中所示的实施例的元素可以以硬件实现，反之亦然，显示的实施例可以修改，而不偏离本发明的精神。因此，此处描述的本发明预期所有此类实施例都在下面的权利要求以及它们的等价物的范围内。

Claims (52)

1.一种用于公平地跨网络环境向至少两台客户端发布事件的方法，事件具有计划在预先确定的发布时间发布的信息，该方法包括：
在发布时间之前从始发服务器向至少两台客户端发送加密事件；以及
在发布时间之后从密钥服务器向至少两台客户端发送解密密钥。
2.根据权利要求1所述的方法，其特征在于，发送解密密钥的操作是紧随在发布时间之后发生的。
3.根据权利要求1所述的方法，其特征在于，发送解密密钥的操作在至少两台客户端中的所有客户端都已经接收完加密事件之后发生。
4.根据权利要求1所述的方法，其特征在于，事件计划在预先确定的结束时间之前发布，并且其中，如果至少两台客户端中的所有客户端都在最后一个密钥发送时间之后接收完加密事件，发送解密密钥在至少两台客户端中的所有客户端接收完加密事件之前发生，最后一个密钥发送时间是结束时间之前足够长的时间以允许向至少两台客户端中的所有客户端传输密钥。
5.根据权利要求1所述的方法，包括：
在发布时间之前从始发服务器向受信任的边缘服务器发送未加密的事件，其中，受信任的边缘服务器是始发服务器和连接的客户端之间的通信路径中的可以被信任不在合适的时间之前发布信息的一台服务器；以及
在第二客户端发送时间向第二客户端发送未加密的事件，第二客户端发送时间允许未加密的事件在与解密密钥被至少两台客户端接收的时间大致相同的时间被第二客户端接收。
6.根据权利要求5所述的方法，进一步包括：
在第三客户端发送时间向第三客户端发送未加密的事件，第三客户端发送时间允许未加密的事件在与解密密钥被至少两台客户端接收的时间大致相同的时间被第三客户端接收。
7.根据权利要求5所述的方法，其特征在于，第二客户端发送时间允许未加密的事件在与解密密钥被至少两台客户端接收的时间大致相同的时间被第二客户端或第三客户端中的希望首先接收它的任何一台客户端接收，该方法进一步包括：
在第二客户端发送时间向第三客户端发送未加密的事件。
8.根据权利要求1所述的方法，其特征在于，密钥服务器包括两台或更多密钥服务器。
9.根据权利要求1所述的方法，其特征在于，发送解密密钥的操作在协调的密钥发送时间发生，其中，协调的密钥发送时间基于网络环境中的所有客户端接收加密事件的时间。
10.根据权利要求1所述的方法，其特征在于，发送解密密钥的操作包括多播密钥消息，该消息至少包括解密密钥的一个副本。
11.一种用于公平地跨网络环境向第一客户端发布事件的方法，事件具有计划在预先确定的发布时间发布的信息，该方法包括：
从始发服务器向受信任的边缘服务器发送加密事件，其中，受信任的边缘服务器是始发服务器和连接的客户端之间的通信路径中的可以被信任不在合适的时间之前发布信息的一台服务器；
在受信任的边缘服务器上对加密事件进行解密；以及
在第一客户端发送时间从受信任的边缘服务器向第一客户端发送解密事件，其中，第一客户端发送时间是向第一客户端传输解密事件的第一期望的时间和第一客户端接收到解密事件的第一客户端到达时间的函数，其中，第一客户端到达时间在发布时间之后。
12.根据权利要求11所述的方法，其特征在于，传输的第一期望的时间是由对受信任的边缘服务器和第一客户端之间的连接历史的引用确定的。
13.根据权利要求11所述的方法，其特征在于，传输的第一期望的时间是由对网络功能测试受信任的边缘服务器和第一客户端之间的第一客户端延迟的结果的引用确定的。
14.根据权利要求11所述的方法，其特征在于，第一客户端到达时间是发布时间。
15.根据权利要求11所述的方法，进一步包括：
在第二客户端发送时间从受信任的边缘服务器向第二客户端发送解密事件，其中，第二客户端发送时间是向第二客户端传输解密事件的第二期望的时间和第二客户端接收到解密事件的第二客户端到达时间的函数，其中，第二客户端到达时间在发布时间之后。
16.根据权利要求15所述的方法，其特征在于，第一客户端发送时间是第二客户端发送时间。
17.根据权利要求15所述的方法，其特征在于，第一客户端到达时间是第二客户端到达时间。
18.根据权利要求11所述的方法，其特征在于，第一客户端到达时间大致与第二客户端密钥接收时间相同，该方法进一步包括：
在发布时间之前从始发服务器向第二客户端发送加密事件；以及
在发布时间之后从密钥服务器向第二客户端发送解密密钥，第二客户端在第二客户端密钥接收时间接收解密密钥。
19.一种用于公平地跨网络环境向至少两台客户端发布事件的方法，该方法包括：
向至少两台客户端发送加密事件；以及
在至少两台客户端中的所有客户端都接收完加密事件向至少两台客户端发送解密密钥。
20.根据权利要求19所述的方法，进一步包括：
向受信任的边缘服务器发送未加密的事件，其特征在于，受信任的边缘服务器是网络环境中的可以被信任不在合适的时间之前发布信息的一台服务器；
在第二客户端发送时间向第二客户端发送未加密的事件，第二客户端发送时间允许未加密的事件在与解密密钥被至少两台客户端接收的时间大致相同的时间被第二客户端接收。
21.根据权利要求19所述的方法，进一步包括：
向受信任的边缘服务器发送加密事件，其中，受信任的边缘服务器是网络环境中的可以被信任不在合适的时间之前发布信息的一台服务器；
在受信任的边缘服务器上对加密事件进行解密；以及
在第二客户端发送时间从受信任的边缘服务器向第二客户端发送解密事件，其中，第二客户端发送时间是向第二客户端传输解密事件的第二期望的时间和第二客户端接收到解密事件的第二客户端到达时间的函数，第二客户端到达时间与解密密钥被至少两台客户端接收的时间大致相同。
22.根据权利要求21所述的方法，其特征在于，传输的第二期望的时间是由对受信任的边缘服务器和第二客户端之间的连接历史的引用确定的。
23.根据权利要求21所述的方法，其特征在于，传输的第二期望的时间是由对网络功能测试受信任的边缘服务器和第二客户端之间的第二客户端延迟的结果的引用确定的。
24.一种用于公平地发布事件的系统，事件具有计划在预先确定的发布时间发布的信息，该系统包括：
始发服务器；
受信任的边缘服务器，其中，受信任的边缘服务器是始发服务器和连接的客户端之间的通信路径中的可以被信任不在合适的时间之前发布信息的一台服务器；
密钥服务器；以及
至少两台客户端；
其中，始发服务器在发布时间之前向至少两台客户端发送加密事件，密钥服务器在发布时间之后向至少两台客户端发送解密密钥。
25.根据权利要求24所述的系统，其特征在于，密钥服务器在至少两台客户端中的所有客户端都已经接收完加密事件之后发送解密密钥。
26.根据权利要求24所述的系统，进一步包括第二客户端，其特征在于，始发服务器向受信任的边缘服务器发送未加密的事件，受信任的边缘服务器在第二客户端发送时间向第二客户端发送未加密的事件，第二客户端发送时间允许未加密的事件在与解密密钥被至少两台客户端接收的时间大致相同的时间被第二客户端接收。
27.根据权利要求24所述的系统，其特征在于，始发服务器向至少两台客户端发送加密事件的操作包括始发服务器向受信任的边缘服务器发送未加密的事件，受信任的边缘服务器对未加密的事件进行加密，以及受信任的边缘服务器向至少两台客户端发送加密事件。
28.根据权利要求24所述的系统，其特征在于，密钥服务器在协调的密钥发送时间发送解密密钥，其中，协调的密钥发送时间基于至少两台客户端接收加密事件的时间。
29.根据权利要求24所述的系统，进一步包括第二客户端，其特征在于，始发服务器向受信任的边缘服务器发送加密事件，密钥服务器向受信任的边缘服务器发送解密密钥，受信任的边缘服务器对加密事件进行解密，受信任的边缘服务器在第二客户端发送时间向第二客户端发送解密事件，第二客户端发送时间允许解密事件在与解密密钥被至少两台客户端接收的时间大致相同的时间被第二客户端接收。
30.根据权利要求24所述的系统，其特征在于，密钥服务器多播一则密钥消息，该消息至少包括解密密钥的一个副本。
31.一种用于公平地发布事件的系统，事件具有计划在预先确定的发布时间发布的信息，该系统包括：
始发服务器；
受信任的边缘服务器，其中，受信任的边缘服务器是始发服务器和连接的客户端之间的通信路径中的可以被信任不在合适的时间之前发布信息的一台服务器；以及
第一客户端；
其中，受信任的边缘服务器在第一客户端发送时间向第一客户端发送未加密的事件，其中，第一客户端发送时间是向第一客户端传输解密事件的第一期望的时间和第一客户端接收到解密事件的第一客户端到达时间的函数，其中，第一客户端到达时间在发布时间之后。
32.根据权利要求31所述的系统，进一步包括第二客户端，其特征在于，始发服务器向受信任的边缘服务器发送加密事件，受信任的边缘服务器对加密事件进行解密，受信任的边缘服务器向第二客户端发送解密事件以使第二客户端大致在第一客户端到达时间接收解密事件。
33.根据权利要求31所述的系统，其特征在于，传输的第一期望的时间是由对受信任的边缘服务器和第一客户端之间的连接历史的引用确定的。
34.根据权利要求31所述的系统，其特征在于，传输的第一期望的时间是由对网络功能测试受信任的边缘服务器和第一客户端之间的第一客户端延迟的结果的引用确定的。
35.根据权利要求31所述的系统，其特征在于，受信任的边缘服务器在第二客户端发送时间向第二客户端发送未加密的事件，其中，第二客户端发送时间是向第二客户端传输未加密的事件的第一期望的时间和第二客户端接收到未加密的事件的第二客户端到达时间的函数，其特征在于，第二客户端到达时间在发布时间之后。
36.根据权利要求35所述的系统，其特征在于，第一客户端发送时间是第二客户端发送时间。
37.根据权利要求35所述的系统，其特征在于，第一客户端到达时间是第二客户端到达时间。
38.根据权利要求31所述的系统，进一步包括密钥服务器和第二客户端，其特征在于，始发服务器在发布时间之前向第二客户端发送加密事件，并且密钥服务器在发布时间之后向第二客户端发送解密密钥，第二客户端在第一客户端到达时间接收解密密钥。
39.一种用于公平地发布事件的系统，包括：
服务器；以及
至少两台客户端；
其特征在于，服务器向至少两台客户端发送加密事件，服务器在至少两台客户端中的所有客户端都已经接收到加密事件之后向至少两台客户端发送解密密钥。
40.根据权利要求39所述的系统，进一步包括第二客户端，其特征在于，服务器是受信任的边缘服务器，受信任的边缘服务器是可以被信任不在合适的时间之前发布信息的一台服务器，并且其中，受信任的边缘服务器在第二客户端发送时间向第二客户端发送未加密的事件，第二客户端发送时间允许未加密的事件在与解密密钥被至少两台客户端接收的时间大致相同的时间被第二客户端接收。
41.根据权利要求39所述的系统，进一步包括第二客户端，其特征在于，服务器是受信任的边缘服务器，受信任的边缘服务器是可以被信任不在合适的时间之前发布信息的一台服务器，并且其中，受信任的边缘服务器从始发服务器接收加密事件，对加密事件进行解密，并在第二客户端发送时间向第二客户端发送解密事件，第二客户端发送时间允许解密事件在与解密密钥被至少两台客户端接收的时间大致相同的时间被第二客户端接收。
42.根据权利要求41所述的系统，其特征在于，第二客户端发送时间是由对受信任的边缘服务器和第二客户端之间的连接历史的引用确定的。
43.根据权利要求41所述的系统，其特征在于，第二客户端发送时间是由对网络功能测试受信任的边缘服务器和第二客户端之间的第二客户端延迟的结果的引用确定的。
44.一种用于公平地跨网络环境向至少两台客户端发布事件的方法，事件具有计划在预先确定的发布时间发布的信息，该方法包括：
在发布时间之前从始发服务器向至少两台客户端发送加密事件的步骤；以及
在发布时间之后从密钥服务器向至少两台客户端发送解密密钥的步骤。
45.根据权利要求44所述的方法，其特征在于，发送解密密钥的步骤在至少两台客户端中的所有客户端都已经接收完加密事件之后发生。
46.根据权利要求44所述的方法，进一步包括：
在发布时间之前从始发服务器向受信任的边缘服务器发送未加密的事件的步骤，其中，受信任的边缘服务器是始发服务器和连接的客户端之间的通信路径中的可以被信任不在合适的时间之前发布信息的一台服务器；以及
在第二客户端发送时间向第二客户端发送未加密的事件的步骤，第二客户端发送时间允许未加密的事件在与解密密钥被至少两台客户端接收的时间大致相同的时间被第二客户端接收。
47.受信任的边缘服务器是始发服务器和连接的客户端之间的通信路径中的可以被信任不在合适的时间之前发布信息的一台服务器，受信任的边缘服务器包括：
用于在发布时间之前向第一客户端发送加密事件的装置，其特征在于，事件包括计划在发布时间发布的信息；以及
用于在发布时间之后向第一客户端发送解密密钥的装置。
48.根据权利要求41所述的受信任的边缘服务器，其特征在于，发送解密密钥的操作在第一客户端已经接收完加密事件之后发生。
49.根据权利要求47所述的受信任的边缘服务器，进一步包括：
用于对加密事件进行解密的装置；以及
用于在第二客户端发送时间向第二客户端发送解密事件的装置，第二客户端发送时间允许解密事件在与解密密钥被第一客户端接收的大致相同的时间被第二客户端接收。
50.根据权利要求49所述的受信任的边缘服务器，其特征在于，第二客户端发送时间是由对受信任的边缘服务器和第二客户端之间的连接历史的引用确定的。
51.根据权利要求49所述的受信任的边缘服务器，其特征在于，第二客户端发送时间是由对网络功能测试受信任的边缘服务器和第二客户端之间的第二客户端延迟的结果的引用确定的。
52.根据权利要求47所述的受信任的边缘服务器，进一步包括：
用于在第二客户端发送时间向第二客户端发送未加密的事件的装置，第二客户端发送时间允许未加密的事件在与解密密钥被第一客户端接收的大致相同的时间被第二客户端接收。
CNB031206158A 2002-03-15 2003-03-14 用于未来的多播传送的时间窗口受约束的多播 Expired - Fee Related CN1282102C (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/099,242 2002-03-15
US10/099,242 US20030188188A1 (en) 2002-03-15 2002-03-15 Time-window-constrained multicast for future delivery multicast

Publications (2)

Publication Number Publication Date
CN1448858A CN1448858A (zh) 2003-10-15
CN1282102C true CN1282102C (zh) 2006-10-25

Family

ID=27765443

Family Applications (1)

Application Number Title Priority Date Filing Date
CNB031206158A Expired - Fee Related CN1282102C (zh) 2002-03-15 2003-03-14 用于未来的多播传送的时间窗口受约束的多播

Country Status (13)

Country Link
US (1) US20030188188A1 (zh)
EP (1) EP1345352B1 (zh)
JP (1) JP2003330897A (zh)
KR (1) KR20030074484A (zh)
CN (1) CN1282102C (zh)
AT (1) ATE352142T1 (zh)
AU (1) AU2003200971A1 (zh)
BR (1) BR0303007A (zh)
CA (1) CA2422153A1 (zh)
DE (1) DE60311163T2 (zh)
HK (1) HK1055864A1 (zh)
MX (1) MXPA03002286A (zh)
RU (1) RU2305863C2 (zh)

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7730300B2 (en) 1999-03-30 2010-06-01 Sony Corporation Method and apparatus for protecting the transfer of data
US7010685B1 (en) 1999-11-09 2006-03-07 Sony Corporation Method and apparatus for storing scrambled digital programs by filtering product identifier
US7039614B1 (en) 1999-11-09 2006-05-02 Sony Corporation Method for simulcrypting scrambled data to a plurality of conditional access devices
US7747853B2 (en) 2001-06-06 2010-06-29 Sony Corporation IP delivery of secure digital content
AU2003275114A1 (en) * 2002-09-23 2004-04-08 Pegasus Communications Corporation System, method and software application for secure communication
US7724907B2 (en) 2002-11-05 2010-05-25 Sony Corporation Mechanism for protecting the transfer of digital content
US8572408B2 (en) 2002-11-05 2013-10-29 Sony Corporation Digital rights management of a digital device
US8645988B2 (en) 2002-12-13 2014-02-04 Sony Corporation Content personalization for digital content
US8667525B2 (en) 2002-12-13 2014-03-04 Sony Corporation Targeted advertisement selection from a digital stream
US7529247B2 (en) * 2003-09-17 2009-05-05 Rivulet Communications, Inc. Empirical scheduling of network packets
US7468948B2 (en) * 2003-09-17 2008-12-23 Steven A Rogers Empirical scheduling of network packets using coarse and fine testing periods
US7339923B2 (en) * 2003-10-31 2008-03-04 Rivulet Communications, Inc. Endpoint packet scheduling system
US20050114465A1 (en) * 2003-11-20 2005-05-26 International Business Machines Corporation Apparatus and method to control access to logical volumes using one or more copy services
US7508813B2 (en) * 2003-11-25 2009-03-24 Rivulet Communications Local area network contention avoidance
US7373502B2 (en) * 2004-01-12 2008-05-13 Cisco Technology, Inc. Avoiding server storage of client state
US7453885B2 (en) * 2004-10-13 2008-11-18 Rivulet Communications, Inc. Network connection device
ATE453269T1 (de) * 2005-01-18 2010-01-15 Koninkl Philips Electronics Nv Verfahren und vorrichtung zum durchsetzen der sendezeitquote in wartungsintervallen in drahtlosen lokalen netzwerken
US7840489B2 (en) 2005-07-01 2010-11-23 Sony Corporation Key sharing for DRM interoperability
US20070071026A1 (en) * 2005-09-23 2007-03-29 Rivulet Communications, Inc. Compressed video packet scheduling system
UA94064C2 (ru) * 2005-10-06 2011-04-11 Вердженс Энтертейнмент Ллк, Калифорния Лимитед Лайбилити Компани Подлинно одновременные оповещения и их использование в прерывистых конкурсах
US8531953B2 (en) * 2006-02-21 2013-09-10 Barclays Capital Inc. System and method for network traffic splitting
US8515079B1 (en) * 2007-01-26 2013-08-20 Cisco Technology, Inc. Hybrid rekey distribution in a virtual private network environment
JP2008263568A (ja) * 2007-04-10 2008-10-30 Takeshi Nakadokoro 時刻認証方法
GB2457253B (en) * 2008-02-07 2010-08-11 Ericsson Telefon Ab L M Controlling media distribution
EP2225848B1 (en) * 2008-03-10 2012-08-15 NDS Limited Key distribution system
CN101651635B (zh) * 2008-08-15 2011-09-28 段卫东 网络环境中以相识对象为线索发布信息的方法和装置
US8655326B2 (en) * 2009-08-13 2014-02-18 Verizon Patent And Licensing Inc. Wireless handset connectivity time optimization
US8806190B1 (en) 2010-04-19 2014-08-12 Amaani Munshi Method of transmission of encrypted documents from an email application
US8824687B2 (en) * 2011-05-04 2014-09-02 Acquire Media Ventures, Inc. Method and system for pacing, acking, timing, and handicapping (path) for simultaneous receipt of documents employing encryption
CN102387140B (zh) * 2011-10-18 2015-01-21 华为技术有限公司 无线局域网络中开展多媒体业务的方法、装置及系统
US8880030B2 (en) * 2012-03-12 2014-11-04 International Business Machines Corporation Serving time critical information to mobile devices
US9590959B2 (en) 2013-02-12 2017-03-07 Amazon Technologies, Inc. Data security service
US10084818B1 (en) 2012-06-07 2018-09-25 Amazon Technologies, Inc. Flexibly configurable data modification services
US9286491B2 (en) 2012-06-07 2016-03-15 Amazon Technologies, Inc. Virtual service provider zones
US10075471B2 (en) 2012-06-07 2018-09-11 Amazon Technologies, Inc. Data loss prevention techniques
US10210341B2 (en) * 2013-02-12 2019-02-19 Amazon Technologies, Inc. Delayed data access
US9300464B1 (en) 2013-02-12 2016-03-29 Amazon Technologies, Inc. Probabilistic key rotation
US9705674B2 (en) 2013-02-12 2017-07-11 Amazon Technologies, Inc. Federated key management
US9608813B1 (en) 2013-06-13 2017-03-28 Amazon Technologies, Inc. Key rotation techniques
US10467422B1 (en) 2013-02-12 2019-11-05 Amazon Technologies, Inc. Automatic key rotation
US9367697B1 (en) 2013-02-12 2016-06-14 Amazon Technologies, Inc. Data security with a security module
US10211977B1 (en) 2013-02-12 2019-02-19 Amazon Technologies, Inc. Secure management of information using a security module
US9547771B2 (en) 2013-02-12 2017-01-17 Amazon Technologies, Inc. Policy enforcement with associated data
US11341572B2 (en) 2013-11-08 2022-05-24 Refinitiv Us Organization Llc Fair credit screened market data distribution
US9571473B2 (en) * 2014-04-14 2017-02-14 Synopsys, Inc. Early content engine receiver synchronization
US9397835B1 (en) 2014-05-21 2016-07-19 Amazon Technologies, Inc. Web of trust management in a distributed system
US9438421B1 (en) 2014-06-27 2016-09-06 Amazon Technologies, Inc. Supporting a fixed transaction rate with a variably-backed logical cryptographic key
US9866392B1 (en) 2014-09-15 2018-01-09 Amazon Technologies, Inc. Distributed system web of trust provisioning
US10469477B2 (en) 2015-03-31 2019-11-05 Amazon Technologies, Inc. Key export techniques
CN105610933B (zh) * 2015-12-25 2019-03-05 北京奇虎科技有限公司 信息管理方法和设备
WO2017177449A1 (en) * 2016-04-15 2017-10-19 Qualcomm Incorporated Techniques for managing secure content transmissions in a content delivery network
US10182387B2 (en) * 2016-06-01 2019-01-15 At&T Intellectual Property I, L.P. Method and apparatus for distributing content via diverse networks
CN106791935A (zh) * 2016-12-23 2017-05-31 中山大学 一种网络视频首播方法及系统
JP6408180B1 (ja) * 2018-03-20 2018-10-17 ヤフー株式会社 端末制御プログラム、端末装置および端末制御方法
US20220104010A1 (en) * 2020-09-29 2022-03-31 Qualcomm Incorporated Synchronous content presentation
CN113591120A (zh) * 2021-08-09 2021-11-02 北京达佳互联信息技术有限公司 信息发布方法及装置、电子设备和存储介质
TW202325029A (zh) * 2021-12-13 2023-06-16 比利時商巴可公司 用於電影院內容之遞送平台

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5920701A (en) * 1995-01-19 1999-07-06 Starburst Communications Corporation Scheduling data transmission
US6223286B1 (en) * 1996-03-18 2001-04-24 Kabushiki Kaisha Toshiba Multicast message transmission device and message receiving protocol device for realizing fair message delivery time for multicast message
US5991306A (en) * 1996-08-26 1999-11-23 Microsoft Corporation Pull based, intelligent caching system and method for delivering data over a network
US6061722A (en) * 1996-12-23 2000-05-09 T E Network, Inc. Assessing network performance without interference with normal network operations
US5978381A (en) * 1997-06-06 1999-11-02 Webtv Networks, Inc. Transmitting high bandwidth network content on a low bandwidth communications channel during off peak hours
US6813358B1 (en) * 1998-11-17 2004-11-02 Telcordia Technologies, Inc. Method and system for timed-release cryptosystems
US6370688B1 (en) * 1999-05-26 2002-04-09 Enounce, Inc. Method and apparatus for server broadcast of time-converging multi-media streams
US6598067B1 (en) * 1999-07-26 2003-07-22 American Management Systems, Inc. Application server framework
US6842768B1 (en) * 2000-03-01 2005-01-11 Siemens Communications, Inc. Apparatus and method for selectable compression
US7385933B2 (en) * 2000-03-17 2008-06-10 British Telecommunications Public Limited Company Synchronised data delivery
WO2002039307A1 (en) * 2000-11-09 2002-05-16 Sri International Content based routing devices and methods
US20050021467A1 (en) * 2001-09-07 2005-01-27 Robert Franzdonk Distributed digital rights network (drn), and methods to access operate and implement the same
US7155478B2 (en) * 2001-10-03 2006-12-26 International Business Machines Corporation Selectively handling data processing requests in a computer communications network
US20030121050A1 (en) * 2002-10-01 2003-06-26 Hari Kalva System and method for scheduling interactive audiovisual presentations

Also Published As

Publication number Publication date
CN1448858A (zh) 2003-10-15
MXPA03002286A (es) 2004-10-29
HK1055864A1 (en) 2004-01-21
CA2422153A1 (en) 2003-09-15
ATE352142T1 (de) 2007-02-15
EP1345352A2 (en) 2003-09-17
DE60311163D1 (de) 2007-03-08
DE60311163T2 (de) 2007-11-08
BR0303007A (pt) 2004-09-08
US20030188188A1 (en) 2003-10-02
JP2003330897A (ja) 2003-11-21
RU2305863C2 (ru) 2007-09-10
KR20030074484A (ko) 2003-09-19
AU2003200971A1 (en) 2003-10-02
EP1345352A3 (en) 2004-10-20
EP1345352B1 (en) 2007-01-17

Similar Documents

Publication Publication Date Title
CN1282102C (zh) 用于未来的多播传送的时间窗口受约束的多播
US9071574B1 (en) Access and control system for network-enabled devices
US8671163B2 (en) Multi-output packet server with independent streams
CN100392626C (zh) 网络化设备的访问和控制系统
Burleigh et al. Licklider transmission protocol-motivation
CN102016820B (zh) 数据转发架构中的实时通信
CN102204157B (zh) 在数据转发存储中轮转加密
EP2005701B1 (en) Method and system for content distribution
US8126001B2 (en) Method and apparatus for multicasting contents between devices in networks
US9270750B1 (en) Distributed cloud computing platform and content delivery network
CN107135266B (zh) Http代理框架安全数据传输方法
CN104009938A (zh) 基于路由层面的长连接的方法和系统
WO2014201931A1 (zh) 资源处理方法和站点服务器
US7693998B2 (en) System and method for message-based scalable data transport
US20100185586A1 (en) Message-based scalable data transport protocol
CN110166577A (zh) 分布式应用群组会话处理系统及方法
KR20110059658A (ko) 데이터 전달 저장에서의 분해/재조립 방법
ZA200708102B (en) Method of implementing a state tracking mechanism in a communications session between a server and a client system
CN116436864B (zh) 一种基于quic协议的部分可靠多路径传输方法
KR101997996B1 (ko) Sdn 콘트롤러에서 키 관리 서버를 이용한 보안 통신 방법 및 이를 수행하는 장치
Jungmaier et al. RFC3436: Transport Layer Security over Stream Control Transmission Protocol
CN112995230B (zh) 加密数据处理方法、装置和系统
JP3427746B2 (ja) メッセージ送受信方法

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant
C17 Cessation of patent right
CF01 Termination of patent right due to non-payment of annual fee

Granted publication date: 20061025

Termination date: 20130314