CN106411694A

CN106411694A - 用于使用xmpp将内容广播到接收方装置的系统和方法

Info

Publication number: CN106411694A
Application number: CN201610642808.9A
Authority: CN
Inventors: 黄耀辉
Original assignee: Ever Rising Information Systems Ltd
Current assignee: Ever Rising Information Systems Ltd
Priority date: 2015-10-19
Filing date: 2016-08-08
Publication date: 2017-02-15
Anticipated expiration: 2036-08-08
Also published as: US9559995B1; HK1221602A2; HK1224512A2; CN106411694B; SG10201606282QA

Abstract

本发明揭示一种用于将一或多个内容广播到接收方装置的系统和方法。所述系统包括由发送方装置经由网络浏览器接入的网络服务器、内容储存库、由接收方装置接入的OJC服务器和XMPP服务器、XMPP客户端。所述网络服务器经由所述网络浏览器接收来自所述发送方装置的广播请求，其中所述广播请求包括待广播到所述XMPP客户端的内容。所述网络服务器将所述内容存储在所述内容储存库中。所述OJC服务器经由所述XMPP服务器检测从所述XMPP客户端接收的连接请求。所述连接请求经接收以启动所述内容到所述XMPP客户端的广播。所述OJC服务器基于所述连接请求的所述接收从所述内容储存库检索所述内容，并且其后经由所述XMPP服务器将所述内容发射到所述XMPP客户端。

Description

用于使用XMPP将内容广播到接收方装置的系统和方法

相关申请案的交叉参考和优先权

本申请案主张日期为2015年10月19日的第62/243,151号美国临时专利申请案的优先权，其作为参考并入本文中。

技术领域

本文中所描述的本发明的标的物大体来说涉及一种用于使用可扩展消息接发和呈现协议(XMPP)将来自基于网络的浏览器的内容广播到接收方装置的系统和方法，且更明确地说涉及一种用于使用可扩展消息接发和呈现协议(XMPP)将来自基于网络的浏览器的即时消息实时广播到接收方装置的系统和方法。

背景技术

随着蜂窝技术的出现，全世界蜂窝订户的数目已大大增加。经由蜂窝技术支持的许多通信方式中的一者是消息接发功能性，其中蜂窝订户可经由蜂窝式通信网络中操作的蜂窝式电话共享到接收方的一或多个消息。尽管消息接发技术已有进步，但当今利用的最优选消息接发技术仍是短消息服务(SMS)技术。最近，SMS技术的使用已从人对人(P2P)消息接发改变为应用对人(A2P)消息接发。与在两个移动订户之间交换消息的P2P消息接发相比，A2P消息接发允许经由应用(例如网络应用)将消息发送到一或多个移动订户。或者，A2P消息接发还能够将消息从移动订户发送到网络应用。

通常，A2P消息接发用于发送警告、通知和营销或促销消息，例如银行警告和/或飞行警告。在一个实例中，A2P消息接发可由航空公司使用以通知乘客起飞时间和登机闸口。类似地，在另一实例中，保险公司可通知其同事参加财务研讨会。在现有技术中，称为可扩展消息接发和呈现协议(XMPP)的通信协议可用于基于XML(可扩展标记语言)的消息定向中间件。XMPP实现任何两个或两个以上网络实体之间经构造但可扩展的数据的近实时交换。然而，使用现有常规基于XMPP的技术交换数据仅基于点对点数据交换环境。

发明内容

提供此概述是为了介绍关于用于将一或多个内容广播到接收方装置的系统和方法的概念，且下文在具体实施方式中进一步描述所述概念。此概述并不意图识别所主张的标的物的基本特征，也并不意图用于确定或限制所主张的标的物的范围。

在一实施方案中，揭示一种将一或多个内容广播到接收方装置的方法。所述方法可包括由第一处理单元接收来自发送方装置的广播请求。在一实施例中，第一处理单元为网络服务器，且其中所述网络服务器经由关联到所述发送方装置的网络浏览器接收来自发送方装置的广播请求。所述广播请求包括一或多个内容以及关联到所述一或多个内容的元数据，其中所述一或多个内容将广播到接收方装置。此外，所述方法可包括由第一处理单元将所述一或多个内容以及所述元数据存储在耦合到所述第一处理单元的内容储存库中。所述方法可进一步包括由耦合到内容储存库的第二处理单元检测从接收方装置接收的连接请求，其中所述连接请求由第二处理单元经由以通信方式与接收方装置耦合的第三处理单元接收。在一实施例中，所述第二处理单元、所述第三处理单元和所述接收方装置分别为OJC(Openfire JAVA组件)服务器、XMPP服务器和XMPP客户端装置(下文称为XMPP客户端)。OJC服务器可进一步包括计算节点的集群。在一个方面中，从接收方装置接收所述连接请求以启动所述一或多个内容到所述接收方装置的广播。此外，所述方法可包括由第二处理单元基于连接请求的接收从内容储存库检索所述一或多个内容。此外，所述方法可包括由所述第二处理单元经由第三处理单元将所述一或多个内容发射到接收方装置。

在另一实施方案中，揭示一种用于将一或多个内容广播到接收方装置的系统。所述系统可包括以通信方式耦合到发送方装置的第一处理单元。所述第一处理单元可经配置以从发送方装置接收广播请求。在一实施例中，第一处理单元为网络服务器，且其中所述网络服务器经由关联到发送方装置的网络浏览器接收来自发送方装置的广播请求。广播请求包括一或多个内容以及关联到所述一或多个内容的元数据，其中所述一或多个广播内容将广播到接收方装置。所述第一处理单元可进一步经配置以将所述一或多个内容以及所述元数据存储在耦合到第一处理单元的内容储存库中。所述系统可进一步包括经由第三处理单元以通信方式与接收方装置耦合的第二处理单元。所述第二处理单元可经配置以检测从接收方装置接收的连接请求，其中所述连接请求经由第三处理单元接收。在一实施例中，第二处理单元、第三处理单元和接收方装置分别为OJC服务器、XMPP服务器和XMPP客户端装置。OJC服务器可进一步包括计算节点的集群。在一个方面中，从接收方装置接收连接请求以启动所述一或多个内容到接收方装置的广播。所述第二处理单元可进一步经配置以基于连接请求的接收从内容储存库检索所述一或多个内容。此外，所述第二处理单元可经配置以经由第三处理单元将所述一或多个内容发射到接收方装置。

附图说明

参考附图描述具体实施方式。在图中，参考标号的最左边数字识别其中所述参考标号第一次出现的图。贯穿图式使用相同数字指代相同特征及组件。

图1说明根据本发明的实施例实现一或多个内容到接收方装置的广播的系统100的网络实施方案。

图2说明基于XMPP的点对点消息接发环境的常规技术。

图3说明根据本发明的实施例用于经由集中式XMPP服务器将消息广播到多个XMPP客户端的基于集中式XMPP的广播技术。

图4说明根据本发明的实施例的流程图400，其展示用于发送方装置的用户(即网络用户)向网络服务器注册的工作流程。

图5说明根据本发明的实施例的流程图500，其展示用于接收方装置(即，XMPP客户端装置)的用户(App用户)向XMPP服务器注册的工作流程。

图6为根据本发明的实施例的流程图600，其展示用于由App用户订阅属于网络用户的频道的工作流程。

图7说明根据本发明的实施例的流程图700，其描绘关于OJC服务器与XMPP客户端装置之间的通信的步骤。

图8为说明根据本发明的实施例OJC服务器的经集群节点/组件/机器之间任务的分布的图。

图9说明根据本发明的实施例的流程图900，其描绘关于OJC服务器和XMPP服务器的外部组件/节点/机器之间的通信的步骤。

图10到图14说明根据本发明的实施例关联到OJC服务器与XMPP客户端装置之间传送的各种数据包的数据包结构。

图15说明根据本发明的实施例用于将一或多个内容广播到接收方装置的方法1500。

具体实施方式

贯穿本说明书提及的“各种实施例”、“一些实施例”、“一个实施例”或“一实施例”意味着结合所述实施例所描述的特定特征、结构或特性被包含在至少一个实施例中。因此，贯穿本说明书各处出现的短语“在各种实施例中”、“在一些实施例中”、“在一个实施例中”或“在一实施例中”未必全部是指同一个实施例。此外，在一或多个实施例中，特定特征、结构或特性可以任何合适的方式组合。

本发明描述用于将一或多个内容广播到接收方装置的系统和方法。更确切地说，本发明描述用以使用XMPP将几乎即时的消息从基于网络的浏览器广播到基于智能电话的应用或App的系统和方法。根据本发明的各方面，所述系统可包含发送方装置(属于期望发送消息的网络用户)、基于网络的浏览器、网络服务器、内容储存库、任务调度装置(中间件应用/装置)、XMPP服务器、OJC(Openfire JAVA组件)服务器和接收方装置(属于期望接收消息的App用户)。必须理解，OJC服务器是由用于Openfire的JAVA(编程语言)编写的OpenfireJAVA组件。OJC服务器包括经配置以与XMPP服务器通信的外部组件(下文可互换地被称作计算节点)的集群。XMPP服务器进一步与接收方装置通信，所述接收方装置是XMPP客户端装置或驻留在XMPP客户端装置上的应用(App)。

在一个方面中，发送方装置的用户(下文也称为网络用户)可经由基于网络的浏览器将广播请求发射到网络服务器。所述基于网络的浏览器可提供用于网络用户的接口以存储来自网络用户的广播请求。所述广播请求可包含消息接发内容、接收方装置(下文也称为App)和用于消息的递送的调度时间。广播请求可存储在内容储存库中且由任务调度装置进一步处理。在一个实施例中，任务调度装置可经由通知消息通知App接入XMPP服务器且借此检索由网络用户发送的既定消息。在另一实施例中，无关于来自任务调度装置的通知，所述App可触发一事件以自动登录XMPP服务器且借此检索所述消息。在此实施例中，一旦App用户解锁屏幕或Wi-Fi已连接或App开始，所述App就可登录到XMPP服务器以便作为后台服务从XMPP服务器提取所述消息。在一实施例中，XMPP客户端可使用基于用户名、上一次消息接发ID和上一次当前登录时戳的部分字符串动态地产生的验证口令登录XMPP服务器。

在一个方面中，经由OJC服务器检索和传递所述消息。OJC服务器可检测来自XMPP客户端的任何新的连接请求，其中所述连接请求指示XMPP客户端打算检索存储在内容储存库中的对应于所述XMPP客户端的向OJC服务器启动连接请求的消息。OJC服务器可经配置以从内容储存库检索对应消息并且其后将对应消息传递到相应XMPP客户端。OJC由外部组件(计算节点或计算机器)的集群形成，所述外部组件使用OJC负载均衡技术共同地执行对应于耦合到XMPP服务器的多个XMPP客户端的消息的检索和传递的分布式任务。在一实施例中，到App的消息到达时间可用内容储存库记录。

消息的检索完成之后，XMPP客户端可在由XMPP服务器监视和控制的闲置时间周期之后被踢出。XMPP客户端的踢出确保XMPP客户端不会由于XMPP客户端的用户的企业工作环境而一直连接。此外，一旦App的用户读取和/或答复所述消息，所述App就可登录到XMPP服务器且促进更新内容储存库-关于经由OJC服务器进行的消息的读取和/或答复的时戳。最后，网络用户可刷新基于网络的浏览器中的网页以便从内容储存库检索最新递送结果。

虽然用于将一或多个内容广播到接收方装置的所描述的系统和方法的方面可在任何数目的不同计算系统、环境和/或配置中实施，但在以下示范性系统的上下文中描述所述实施例。

现参看图1，说明根据本发明的实施例的用于将一或多个内容广播到接收方装置的系统100的网络实施方案。如图1中所展示，系统100可包括经由网络浏览器104以通信方式耦合到第一处理单元106的发送方装置102。发送方装置102的实例可包含(但不限于)移动装置、个人数字助理(PDA)、移动计算装置、通信装置、电话、移动电话、蜂窝式电话、智能电话、手持机、单向寻呼机、双向寻呼机、消息接发装置、计算机、个人计算机(PC)、台式计算机、工作站、膝上型计算机、笔记本计算机、平板计算机、手持型计算机、迷你计算机、网络设备、网站设备等等。在一个实施例中，耦合到发送方装置102的第一处理单元106为网络服务器。下文中，第一处理单元106将被称作网络服务器106。网络服务器106可进一步耦合到经配置以存储多个内容的内容储存库108。内容储存库108可进一步由如图1中所展示的第二处理单元110和任务调度装置114接入。在一个实施例中，第二处理单元110为OJC(OpenfireJAVA组件)服务器。下文中，第二处理单元110将被称作OJC(Openfire JAVA组件)服务器110。OJC服务器110进一步耦合到第三处理单元112，如所示。

在一个实施例中，第三处理单元112为可扩展消息接发和呈现协议(XMPP)服务器。下文中，第三处理单元112将被称作XMPP服务器112。XMPP服务器112可进一步由接收方装置116或驻留在接收方装置116上的应用接入。在一个实施例中，接收方装置116中的每一者可为XMPP客户端装置。下文中，接收方装置116中的每一者将被称作XMPP客户端装置116。XMPP客户端装置116的实例可包含(但不限于)移动装置、个人数字助理(PDA)、移动计算装置、通信装置、电话、移动电话、蜂窝式电话、智能电话、手持机、单向寻呼机、双向寻呼机、消息接发装置、计算机、个人计算机(PC)、台式计算机、工作站、膝上型计算机、笔记本计算机、平板计算机、手持型计算机、迷你计算机、网络设备、网站设备等等。

包含发送方装置102、网络服务器106、OJC服务器110、XMPP服务器112、任务调度装置114和XMPP客户端装置116的前述计算装置可包含至少一个处理器、输入/输出(I/O)接口和存储器(图1中未图示)。所述至少一个处理器可实施为一或多个微处理器、微计算机、微控制器、数字信号处理器、中央处理单元、状态机、逻辑电路和/或基于操作指令操纵信号的任何装置。所述至少一个处理器还经配置(以及其它能力)以提取并执行存储在存储器中的计算机可读指令。

I/O接口可包含多种软件和硬件接口，例如网络接口、图形用户接口等等。I/O接口可允许与其它计算装置和终端用户交互。I/O接口可促进多种网络和协议类型内的多个通信，所述多种网络和协议类型包含例如LAN、线缆等有线网络和例如WLAN、蜂窝式或卫星等无线网络。I/O接口可包含用于将若干装置连接到彼此的一或多个端口。

存储器可包含此项技术中已知任何计算机可读媒体，包含例如：易失性存储器，例如静态随机存取存储器(SRAM)和动态随机存取存储器(DRAM)；和/或非易失性存储器，例如只读存储器(ROM)、可擦除可编程ROM、快闪存储器、硬盘、光盘以及磁带。存储器可包含模块和数据。所述模块包含例程、程序、对象、组件、数据结构等，其执行特定任务或实施特定抽象数据类型。所述数据，在各种用途中，可以充当储存库以用于存储由模块中的一或多者处理、接收以及产生的数据。

前述计算装置可支持根据所描述的实施例的一或多种类型的网络上的通信。举例来说，一些计算装置和网络可支持广域网(WAN)、因特网、电话网(例如模拟、数字、POTS、PSTN、ISDN、xDSL)、移动电话网络(例如CDMA、GSM、NDAC、TDMA、E-TDMA、NAMPS、WCDMA、CDMA-2000、UMTS、3G、4G)、无线电网络、电视机网络、线缆网络、光网络(例如PON)、卫星网络(例如、VSAT)、包交换网络、电路交换网络、公用网络、私用网络和/或经配置以携载数据的其它有线或无线通信网络上的通信。计算装置和网络还可支持包含因特网接入的无线广域网(WWAN)通信服务，例如EV-DO、EV-DV、CDMA/1×RTT、GSM/GPRS、EDGE、HSDPA、HSUPA等。

前述计算装置和网络可根据电气电子工程师学会(IEEE)标准、协议和例如IEEE802.11(“WiFi”)、IEEE 802.16(“WiMAX”)、IEEE 802.20x(“移动-Fi”)等变型支持无线局域网(WLAN)和/或无线城域网(WMAN)数据通信功能性。计算装置和网络还可支持例如无线个域网(WPAN)通信、数据通信、红外(IR)通信、近场通信、电磁感应(EMI)通信、无源或有源RFID通信、微脉冲雷达(MIR)、超宽带(UWB)通信、自动识别和数据俘获(AIDC)通信等短程通信。

前述计算装置共同地实现将所述一或多个内容从发送方装置102(下文中可互换地称作发送方装置102或网络用户102)广播到XMPP客户端装置116(下文中可互换地称作XMPP客户端装置116或XMPP客户端App 116或App用户116)。所述一或多个内容可属于网络用户102，其中所述一或多个内容将广播到App用户116。在一些实施例中，所述一或多个内容可包括文本消息、音频消息、视频消息、多媒体消息、图像及其组合中的至少一者。在一个实例中，本文的所述一或多个内容可包含待由网络用户102使用可扩展消息接发和呈现协议(XMPP)广播到App用户116的大量消息。大体来说，XMPP实现两个或两个以上网络实体(即XMPP客户端)之间经构造但可扩展的数据的近实时交换。图2说明实现使用XMPP的内容的点对点交换的常规/传统技术。如所示，XMPP服务器实现XMPP装置之间数据的传递。因此，在现有情境中，发送方装置和接收方装置两者必须为XMPP客户端装置以便实现经由XMPP服务器在两个装置之间数据的传递，如图2中所展示。

与前述常规/传统技术相比，当前系统100实现经由非XMPP组件(也就是OJC组件(即图1中展示的OJC服务器110))将数据传递到XMPP客户端装置。图3说明根据本发明的实施例经由集中式XMPP服务器112将消息广播到多个XMPP客户端装置116的基于集中式XMPP的广播技术。如图3中所展示，待广播的消息来源于网络门户302，其经由网络浏览器104接收来自发送方装置102的消息。所述消息随后经由非XMPP组件(即OJC服务器110)经由XMPP服务器112传递到XMPP客户端装置116。下文中参看图1和图4到图15阐述使用基于集中式XMPP的广播技术(如图3中所说明)将内容广播到XMPP客户端装置116的详细描述，如下。

参看图1，为了实现由网络用户将内容传递到App用户，网络用户必须初始地向网络服务器106注册发送方装置102(属于网络用户)。本文的网络用户指代团体、组织或人的群组。网络用户可经由图1中展示的网络浏览器104注册发送方装置102。

参看图4，说明用于网络用户的注册的工作流程400。如图4中所展示，在框402处，开始注册过程。在框404处，提示网络用户注册对应于网络服务器106上的发送方装置102的账号。在框406处，提示网络用户输入用户名。在框408处，检验网络用户提供的用户名是否已经存在于系统中。如果在框408处确定所述用户名存在于系统中，那么在框406处提示网络用户输入新的用户名。如果在框408处确定由网络用户提供的用户名并不存在于系统中，那么在框410处进一步提示网络用户输入口令。在框412处，检查由网络用户提供的口令的格式。如果所提供的口令的格式正确，那么在框414处使网络用户能够输入电子邮件地址。如果口令的格式不正确，那么可提示网络用户再输入口令直至获得具有正确格式的口令为止。在框416处，检查由网络用户提供的电子邮件地址以确定是否相同电子邮件地址由其他网络用户使用。如果确定电子邮件地址由其他网络用户使用，那么提示所述网络用户再输入对于所述网络用户来说是唯一的电子邮件地址。如果确定电子邮件地址并不由任何其他网络用户使用，那么在框418处，通过在所提供的电子邮件地址上将检验电子邮件发送到网络用户来检验网络用户的电子邮件地址。如果未成功地检验所述电子邮件地址，那么在框420处，将检验电子邮件重新发送到网络用户且相应地成功地检验网络用户的电子邮件地址。基于在框418处电子邮件地址的成功验证，在框422处向网络服务器106成功地注册网络用户以及关联到网络用户的发送方装置102借此终止注册工作流程400。

类似地，为了实现由App用户从网络用户接收内容，App用户必须初始地向XMPP服务器112注册XMPP客户端装置116(属于App用户)或驻留在所述XMPP客户端装置上的XMPPApp。

参看图5，说明用于App用户的注册的工作流程500。如图5中所展示，在框502处，开始注册过程。在框504处，提示App用户注册对应于XMPP服务器112上的XMPP客户端装置116的账号。在框506处，提示App用户选择用于注册XMPP客户端装置116和/或XMPP客户端装置116上的XMPP App的注册方法。在框508处，使App用户能够基于框506处注册方法(即电子邮件注册方法或电话注册方法)的选择提供电子邮件地址或电话号码。在框510处，检查所提供的电子邮件地址或电话号码的格式。如果电子邮件地址或电话号码的格式正确，那么在框512处，使App用户能够输入所述电子邮件地址处或电话号码上发送的检验码。如果电子邮件地址或电话号码的格式不正确，那么可提示App用户重新输入电子邮件地址或电话号码直至提供正确格式的电子邮件地址或电话号码为止。在框514处，检查由App用户提供的检验码。如果确定App用户提供的检验码不正确，那么可提示App用户重新输入正确的检验码。如果在框514处确定App用户提供的检验码正确，那么在框516处检查是否XMPP服务器112上已经存在对应于App用户的账号。如果已经存在对应于App用户的账号，那么在框518处，可提示App用户确认现有账号的使用。如果App用户确认使用现有账号，那么在框520处，将关于App用户的现有账号的账号数据恢复到App用户的XMPP客户端装置116。基于框520处账号数据的成功恢复或框516处现有账号的不可用性的确定，在框522处向XMPP服务器112成功地注册App用户以及XMPP客户端装置116和/或XMPP客户端装置116上的XMPP App借此终止注册工作流程500。

现再次参看图1，基于网络用户102向网络服务器106的成功注册，网络用户102可经由网络浏览器104向网络服务器106提交广播请求。确切地说，网络用户可经由网络浏览器104登录到网络服务器106。在一实施例中，广播请求可包括一或多个内容以及关联到所述一或多个内容的元数据。所述一或多个内容将经由属于网络用户102的频道广播到至少一个XMPP客户端装置116。本文中的频道指示网络用户102与所述至少一个XMPP客户端装置116之间的通信关系。所述通信关系也称为“会见”，其中所述通信关系用于将来自网络用户的内容传递到XMPP客户端装置116且反之亦然。在一方面中，所述关系为多对多关系。也就是说，属于单一网络用户的单一频道可由多个XMPP客户端装置116订阅。应注意，App用户116可基于向XMPP服务器114成功注册而向网络用户102提交订阅请求以便订阅关联到网络用户102的频道。网络用户102可批准来自App用户116的所述订阅请求。图6说明流程图600，其描绘用于由关联到XMPP客户端装置116的用户(即App用户)订阅频道的工作流程，其中所订阅的所述频道属于关联到发送方装置102的用户(即网络用户)。

如图6中所展示，在框602处，开始用于频道的订阅的过程。在框604处，App用户可订阅网络用户的频道。在框606处，可提示App用户输入对应于正由App用户订阅的频道的频道识别符(ID)。在框608处，检查是否存在对应于频道ID的频道。如果在框608处确定不存在对应于频道ID的频道，那么提示App用户重新输入关于存在的有效频道的频道ID。如果在框608处确定存在对应于频道ID的频道且其为有效频道，那么在框610处，检验App用户是否已经订阅所述频道。如果App用户已经订阅所述频道，那么提示App用户输入对应于所订阅的频道的频道ID且借此网络用户和App用户经由所订阅的频道连接以便实现网络用户与App用户之间数据的传递。然而，如果在框610处确定App用户尚未订阅所述频道，那么在框612处使App用户能够将频道订阅请求发射到网络用户以便订阅和/或确认属于所述网络用户的频道。在框614处，基于频道的确认，可提示App用户提供额外留言以便检验App用户。在一个实例中，可提示App用户输入App用户的姓名或识别App的识别符或先前由网络用户提供到App用户的个人识别号(PIN)。在框616处，网络用户可批准频道订阅请求。在框618处，检查网络用户是否已经批准来自App用户的频道订阅请求。如果在框618处确定网络用户尚未批准频道订阅请求，那么迭代地执行前述频道订阅的过程(框604-618)直至网络用户批准App用户的频道订阅请求为止。如果在框618处确定网络用户已经批准频道订阅请求，那么频道订阅在框620处成功，借此终止用于频道订阅的工作流程600。

必须理解，每一网络用户102具有用于广播属于相应网络用户的内容的单独和/或唯一频道。此外，每一App用户必须订阅相应网络用户的相应频道以便在App用户与网络用户之间建立用于广播所述内容的通信关系。在一个方面中，本文中的内容可指代关于由主要是企业和/或商业组织的网络用户提供的各种产品/解决方案的广告和营销/促销消息。

如上文所描述，网络服务器106可接收包括所述一或多个内容和关联到所述一或多个内容的元数据的广播请求。在一个实例中，所述一或多个内容指示待广播到XMPP客户端装置116的消息。此外，所述元数据可包括关于XMPP客户端装置116(和借此识别的App用户身份)的识别符和用于启动消息到App用户的传递的调度时间。应注意，网络用户通过从发送方装置102的地址簿存储器选择App用户，输入待广播到所选择的App用户的内容/消息且设定用于内容/消息的广播的调度时间来产生广播请求。所述广播请求可存储在与如图1中所展示的网络服务器106耦合的内容储存库108中。在一个实施例中，内容储存库108是含有存储数据(即内容和关于所述内容的元数据)的不同数据表的数据库。

现再次参看图1，任务调度装置114可经配置以按照内容/消息的广播请求中设定的调度时间触发存储在内容储存库108中的内容/消息到XMPP客户端装置116的广播。任务调度装置114为经配置以基于内容储存库108中内容/消息的发射/接收的状态更新内容储存库108的中间件装置和/或应用。在一实施例中，任务调度装置114可通知XMPP客户端装置116触发从XMPP客户端装置116到XMPP服务器112的连接请求以用于内容/消息的检索。确切地说，任务调度装置114可在XMPP客户端装置(或XMPPApp)上将通知消息发送到App用户，其中所述通知消息指示App用户登录XMPP服务器112且检索经调度用于广播到App用户的消息/内容。经由下文中详细阐述的OJC服务器110与XMPP客户端装置116之间建立的连接启用内容/消息的传递。

OJC服务器110可经配置以管理从内容储存库108检索内容/消息，且经由XMPP服务器112将内容/消息传递到XMPP客户端装置116。OJC服务器110可经配置以经由XMPP服务器112从XMPP客户端装置116中的至少一者接收连接请求。OJC服务器110包含共同地执行从内容储存库108检索内容和将内容传递到XMPP客户端装置116的任务的计算节点(或外部组件/机器)的集群。OJC服务器110可包括‘N’数目个计算节点，其中N>1。所述组件中的每一者具有对等组件或节点之间的相同配置和数据库会话。集群设计经由服务器之间的负载均衡算法实现均衡连接，且提供故障接管支持。如下详细阐述由计算节点的集群执行的负载均衡算法。

计算节点的集群包括第一节点(下文中被称作主节点)和多个从节点(下文中被称作工作节点)。第一节点或主节点适于将任务指派到每一工作节点以检索和传递对应于XMPP客户端装置116中的至少一者的内容/消息。任务到工作节点的指派是基于负载均衡算法。如上文所描述，主节点管理工作节点且因此并不负责执行内容检索及其到XMPP客户端装置116中的一者的传递的任务。在主节点失效或不在执行的情境中，将工作节点中的一者指定为管理其它工作节点的主节点。所述主节点可经配置以提取以表呈现的内容储存库108中的内容/消息，其被称作“批次”，具有状态＝“NEW_ENTRY”。必须理解，每一批次包含由网络用户发送到App用户的大量消息。因此，每一批次中的总接收方不同于其它批次。

主节点可将总接收方分类为三个不同批次，即小样本、中等样本和大样本。在一个示范性实施例中，小样本可包含1-50个接收方，中等样本可包含51-500个接收方，且大样本可包含超过500个接收方。主节点接着可将这些小、中等和大样本指派到工作节点以供执行。在一个实施例中，总接收方的分类为小样本、中等样本和大样本的类别的接收方百分比分别大致为75％、20％和5％。图8为说明根据本发明的实施例的OJC服务器110的经集群节点/组件之间任务的分布的框图。应注意，工作节点适于优先处理关于分类为小样本的接收方的内容/消息，但中等样本和大样本在队列中等待处理。这是因为，从网络用户使用体验的观点来看，小样本的处理可以较少时间完成且更容易被通知具有延迟。在一个极端情境中，可指派100％的工作节点来处置小样本。专门工作节点可经配置以处置具有大样本的罕见的情境。用于大样本的专门工作节点分配使专门工作节点能够仅处置/处理此特定批次的大样本，因此避免节点之间不必要的上下文切换。主节点可分配剩余工作节点来处置中等样本。应注意，一旦批次的处理完成，所述批次的状态就更新为“COMPLETED”，且所述批次将不再次处理。一旦工作节点完成所指派的任务，所述工作节点就向主节点更新完成状态且等待主节点进一步分配后续任务。

分配到工作节点中的每一者的任务是：由OJC服务器110从所述至少一个XMPP客户端装置116接收连接请求之后的内容/消息到所述至少一个XMPP客户端装置116的检索和传递。由工作节点代表OJC服务器110进行的前述任务的执行经由OJC服务器110与XMPP客户端装置116之间建立的通信来促进。图7为描绘关于OJC服务器110与所述至少一个XMPP客户端装置116之间的通信的步骤的流程图700。

如图7中所展示，在框702处，开始用于促进OJC服务器110与XMPP客户端装置116之间的通信的过程。在框704处，OJC服务器110可收听来自XMPP客户端装置116的连接请求。在框706处，OJC服务器110可检查是否消息从网络用户发送到App用户。如果在框706处确定消息从网络用户发送到App用户，那么在框708处，OJC服务器110可从内容储存库108读取消息且将消息传递到App用户。在框710处，OJC服务器110可用关于App用户对消息的接收的时戳更新内容储存库108。在框712处，XMPP客户端装置116可保持与OJC服务器110连接。如果在框706处确定消息未从网络用户发送到App用户，那么在框714处App用户可读取或答复从网络用户接收的消息。在框716处，检验App用户是否已经读取所述消息或答复所述消息。如果在框716处确定App用户已经读取所述消息，那么在框718处，OJC服务器110可用关于App用户作出的对应于来自网络用户的所接收的消息的答复的内容更新内容储存库108。或者，在框720处，OJC服务器110可用关于正由App用户读取的消息的时戳更新内容储存库108。应注意，内容储存库中记录的时戳指示到XMPPApp或XMPP客户端装置116的消息到达时间。在用所答复内容或时戳更新内容储存库108之后，所述过程进行到框712，其中XMPP客户端装置116保持与OJC服务器110连接。在框722处，检查XMPP客户端装置是否闲置(即App用户既不读取也不答复来自网络用户的所接收的消息)持续大于一分钟的预定义时间周期。如果XMPP客户端装置并不闲置持续大于一分钟的时间周期，那么在框724处，检查是否存在从XMPP客户端装置116到OJC服务器110的任何新的连接请求用于从网络用户接收新消息。如果在框724处确定存在新连接请求，那么重复从框706的过程步骤直至不再检测到新的连接请求。如果在框724处确定不存在新的连接请求，那么过程进行到框712。如果在框722处确定XMPP客户端装置闲置持续大于一分钟的时间周期，那么在框726处将XMPP客户端装置116自动踢出使其不与OJC服务器110连接，借此终止OJC服务器110与XMPP客户端装置116之间的通信。

必须理解，OJC服务器110可经由XMPP服务器112与XMPP客户端装置116通信。主节点可针对每一工作节点指派专门通信会话，其中所述专门通信会话促进相应工作节点与XMPP服务器112之间的通信。在一个实施例中，通信会话为TCP会话。更确切地说，TCP会话实现内容/消息从工作节点到相应XMPP客户端装置116的传递。工作节点经由XMPP服务器112的通信端口(例如端口号843)与XMPP服务器112连接以便传递内容/消息。所述通信端口经配置以收听来自工作节点的传入连接请求。在一实施例中，工作节点与XMPP服务器112之间经由通信端口建立的连接是遵循由XMPP标准(即“XEP-0114：Jabber组件协议”)指定的规格的插口连接。工作节点与XMPP服务器112之间的通信的细节在下文中参看图9描述。

图9为描绘关于OJC服务器110与XMPP服务器112的节点(即工作节点/组件)之间的通信的步骤的流程图900。如图所示，在框902处，工作节点与XMPP服务器112之间的通信经由通信端口843上建立的专门TCP会话开始。在框904处，工作节点可将流发射到XMPP服务器112。在一个实施例中，工作节点发射的流的格式如下：

<stream:stream

xmlns＝'jabber:component:accept'

xmlns:stream＝'http://etherx.jabber.org/streams'

to＝'xxx.192.1.1.1'>；

其中，“xxx.192.1.1.1”指示处置由名称和服务器IP组成的组件/工作节点的XMPP服务器112的代理。

在框906处，在接收流之后，XMPP服务器112可通过将流标头发射到组件/工作节点而答复组件/工作节点。流标头可包括关于从组件/工作节点接收的流的流识别符(流ID)。在一个实施例中，由XMPP服务器112发射到组件/工作节点的流标头的格式如下：

<stream:stream

xmlns:stream＝'http://etherx.jabber.org/streams'

xmlns＝'jabber:component:accept'

from＝'xxx.192.1.1.1'

id＝'[StreamID]'>

在框908处，组件/工作节点可将握手要素以握手信号的形式发射到XMPP服务器112。在一实施例中，可至少基于与预共享机密密钥串接的流识别符(流ID)来计算握手要素的XML字符数据。在一个实施例中，包括与机密密钥串接的流ID的握手信号的格式如下：

<handshake>aaee83c26aeeafcbabeabfcbcd50df997e0a2a1e</handshake>

在框910处，检查所接收的握手要素是否正确。如果确定所接收的握手要素不正确，那么过程进行到框904。如果确定所接收的握手要素正确，那么在框912处XMPP服务器112可将对应于以上握手信号的确认信号的形式的空握手要素发射到组件/工作节点。发射确认信号以指示XMPP服务器112与所述组件/工作节点之间建立成功连接。在一个实施例中，空握手要素(即确认信号)的格式如下：

在框914处，基于确认信号的接收，组件/工作节点向XMPP服务器112的验证成功，借此在组件/工作节点与XMPP服务器112之间建立插口连接。在框916处，在建立插口连接之后，XMPP服务器112和OJC服务器110两者均就绪以经由所建立的插口连接在彼此间发送和/或接收消息/内容。

在框918处，检查OJC服务器110是否已经将解除连接信号发送到XMPP服务器112。如果在框918处确定OJC服务器110尚未发送解除连接信号，那么在框920处检验OJC服务器110与XMPP服务器112之间的连接是否由于缺乏内容/消息的传递而非活跃持续大于30秒的时间周期。如果在框920处确定所述连接非活跃持续大于30秒的时间周期，那么在框922处，OJC服务器110将心跳消息发射到XMPP服务器112以维持插口连接以便促进消息/内容从OJC服务器110到XMPP服务器112的传递且反之亦然。如果在框918处确定OJC服务器110已经发送解除连接信号，那么在框924处，终止组件/工作节点与XMPP服务器之间的插口连接。

必须理解，OJC服务器110的组件/工作节点可首先将既定针对XMPP客户端装置116的消息传递到XMPP服务器的代理，并且其后将消息重定向到XMPP客户端装置116。在一个实施例中，传递到XMPP客户端装置116的消息如下：

其中，“john.lee\40abc.com”是指定的XMPP客户端装置，且[content]是消息接发内容。类似地，如果存在对应于来自XMPP客户端装置116的消息接发内容的响应内容，那么所述响应内容由XMPP客户端装置116传递到XMPP服务器112。XMPP服务器112随后将响应内容重定向到OJC服务器110的组件/工作节点，所述OJC服务器110最终将响应内容插入在内容储存库108中。在一个实施例中，从XMPP客户端装置116传递的响应内容如下：

其中，[content]是来自XMPP客户端装置116的响应内容。

必须理解，OJC服务器110的组件/工作节点可经配置以更新对应于内容/消息的关于响应内容的接收的内容储存库，或所述内容/消息由XMPP客户端装置116或其组合存取。XMPP客户端装置116可由任务调度装置114触发以登录XMPP服务器112以便检索去往相应客户端装置116的消息/内容。或者，XMPP App经配置以在一旦发生以下情况时在不接收来自任务调度装置114的触发/通知的情况下自动登录XMPP服务器112：XMPP客户端装置116解锁或因特网连接(例如Wi-Fi或2G/3G/4G)可用或XMPP客户端装置116上的XMPPApp开启。

在一个实施例中，XMPP客户端装置116可经由使用动态口令产生技术产生的动态口令登录到XMPP服务器112。XMPP服务器113可基于动态口令以及由App用户提供的AppUsername(例如电子邮件地址、手机号等)验证XMPP客户端装置116以便接入XMPP服务器112。在一个实施例中，动态口令可针对XMPP服务器112与XMPP客户端装置116之间启动的当前登录会话而实时产生。在此实施例中，可基于以下中的至少一者产生动态口令：接收方识别符(即关联到App用户的识别符)、关联到由接收方装置检索的上一内容的内容识别符、对应于XMPP服务器112与XMPP客户端装置116之间的上一登录会话的时戳及其组合。在一个实例中，针对每一登录会话产生的口令串是基于公式(1)，如下：

口令串＝MD5[substr(AppUsername,10)+上一MessageID+上一登录时戳]........................................公式(1)

其中，

AppUsername为关于App用户的注册用户名。应注意，AppUsername为App用户注册之后产生的恒定串。

MessageID：其为对应于每一内容/消息的唯一内容/消息识别符。所述内容/消息识别符可在XMPP服务器112和XMPP客户端装置116两者处经由HTTP同步发射而同步。

登录时戳：指示每一XMPP验证期间XMPP服务器112与XMPP客户端装置116两者处记录的时戳。

应注意，以上公式(1)可每次根据App版本更新而更新/修改/改变以便增加口令串形成的复杂性。

基于由XMPP服务器112对XMPP客户端装置116的成功验证，XMPP客户端装置116可检索去往XMPP客户端装置116的内容/消息。如果XMPP客户端装置116非活跃持续预定义时间周期(例如比方说1分钟)，那么XMPP客户端装置116可由XMPP服务器112踢出。确切地说，XMPP服务器112可经编程以选择在线且已提取内容/消息持续预定时间间隔(例如两分钟)的XMPP客户端装置116，并且其后所述XMPP客户端装置116仍连接，而在预定义时间周期(例如一分钟或更长时间)内无任何活动。这些所选择的XMPP客户端装置116由XMPP服务器112踢出。非活跃XMPP客户端装置116的踢出实现系统资源的负担的减小且借此促进节省装置的电池服务寿命。

网络用户102可经配置以通过刷新发送方装置102上呈现的网页而经由网络浏览器104从内容储存库108检索最新递送报告。最新递送报告可显示递送到相应XMPP客户端装置116的内容/消息的状态。在一个方面，系统100可能够经由网络浏览器实施全载寻呼算法而发送大量消息且检索高达50000个App用户的递送结果以实现对网络用户的提示响应。全载寻呼算法进一步描述如下。

网络用户102可经配置以经由网络门户302(图3中展示)执行从内容储存库108的大量加载。举例来说，网络用户102可跨越若干个月加载高达50，000个条目(例如地址簿检索、递送结果)且执行统计分析。为了实现大量加载期间针对网络用户的提示视觉响应，系统100实施全载寻呼算法如下：

根据由系统100实施的全载寻呼算法，可首先计算待加载的总条目且将其相应地分类为包含小样本和大样本的两个类型。应注意，每一小样本含有1-500个条目，而每一大样本可含有超过500个条目。对于分类为小样本的条目，系统100可检索来自内容储存库108的数据且可针对每一条目计算小计的统计。系统100接着可将数据写入到内容储存库的数据表，内容储存库为用于jQuery javascript库的插件。因为小样本中的条目小于500，所以用于检索来自内容储存库108的数据的数据检索时间以及用以将数据写入到数据表中的处理时间对于网络用户来说并不显著。应注意，数据检索时间和处理时间共同地总共小于1秒。必须理解，当数据全载到网络浏览器104中时，网络用户102可享受浏览期间的提示视觉响应。可向网络用户瞬时显示结果的每一过滤或上下文搜索，而不需要网络用户点击经提供用以搜索条目的搜索按钮。

对于分类为大样本的条目，系统100可基于页面单位读取部分条目，其中含有页面单位中的总条目的页面大小可依据网络用户的偏好界定。在一个实例中，网络用户可针对每一页面单位设定10-50个条目的偏好范围。因此，因为每一检索可仅含有每次读取10-50个条目数据，所以网络用户仍具备提示视觉响应。应理解，针对每一浏览事件，网络用户可应用过滤或上下文搜索操作来促进从内容储存库的数据检索，且借此实现对数据表的处理。为了执行对于过滤或上下文搜索的请求，网络用户可点击搜索按钮。尽管大样本检索执行许多网络请求，但因为条目数目较小，所以对于网络服务器106不存在负担且提示视觉响应仍提供到网络用户。

应注意，经由以JavaScript对象记法(JSON)格式表示的数据包促进OJC服务器110与XMPP客户端装置116之间的前述通信。每一数据包的结构以及其JSON格式的表示进一步参看图10、图11、图12、图13和图14详细阐述如下：

参看图10，其为说明根据本发明的实施例用于将来自OJC服务器110的消息发送到XMPP客户端装置116的数据包的交换的图。如图所示，经由各种命令(作为数据包交换)促进消息的发送，所述各种命令包含HOST_SEND_MSG、HOST_SEND_HANDSET_REACH或HOST_SEND_HANDSET_REJECT(未图示)、HOST_SEND_HANDSET_REACH_ACK或HOST_SEND_HANDSET_REJECT_ACK(未图示)、HOST_SEND_CLIENT_READ和HOST_SEND_CLIENT_READ_ACK。下文中在后续段落中描述这些命令中的每一者的结构(及其实例)。

命令10：HOST_SEND_MSG(指示OJC服务器主机使用XMPP协议将消息发送到XMPP客户端App中的一者。在一个示范性实施例中，所述命令10的结构如下：

前述命令10以JSON格式传递为：{"CommandName":"10","HostPacketID":"100","AppUsername":"85297911476","ChannelID":"1","MsgDID":"20000","MsgDType":"1","MsgMContent":"Msg-1534"}

命令11：HOST_SEND_HANDSET_REACH(指示消息已到达手持机(即XMPP客户端装置)，且因此XMPP客户端app将到达接收信号传回到OJC服务器主机)。在一个示范性实施例中，所述命令11的结构如下：

前述命令11以JSON格式传递为：{"CommandName":"11","HostPacketID":"100","AppPacketID":"5","AppUsername":"85297911476","AppMsgID":"20","MsgDID":"20000"}

命令12：HOST_SEND_HANDSET_REACH_ACK(指示OJC服务器主机接收了包“HOST_SEND_HANDSET_REACH”，且因此所述OJC服务器主机将其确认传回到XMPP客户端app)。在一个示范性实施例中，所述命令12的结构如下：

结构	实例
		CommandName	12(HOST_SEND_HANDSET_REACH_ACK)
AppPacketID	5
		AppUsername	85297911476
MsgDID	20000
		HandsetReachTimestamp	1376372282

前述命令12以JSON格式传递为：{"CommandName":"12","AppPacketID":"5","AppUsername":"85297911476","MsgDID":"20000","HandsetReachTimestamp":"1376372282"}

命令13：HOST_SEND_HANDSET_REJECT(指示消息已到达手持机(即XMPP客户端装置)但所述消息已被拒绝(例如由于频道的去激活)。在一个示范性实施例中，所述命令13的结构如下：

结构	实例
		CommandName	13(HOST_SEND_HANDSET_REJECT)
HostPacketID	100
		AppPacketID	5
AppUsername	85297911476
		MsgDID	20000
RejectErrorCode	332

前述命令13以JSON格式传递为：{"CommandName":"13","HostPacketID":"100","AppPacketID":"5","AppUsername":"85297911476","MsgDID":"20000","RejectErrorCode":"332"}

命令14：HOST_SEND_HANDSET_REJECT_ACK(指示OJC服务器主机已接收包-“HOST_SEND_HANDSET_REJECT.”，因此OJC服务器将其确认发送到XMPP客户端App)。在一个示范性实施例中，所述命令14的结构如下：

前述命令14以JSON格式传递为：{"CommandName":"14","AppPacketID":"5","AppUsername":"85297911476","MsgDID":"20000","HandsetRejectTimestamp":"1376372282"}

命令15：HOST_SEND_CLIENT_READ(指示消息已由XMPP客户端装置读取，且因此XMPP客户端装置将读取接收传回到OJC服务器主机)。在一个示范性实施例中，所述命令15的结构如下：

结构	实例
		CommandName	15(HOST_SEND_CLIENT_READ)
AppPacketID	6
		AppUsername	85297911476
AppMsgID	20
		MsgDID	20000

前述命令15以JSON格式传递为：{"CommandName":"15","AppPacketID":"6","AppUsername":"85297911476","AppMsgID":"20","MsgDID":"20000"}

命令16：HOST_SEND_CLIENT_READ_ACK(指示OJC服务器主机已接收包-“HOST_SEND_CLIENT_READ.”，因此OJC服务器主机将其确认发送到XMPP客户端App)。在一个示范性实施例中，所述命令16的结构如下：

结构	实例
		CommandName	16(HOST_SEND_CLIENT_READ_ACK)
AppPacketID	6
		AppUsername	85297911476
MsgDID	20000
		HandsetReachTimestamp	1376372282加回
ClientReadTimestamp	1376372284

前述命令16以JSON格式传递为：{"CommandName":"16","AppPacketID":"6","AppUsername":"85297911476","MsgDID":"20000","ClientReadTimestamp":"1376372284"}

参看图11，其为说明根据本发明的实施例的指示从XMPP客户端装置116到OJC服务器110的答复消息的数据包的交换的图。如图所示，答复消息经由各种命令(作为数据包交换)来促进，所述各种命令包含APP_REPLY_MSG、APP_REPLY_MACHINE_REACH或APP_REPLY_MACHINE_REJECT(未图示)、APP_REPLY_MACHINE_REACH_ACK或APP_REPLY_MACHINE_REJECT_ACK(未图示)、APP_REPLY_ADMIN_READ和APP_REPLY_ADMIN_READ_ACK。下文中在后续段落中描述所述命令中的每一者的结构(及其实例)。

命令20：APP_REPLY_MSG(指示XMPP客户端App以消息向OJC服务器答复)。在一个示范性实施例中，所述命令20的结构如下：

结构名称	实例
		CommandName	20(APP_REPLY_MSG)
AppPacketID	7
		AppUsername	85297911476
MsgDID	20000
		AppMsgID	500
AppMsgType	1(文本)
		AppMsgContent	答复消息

前述命令20以JSON格式传递为：{"CommandName":"20","AppPacketID":"7","AppUsername":"85297911476","MsgDID":"20000","AppMsgID":"500","AppMsgType":"1","AppMsgContent":"replies message"}

命令21：APP_REPLY_MACHINE_REACH(指示来自XMPP客户端的消息已到达OJC服务器主机，OJC服务器主机确认消息的接收)。在一个示范性实施例中，所述命令21的结构如下：

结构	实例
		CommandName	21(APP_REPLY_MACHINE_REACH)
HostPacketID	101
		AppPacketID	7
AppUsername	85297911476
		AppMsgID	500
MsgRID	40000
		MachineReachTimestamp	1376372288

前述命令21以JSON格式传递为：{"CommandName":"21","HostPacketID":"101","AppPacketID":"7","AppUsername":"85297911476","AppMsgID":"500","MsgRID":"40000","MachineReachTimestamp":"1376372288"}

命令22：APP_REPLY_MACHINE_REACH_ACK(指示XMPP客户端App已接收包-“APP_REPLY_MACHINE_REACH”，因此XMPP客户端App将其确认传回到OJC服务器主机)。在一个示范性实施例中，所述命令22的结构如下：

结构	实例
		CommandName	22(APP_REPLY_MACHINE_REACH_ACK)
HostPacketID	101
		AppUsername	85297911476

前述命令22以JSON格式传递为：{"CommandName":"22","HostPacketID":"101","AppUsername":"85297911476"}

命令23：APP_REPLY_MACHINE_REJECT(指示答复消息已到达OJC服务器主机，但答复消息已被拒绝(例如由于会见(即通信关系)期满))。在一个示范性实施例中，所述命令23的结构如下：

结构	实例
		CommandName	23(APP_REPLY_MACHINE_REJECT)
HostPacketID	101
		AppPacketID	7
AppUsername	85297911476
		AppMsgID	500
MsgRID	40000
		MachineRejectTimestamp	1376372288
RejectErrorCode	334

前述命令23以JSON格式传递为：{"CommandName":"23","HostPacketID":"101","AppPacketID":"7","AppUsername":"85297911476","AppMsgID":"500","MsgRID":"40000","MachineRejectTimestamp":"1376372288","RejectErrorCode":"334"}

命令24：APP_REPLY_MACHINE_REJECT_ACK(指示XMPP客户端App已接收包-“APP_REPLY_MACHINE_REJECT”，且因此XMPP客户端App将其确认传回到OJC服务器主机)。在一个示范性实施例中，所述命令24的结构如下：

结构	实例
		CommandName	24(APP_REPLY_MACHINE_REJECT_ACK)
HostPacketID	101
		AppUsername	85297911476

前述命令24以JSON格式传递为：{"CommandName":"24","HostPacketID":"101","AppUsername":"85297911476"}

命令25：APP_REPLY_ADMIN_READ(指示来自XMPP客户端App的答复消息已由机器读取，且因此OJC服务器将所述答复消息的读取接收传回到XMPP客户端App)。在一个示范性实施例中，所述命令25的结构如下：

结构	实例
		CommandName	25(APP_REPLY_ADMIN_READ)
HostPacketID	102
		AppUsername	85297911476
AppMsgID	500
		MsgRID	40000
MachineReachTimestamp	1376372288
		AdminReadTimestamp	1376372290

前述命令25以JSON格式传递为：{"CommandName":"25","HostPacketID":"102","AppUsername":"85297911476","AppMsgID":"500","MsgRID":"40000","MachineReachTimestamp":"1376372288","AdminReadTimestamp":"1376372290"}

命令26：APP_REPLY_ADMIN_READ_ACK(指示XMPP客户端App已接收包-“APP_REPLY_ADMIN_READ”，且因此XMPP客户端App将其确认传回到OJC服务器主机)。在一个示范性实施例中，所述命令26的结构如下：

结构	实例
		CommandName	26(APP_REPLY_ADMIN_READ_ACK)
HostPacketID	102
		AppUsername	85297911476

前述命令26以JSON格式传递为：{"CommandName":"26","HostPacketID":"102","AppUsername":"85297911476"}

现参看图12，其为说明根据本发明的实施例的关于属于网络用户的频道的批准/拒绝/阻挡的XMPP客户端装置116与OJC服务器110之间的数据包的交换的图。如图所示，经由各种命令(作为数据包交换)促进频道批准/拒绝/阻挡，所述各种命令包含HOST_CHANNEL_APPROVE或HOST_CHANNEL_REJECT(未图示)、HOST_CHANNEL_APPROVE_ACK或HOST_CHANNEL_REJECT_ACK(未图示)、HOST_CHANNEL_BLOCK(未图示)或HOST_CHANNEL_UNBLOCK(未图示)、HOST_CHANNEL_BLOCK_ACK(未图示)或HOST_CHANNEL_UNBLOCK_ACK(未图示)、HOST_CHANNEL_CHANGE_PROFILE(未图示)和HOST_CHANNEL_CHANGE_PROFILE_ACK(未图示)。下文中在后续段落中描述所述命令中的每一者的结构(及其实例)。

命令40：HOST_CHANNEL_APPROVE(指示OJC服务器主机已批准来自XMPP客户端App的频道订阅请求)。在一个示范性实施例中，所述命令40的结构如下：

结构	实例
		CommandName	40(HOST_CHANNEL_APPROVE)
HostPacketID	110
		AppUsername	85297911476
ChannelID	1(Meteorsis)

前述命令40以JSON格式传递为：{"CommandName":"40","HostPacketID":"110","AppUsername":"85297911476","ChannelID":"1"}

命令41：HOST_CHANNEL_APPROVE_ACK(指示XMPP客户端App已从OJC服务器主机接收包-“HOST_CHANNEL_APPROVE”，且因此XMPP客户端App将其确认传回到OJC服务器主机)。在一个示范性实施例中，所述命令41的结构如下：

结构	实例
		CommandName	41(HOST_CHANNEL_APPROVE_ACK)
HostPacketID	110
		AppUsername	85297911476

前述命令41以JSON格式传递为：{"CommandName":"41","HostPacketID":"110","AppUsername":"85297911476"}

命令42：HOST_CHANNEL_REJECT(指示OJC服务器主机已拒绝来自XMPP客户端App的频道订阅请求)。在一个示范性实施例中，所述命令42的结构如下：

结构名称	实例
		CommandName	42(HOST_CHANNEL_REJECT)
HostPacketID	111
		AppUsername	85297911476
ChannelID	1(Meteorsis)

前述命令42以JSON格式传递为：{"CommandName":"42","HostPacketID":"111","AppUsername":"85297911476","ChannelID":"1"}

命令43：HOST_CHANNEL_REJECT_ACK(指示XMPP客户端App已从OJC服务器主机接收包-“HOST_CHANNEL_REJECT”，且因此XMPP客户端将确认传回到OJC服务器主机)。在一个示范性实施例中，所述命令43的结构如下：

结构	实例
		CommandName	43(HOST_CHANNEL_REJECT_ACK)
HostPacketID	111
		AppUsername	85297911476

前述命令43以JSON格式传递为：{"CommandName":"43","HostPacketID":"111","AppUsername":"85297911476"}

命令44：HOST_CHANNEL_BLOCK(指示OJC服务器主机已阻挡XMPP客户端App订阅的当前频道)。在一个示范性实施例中，所述命令44的结构如下：

结构名称	实例
		CommandName	44(HOST_CHANNEL_BLOCK)
HostPacketID	112
		AppUsername	85297911476
ChannelID	1(Meteorsis)

前述命令44以JSON格式传递为：{"CommandName":"44","HostPacketID":"112","AppUsername":"85297911476","ChannelID":"1"}

命令45：HOST_CHANNEL_BLOCK_ACK(指示XMPP客户端App已从OJC服务器主机接收包-“HOST_CHANNEL_BLOCK”)。在一个示范性实施例中，所述命令45的结构如下：

结构	实例
		CommandName	45(HOST_CHANNEL_BLOCK_ACK)
HostPacketID	112
		AppUsername	85297911476

前述命令45以JSON格式传递为：{"CommandName":"45","HostPacketID":"112","AppUsername":"85297911476"}

命令46：HOST_CHANNEL_UNBLOCK(指示OJC服务器主机已阻挡用于XMPP客户端App的当前频道)。在一个示范性实施例中，所述命令46的结构如下：

结构名称	实例
		CommandName	46(HOST_CHANNEL_UNBLOCK)
HostPacketID	113
		AppUsername	85297911476
ChannelID	1(Meteorsis)

前述命令46以JSON格式传递为：{"CommandName":"46","HostPacketID":"113","AppUsername":"85297911476","ChannelID":"1"}

命令47：HOST_CHANNEL_UNBLOCK_ACK(指示XMPP客户端App已从OJC服务器接收包-“HOST_CHANNEL_UNBLOCK”，因此XMPP客户端App将其确认传回到OJC服务器主机)。在一个示范性实施例中，所述命令47的结构如下：

结构	实例
		CommandName	47(HOST_CHANNEL_UNBLOCK_ACK)
HostPacketID	113
		AppUsername	85297911476

前述命令47以JSON格式传递为：{"CommandName":"47","HostPacketID":"113","AppUsername":"85297911476"}

命令48：HOST_CHANNEL_CHANGE_PROFILE(指示OJC服务器主机已改变由XMPP客户端App订阅的频道的细节。在一个实例中，频道的细节可包含标志、公司名称和描述等)。在一个示范性实施例中，所述命令48的结构如下：

前述命令48以JSON格式传递为：{"CommandName":"48","HostPacketID":"114","AppUsername":"85297911476","ChannelID":"1","ChannelName":"Meteors信息系统有限公司","ChannelDescription":"提供SMS服务","CompanyWebsite":"http://www.meteorsis.com","LogoDownloadURL":"meteorsis-标志-1391675464.GIF"}

命令49：CHANNEL_CHANGE_PROFILE_ACK(指示XMPP客户端App已从OJC服务器接收包-“HOST_CHANNEL_CHANGE_PROFILE”，因此XMPP客户端App将其确认传回到OJC服务器主机)。在一个示范性实施例中，所述命令49的结构如下：

结构	实例
		CommandName	49(HOST_CHANNEL_CHANGE_PROFILE_ACK)
HostPacketID	114
		AppUsername	85297911476

前述命令49以JSON格式传递为：{"CommandName":"49","HostPacketID":"114","AppUsername":"85297911476"}

前述频道可由XMPP客户端App基于从XMPP客户端app接收的到OJC服务器主机的订阅请求来订阅。图13说明XMPP客户端App与OJC服务器主机之间交换的数据包(即，APP_CHANNEL_REQUEST_SUBSCRIBE和APP_CHANNEL_REQUEST_SUBSCRIBE_ACK)，其促进由XMPP客户端App发布到OJC服务器主机的频道订阅请求。基于频道订阅请求的接收，OJC服务器主机可通过如上文所解释交换数据包(图12中展示)来批准/拒绝所述频道。

现参看图14，其为说明根据本发明的实施例的XMPP客户端装置116与OJC服务器110之间数据包的交换以请求属于网络用户的频道的再订阅的图。如图所示，经由各种命令(作为数据包交换)促进频道再订阅请求，所述各种命令包含APP_CHANNEL_REQUEST_RESUBSCRIBE、APP_CHANNEL_REQUEST_RESUBSCRIBE_ACK、APP_CHANNEL_REQUEST_UNBLOCK(未图示)和APP_CHANNEL_REQUEST_UNBLOCK_ACK(未图示)。下文中在后续段落中描述所述命令中的每一者的结构(及其实例)。

命令54：APP_CHANNEL_REQUEST_RESUBSCRIBE(指示XMPP客户端App已将再订阅频道的请求发送到OJC服务器主机)。在一个示范性实施例中，所述命令54的结构如下：

结构名称	实例
		CommandName	54(APP_CHANNEL_REQUEST_RESUBSCRIBE)
AppPacketID	83
		AppUsername	85297911476
ChannelID	1(Meteorsis)

前述命令54以JSON格式传递为：{"CommandName":"54","AppPacketID":"83","AppUsername":"85297911476","ChannelID":"1"}

命令55：APP_CHANNEL_REQUEST_RESUBSCRIBE_ACK(指示OJC服务器主机已从XMPP客户端App接收包-“APP_CHANNEL_REQUEST_RESUBSCRIBE”，且因此OJC服务器主机将其确认传回到XMPP客户端App)。在一个示范性实施例中，所述命令55的结构如下：

结构	实例
		CommandName	55(APP_CHANNEL_REQUEST_RESUBSCRIBE_ACK)
AppPacketID	83
		AppUsername	85297911476

前述命令55以JSON格式传递为：{"CommandName":"55","AppPacketID":"83","AppUsername":"85297911476"}

命令56：APP_CHANNEL_REQUEST_UNBLOCK(指示XMPP客户端App已将对频道进行解除阻挡的请求发送到OJC服务器主机)。在一个示范性实施例中，所述命令56的结构如下：

结构名称	实例
		CommandName	56(APP_CHANNEL_REQUEST_UNBLOCK)
AppPacketID	84
		AppUsername	85297911476
ChannelID	1(Meteorsis)

前述命令56以JSON格式传递为：{"CommandName":"56","AppPacketID":"84","AppUsername":"85297911476","ChannelID":"1"}

命令57：APP_CHANNEL_REQUEST_UNBLOCK_ACK(指示OJC服务器主机已从XMPP客户端App接收包-“APP_CHANNEL_REQUEST_UNBLOCK”，且因此OJC服务器主机将其确认传回到XMPP客户端App)。在一个示范性实施例中，所述命令57的结构如下：

结构	实例
		CommandName	57(APP_CHANNEL_REQUEST_UNBLOCK_ACK)
AppPacketID	84
		AppUsername	85297911476

前述命令57以JSON格式传递为：{"CommandName":"57","AppPacketID":"84","AppUsername":"85297911476"}

应注意，图10到图14中展示的数据包流指示为‘N’或‘1’。如果数据包的流指示为‘N’，那么相应数据包由发送方(即OJC服务器110或XMPP客户端装置116)重试以发射‘N’次到接收器(即OJC服务器110或XMPP客户端装置116)直至所述数据包接收到其对应的取消确认为止。在一个实施例中，‘N’可在1-10之间变化。或者，如果数据包的流指示为‘1’，那么数据包仅发送一次，而不进行进一步发射尝试。在此情况下，即使然后接收到指示为‘N’的复制包，指示为“1”的新的包(具有不同包id)也记录为确认。

现参看图15，展示根据本发明标的物的实施例用于将一或多个内容广播到接收方装置的方法1500。方法1500的描述次序并不希望解释为限制，且任何数目的所描述方法框可按任何次序组合以实施方法1500或替代方法。此外，方法1500可以任何合适的硬件、软件、固件或其组合实施。然而，为便于阐释，在下文描述的实施例中，方法1500可被认为实施在上文所描述的系统100中。

在框1502处，广播请求由第一处理单元106从发送方装置102接收。在一个实施方案中，第一处理单元106为以通信方式耦合到发送方装置102的网络服务器。第一处理单元106可经由关联到发送方装置的网络浏览器104接收广播请求。在一实施例中，广播请求可包括待广播到接收方装置116的一或多个内容以及关联到所述一或多个内容的元数据。元数据可至少包括接收方装置116(即XMPP App)的用户(即App用户)的身份和用于将所述一或多个内容广播到接收方装置116的调度时间。

在框1504处，所述一或多个内容以及所述元数据可存储在耦合到第一处理单元106的内容储存库108中。在一个实施方案中，所述一或多个内容以及所述元数据由第一处理单元106存储在内容储存库108中。

在框1506处，可经由任务调度装置114按照元数据中的调度时间调度用以触发所述一或多个内容到接收方装置的广播的任务。

在框1508处，可由第二处理单元110检测从接收方装置116接收的连接请求。在一个实施例中，第二处理单元110为OJC服务器。OJC服务器进一步包括计算节点的集群。连接请求由第二处理单元110经由以通信方式与接收方装置116耦合的第三处理单元112接收。在一个实施例中，第三处理单元112为XMPP服务器，且接收方装置116为XMPP客户端装置116。连接请求指示接收方装置打算接收所述一或多个内容。

在框1510处，可由第二处理单元110基于连接请求的接收从内容储存库108检索所述一或多个内容。在一个实施方案中，由第二处理单元110经由计算节点的集群中的至少一个计算节点(图8中展示)检索所述一或多个内容。

在框1512处，所检索的所述一或多个内容由第二处理单元110经由第三处理单元112发射到接收方装置116。在一个实施方案中，所述一或多个内容由第二处理单元110使用所述至少一个计算节点经由第三处理单元112发射。在一实施例中，所述至少一个计算节点经由通信端口在TCP会话期间与第三处理单元112连接以便促进所述一或多个内容到接收方装置116的传递。

上文所论述的示范性实施例可提供特定优点。尽管对于实践本发明的方面不是必需的，但这些优点可包含以下特征提供的优点。

本发明的一些实施例实现一种用于经由单一非XMPP组件(例如OJC服务器)将来自基于网络的应用的消息瞬时传递到多个XMPP客户端装置的系统和方法。

本发明的一些实施例实现一种用于基于针对XMPP App用户与XMPP服务器之间启动的当前登录会话实时产生的动态口令用XMPP服务器验证XMPP App用户的系统和方法。

本发明的一些实施例实现一种用于使用负载均衡算法经由外部组件/计算节点的集群将内容/消息广播到XMPP客户端装置的系统和方法。

本发明的一些实施例实现一种用于通过基于全载寻呼算法向网络用户呈现递送结果来实现到网络用户的提示视觉响应的系统和方法。

尽管已经用特定针对结构特征和/或方法的语言描述用于将一或多个内容广播到接收方装置的方法和系统的实施方案，但应理解，所附权利要求书不必限于所描述的特定特征或方法。实际上，所述特定特征和方法作为用于将一或多个内容广播到接收方装置的实施方案的实例而揭示。

Claims

1.一种用于将一或多个内容广播到接收方装置的方法，所述方法包括：

由第一处理单元接收来自发送方装置的广播请求，其中所述广播请求包括一或多个内容以及关联到所述一或多个内容的元数据，且其中所述一或多个广播内容将广播到接收方装置；

由所述第一处理单元将所述一或多个内容以及所述元数据存储在耦合到所述第一处理单元的内容储存库中；

由耦合到所述内容储存库的第二处理单元检测从所述接收方装置接收的连接请求，其中所述连接请求由所述第二处理单元经由以通信方式与所述接收方装置耦合的第三处理单元接收，且其中所述连接请求经接收以启动所述一或多个内容到所述接收方装置的广播；

由所述第二处理单元基于所述连接请求的所述接收从所述内容储存库检索所述一或多个内容；以及

由所述第二处理单元经由所述第三处理单元将所述一或多个内容发射到所述接收方装置。

2.根据权利要求1所述的方法，其中所述第一处理单元为网络服务器，且其中所述广播请求由所述网络服务器经由关联到所述发送方装置的网络浏览器从所述发送方装置接收。

3.根据权利要求1所述的方法，其中所述一或多个内容包括以下中的至少一者：文本消息、音频消息、视频消息、多媒体消息、图像及其组合。

4.根据权利要求1所述的方法，其中所述元数据至少包括所述接收方装置的用户的身份和用于将所述一或多个内容广播到所述接收方装置的调度时间。

5.根据权利要求4所述的方法，其进一步包括经由耦合到所述网络服务器的任务调度装置按照存在于所述元数据中的所述调度时间调度触发所述一或多个内容到所述接收方装置的所述广播的任务。

6.根据权利要求5所述的方法，其进一步包括经由所述任务调度装置通知所述接收方装置以基于所述调度时间触发用于所述一或多个内容的所述接收的所述连接请求。

7.根据权利要求1所述的方法，其中所述第二处理单元、所述第三处理单元和所述接收方装置分别为OJC服务器、XMPP服务器和XMPP客户端装置，其中所述OJC服务器进一步包括计算节点的集群。

8.根据权利要求7所述的方法，其中至少一个计算节点经配置以：

在经由所述XMPP服务器从所述XMPP客户端装置接收所述连接请求之后从所述内容储存库提取所述一或多个内容，且

经由所述XMPP服务器将所述一或多个内容传递到所述XMPP客户端装置。

9.根据权利要求8所述的方法，其中所述XMPP客户端装置经配置以在由所述XMPP服务器验证所述XMPP客户端装置之后经由所述XMPP服务器发射所述连接请求。

10.根据权利要求8所述的方法，其中所述XMPP服务器基于针对所述XMPP服务器与所述XMPP客户端装置之间启动的当前登录会话实时产生的动态口令验证所述XMPP客户端装置。

11.根据权利要求10所述的方法，其中基于以下中的至少一者产生所述动态口令：接收方识别符、关联到由所述接收方装置检索的上一内容的内容识别符、对应于所述XMPP服务器与所述XMPP客户端装置之间的上一登录会话的时戳及其组合。

12.根据权利要求8所述的方法，其中所述至少一个计算节点经由用于所述一或多个内容的所述传递的通信端口在TCP会话期间与所述XMPP服务器连接，且其中所述连接是基于以下操作建立

由所述XMPP服务器接收来自所述至少一个计算节点的流；

由所述XMPP服务器将流标头发射到所述至少一个计算节点，其中所述流标头包括与所述流相关联的至少一流识别符；

由所述XMPP服务器从所述至少一个计算节点接收握手信号，其中所述握手信号至少包括与预共享机密密钥串接的所述流识别符；以及

由所述XMPP服务器响应于所述握手信号将确认信号发射到所述至少一个计算节点，其中所述确认信号指示在所述XMPP服务器与所述至少一个计算节点之间建立成功连接。

13.根据权利要求12所述的方法，其中所述至少一个计算节点进一步经配置以从所述XMPP服务器接收以下中的至少一者

对应于所述一或多个内容的响应内容，以及

指示所述一或多个内容由所述接收方装置存取的确认消息。

14.根据权利要求13所述的方法，其中所述至少一个计算节点进一步经配置以关于对应于所述一或多个内容的所述响应内容的所述接收或所述一或多个内容由所述接收方装置存取或其组合而更新所述内容储存库。

15.一种用于将一或多个内容广播到接收方装置的系统，所述系统包括：

第一处理单元，其以通信方式耦合到发送方装置，其中所述第一处理单元经配置以

接收来自所述发送方装置的广播请求，其中所述广播请求包括一或多个内容以及关联到所述一或多个内容的元数据，且其中所述一或多个内容将广播到接收方装置，且

将所述一或多个内容以及所述元数据存储在耦合到所述第一处理单元的内容储存库中；以及

第二处理单元，其经由第三处理单元以通信方式与所述接收方装置耦合，其中所述第二处理单元经配置以

检测从所述接收方装置接收的连接请求，其中所述连接请求经由所述第三处理单元接收，且其中所述连接请求经接收以启动所述一或多个内容到所述接收方装置的广播，

基于所述连接请求的所述接收从所述内容储存库检索所述一或多个内容，且

经由所述第三处理单元将所述一或多个内容发射到所述接收方装置。

16.根据权利要求15所述的系统，其中所述第一处理单元为网络服务器，且其中所述广播请求由所述网络服务器经由关联到所述发送方装置的网络浏览器从所述发送方装置接收，且其中所述第二处理单元、所述第三处理单元和所述接收方装置分别为OJC服务器、XMPP服务器和XMPP客户端装置，且其中所述OJC服务器进一步包括计算节点的集群。

17.根据权利要求16所述的系统，其进一步包括耦合到所述网络服务器的任务调度装置，所述任务调度装置经配置以按照存在于所述元数据中的所述调度时间调度触发所述一或多个内容到所述接收方装置的所述广播的任务，且其中所述任务调度装置通知所述接收方装置以基于所述调度时间的期满而触发用于所述一或多个内容的所述接收的所述连接请求。

18.根据权利要求16所述的系统，其中所述至少一个计算节点经由用于所述一或多个内容的所述传递的通信端口在TCP会话期间与所述XMPP服务器连接，且其中所述连接是基于以下操作建立

由所述XMPP服务器接收来自所述至少一个计算节点的流；

由所述XMPP服务器从所述至少一个计算节点接收握手信号，其中所述握手信号至少包括与预共享机密密钥串接的流识别符；以及

19.根据权利要求18所述的系统，其中所述至少一个计算节点进一步经配置以从所述XMPP服务器接收以下中的至少一者

对应于所述一或多个内容的响应内容，以及

指示所述一或多个内容由所述接收方装置存取的确认消息。

20.根据权利要求19所述的系统，其中所述至少一个计算节点进一步经配置以关于对应于所述一或多个内容的所述响应内容的所述接收或所述一或多个内容由所述接收方装置存取或其组合而更新所述内容储存库。