CN102498486A - 内容提供商网站交互的系统、服务器和移动设备及其方法 - Google Patents

内容提供商网站交互的系统、服务器和移动设备及其方法 Download PDF

Info

Publication number
CN102498486A
CN102498486A CN2010800404895A CN201080040489A CN102498486A CN 102498486 A CN102498486 A CN 102498486A CN 2010800404895 A CN2010800404895 A CN 2010800404895A CN 201080040489 A CN201080040489 A CN 201080040489A CN 102498486 A CN102498486 A CN 102498486A
Authority
CN
China
Prior art keywords
server
mobile device
information
web server
content
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.)
Pending
Application number
CN2010800404895A
Other languages
English (en)
Inventor
马克森·R·惠勒
威廉·N·坎普二世
利恩·T·马米特苏卡
克里斯托弗·A·米特拉
斯科特·I·普特曼
赛鲁斯·P·马斯特
史蒂芬·J·塞韦里内克
米兰·S·布拉姆巴特
阿尼什·M·沙阿
保罗·韦恩·汉加斯
胡鑫
萨普纳·索尼
托尼·鲁宾逊
希瑟·M·勒罗伊
克里斯托弗·雷平斯基
魏凯
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.)
Motorola Mobility LLC
Original Assignee
Motorola Mobility LLC
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 Motorola Mobility LLC filed Critical Motorola Mobility LLC
Publication of CN102498486A publication Critical patent/CN102498486A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Business, Economics & Management (AREA)
  • Computer Hardware Design (AREA)
  • Tourism & Hospitality (AREA)
  • Economics (AREA)
  • General Health & Medical Sciences (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Primary Health Care (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Telephonic Communication Services (AREA)

Abstract

一种聚合服务服务器，该聚合服务服务器被配置成与用户设备和多个不同的内容提供商进行通信。处理器被配置成从所述多个不同的内容提供商获得内容并且进一步被配置成将所获得的内容推到所述用户设备。

Description

内容提供商网站交互的系统、服务器和移动设备及其方法
技术领域
本发明涉及包括移动设备的通信，并且更具体地涉及这样的移动设备与互联网内容提供商网站之间的通信。
背景技术
诸如社交网网站(SNW)、新闻订阅源、音乐和相片网站的内容提供商网站(CPW)、以及诸如企业到企业(b2b)或企业到消费者(b2c)网站的其它类型的网站是交互式网站，其支持诸如新闻、天气、个人和/或企业信息、图片、视频以及歌曲的各种形式的数据的下载和/或上传(例如，发帖)，并且从而有助于在人和人群之中的人与人之间的连接的创建和维护。由一个用户将数据上传到CPW能够允许其他用户访问和/或下载所上传的数据。通常，SNW为无数用户提供了架构，以创建分别标识相应的用户的相应的个人空间或专业空间并且允许上传的数据与相应的空间相关联。
CPW能够与正在操作常常经由因特网型网络与CPW联系的各种不同类型的设备中的任何一个的用户进行通信。逐渐地，用户采用移动设备来与CPW进行交互。随着这样的通信活动增加，有发展着对于改进在进行这样的通信活动中的质量和/或用户友好性的不断增加的需求。另外，还发展着对于改进这样的通信活动的效率以改进移动设备的电池性能并且减少所有设备的数据传输的不断增加的需求。
因此，如果能够提供将帮助至少部分地解决前述发展需要中的一个或多个、以改进的移动设备和/或其它设备和/或用于允许移动设备与CPW进行通信的改进的方法的形式的改进，其将是有利的。
附图说明
图1以示意形式示出了包括与多个内容提供商网站进行通信的多个移动设备的示例通信系统，其中通信中的一些经由中间web服务器发生；
图2是示出图1的移动设备中的一个的示例组件的框图；
图3是示出图1的中间web服务器的示例组件的框图；以及
图4-9是示出图1的中间web服务器和移动设备的操作的各种示例步骤的示例性流程图。
图10是图示中间服务器的操作的示例性流程图；
图11是图示移动设备的操作的示例性流程图；
图12是图示中间服务器的操作的示例性流程图；
图13是图示中间服务器的操作的示例性流程图；
图14图示了移动设备的示例性操作；
图15是图示移动设备的操作的示例性流程图；
图16是图示中间服务器的操作的示例性流程图；
图17是根据实施例的另一示例性通信系统；
图18是根据实施例的又一示例性通信系统；
图19图示了客户端设备与中间服务器之间的示例性通信；
图20图示了中间服务器的后端的示例性推式服务；
图21图示了根据一个实施例的、用于导入联系人的示例性方法；
图22图示了根据实施例的示例性序列；
图23-30图示了根据实施例的来自客户端设备的示例性屏幕；
图31图示了根据实施例的另一示例性通信系统；以及
图32图示了根据一个实施例的示例性协议。
具体实施方式
参考图1，以简化的示意形式示出了示例通信系统100的框图。如所示，在这个实施例中通信系统100包括三个移动设备102，其中的一个被示出为经由通信链路105与服务器进行通信，所述服务器在本实施例中为web服务器104。移动设备102分别表示由个人(或用户)或可能地由期望或需要通信能力的其它实体(例如，上网本或其它计算机)操作的通信设备。在一些实施例中，例如，移动设备102可以为蜂窝电话、诸如个人数字助理的其它无线设备、和/或诸如能连接到网络(通信链路105)并且与网络进行通信的膝上型计算机和台式计算机的设备中的任何一个。
通信系统100此外被示出为包括三个内容提供商网站(CPW)106，其中的一个被示出为经由通信链路108与中间web服务器104进行通信。另外，通信链路110还被提供成支持与web服务器104进行通信的移动设备102中的一个直接与也与该web服务器进行通信的CPW106中的那一个进行通信，而无需web服务器104的调解。尽管移动设备102中的仅一个和CPW 106中的一个被示出为与web服务器104进行通信，但是将理解的是，取决于时间或者操作环境，移动设备102和CPW 106中的任何一个或全部都能够与web服务器进行通信。同样地，取决于时间或者操作环境，移动设备102中的任何一个都能够经由诸如链路110的直接通信链路进入与CPW 106中的任何一个的通信。
尽管图1中示出了三个移动设备102，但是在其它实施例中，仅一个移动设备与web服务器104进行通信，或者替代地任何任意数量的移动设备能够与web服务器104进行通信。同样地，尽管在图1中示出了三个CPW 106，但是在其它实施例中，仅一个CPW与web服务器104进行通信，或者替代地任何任意数量的CPW能够与web服务器104进行通信。此外，在其它实施例中，任何任意数量的移动设备能够经由诸如链路110的直接通信链路与任何任意数量的CPW进行通信。也就是说，图1旨在表示采用经由web服务器接口彼此间接地或者彼此直接进行通信的任何任意数量的移动设备和任何任意数量的CPW的各种系统中的任何一个系统。
取决于实施例，通信链路105、108以及110能够为单个网络或多个网络的一部分，并且每个链路能够包括一个或多个有线和/或无线通信通道，例如，陆上通讯线(例如，光纤、铜)布线，微波通信、无线电信道、无线路径、内联网、互联网和/或万维网通信通路(他们本身能够采用无数的中间硬件和/或软件设备，包括例如无数的路由器等)。此外，各种通信协议和方法学能够被用来在移动设备102、web服务器104以及CPW 106之间经由通信链路105、108以及110进行通信，包括例如传输控制协议/网际协议(TCP/IP)、可扩展消息存在协议(XMPP)、文件传输协议(FTP)等。在其它实施例中，也能够利用用于帮助多个移动设备102与CPW 106之间的信号的传输的其它类型的通信链路。尽管在本实施例中，通信链路/网络和服务器都被讨论为基于web的，但是在其它实施例中，链路/网络和服务器能够采取各种非基于web的形式。
如将在下文中有关图3-16更详细地讨论的，web服务器104被配置成充当移动设备102与CPW 106之间的中间物。移动设备102与CPW106之间的各种类型的通信通过web服务器104、被web服务器104处理和/或监视，所述各种类型的通信包括例如包括文件(例如，相片、音乐、视频、文本输入等)的上传和下载、博客发布以及消息传递(例如，短消息服务(SMS)、多媒体消息服务(MMS)以及即时发消息(IM))的通信。CPW通常旨在包括支持诸如个人和/或企业信息、图片、视频以及歌曲的各种形式的数据的下载和上传(例如，发布)并且从而有助于人和人群之中的人与人之间的连接的创建和维持的各种交互式网站。CPW的示例包括例如FacebookTM、MySpaceTM、hi5TM、LinkedInTM以及TwitterTM。为了本发明的目的，CPW还能够被理解成包括各种其它类型的网站(例如，企业到企业或企业到消费者网站)，尽管不完全地或主要地集中在社交网上，然而也包括社交网类型特征。其它内容提供商网站包括RSS的源或其它新闻订阅源、诸如PicasaTM或PhotobucketTM的相片服务、以及诸如LastFMTM的音乐服务。
简易信息聚合(RSS)指的是用来频繁地发布诸如博客条目、新闻头条、音频以及视频的更新的作品的web订阅源格式。RRS文档(其被称为“订阅源”或“频道”)包括完全的或概略的文本、加上诸如出版日期和原创作者的元数据，并且可以包括相片。
参考图2，提供了图示根据一个实施例的诸如移动设备102的移动设备的示例内部组件200的框图。如图2中所示，组件200包括一个或多个无线收发器202、203、205、处理器204(例如，微处理器、微计算机、专用集成电路等)、存储器部分206、一个或多个输出设备208、以及一个或多个输入设备210。在至少一些实施例中，存在包括诸如显示器的一个或多个输出设备208和诸如小键盘或触摸传感器的一个或多个输入设备210的用户接口。内部组件200进一步能够包括组件接口212以向辅助组件或附件提供直接连接以用于另外的或增强的功能性。内部组件200优选地还包括诸如电池的电源214，以用于向其它内部组件提供电力同时使移动设备能够是可携带的。内部组件200中的全部都能够经由一个或多个内部通信链路232(例如，内部总线)耦合到彼此，并且与彼此进行通信。
无线收发器202中的每一个都利用无线技术以便进行通信，所述无线技术能够包括：例如(但不限于)基于蜂窝的通信技术，诸如模拟通信(使用AMPS)、数字通信(使用CDMA、TDMA、GSM、iDEN、GPRS、EDGE等)、以及下一代通信(使用UMTS、WCDMA、LTE、IEEE 802.16等)或其变体；或对等或者自组织通信技术，诸如HomeRF(射频)、蓝牙以及IEEE 802.11(a、b、g或n)；或其它无线通信技术，诸如红外技术。在本实施例中，无线收发器202包括蜂窝收发器203和无线局域网(WLAN)收发器205，但是在其它实施例中，存在这些类型中的无线收发器中的仅一个(并且可能地这些类型的无线收发器和/或其它类型的无线收发器都不存在)。通过使用无线收发器202，移动设备102不仅能经由通信链路110与CPW 106进行通信并且还能经由通信链路105与web服务器104(并且因此再次间接与CPW 106)进行通信。
与移动设备102的内部组件200的其它部分相结合的无线收发器202的示例操作能够采取各种形式并且能够包括例如操作，在该操作中，在接收到无线信号时，内部组件检测通信信号并且收发器202对该通信信号进行解调以重新获得由无线信号传送的诸如语音和/或数据的传入信息。在从收发器202接收到传入信息之后，处理器204对该传入信息进行格式化以用于一个或多个输出设备208。同样地，为了无线信号的传输，处理器204对传出的信息进行格式化，其可以或可以不由输入设备210来激活，并且将该传出信息传递到无线收发器202中的一个或多个以调制成通信信号。无线收发器202经由无线和(也可能有线的)通信链路将经调制的信号传递到诸如web服务器104和CPW 106中的一个或多个的其它设备(以及可能地传递到诸如小区塔、接入点、或另一服务器或各种远程设备中的任何一个的其它设备)。
取决于实施例，内部组件200的输入和输出设备208、210能够包括各种视觉、音频和/或机械输出。例如，输出设备208能够包括：诸如液晶显示器和发光二极管指示器的一个或多个视觉输出设备216；诸如扬声器、警报器和/或蜂鸣器的一个或多个音频输出设备218；和/或诸如振动机构或其它触觉反馈系统的一个或多个机械输出设备220。视觉输出设备216尤其能够包括视频屏幕。同样地，以举例的方式，输入设备210能够包括：诸如光学传感器(例如，相机)的一个或多个视觉输入设备222；诸如麦克风的一个或多个音频输入设备224；以及诸如翻转传感器、键盘、小键盘、选择按钮、导航群集、触摸板、触摸屏、电容传感器、运动传感器、以及开关的一个或多个机械输入设备226。能够致动输入设备210中的一个或多个的动作能够不仅包括按钮或其它致动器的物理按压/致动，而且还包括例如打开移动设备、将设备解锁、使设备移动以致动运动、使设备移动以致动位置定位系统以及对设备进行操作。
如图2中所示，移动设备102的内部组件200还能够包括各种类型的传感器228中的一个或多个。传感器228能够包括例如接近传感器(光检测传感器、超声收发器或红外收发器)、触摸传感器、高度传感器、能够包括例如全球定位系统(GPS)接收器、三角测量接收器、加速计、倾斜传感器、陀螺仪的位置电路、或能够标识移动设备102的当前位置或用户设备接口(运载模式)的任何其它信息收集设备。
内部组件200的存储器部分206能够包括各种形式(例如，只读存储器、随机存取存储器、静态随机存取存储器、动态随机存取存储器等)中的任何一个的一个或多个存储器设备，并且能够由处理器204用来存储和检索数据。由存储器部分206存储的数据能够包括但是不必限于操作系统、应用以及信息数据。每个操作系统都包括控制通信设备的基本功能的可执行代码，所述通信设备的基本功能诸如在内部组件200之中包括的各种组件之间的交互，经由无线收发器202和/或组件接口212与外部设备的通信、以及应用和数据向存储器部分206的存储和从存储器部分206的对应用和数据的检索。每个应用都包括利用操作系统为通信设备提供诸如文件系统服务的更多的特定功能性和在存储器部分206中存储的受保护的和无保护的数据的处理的可执行代码。信息数据是能够被用于执行通信设备的功能的操作系统或应用引用和/或操纵的非可执行代码或信息。
接下来参考图3，更详细地示出了图1的web服务器104的另外的示例组件。如所示，web服务器104包括存储器部分302、与该存储器部分进行通信的处理器部分304、以及用于将通信链路105、108与处理器304对接的一个或多个输入/输出(I/O)接口(未示出)。处理器部分304进一步包括后端部分306(或社交网处理器)和前端部分308。后端部分306经由通信链路108与CPW 106(以虚线示出)进行通信，而前端部分308经由通信链路105与移动设备102(也以虚线示出)进行通信。
如在下文中进一步详细地讨论的，在至少一些实施例中，后端部分306支持与诸如CPW 106的CPW的拉式(pull)通信。拉式通信能够例如使用对web典型的类型的表述性状态转移(REST)架构来实现，并且当这样的后端部分被配置成生成对于要在由web服务器104确定的时间/环境从诸如CPW 106的CPW提供给后端部分306的信息的请求时，响应于此CPW搜索所请求的数据并且将其提供回web服务器。同样地，如在下文中进一步详细地讨论的，在至少一些实施例中，前端部分308与诸如移动设备102的移动设备协力建立推式信道。
在至少一些这样的实施例中，推式信道允许前端部分308在由web服务器104确定的时间/环境将来自web服务器104的通知(由前端部分所生成)提供给移动设备102。该通知能够指示可用于提供给移动设备的信息内容。移动设备102进而能够以移动设备认为适当的方式对该通知作出响应。这样的响应通常(但是未必一直)构成可用的信息内容中的一些或全部从中间web服务器104的前端部分提供给移动设备的请求。
参考图4，提供了示出图1和图3的web服务器104具体地当与诸如如图1中所示的移动设备102和CPW 106的移动设备和CPW进行交互以及在诸如如图1中所示的移动设备102与CPW 106的移动设备与CPW之间调解通信时的操作的示例步骤的流程图。在开始步骤400处开始由图4的流程图表示的处理之后，在步骤402处web服务器104通过建立诸如与图1的移动设备102的通信链路105的与移动设备的通信链路来开始操作。如将在下文中进一步详细地描述的，取决于实施例，与移动设备建立通信链路能够实际上包括与该移动设备建立多个通信链路(能够并行或在不同的时间存在)。
在一些这样的情况下，多个通信链路是不同的类型的，例如，包括推式信道或除了推式信道之外的通信协议。而且，尽管与移动设备102建立通信链路通常包括与基站建立电路转换连接，并且因此通信设备将标识信息提供给基站，移动设备由此将它本身标识到电信网络，但是到web服务器104的连接还能够经由网际协议(IP)连接或移动设备正与其进行通信的基站与负载平衡器/防火墙之间的点到点(P2P)电信连接，并且还能够包括将来自web服务器的响应信号往后提供给移动设备，移动设备由此识别到其正与web服务器联系。
一旦完成步骤402，则在步骤404处，web服务器104进一步建立与CPW的通信链路，诸如与图1所示的CPW 106的通信链路108。在步骤404处通信链路的建立能够包括例如提供一个或多个web服务调用和/或其它技术。在步骤404之后，web服务器104维持与CPW 106的正在进行的通信，所述通信可以是(但是不必是)定期的通信，并且web服务器104在一个或多个时间从CPW获得(拉式)信息。从CPW获得的信息能够包括各种不同类型的信息中的任何一个，包括例如有关联系人或朋友(包括联系人列表)、新朋友或更新的联系人、特殊消息、新闻、事件的信息，和可能地包括文件(诸如图像文件或文本文件)或其它形式的数据的其它类型的信息。一旦在步骤406处获得信息，则在步骤408处web服务器对所获得的信息进行处理。
另外参考图5，根据一个实施例示出了与图4的步骤406和步骤408相对应的示例子步骤。如所示，步骤406(获得步骤)能够被理解为包括以开始子步骤500开始并且进一步包括三个另外的子步骤502、504以及506的若干子步骤。更具体地，在子步骤502中，web服务器104将拉式信号发送到CPW 106，并且在子步骤504处，在web服务器的后端部分306处从CPW往回接收信息。在后端部分306处接收到信息之后，在步骤506处，该信息然后从后端部分被推到web服务器104的前端部分308。
进一步如图5中所示，在一个实施例中步骤408(处理步骤)能够包括在子步骤518处结束之前在子步骤508处开始的若干子步骤(图5示出了与步骤408相对应的子步骤，如为与步骤406相对应的子步骤的接续)。更具体地，在子步骤508处，一旦web服务器104的前端部分308接收到在子步骤506处从后端306部分所推的信息，则该信息被放入到通用传输队列中。接下来，在子步骤510处，信息能够可选地被压缩。此外，在子步骤512处，信息能够可选地被转换成不同的格式，例如二进制格式。如由框509所另外表示的(以虚线示出)，在子步骤512处发生的格式转换能够包括对由CPW 106提供的特定格式信息的移除，以便对信息的格式进行标准化并且移除站点特定的格式信息，然而不是来源身份，或者另外修改信息的格式以成为提供给移动设备的统一的或通用的格式，无论作为信息的来源的CPW格式如何。
接下来，在子步骤514处，信息基于其是否是高重要性或低重要性被过滤。如由子步骤511、513、515以及517(以虚线示出)所进一步表示的，这个过滤操作能够进一步包括确定。即，如子步骤511处所示，web服务器104能够确定信息是否关系到朋友、新朋友、特殊消息、新闻或者事件。如果是这样的话，则在子步骤513处，该信息被指派低级别状态。然而，如果信息不落入那些分组中的一个，则该过滤处理继续进行到子步骤515，在该处web服务器确定信息是否关系到状态更新。如果其关系到，则在子步骤517处高级别状态被指派给该信息。在本示例实施例中，如果在子步骤515处信息被确定为不关系到状态更新，则处理再次返回到子步骤513。将认识到web服务器104能够确定该信息是否为用户的状态更新，并且如果它是，则将该信息看作高级别，或者高优先级，并且如果它不是，则将该信息看作低级别，或低优先级。其它类型的信息也可以被看作高优先级，然而期望限制导致通信设备的不断增加的活动的消息的数量。
一旦完成了过滤子步骤514，则处理前进到子步骤516，其中web服务器104(具体地web服务器的前端部分308)确定可能在步骤406处从CPW 106获得的信息与更早地从该相同的CPW接收到的先前的信息之间存在的一个或多个差异。在本实施例中，最终传送回移动设备102的仅是这样的差异信息。如已经提到，由图5所表示的、并且与图4的步骤408相对应的子步骤在子步骤518处结束。将认识到，步骤516能够有利地在步骤504与步骤506之间在后端部分306中发生，在该情况下如果从内容被拉(pull)用于特定订户的先前时间在CPW信息中存在改变，则信息将仅在web服务器104中进一步被处理。这将释放服务器资源以继续从CPW拉信息以用于设备102的用户或使用中间web服务器和CPW的其它用户。
返回图4，一旦完成了步骤408，则web服务器104考虑经处理的信息中的一个或多个部分具有高重要性还是不具有高重要性(例如，具有低重要性，或可能具有中间重要性或某个其它重要性级别)。如果确定经处理的信息具有高重要性，则在步骤412处web服务器104的前端部分308经由跨越通信链路105建立的推式信道将高重要性经处理的信息发送到移动设备102。这在由web服务器确定的时间立即发生，如经由使用推式信道可能进行的。如果在步骤410处确定经处理的信息不具有高重要性，则经处理的信息的发送能够被延迟直到另一更适当的时间为止以从而减少设备与服务器之间的通信活动，并且因此减少设备上的电池消耗。因此，在步骤414处，web服务器104等待适当的时间将经处理的信息发送到移动设备102。然后，一旦适当的时间已经出现，则在步骤416处然后信息由web服务器104发送到移动设备102。
低重要性经处理的信息由web服务器104发送到移动设备102的适当时间能够基于各种考虑。例如，在一些实施例中，这样的适当时间仅仅是定期出现的时间，在该时间处移动设备102轮询web服务器104以获得信息。这样的轮询通常包括将来自移动设备102的查询信号重复地发送到web服务器104。在其它情况下，当特定的环境已经出现时适当的时间就出现。例如，当移动设备102做出请求如果同时是在相同的时间web服务器104已经确定特定数量的低重要性经处理的信息已经被存储用于传输到移动设备的情况时，用于发送低重要性经处理的信息的适当时间能够出现。尽管在上述描述中，通过web服务器104获得信息被描述为包括拉，而通过移动设备从web服务器获得低重要性信息被描述为包括轮询，但是应当理解，取决于实施例，拉操作或轮询操作(和定期通信或者异步通信)能够分别由web服务器和移动设备中的任何一个使用，以分别从CPW 106和web服务器获得信息。另外，设想当移动设备102未被连接到系统100时，服务器能够正从内容提供网站106拉信息，作为这样的结果服务器将保留信息直到移动设备重新连接为止，或者当足够的时间过去以致服务器删除该信息时。
无论高重要性或低重要性信息是否分别在步骤412和步骤416处发送到移动设备102，一旦完成这些步骤，则一系列的另外的步骤由正在与移动设备、CPW、或另外的移动设备/CPW交互的web服务器104来执行。更具体地在这点上，一旦完成了步骤412和步骤416，则在步骤418-428处，来自移动设备102的信息能够被上传到web服务器104并且进一步提供给CPW 106。如图4中所示出，在步骤418处，这样的交互能够通过web服务器104从移动设备102接收标识信息开始。这样的标识信息的接收不必一直发生，例如，如果这样的标识信息已经在步骤402处被接收到。然后，在步骤420处，web服务器104另外地从移动设备102接收内容信息。内容信息能够包括例如诸如图像文件或文本文件的文件、或移动设备的用户想要已经上传到在CPW处存在的用户简档(例如，“背景墙”)的其它数据。
接下来，在步骤422处，web服务器104从移动设备102接收指令web服务器将内容信息上传到CPW 106的命令。在替代实施例中，这个命令不必由移动设备102明确地提供给web服务器104，因为在这样的实施例中，web服务器假定由移动设备提供的所有内容信息应当进一步被上传到该移动设备所关联的任何CPW。进一步地，然后在步骤424处，web服务器104将从移动设备102接收到的标识信息发送到CPW 106以便认证该web服务器与该CPW之间的关系。响应于发送这个标识信息，通常如果认证是符合要求的，则从CPW往回接收到令牌，如由步骤426所指示的。如关于步骤418，在所有的实施例中步骤424和步骤426不必在这个时候被明确地执行，特别地在这样的动作被视为在步骤402、404中的通信链路的建立的一部分的情况下。无论认证何时发生，认证处理允许web服务器104代表移动设备102和作为移动设备102的代理来与CPW 106进行交互。假定适当的认证已经发生，则在步骤428处内容信息由web服务器104发送到CPW 106。
设想当移动设备102首次连接到服务器并且在web服务器上建立内容提供商网站时，用于内容提供商网站上的特定用户账户的针对web服务器104将内容上传到内容提供商网站106和从内容提供商网站106下载内容所需要的用户ID和密码能够由用户加载到web服务器104中。web服务器将用户ID和密码存储在存储器中，并且只要用户不改变他们，就使用该用户ID和密码来访问CPW，以维持与CPW的持续连接，不管移动设备102是否被连接。进一步设想如果对于预定的时间段移动设备不从服务器请求信息，或者如果用于将内容下载到设备的用户设备队列超过老化阈值和/或存储容量阈值，则能够在频率上减少或者完全暂停从CPW 106拉信息。
除了先前描述的上传处理之外，在一些环境下，操作移动设备102的用户将还期望内容被上传到不止一个CPW 106。这样的处理能够通过web服务器104来促进，如由图4的步骤430-438所指示的，特别在内容信息已经由移动设备102提供给web服务器的情况下。更具体地如所示，在步骤430处，由web服务器104确定web服务器是否已经从移动设备102接收到指令web服务器将内容信息提供给另一CPW的进一步命令。如果已经接收到这样的命令，则在下一个步骤432处，web服务器104确定是否已经建立与其它CPW的通信链路。如果尚未建立这样的通信链路，则处理前进到步骤434，其中从移动设备102接收到另外的标识信息，并且随后在步骤436处在web服务器104与其它CPW 106之间建立通信链路。也就是说，如果尚未建立与其它CPW的通信链路，如在步骤432处所确定的，则为了建立这样的通信链路，再次必须从移动设备102向web服务器104提供标识信息，允许web服务器与该其它CPW有关地被认证以便操作为与该其它CPW有关的移动设备的代理(例如，与上文中与步骤424-426有关地所描述的基本上相同的操作)。
一旦步骤436处建立通信链路，或者如果在步骤432处确定已经建立与其它CPW的通信链路，则处理前进到步骤438，在该处内容信息被上传到其它CPW。因此，借助于步骤430-438，在步骤428处已经提供给第一CPW的内容信息被另外地提供给另一CPW。将理解的是，尽管图4没有示出在重复执行步骤418-438中的立即循环，但是步骤能够与无数部分的信息和不止一个另外的CPW有关地重复无数次。设想将以统一的格式从移动设备102提供内容，并且服务器后端将单独地并且适当地对数据进行格式化以用于内容正被上传到的目标CPW中的每一个。
进一步关于图4，一旦完成了步骤438，或者在步骤430处由web服务器104确定没有接收到命令的情况下，则在步骤440处web服务器另外继续进行以确定移动设备102是否已经从web服务器断开连接。即使移动设备102已经从web服务器104断开连接，但是作为一般规则web服务器将仍然维持其与CPW 106的通信链路，web服务器先前已经进入对于该CPW 106的通信，并且与该CPW 106相关地该web服务器能充当代表已经被断开连接的移动设备的代理，如由步骤442所表示的。因此，即使web服务器代表其正在行动的移动设备102暂时地离开通信，web服务器104也能够在正在进行的基础上继续与CPW106相关地进行操作。因此，web服务器104能够继续操作以从各种CPW 106拉信息并且可以随着时间的推移访问和监视这样的信息，使得当先前断开连接的移动设备被重新连接到web服务器时，web服务器能够立即(如果有的话)提供可用的最近的、更新的CPW信息。
尽管上文的描述，并且尽管图4中未示出，但是在某些实施例中移动设备102还可能将该web服务器停止代表它本身与CPW 106中的一个或多个相关地行动的指令传送到web服务器104，在该情况下，web服务器将这样做。最后，还如图4中所示，当步骤442已经完成或倘若在步骤440处确定移动设备102仍然连接时，web服务器104继续确定是否存在与移动设备102和/或CPW 106中的其它移动设备102和/或CPW 106建立另外的通信链路的需要或期望。根据本流程图，如果不存在这样的需要或期望，则处理在步骤446处结束，而如果存在这样的需要或期望，则处理返回到开始步骤400。
应当理解的是，尽管如图4中所示的特定步骤，但是取决于实施例各种另外的或不同的步骤能够由web服务器104来执行，并且取决于实施例能够对图4中所示的特定步骤中的一个或多个进行重新排列，重复或完整地消除。而且，根据图4的流程图执行的步骤中的一些能够当执行步骤中的其它步骤的同时在正在进行的或连续的基础上重复。例如，即使当诸如与从移动设备到web服务器并且然后到CPW中的一个或多个的内容信息的上传有关的由步骤418-438表示的那些的其它交互也正在进行时，与从CPW 106接收到的信息的获得和处理和到移动设备102的高重要性信息的立即(或基本上立即)发送有关的步骤406-412能够在正在进行的或连续的基础上重复。另外，尽管图4相当详细地描述了web服务器104正与多个CPW 106连续地或同时地进行通信的可能性，并且图示了由给定移动设备和这样的一个或多个CPW之间的web服务器促进的示例交互，但是应当理解的是，就允许类似的交互在任何数量的其它移动设备和这样的一个或多个CPW之间发生而言，可以由web服务器在相同的时间或基本上相同的时间执行相同的处理。
设想后端部分306能够包括用于每个CPW 106的单独的插件，包括适合其相应CPW的相应API。插件中的每一个都包括用于其相应CPW的API，插件由此从网站拉信息并且将该信息重新格式化成移动设备102客户端的通用格式。此外，当由后端部分306上传时，来自移动设备的内容将从移动设备102客户端程序的统一格式重新格式化为由与该插件相关联的CPW规定的适当格式。以这种方式，来自用户设备102的内容能够以具有统一格式的单个消息被发送，并且其将如由用户选择一样被路由和由用于作为其目标的相应CPW中的每一个的后端部分插件中的每一个格式化。
转向图6，提供了示出当移动设备102与web服务器进行交互，并且借助于这个交互能够与一个或多个CPW进行交互时移动设备102的操作的示例步骤的另外的流程图。也就是说，图6旨在图示移动设备102的操作的示例步骤，其相对于如上文中的图4和图5中所图示的由web服务器104执行的多个步骤是补充的(或者大部分是补充的)。此外，如在下文中将被进一步描述的，图6还包括使移动设备102能在不用通过web服务器104的调解的情况下直接或者与(但是独立于)通过web服务器的调解一起同时地与CPW 106中的一个或多个进行交互的步骤。如图6中所示，一旦在开始步骤600处开始操作，则在步骤602处移动设备102通过与web服务器建立通信链路并且经由web服务器因此与CPW建立通信链路来开始其与web服务器104的交互。
另外参考图7，步骤602能够被理解为包括如在图7中所图示的若干子步骤。如所示，一旦在子步骤700处开始，则移动设备102激活在移动设备上支持的推式信道应用，如在子步骤702处所指示的。然后，在子步骤704处移动设备102将标识信息提供给web服务器104。这样的标识信息能够包括例如规定特定移动设备(例如，序列号、型号或者产品参考号)的标识码、与利用该移动设备的用户的身份有关的信息、或诸如登录或密码代码的其它编码信息。接下来，在子步骤706处，确定在移动设备102处是否存在经由web服务器与CPW 106中的特定一个建立通信链路的期望。如果在这个时候不存在这样的期望，则由图7表示的处理在子步骤708处结束。替代地，如果存在经由web服务器104与CPW 106建立通信链路的期望，如能够由将指示这样的期望的命令提供给移动设备102的用户所指示的，则在子步骤710处移动设备另外地将指令web服务器建立这样的通信链路的命令发送到web服务器。
另外，在子步骤712处，移动设备102另外地将另外的web标识信息发送给web服务器104，允许该web服务器与CPW 106建立通信链路，并且充当用于与该CPW进行其通信的移动设备的代理。在一些实施例中在子步骤712处发送的标识信息能够与子步骤704的标识信息相同，在该情况下不需要执行子步骤712。一旦在子步骤712处已经提供标识信息，则在子步骤714处在移动设备与web服务器之间建立了推式信道链路。一旦完成了子步骤714，则能够执行在步骤602之后的由图6表示的处理的剩余步骤(如由框“返回到A”所指示的)。
返回到图6，一旦在步骤602处建立了与web服务器104的通信链路，则在步骤604处移动设备102经由推式信道(例如，在子步骤714处建立的推式信道)从web服务器接收高重要性信息。如已经参考图4-5所描述的，在本实施例中以异步的方式，也就是，在不是由移动设备确定的时间将该信息从web服务器104提供给移动设备102。除了在异步的基础之上接收这样的高重要性信息之外，如由后续步骤606所进一步表示的，移动设备102能够另外地将与待由web服务器下载到移动设备的其它信息有关的一个或多个查询发送到web服务器104。如在上文中参考图5所讨论的，尽管高重要性信息能够包括诸如状态更新信息的信息，但是其它信息(例如，低重要性信息)能够包括诸如联系人/朋友信息、新朋友信息、联系人列表、相片或视频、特殊消息、新闻或者事件信息。
在步骤606处由移动设备102提供的查询能够在定期性的基础上或者在由该移动设备确定的其它时间被提供。尽管在本实施例中设想移动设备102将确定何时对web服务器104进行查询，该查询进而确定是否将除了高重要性信息之外的信息从web服务器传送到移动设备，但是在其它实施例中这样的查询和/或信息的下载能够在通过web服务器与移动设备之间的双方协定所确定的时间、在由web服务器独自单独地所确定的时间(例如，当web服务器已经确定已经收集到足够量的低重要性信息时)、或在诸如已经对两个设备进行编程的制造商的另一实体或一方所确定的时间发生。无论其是否是来自移动设备102的促使通过web服务器104将信息往回发送到移动设备的查询或者其是否是促使发送这样的信息的其它触发，如在步骤608处所指示的，最终还由移动设备从web服务器接收到这样的其它信息。尽管步骤602能够被认为是图4的步骤402的补充，但是步骤604-608能够被认为是由图4的步骤406-412(并且特别地步骤414-412)表示的web服务器操作的补充。
仍参考图6，在后续步骤609处，由移动设备102从web服务器104接收到的信息通过移动设备来显示或以其它方式输出。这样的信息的显示/输出发生的程度将取决于实施例。在至少一些实施例中，信息通过移动设备102以标准化的方式来显示/输出，使得CPW特定格式信息或特征不被提供为所显示的/输出的信息的一部分。更具体地在一些这样的实施例中，CPW特定格式信息和特征由web服务器104、或者在一些替代实施例中由移动设备或web服务器和移动设备两者的组合来编校。
在执行这样的编校中，在不同的CPW处发现的类似类型的信息，即使通过不同的CPW以不同的方式引用(例如，如在发布站点发现的信息或代替如在背景墙上发现的信息)，也被识别为在概念上类似类型的，并且基于这样的识别，这样的信息能够以常见的方式被显示(可输出)在移动设备上，而无论信息的起源如何。也就是说，考虑到这样的CPW特定格式信息或特征的编校，来自不同的CPW的相同的概念类型的信息，即使在不同的CPW处不同地格式化，仍然以相同或类似、一致的方式被显示在移动设备上，而无论该信息的起源如何，因此有助于用户的对这样的信息的回顾。应当进一步注意到，这样的信息能够不仅包括文本和图像数据而且包括广泛的各种其它数据，包括支持在移动设备上的交互式窗口和数据条目字段的显示的数据，用户能够将然后能够被发送回到web服务器的另外的信息或命令键入到交互式窗口和数据条目字段中。
接下来，在步骤610处，移动设备102确定是否存在将在移动设备处当前可用的内容信息上传到web服务器和/或最终地上传到CPW106的需要或期望。例如，基于是否已经由移动设备从用户或其它来源接收到特定类型的信息或者特定的事件是否已经发生或者触发这样的上传事件的时间是否已经过去，该需要或期望能够由移动设备102自动地确定。通常，响应于提供给移动设备102的用户命令，这样的需要/期望将发生。如果在步骤610处，确定不存在这样的需要/期望，则如所示该处理前进到下文中所讨论的步骤622。然而，如果在步骤610处确定存在这样的需要/期望，则在步骤612处移动设备102将内容信息发送到web服务器104并且在步骤614处移动设备另外地将用于将该内容信息上传到CPW 106的命令发送到web服务器。步骤610-614能够被理解为通常为图4的步骤418-428的补充，除了在如参考步骤418所讨论的从移动设备102提供以用于认证目的的标识信息能够被理解为已经在图6中所示出的步骤602处提供(替代地，适合于这个目的的另外的标识信息能够被刚好在步骤612之前提供)的范围内除外。
一旦完成步骤614，则在步骤616处，移动设备102进一步确定是否存在将内容信息上传到除了该信息已经被上传到的第一个CPW以外的一个或多个另外的CPW的需要/期望。再者，该需要或期望能够基于包括除了别的以外由移动设备的用户提供给移动设备的一个或多个指令的各种因素来确定。如果在步骤616处确定不存在这样的需要或期望，则该处理再次前进到下文中所讨论的步骤622。然而，如果在步骤616处确定存在这样的需要或期望，则处理前进到步骤618，其中经由web服务器在移动设备与这样的另外的CPW之间建立另外的通信链路。步骤618能够被视为图4的步骤432-436的补充并且取决于实施例能够包括子步骤，其中移动设备首先确定与这样的另外的CPW的通信链路是否已经存在，并且如果确定这样的通信链路还不存在，则将另外的标识信息发送到web服务器以与这样的另外的CPW建立通信链路并且允许web服务器在这样的通信中充当移动设备的代理。
一旦在步骤618处与另外的CPW 106建立了另外的通信链路，则在步骤620处移动设备102进一步将用于将内容信息上传到该另外的CPW 106的命令发送到web服务器104。步骤620的执行能够被理解为对应于图4的步骤430，要进一步理解的是，步骤618和步骤620的执行的顺序是可逆的，使得那些步骤更接近地对应于图4的步骤430-436的顺序。另外参考图6，一旦完成步骤620，则假定web服务器104实际上将内容信息上传到另外的CPW。尽管未示出，但是在一些实施例中，一旦完成这样的上传，则web服务器104将确认这样的上传已经发生的指示信号发送回到移动设备102。
尽管图6的上述步骤以及图4的步骤将web服务器104的使用预想为移动设备102与CPW之间的中间物，但是web服务器不必一直调解这样的通信而是在一些情况下移动设备直接(也就是说，直接经由不包括任何web服务器、或者至少不包括如上文所描述的web服务器的一个或多个网络)关于CPW中的一个或多个进行交互。在该点上，一旦完成步骤620(或，在一些情况下，如上文所讨论的步骤610和步骤616)，则在步骤622处移动设备102进一步确定是否存在移动设备与CPW 106中的一个或多个直接进行通信的需要或期望。
如果在步骤622处移动设备102确定这不是该情况，则移动设备能够将其操作返回到节点A，响应于此，该处理在步骤604处再次开始并且向前进行。假定这个发生，移动设备102因此继续不仅从web服务器104接收信息而且也继续操作以在重复、持续的基础上将内容信息上传到web服务器。然而如果在步骤622处移动设备102确定存在直接与CPW 106进行通信的需要或期望，则移动设备继续进行到步骤624，在该处移动设备建立这样的直接通信链路。
是否存在直接与CPW 106进行通信的需要或期望能够基于各种考虑来确定。在一些情况下，移动设备102对此自动地确定并且因此自动地继续进行以与CPW 106建立直接通信链路。例如，如果用户请求关于特定主题的更多的信息并且从给定CPW的该信息的下载经由与CPW的直接通信来最好地完成(例如，就数据传输的效率等等而言)，则移动设备能够尝试直接连接到CPW。而且，可能在一些情况下，用户可能希望查看在特定CPW处可用的具有与该CPW相关联的特定格式的信息，并且可能不希望查看这样的信息的编校的视图，如在信息到移动设备的途中被web服务器104处理的情况下可能提供的。而且，是否存在直接与CPW 106进行通信的需要或期望的确定能够基于明确地请求这样的通信的用户命令的接收来确定。
取决于实施例，在步骤624处的直接通信链路的建立能够包括各种特定的命令或移动设备的操作，其在一些环境下能够包括从用户接收输入。例如，在一种环境下，用户通过使浏览器应用/程序在移动设备上打开和运行并且通过将用于CPW的URL(统一资源定位符)键入到由浏览器提供的输入字段来发起这样的直接通信链路的建立，因此浏览器进入与CPW的通信中并且CPW进而将网页或其它信息返回到浏览器，移动设备(和用户)由此能够参与与CPW的进一步的通信。在其它实施例中，直接通信链路的建立是不包括任何特定用户动作的自动处理。
无论如何建立直接通信链路，一旦建立了该链路，则在进一步的步骤626处移动设备102直接将信息发送到CPW 106和/或直接从CPW106接收信息(再次，没有上文所描述的web服务器的调解)。随后，在步骤628处，移动设备进一步确定是否存在停止与web服务器104的现有通信链路的需要/期望。如果不存在这样的需要/期望，则处理返回到节点A并且再次步骤604和后续步骤被重复。也就是说，在移动设备与CPW之间的直接通信(没有web服务器调解)和间接通信(经由web服务器)两者能够同时地继续。然而，如果在步骤628处确定存在停止基于服务器的通信的需要或期望，则处理前进到步骤630，在该处与web服务器的移动设备通信被中断(其对应于在上文中关于图4所讨论的步骤440)。
在本实施例中，如上文所讨论的，web服务器104被配置成将其本身维持在其先前代表移动设备与其进行通信的CPW或站点的通信中，即使在与移动设备的通信已经终止之后，其中web服务器继续充当移动设备的代理。然而，在其它实施例中，当移动设备终止其与web服务器的通信时，web服务器与CPW的通信被切断。在任何情况下，在步骤630之后，在步骤632处可能存在代表移动设备与web服务器重新建立通信的新的需要或期望。正如在步骤622处确定是否与CPW106进入直接通信或者在步骤628处停止与web服务器104通信的情况下一样，在步骤632处是否存在代表移动设备102重新建立与web服务器104通信的需要或期望能够基于各种考虑中的任何一个，包括例如触发这样的活动的用户命令、电池电源考虑等。如果在步骤632处确定应当重新建立基于服务器的通信，则处理返回到开始步骤600。如果不是，则在结束步骤634处结束由图6表示的处理。
分别转向图8和图9，在进一步的实施例中，由web服务器104和移动设备102执行的操作能够与图4-7中所示的那些稍微不同。更具体地，在一些其它实施例中，web服务器104不是执行图4中所示的节点B与节点C之间的步骤408-416，而是以不同的方式操作，包括图8中所示的步骤800-814。如所示，一旦从节点B行进，则web服务器104不是执行处理步骤408(和图5中所示的对应步骤)，而是执行步骤800、802以及804。特别在步骤800处，web服务器104确定在步骤406中刚刚从CPW 106获得/拉的信息与在更早时间从该CPW先前接收到的信息之间是否已经发生改变。如果在步骤802处检测到改变，则在步骤804处web服务器104的前端部分308将该改变信息放到改变列表中。在这些步骤与web服务器104与其联系的多个CPW有关地重复地被执行的情况下，与CPW中的每一个有关地检测到的改变信息能够全部被置于改变列表中，在该情况下其能够被称为通用改变列表。
接下来，在步骤806处，web服务器104的前端部分308确定经处理的信息是具有高重要性还是不具有高重要性(例如，低重要性)。在执行这个确定中，能够考虑到与在上文中与图4的步骤410有关地所讨论的相同的考虑，并且因此在图8中步骤806还被标记为步骤410。取决于经处理的信息是被确定具有高重要性还是低重要性，该处理然后相应地前进到步骤808或步骤810。在步骤808中，一旦已经确定经处理的信息具有高重要性(例如，信息关系到状态更新)，则web服务器104的前端部分308经由推式信道将指示已经发生高重要性改变的通知发送到移动设备102。同样地，在步骤810处，一旦已经确定经处理的信息具有低重要性，则web服务器104的前端部分308经由推式信道将指示已经发生低重要性改变的通知发送到移动设备102。
一旦在步骤808或步骤810中已经发送了通知，则在步骤812处web服务器104的前端部分308在稍后的时间能够从移动设备102接收用于自身发送该改变信息的请求。能够在如由移动设备102确定的任何时间接收该请求。通常，如果改变信息具有高重要性，则移动设备102将在步骤808处接收到通知之后立即或非常快发送对于该信息的请求。与此相反，如果改变信息具有低重要性，则移动设备经常常等待直到对于这样的请求的预定时间(例如，定期性或非定期性轮询时间)已经到达为止。例如，设备可以等待不超过5分钟来请求高重要性信息并且在请求之间等待15-30分钟来下载低重要性信息。在任何情况下，一旦在步骤812处从移动设备102接收到对于改变信息的传输的请求，则所请求的改变信息随后由web服务器104的前端部分308发送到移动设备102。在本示例中，优选的是，这个改变信息不通过推式信道来发送，或者替代地仅高重要性改变信息通过推式信道来发送，以减少移动设备被加电以接收该改变内容的时间量，然而认识到在其它实施例中所有的改变信息都能够经由推式信道来发送。一旦在步骤814处发送这个信息，或如果在步骤812处未接收到对于该信息的请求(或至少在预定时间段内未接收到)或如果在步骤802处在从CPW 106接收到的信息中未检测到改变，则该处理返回到图4的节点C(并且因此返回到步骤418)。应当认识到，如果没有内容应当需要用于上传到内容提供商网站，则当其将继续从内容提供商网站106拉内容时web服务器104将返回到步骤406，与内容是否正被上传到移动设备102客户端无关。
尽管在本示例中，在步骤808和812处经由推式信道以相同的方式来提供改变信息的通知，而不管该改变信息是具有高重要性还是具有低重要性，但是这个不必一直是这种情况。在其它实施例中，例如，有关高重要性改变的通知能够比有关低重要性改变的通知更迅速地、或以某种其它方式被发送。另外，虽然在图8的本示例中在步骤814处改变信息的发送发生在与在步骤808、810处的通知的发送不同的时间，但是这个不必一直是这种情况。例如，在一个其它实施例中，在高重要性改变信息的内容为小的(例如，小于100个字符的文本消息)的情况下，该内容能够与高重要性改变的通知一起(或者甚至充当高重要性改变的通知)被提供。从上述描述中，还应当显而易见的是，在至少一些实施例中，就与CPW 106和移动设备102的不同部分的相应的通信而言，后端部分的操作能够大体上或完全地与前端部分的操作无关。取决于实施例，各种不同类型的通信，例如包括拉或轮询的那些、或定期性或异步的通信能够被任一端部分采用，而不管另一端部分的操作。因此，后端部分306能够连续地从CPW 106拉内容并且将改变发送到前端部分308，而不管前端部分正在做什么。前端部分308能够同样地推到移动设备102并且等待请求下载改变内容，或使服务器和移动设备同步，而不用关心在任何特定时刻后端部分306正在做什么。
至于图9，在其中所提供的流程图示出了在一些其它实施例中，如何不是执行图6中所示的节点A与节点D之间的步骤604-609，而是移动设备102以包括步骤900-914的不同的方式操作。图9中所示的由移动设备102执行的步骤900-914是特别地相对于图8中所示的由web服务器104执行的步骤800-814的补充。如图9中所示，一旦从节点A继续，则移动设备102不是执行图6的接收步骤604，而是能够从web服务器104接收在从CPW 106最近并且在更早时间提供的信息中已经检测到一个或多个改变的通知(在步骤808、810中的一个或两者处发送的)。如果在步骤900处接收到通知，则在步骤902处移动设备102确定该通知是指示该改变具有高重要性还是具有低重要性。
如果在步骤902处确定该改变具有高重要性，则在步骤904处移动设备102确定是否应当立即从web服务器104获得该高重要性改变信息。尽管在一些实施例中一直是应当尽可能快地获得高重要性改变信息的情况，但是在其它实施例中，由于各种原因移动设备仍然能够确定将优选地推迟尝试从web服务器获得该信息(例如，因为移动设备电量低)。假定在步骤904处移动设备102确定应当立即获得改变信息，则处理前进到步骤906，在该处移动设备立即将用于请求将高重要性改变信息立刻提供给移动设备的请求信号发送到web服务器。作为响应，在步骤908处，移动设备102最终从web服务器接收到所请求的改变信息(或该信息中的至少一些，如由web服务器104所确定的)。在这点上，步骤908的执行补充了图8的步骤814的执行。
如果替代地在步骤902处由移动设备确定该通知指示改变信息具有低重要性，或如果在步骤904处移动设备确定不应当(或需要)立即获得改变信息，则处理前进到步骤910。在步骤910处，移动设备102进一步确定用于轮询web服务器104以获得改变信息的适当时间是否已经出现。这样的适当时间可以是定期性出现的时间，或在其它实施例中，能够由移动设备102基于各种其它考虑(例如，自从另一事件已经流逝的预定量的时间，或如接收到指令移动设备从web服务器104获得内容信息的用户命令)来确定。
如果在步骤910处用于轮询web服务器的适当时间仍然未出现，则处理能够重复该步骤直到这样的时间出现(或能够前进到处理的另一步骤和/或可能地在不同的时间返回到步骤910)为止。然而，如果在步骤910处适当时间已经出现，则处理前进到步骤912，在该处轮询/请求信号由移动设备102发送到web服务器104。一旦发送了该信号，则该处理返回到移动设备102接收所请求的改变信息的步骤908。进一步如图9中所示，一旦完成步骤908，则移动设备102继续进行执行步骤913，其中所接收到的信息由移动设备102来显示或以别的方式输出以支持移动设备的用户对信息的回顾。如所示，步骤913能够相同于或类似于图6的步骤609。
虽然在步骤908处由web服务器104发送的改变信息常常是移动设备102的用户最感兴趣的，但是这个改变信息常常不包括在由web服务器对该信息进行处理之前在CPW 106处原始可用的各种内容(以及格式化)信息。也就是说，虽然由web服务器104提供的信息能够包括诸如事件、最近的状态信息、来自其它人的评论等的各种内容，并且虽然移动设备102也能够理所当然将某个标准信息显示为其用户界面的一部分(例如，用户的名称、用户与其联系的CPW等)，但是由于web服务器104的调解而造成相当量的内容和/或其它信息能够被排除在外。因此，一旦在步骤913处显示了改变信息，则用户可以决定不仅获得改变信息而且获得其它内容(或甚至格式化)信息将是所希望的。如果用户希望获得这样的其它信息，则在后续步骤914处移动设备进一步确定是否已经接收到用于获得不是在步骤908处从web服务器104接收到的其它信息的用户命令。例如，当用户选择由移动设备显示的图标时，能够接收到这样的命令，其在步骤913处可以被显示为改变信息的一部分。
如果在步骤914处确定接收到这样的命令，则在步骤916处移动设备102与CPW 106建立直接通信链路。建立直接通信链路的这个操作能够相同于或类似于与上文所讨论的步骤624相关联的操作，并且能够包括被设计成既建立通信链路又发出用户所期望的其它信息的标准的基于web的客户端-服务器通信(例如，包括统一资源定位符(URL)的输入/传输和/或与CPW 106的web页面进行对接)。因此，一旦在步骤916处建立直接通信链路之后，则在步骤918处从CPW 106接收用户所期望的其它信息。一旦完成步骤918，以及在确定在步骤914处没有接收到用户命令的情况下或在步骤900处接收到来自web服务器104的通知的情况下，则该处理返回到节点D并且继续图6的步骤610。
在本发明的另一替代实施例中，后端部分306包括多个插件或处理器，其中的每一个都与相应的CPW 106相关联。每个插件都包括用于其关联CPW 106的应用编程接口(API)。每个插件都使用超文本传输协议(HTTP)以持续地从其相应内容提供商网站106拉信息。
当后端部分306插件检测到改变时，改变被加载到队列中并且前端部分308将通知推到移动设备102。后端部分306中的所有插件将继续向队列加载根据包括例如信息源的ID(源内容提供商网站标识)、用户设备的账户ID、内容类型、优先级以及信息的通用格式所格式化的信息。例如，对于状态，格式可以为：类型(状态、情绪、STATUS_AND_MOOD)、动作(清除状态或更新状态)、提供商、聚合服务账号id、外部id、如果更新是用于朋友的朋友id、状态文本、发布日期和时间。web服务器104通过将由所有的插件拉的内容组合到用于每个相应设备(或用户账号)的通用改变列表中来为每个用户设备(或用户账号)构建统一的订阅源。内容被随着时间的推移而构建，并且每个条目能够被加时间戳。
以下算法能够用于检测在服务器同步期间的改变，其中服务器同步被理解成包括web服务器104与CPW 106的同步(通过比较，客户端同步能够被理解成包括诸如移动设备102的客户端与web服务器的同步)。web服务器104程序维持用于每个账号的三个号码：cla、w1以及w2。cla是改变列表锚，w1是改变列表窗口的开始时间(采样)，而w2是改变列表窗口的结束时间(采样)。服务器104存储落入窗口[w1，w2]内部的改变列表的部分。在服务器同步期间(即，后端部分从CPW拉)找到的所有改变用等于当前w2(即，在w2递增1之前)的同步锚被加戳。一旦窗口大小达到或超过最大窗口大小mw，则该程序就暂停服务器同步(内容提供商网站大小同步)。一旦暂停，则当接收到新的客户端轮询时服务器将恢复服务器同步。其它变量是作为客户端锚的ca，OFF是指示没有同步活动的标记。cla、w1以及w2的值根据以下状态转变规则来更新：
Figure BDA0000142646310000281
当客户端轮询以获得改变时，如果客户端锚ca落入[w1，w2]内部，则部分同步将工作并且服务器发送回落入[ca，w2]的改变(并且删除比ca老的改变)。在对同步作出结论后，ca将被更新。如果当客户端轮询以获得改变时，客户端锚落在[w1，w2]的外部，则在web服务器104与移动设备102中的客户端程序之间将发生新的完全同步。
设想当窗口大小达到mw时服务器同步(后端插件拉用于特定设备102的内容)能够针对特定移动设备102账户被暂停，在此情况下在缺少客户端轮询的情况下稍有丢失的推(到设备的通知)可能造成设备的服务中断。设想如果自上一个w2以来存在未决的改变，则对于发送推式可能是有利的，只要自w1以来存在未决的改变，则能够发送推式。
进一步设想在本文中所描述的中间web服务器104能够有利地与于2009年5月21日提交的、题为A MOBILE COMPUTING DEVICEAND METHOD WITH ENHANCED POLING MANAGEMENT的美国临时申请61/180,301中所描述的设备轮询管理器一起使用。
现将对作为上传内容的示例的还被称为图片的照片上传进行描述。通过将照片缓存在中间web服务器104存储器302处，能够采用中间web服务器104来优化将照片从用户设备102上传到多个社交网系统106的处理。示例性流程可以为如下：
1.在步骤1002处，中间web服务器前端308向后端部分306指示用户设备102上传了照片(图10)；
2.在步骤1004处，web服务器前端或后端部分将照片URL和系统范围的唯一照片ID给予新照片；
3.在步骤1006处，照片ID被下载到设备102，响应于此，设备客户端程序将照片ID与照片名称相关联；
4.在步骤1008处，后端通过HTTP将文件下载到诸如/tmp/uniquephotoid.tmp的位置；
5.在步骤1010处，与目标内容提供商网站中的每一个相关联的相应后端部分306插件为每个内容提供商网站提交work.uploadPhoto以上传这个照片文件；
6.在步骤1012处，后端部分将照片分享的成功或失败的报告往回提供给前端部分；
7.在步骤1014处，前端能够可选地向用户设备102通知成功或失败；
8.在步骤1016处，在预定时间段已经过去之后，该照片被删除。
在操作中，来自用户设备102的照片从用户设备102上传到网络的前端部分308，如由步骤1102(图11)处所指示的。前端部分308或后端部分306将照片缓存在中间web服务器302中持续预定的时间段以允许在步骤1206(图12)中将同一照片提交到不同系统的网站而不要求该照片由用户设备102再次上传。在预定的时间段之后，该照片将被擦除。预定的时间段可以是任何时间段，并且根据存储器约束和使用的频率来选择。时间段可以例如为24小时，该时间段能够在相片被上传到存储器302的时间开始，从而一旦图片被上传，则设置了该时间段，或者该时间段可以一旦照片上传到内容提供商106就开始，从而每当图片被上传到新的内容提供商时该时间段就被延长。
对于一个示例性实施例而言，在步骤1102(图11)处，相片作为动作与指定的内容提供商网站106的标识一起从移动设备102被上传到中间服务器前端308并且存储在网络服务器的临时存储器中。在步骤1004(图10)处，前端308将该照片转发到后端306中的插件，该插件能够例如专用于由移动设备指定的内容提供商网站。在步骤1006处，网络服务器前端部分308还将包括与所保存的相片相关联的照片标识(ID)的消息往回发送到用户设备102。照片ID标识位置或指向在web服务器存储器302处存储照片的位置的指示器。在步骤1104中移动设备接收照片ID并且如在步骤1106中所指示的将照片ID与照片的名称相关联(映射)。随后，在步骤1108中，如果移动设备102经由用户接口选择将同一照片发送到不同的社交网系统，则移动设备将照片ID而不是实际的照片发送到网络服务器。作为响应，中间服务器104将检索照片并且将其转发到专用于另一内容提供商网站106的另一插件，如步骤1204(图12)中所指示的。在步骤1110中，设想一旦从存储器302中移除照片，则更新将被发送到用户设备102以便用户设备移除照片名称和照片ID的关联，使得设备将上传该相片。如果另一方面不再存储照片，并且服务器接收到用于上传与照片ID相关联的照片的请求，则前端部分将错误消息发送到订户设备，响应于此，该订户设备将被邀请再次上传该照片。
对于其它实施例而言，web服务器后端部分306将确定从用户设备102上传的相片是否在目标社交网系统的必要限制(例如，尺寸和大小)内。设想当从存储器302中移除图片时这个能够由与每个内容提供商网站相关联的插件来处理，因为每个插件都能够存储对于相片的内容提供商网站的限制。如果满足限制，则后端306能够将照片一直发送到目标内容提供商网站。否则，照片将根据内容提供商网站的要求来调整大小。为了调整相片大小和/或将照片缩放到目标大小，确定了调整大小因子。能够被用来确定调整大小因子X的特别有利的算法为如下：
x/100＝((t-f)/(kc))^(0.5)
其中
x是调整大小百分比
t是以字节为单位的目标大小，并且可以例如大约1兆字节或更小，并能够有利地小于200,000字节，并且在一个实现中是100,000字节。
f是用于文件大小的小容差因子
k是常量因子，并且可以小于1，以及有利地能够小于0.5，而且在一个实现中被选择为0.23。
c是以字节为单位的原始文件的大小。
通过将相片存储在web服务器104中，通过准许移动设备在不同的时间将媒体发送到不同的社交网络服务器同时通过设备通过其进行通信的局域网或广域网将该媒体仅仅上传一次，服务器有助于减少设备的电力消耗和通信网络上的带宽负担。此外，web服务器能够采用每个内容提供商网站所期望的格式的媒体，并且设备不必知道或适应这些需求以成功地上传该媒体。
还设想，能够在步骤1302(图13)中经由中间web服务器104将照片下载到设备102。例如，对于RSS新闻订阅源而言，来自RSS内容源的照片由具有新闻订阅源概要的后端新闻订阅源来拉。当在步骤1304中后端306检测到这样的新闻信息是新的，或者换句话说自由后端部分从这个CPW拉先前的RSS新闻订阅源以来已经发生改变时，则服务器104的后端部分306将针对客户端设备将在步骤1306中适当地格式化的订阅源传送到前端部分。前端部分308将向客户端设备102生成低优先级推式通知并且设备102的队列将装载有概要和照片。当客户端设备此后将轮询请求发送到前端部分以获得内容时，在步骤1308中前端将传送包括包含已格式化的照片和概要的该新闻订阅源的队列的内容。移动设备102上的客户端程序将会将概要和关联的照片显示在移动设备102显示器216上。通过示例的方式，如果输入210包括在显示器上的触摸传感器(通常被称为触摸屏)，则用户能够在概要和照片处触摸该屏，并且用户接口将通过链路110直接连接到与新闻订阅源概要/照片相关联的内容提供商网站并且将有关该新闻订阅源的另外的信息加载在显示器216上以供用户查看。后端部分306因此检测并且格式化用于该设备的新照片和概要，并且前端部分308向设备通知内容是可用的并且响应于来自设备的轮询请求而将新闻订阅源下载到移动设备102。
进一步设想，移动设备102中的客户端程序将存储有关用户具有服务器帐户的每个内容提供商网站的内容类型和特性的一些定义。在步骤1502中，设备的用户接口将根据用户在服务器上设定哪些账号而变化。例如，假定用户在他们的web服务器104帐号上进入FacebookTM和TwitterTM。当用户与用户接口交互以构建待上传到内容提供商网站的消息1402(图14)时，用户接口显示器呈现用于消息将被发送的目标内容提供商网站的“Facebook”、“Twitter”或“所有”的选择(未示出)。在步骤1504中，取决于做出了哪个选择，用于消息的参数可以是不同的(例如，字符的数量)。如果用户选择所有，则长度1404将是两个内容提供商网站限制中的较短的。进一步设想能够提供长度计数1404和告警1406。在步骤1506中当用户键入文本时，在达到限制之前准许的剩余字符被显示在字符限制1404中。在步骤1514中，在某个阈值处，诸如30个字符，将显示告警1406。在步骤1516中，当超过限制时，剩余字符将转向负计数，或者用户将被阻止输入另外的字符。在用户改变目的地内容提供商源的情况下，限制将适当地改变。例如，如果在创建消息之后TwitterTM网站被添加为目的地，则限制将减小。如果TwitterTM网站作为目的地被移除，则限制增加。
移动设备102生成具有取决于用户设备在中间web服务器上设定的一个或多个内容提供商网站的操作参数1404的用户接口显示216。对于消息，通用消息输入域1402被呈现在显示器216上以供用户输入文本，大小上限基于由被选择为消息文本的目的地的一个或多个社交网网站所准许的最小的最大消息大小。限制能够保留在客户端移动设备上。当消息大小变得在限制的预定量内时，移动设备客户端程序能够生成告警1406。如果在步骤1508中一个或多个社交网网站改变，则在步骤1510中限制改变。来自用户接口输入的内容填充了消息输入区域1402，并且当达到限制时能够生成告警。客户端程序用一个或多个目的地社交网web网站的身份来传送在步骤1602(图16)处由服务器前端接收到的消息。后端部分在步骤1604中针对一个或多个目的地网站对消息进行格式化并且在步骤1606中以社交网网站所期望的格式上传该消息。
从以上描述中，应当明显的是，采用诸如上文所讨论的那些的许多不同的操作步骤的各种方法均由本发明包括。此外，除上文所描述的具体实施例以外本发明还旨在包括各种替代实施例，包括采用具有除了或代替上文所描述的那些以外的其它操作步骤的方法的实施例，以及采用具有以除了或代替上文所讨论的步骤的特定顺序或组合以外的各种顺序或组合的步骤的方法的实施例。进一步应当明显的是，根据上文所描述的实施例中的一个或多个的系统在就促进由用户操作的移动设备与社交网网站之间的交互而言的在若干方面中能够提供增强的功能性。取决于实施例，能够增强用户与社交网网站之间的通信的质量、如移动设备用户所体验的社交网网站和关联的事务处理的用户友好性、和/或移动设备与这样的网站之间的通信的效率中的任何一个或多个。
图17图示了另一示例性通信系统1700。图中的通信系统1700包括中间web服务器1704，在本文中还被称为web服务器、媒介web服务器、聚合服务器、或聚合服务。web服务器1704可以包括内容提供商处理器1716、核心服务处理器1718以及存储器1714，如下文进一步详细地描述的。
web服务器1704在一个或多个用户设备1702和1703与一个或多个内容提供商网站1706-1708之间交换信息，所述一个或多个内容提供商网站1706-1708还可以被称为内容提供商、社交网网站、新闻源或新闻订阅源。用户设备1702和1703可以是在本文中所讨论的用户设备中的任何一个。响应于来自用户设备的轮询，中间web服务器1704从内容提供商网站1706-1708拉信息并且使信息对用户设备1702-1703可用。用户设备1702和1703还能够经由中间web服务器1704将内容推到内容提供商网站。此外，用户设备1702、1703能够通过互联网1705经由直接连接1720直接访问内容提供商网站(CPW)1706-1708，所述互联网1705还可以被称为万维网或简单地称为web。
用户设备1702和1703、中间web服务器1704、以及内容提供商网站1706经由互联网1705连接，并且由第一互联网网络1705’和第二互联网网络1705”来图示。根据对于每个设备1702和1703的设置、根据选择的与每个特定内容提供商相关联的应用程序接口(API)，中间web服务器1704经由互联网网络1705”访问内容提供商网站使得可访问的内容，并且以容易处理的格式使内容对用户设备可用。中间web服务器1704还接收通过互联网1705或经由诸如蜂窝网络的另一通信网络传送的、源自用户设备1702和1703的内容，并且以用于相应内容提供商网站的适当格式将该信息提供给适当的内容提供商1706-1708。
图18图示了又一示例性通信系统1800，其中，用户设备1802经由互联网网络1805连接到中间web服务器1804。图18中被图示为移动设备的用户设备1802还可以经由P2P载波连接1822连接到中间web服务器1804。中间web服务器1804经由互联网1805连接到内容提供商网站1806-1808，并且经由P2P连接1821连接到运营商网络1820。运营商网络1820可以包括可以具有到后端插件的连接的地址簿。
中间web服务器1804包括内容提供商处理器1816以从内容提供商网站1806-1808拉信息，处理信息以标识新内容，并且如果标识了新信息，则生成发送到核心服务处理器1818的通知。该信息可以被本地地存储在web服务器1804内的存储器1814中。核心服务处理器1818向用户设备1802、1803通知新信息是可用的并且存储用户设备信息以用于与用户设备同步。核心服务1818对来自用户设备1802和1803的轮询做出响应以将内容提供给相应用户设备。
由用户设备1802或1803传送的信息还可以通过web服务器1804发布到内容提供商网站1806-1808。从用户设备1802或1803提供的内容由核心服务处理器1818来接收，由内容提供商处理器1816来格式化以与内容提供商网站1806-1808中的一个或全部兼容，并且发送到适当的内容提供商1806-1808。
内容提供商网站1806-1808的示例包括社交网络网站(SNW)，诸如FacebookTM、TwitterTM以及MyspaceTM。其它内容提供商网站可以是照片网站，诸如PhotobucketTM、或者新闻源，包括提供简易信息聚合(RSS)订阅源的任何源或新闻内容的任何其它源。上述示例不被认为是详尽的，而是能够为用户设备提供内容的源的类型的示例。源可以包括用于移动设备的特殊内容，或者用于个人计算机的内容。
还可以被称为后端、后端部分、或社交网络处理器(SNP)的中间web服务器的内容提供商处理器1816包括用于每个内容提供商的相应插件1824。每个插件1824都可以具有相应的处理器和/或存储定义的程序或API，以用于从其相应的内容提供商拉内容并且用适当的格式将信息从设备上传到相应的内容提供商。
核心服务处理器1818还被称为前端。核心服务处理器1818包括web支持门户应用服务器1826、核心web服务应用服务器1828、以及推式服务器1830。核心服务处理器1818和内容提供商处理器1816连接到存储器1814，所述存储器1814充当临时储存器或缓存，其能够例如使用分割成数据库的大存储器系统来实现。
如图18中所图示，移动设备1802能够经由诸如有线以太网或无线802.x连接的局域网或经由蜂窝网络连接到基站1832。运营商能够通过基站1832与负载平衡器和防火墙SSL 1834之间的P2P连接1822连接到中间web服务器。运营商基站1832还能够通过互联网1805连接到中间web服务器1804。P2P连接1821还可能存在于插件1824与运营商网络1820之间。
推式服务器1830可以例如通过TCP连接连接到用户设备1802。核心web服务服务器1828和web支持门户1826可以经由HTTP连接来连接。插件1824还可以经由HTTP连接与内容提供商网站1806-1808进行通信。
如上文所讨论的，相应的插件1824支持诸如FacebookTM、TwitterTM、MySpaceTM的社交网网站和诸如RSS、ATOM、Podcasts等等的内容订阅源。此外，插件1824可以被提供用于发消息门户，诸如YahooTM邮件、GoogleTM邮件、以及MicrosoftTM邮件。然而，电子邮件服务仍然可以由移动设备1802和1803直接访问，并且来自邮件服务的联系人列表经由前端服务进行备份。数据聚合(从内容提供商到设备的信息)和通知API(从设备到内容提供商)可以支持各种活动，诸如状态、通知(新的邮件、订阅源改变)、朋友订阅源、以及朋友/联系人。web服务器1804还支持推式信道(以向设备提供通知)、空中软件供应、对于设备的中间web服务器的设定和配置(例如，用户的账号、偏好等)以及web服务。中间web服务器1804特征是用户设备安全性、基于微件的web访问、设备备份和恢复、以及运营商支持工具。
中间web服务器1804可以向设备1802或1803提供账户管理、推以及数据服务。账户管理服务可以提供设定和设备设定、支持服务标识、用于用户的服务器设置以及其它账户/用户配置。推式服务可以提供用于向设备通知其具有新内容或可用数据的服务，因此支持向用户及时呈现诸如状态、新闻以及朋友更新的动态数据，而无需用户设备必须直接轮询内容提供商。数据服务可以包括对于设备上传、检索以及用于各种类型的数据的同步服务。例如，订阅源将从内容提供商网站检索到的信息提供给设备，上传将来自设备的内容提供给内容提供商网站，并且同步使得能够实现设备1802或1803与服务器上缓存的同步。
连接到中间web服务器1804的设备1802或1803首次可以连接到设备设定服务以进行初始设备设定，诸如设置键入电子邮件账户以与聚合服务相关联、设定内容提供商网站以由设备访问、键入密码和用户标识，以及建立诸如语言的偏好。一旦完成了设备设定，则为客户端设备和推式服务建立了持续的TPC/IP连接。当中间web服务器1804检测到已经发生影响用于特定设备的数据的改变时，信号经由推式服务发送到设备。在这个时候由设备决定判断是否直接连接到相关的数据服务并且检索任何新的或修改的数据。例如，设备可以轮询服务器以获得该信息，并且经由用户界面(例如，显示器)将该信息呈现给用户。该用户能够查看该信息，并且决定是否直接访问该源以获得另外的信息。
由插件1824从内容提供商网站1806-1808拉的信息在中间web服务器1804中处理并且与先前的信息进行比较以标识改变。
可从内容提供商1806-1808得到的信息可以具有众多类型。聚合服务1804所支持的那些内容类型被监视以获得改变。当检测到事情时，条目被添加到改变列表以提供给用户设备。改变列表包含从初始化或从最后的改变列表锚开始已经发生的所有事情。事情包括发布，包括但不限于状态或评论，新闻订阅源、社交网络联系人的更新。
更具体地，对于每个内容提供商1806-1808，定义集合被提供用于聚合服务支持的内容类型的子集。与内容提供商相关联的插件1824将从内容提供商网站1806-1808拉所支持的内容。然后可以再检查内容以获得改变。当改变发生时，该改变作为改变列表的一部分被传送到前端1818。
在操作中，服务器1804和设备1802每个都存储改变锚。服务器1804将连续不断地从内容提供商网站1806-1808拉内容以保持与内容提供商网站1806-1808同步。每当后端部分1816拉内容，其检查改变。如果检测到改变，则其被添加到可以被存储在例如存储器1814中的改变列表。设备1802同步到服务器1804以保持在改变上最新的，并且服务器1804和设备1802使用锚来确定要交换多少信息。
以下术语与web服务器1804的后端部分改变同步相关联：
■服务器同步-服务器从数据的原版同步(例如，后端从诸如FacebookTM、TwitterTM等的内容提供商网站的同步)
■客户端同步-移动设备102中的客户端程序与前端同步(核心服务服务器)
■CLA-改变列表锚-采样(时间或改变)在该处如在服务器中记录的发生最后的完全或部分同步(在聚合服务服务器程序处记录的)
■改变列表版本-改变列表可以被给予版本号以帮助同步跟踪
■W1-存储的改变列表窗口的较低的采样(开始)
■W2-存储的改变列表窗口的较高的采样(结束)
■MW-最大窗口大小(能够被指定为时间跨度，改变数量，或时间跨度和改变数量的组合)
■OFF-指示同步是否被暂停的标志
■CA-客户端锚-采样(时间或改变)在该处如在设备中记录的发生最后的完全或部分同步(在聚合服务客户端程序处记录的)。
当在服务器同步期间检测到改变时能够使用以下同步传输队列算法，并且确保新信息被提供给设备使得设备被更新。web服务器1804程序针对每个账户维持三个数值：CLA、W1以及W2。服务器1804程序存储落入在窗口[W1，W2]内部的改变列表的部分。在服务器同步期间发现的所有改变用等于当前W2(即，在W2递增1之前)的同步锚来加戳。一旦窗口大小到达或者超过最大窗口大小mw，则程序就暂停服务器同步(内容提供商web大小同步)。一旦暂停，则当接收到新的客户端轮询时，服务器1804将重新开始服务器同步。CLA、W1以及W2的值根据以下状态转换规则来更新：
Figure BDA0000142646310000391
当客户端1802或1803轮询以获得改变时，如果客户端锚CA落入[W1，W2]内部，则部分同步将工作并且服务器往回发送落入[Ca，W2]内部的改变(并且删除老于CA的改变)。否则，服务器和客户端开始完全同步。当且仅当客户端锚CA小于W1或大于W2(即，CA在窗口的外部)时客户端才需要完全同步。在这种情况下，客户端锚CA是“无效的”。当且仅当改变列表锚CAL小于W1(即，服务器不具有当前改变列表的完整历史)时服务器1804复位其改变列表。服务器1804将窗口[0，W2]发送给客户端，其中“0”告诉客户端其应当进行完全同步。
尽管账户要与单个设备相关联，但是在聚合服务中用户可能想要不止一个设备同步到同一用户账户。在缺少改变列表复位的情况下，多个设备和单个设备一样工作。在改变列表复位的情况下，可能在多个设备之间发生将引起改变列表在服务器上不断地复位的竞态条件。例如，设备1轮询以获得改变，发送无效的CA。服务器1804不具有当前改变列表的完整历史，因此其复位其改变列表。设备1再次轮询以获得改变，使W1往上移动。然后设备2轮询以获得改变，并且由于由设备1的轮询引起的改变列表复位，所以其CA肯定是无效的。然后服务器1804被迫再次复位其改变列表。设备2然后可以再次轮询以获得改变，使W1往上移动。如果设备1然后轮询以获得改变，并且由于改变列表复位所以其CA肯定是无效的并且服务器1804被迫再次复位其改变列表。
为了避免这个竞态条件，服务器1804能够为每个设备保持一个确认的客户端锚(“ACA”)，并且当最小的ACA大于当前的W1时仅将W1往上移动。替代地，服务器可以为W1创建缓冲区，即服务器将不一直将W1往上移动到CA，而是移动到CA或W2-MW/2中的最小值。
在与内容提供商(例如，FacebookTM)进行同步的背景下，由于内容提供商处理器1816(即，SNP处理器或后端部分)不具有数据的原版的事实的原因(即，来自FacebookTM或其它内容提供商网站1808-1808中的一个的数据未被全部拷贝)，并且服务器1804没有本地地存储改变的完整历史，所以服务器1804将需要时不时地(例如，当设备过期时)复位(即，从头开始重建)改变列表。因此，在不同的时间构建的改变列表的背景下，相同的时间戳/同步锚能够意指不同的情况。
考虑图22中所图示的事情2200的以下序列。在图22中，aX意指“添加项目X”，mX意指“修改项目X”，以及dX意指“删除项目X”。
如图22中所见，服务器以仅具有在存储器1814中本地地存储的(m2，a2)的改变列表CL1(2210)开始，并且客户端具有(a1，a2)。客户端发送同步锚t(2212)，其为过期的因此服务器擦除CL1，并且重建改变列表，具有(a2，a3)的CL2(2220)本地地存储在存储器114中。客户端然后带着其同步锚t(2222)回来并且服务器往回发送(a3)。客户端现在具有(a1，a2，a3)，并且失去(d1)。应当已经发生的是服务器往回发送了(a2，a3)并且通知设备进行完全同步。如果这个发送失败，则当客户端再带着t回来时，服务器可能强制完全同步或仅往回发送(a3)。
为了避免这个问题，版本号能够与改变列表一起保存，而不是仅保存个别改变。也就是说，每当改变列表在服务器上复位时，该改变列表的版本就递增1。然后当从客户端接收到老的版本号时，服务器将明确地知道客户端需要完全同步。在另一实施例中，web服务器1804可以为每个设备存储客户端锚，并且当所存储的客户端锚与从设备接收到的同步锚(例如，在上文示例中的t)失去同步时强制完全同步。对于任何给定的改变列表CL和任何给定的改变C，当且仅当C来自其版本低于CL的版本的改变列表时才存在锚(C)＜版本(CL)，然后服务器不必在服务器与客户端之间传送额外的版本号——服务器仅需要将当前改变列表的版本存储在服务器上，并且将传入的客户端同步锚与这个版本号进行比较以确定客户端是否是版本过期的(并且因此需要完全同步)。服务器能够通过从相同序列号拾取同步锚和改变列表来实现这个。
这种方法的一个结果是服务器不再能够将外部的时间戳(例如，伴随FacebookTM消息发生的那些)用作同步锚，而是指派其自己的同步锚。
中间web服务器1804可以以无论哪一种的语言将其通过后端从内容提供商网站1806-1808所拉的内容提供给移动设备1802-1803。例如，如果客户的FacebookTM偏好是法语，则FacebookTM将发送法语的内容，并且该内容将以法语通过中间web服务器1804的聚合服务。这与用户设备和社交网络提供商的直接关系一致，其中，账户持有者不能够在他们的设备上改变语言偏好，而是在社交网络提供商网站上选择语言。
当由后端1816在由web服务器1804支持的“内容类型”中检测到改变时(即，聚合服务)，该后端1816将通知前端部分1818将通知发送到用户设备1802或1803。
web服务器1804还可以插入(sink)新闻订阅源。新闻源可以通过移动设备服务提供商(例如，蜂窝运营商)或用户设备来选择。中间web服务器1804能够为其中利用了用户设备的市场和语言中的每一个提供本地内容。在一个实施例中，中间web服务器1804不可以翻译内容的语言，但是仅可以通过后端部分1816从新闻服务内容提供商所拉的内容。
web服务器1804还可以插入管理订阅源。管理订阅源消息能够通过系统管理者来创建，他们被局部化并且他们以用于设备的正确语言被发送到用户设备。
web服务器1804还可以插入联系人，诸如朋友列表。如果联系人不经常被更新，则聚合服务的前端1818可以偶尔使他们同步，例如，不是一天一次以上或两次。支持异步改变通知的提供商对于这个处理是个例外并且这样的改变被立即同步。
当中间web服务器1804后端1816检测到在社交网络网站中已经更新联系人时，其通过推式信道将低优先级信号发送到在设备1802或1803中存储的聚合服务客户端程序。一旦接收到这个信号，则聚合服务客户端将通过在服务器1804的前端中调用聚合服务的同步web服务来发起双向同步操作。
聚合服务客户端还可以允许用户手动地发起同步。例如，设备1802可以包括使用户能够请求与web服务前端同步的菜单。在聚合服务客户端程序上的联系人的改变可以以“缓慢的”方式与web服务器同步。在将改变发送到服务器前端1818之前，客户端程序将在可配置的时间段中对改变进行批处理。
如上文所讨论的，朋友订阅源是关于社交网网站提供商的网络中的联系人/朋友的信息。当聚合服务检测到新的订阅源元素时，其通过推式信道将低优先级信号发送到用户设备中的聚合服务客户端程序。一旦接收到这个信号，则客户端将使用适当的web服务轮询交换从聚合服务中取得订阅源。订阅源可以包括来自若干内容提供商1806-1808的元素。
状态通常由用户针对多数内容提供商手动地设置，但是聚合服务客户端程序也能够支持即时发消息(IM)风格呈现。状态被监视用于订户(自身状态)并且用于所有的关联朋友(朋友状态)。自身状态还可以使用适当的web服务通过聚合服务客户端程序在提供商中设置。当聚合服务web服务器后端检测到状态的变化(自身的或朋友的)时，其通过推式信道将高优先级信号发送到聚合服务客户端程序。这个推式信号能够在其净荷中有利地包含状态值。
支持状态的社交网提供商将在提供商设置中具有入口。每个提供商都将包括定义如下的状态设置：提供商到提供商ID的映射；状态文本的最大长度；如果支持情绪，则情绪列表和/或可用反应的列表。在一个实施例中，用户或提供商可以键入无效的或空字符串以清除状态。
如果用户正在设置情绪，则用户可以提供该情绪的标识、对该情绪的描述，选择描绘该情绪的预定义图片或为用户选择的图片提供url。
web服务器1804后端1816插件1824能够直接从社交网网站获得状态和情绪更新，并且向核心web服务1828通知任何改变。状态和情绪更新可以包含以下信息：类型(状态、情绪、STATUS_AND_MOOD)、动作(清除状态或更新状态)、内容提供商(例如，内容提供商1806-1808中的一个)、聚合服务账户id、外部id、如果更新是针对朋友则朋友id、状态文本和/或发布日期。如果更新是情绪或STATUS_AND_MOOD更新，则更新可以包括如上文所讨论的id、描述、图片名称和/或图片url。id、描述、图片名称以及图片url被包括以支持定制情绪。Id常常是数字，并且描述、图片名称以及图片url是文本。
一些社交网提供商允许用户按照状态行事。FacebookTM例如允许用户对状态进行评论。TwitterTM允许用户指示喜爱的状态以及答复状态。状态反应提供这个能力并且能够与朋友动作非常类似而且与朋友订阅源和朋友订阅源反应非常类似。
例如，使用聚合服务器1804的一个好处是，通过进行改变列表的定期性的主动复位来有利地消除将改变或更新中的任何一个永久地存储在服务器上的需要。结果，客户端设备将必须执行与聚合服务器1804的更多的完全同步。
因为当窗口大小达到MW时服务器同步被暂停，所以在缺少客户端轮询的情况下很少丢失的推式可以造成设备的服务停歇期。能够采用某些措施来使这种情况不太可能发生。例如，代替仅当自上一个W2以来存在未决的改变时才发送推式，只要自W1以来(或在多个设备情况下自每个设备的ACA以来)存在未决的改变就能够发送推式。这个方式确实导致正被发送的冗余推式和因此客户端的冗余轮询，但是如果W1(或在多个设备情况下每个设备的ACA)被包括在推式消息中则能够最小化后者的不利。
核心web服务应用服务器1828包括核心服务应用，该核心服务应用的主要功能将是从后端1816(社交网处理器(SNP))接收数据并且对其进行封装以传递到客户端设备。这些应用包括朋友订阅源、社交网朋友、发消息/邮件以及新闻。它们可以具有共有的若干属性：数据流可以是从服务器到客户端的单方向的；没有客户端改变可以被往回交付给核心web服务应用服务器1828并且数据不被永久地维持在核心web服务应用服务器1828中。
前端1818能够提供同步传输队列、用于通过同步信道将数据向下发送到客户端设备1802或1803的过渡机构。核心web服务应用服务器1828中的应用能够向传输队列注册它们的同步应用ID，所述传输队列进而向由作为应用的代理的前端1818控制的同步引擎注册。传输队列支持一个或多个条目到队列中的入队。每个条目都能够指定对队列不透明的多个字段，包括一点数据；提供商的名称；项目是否构成添加、修改或删除以及用于条目的唯一ID。同步传输队列不关心指派给这些字段中的任何一个的值；其仅仅以其被排队的顺序对数据进行排序。应用在入队期间不获取任何锁。队列允许应用连续不断地将数据添加到队列中。
前端1818还能够通过用于每个应用的同步锚来提供对客户端状态的跟踪。这个同步锚不可以暴露给应用。前端1818可以进一步当其已经验证了客户端已经接收到它时提供从队列中移除数据。当客户端进来为了其下一次更新请求时，能够容易地确定这个验证；前端1818能够假定客户端设备已经接收和处理了具有在先的同步锚的任何条目。
在期满时段之后前端1818能够清除应用数据。每个应用都能够指定任何数量的限额大小和持续时间对(例如，在一天以后允许不超过1000个条目，在一周之后允许不超过100个条目，以及不允许老于一个月的条目)。核心web服务应用服务器1828可以具有例行地检查队列并且弄清用于任何客户端设备的队列是否不符合的保管服务。保管服务能够通过删除其已经发送给客户端的记录来满足限额。否则，保管服务将为过度限额设备清除队列中的所有的该应用的数据。
当队列不能够履行客户端的更新请求时，前端1818能够调用应用提供的回叫。如果设备已经被擦(例如，擦除)或者如果用户已经脱机足够长使保管服务已经清除了队列，则这种情况可能发生。在这种情况下，应用被通知队列需要复位，并且期望应用从头开始对数据进行重新排队。客户端被返回指示它的锚不再有效的错误代码，并且期望的是客户端将往回复位到锚0。队列进入复位状态直到应用指示其已经重新住入队列为止。直到该时间为止，队列针对任何客户端更新请求而返回零个条目。
前端1818还可以允许应用强制设备的队列的复位。如果应用检测到后端部分已经经历灾难性的故障并且不再能够向应用提供差别的改变，则这可能是必要的。
在核心web服务应用服务器1828中的应用能够向队列提供回叫，所述回叫能够将一系列队列条目转化成用于客户端的有效的改变列表。由于队列是数据不可知论的，所以在其能够被返还到同步引擎以用于传输到设备之前，应用可以对该队列数据进行解释。队列可以是数据库支持的。每逢客户端做出更新请求或队列被复位时，获取锁，但是这不阻止应用继续将数据扔进队列中。
聚合服务web服务器1804暴露两个同步有关的web服务调用。
第一个调用是称作更新的POST方法。这个调用从服务器中检索客户端程序能够使用的改变列表以合并在最新的服务器改变中。客户端上的状态信息经由用于每个同步应用的同步锚来维持，其是被初始设置为零的长值。当客户端请求给定的同步应用ID的服务器改变时，客户端作为参数提供其当前的锚。服务器返回格式化的改变列表以及最近的服务器锚。在客户端成功地合并服务器改变之后，其必须将其锚更新成服务器的值。客户端能够指定页面大小参数以限制改变列表的大小；在这种情况下，“is_more”标志被设置成指示客户端需要取得更多的更新。更新可以是允许客户端同时地为多个同步应用id取得服务器更新的成批调用，这能够有助于减少往返的数量。
第二调用是称作交付的POST方法，其将客户端的改变列表发送到服务器1804。客户端1802在请求中再次规定其最后的锚。注意，如果客户端1802没有被更新成最新的服务器版本，则服务器1804将(通过特定的错误响应)拒绝交付请求。在这种情况下，客户端1802应当在重试之前调用更新并且合并服务器的最新改变。因此，客户端通常应当在交付其改变之前调用更新。
客户端程序检测并且解决任何冲突。交付必须是无冲突的，并且因此冲突可能仅当客户端取得服务器更新并且尝试将其合并到其本地数据储存器中时才发生，其可以包含竞争客户端改变。一般而言，存在客户端必须处理的三个种类的冲突：
●服务器-模型-客户端-模型。自上一次成功的同步以来，客户端和服务器两者都已经对特定数据项目做出了改变。
●服务器-模型-客户端-删除。服务器正在试图修改自上一次成功的同步以来客户端已经删除的数据项目。
●服务器-删除-客户端-模型。服务器正在试图删除自上一次成功的同步以来客户端已经修改的项目。
注意，同步web服务调用是关于在客户端与服务器应用之间交换的同步数据的格式是完全地不可知论的。服务器与客户端改变列表是端点经由同步框架交换的不透明点。在这个意义上，同步web服务调用主要地是两个端点之间的锚定的传输机制。
聚合服务web服务器1804还可以具有聚合服务同步协议处理机、同步有限状态机构，这在图19中被描述。一旦聚合服务同步任务通过同步引擎控制器从队列中取出，则控制器调用处理机的executeSync()方法，其往下进行在开始处开始的流程图。尽管executeSync调用块直到完成为止，但是对于要完成的整个任务，存在超时(通常2分钟，然而这是可配置的)。
图19是图示示例性同步操作的流程图1900。最简单的场景是遵循图19中的流程图的结果，从开始1901笔直往下。如果同步被强制(即，作为服务器推式通知或另一应用的显式力量的结果)或如果与处理机相关联的同步适配器具有本地改变，则同步继续进行(步骤1902)。如果处理机不具有改变，则该处理结束。(步骤1903)。如果存在改变，或者同步被强制，则处理机获得客户端的锚(步骤1904)，并且调用同步WS处理机以得到有差别的服务器改变。(步骤1905)。如果请求是成功的(步骤1906)，则处理机现在具有一点(字节阵列)以经由updateClient()调用合并到适配器中(步骤1907)。如果合并成功(步骤1908)，则客户端适配器必须将其锚更新成服务器的锚，并且这个值被发送到缓存(步骤1909)。处理机可以被配置成在页面中检索更新；10的页面大小指示客户端仅想要具有相对于客户端的接下来的10个锚值记录。如果使用了页面，则处理机将继续取得并且合并更新，直到被明确地告知在服务器上不存在进一步的数据。(步骤1910)。接下来，处理机确定是否存在任何本地客户端改变(步骤1911)。如果不存在客户端改变，则处理结束(步骤1912)。如果存在客户端改变，则处理机检索改变(步骤1913)并且将该改变交付给服务器。(步骤1914)。处理机然后将确认该交付是成功的(步骤1915)。如果该交付是成功的，则服务器将往下发送其新的锚。(步骤1916)当确认该交付时，锚被给予适配器；适配器必须假定该交付失败直到其接收到这个确认为止。最终，新的锚被中继到缓存(步骤1916)。
流程图1900的侧枝图示了如何处理若干失败情况。服务器可以拒绝在更新请求中的客户端锚。如果锚是负的，或者如果客户端提交了大于服务器锚的锚(具有下面的一个例外的情况)，则这种情况将发生。在这种情况下，客户端被告知清除其数据并且从头开始。(步骤1917)。服务器可以推测客户端处于损坏的状态并且要求客户端请求(步骤1917)。这与上文中的基本上是相同的情况。服务器可能请求恢复(步骤1918)，其指示客户端需要将所有其数据向上发送到服务器(完全同步)，使得服务器能够从客户端数据恢复。这可能在灾难恢复的过程中或者当客户端被迁移到新的云(从一个服务器104移动到不具有其数据的另一服务器104)时发生。当客户端锚为非零时，如果服务器锚为零，则服务器还能够检测到对于恢复的需要。
该流程图还图示了冲突处理过程(步骤1919)。可以例如在客户端程序上完成冲突处理。服务器可能告诉客户端程序，当后者试图交付设备改变时其为过期的。为了简单起见，当客户端被更新成最新的服务器数据时服务器才允许交付。因此，从不存在服务器侧冲突。
聚合服务客户端电话(例如，图18的移动设备1802)的基础特征中的一个是用来自用户以及时且有效的方式签约的各种社交网络的新数据来对其进行更新的能力。为了做这个，已经确定，聚合服务包括将通知发送到设备的机制，使得其能够知道何时从图18的聚合服务核心服务应用服务器1818检索新数据。
为了提供其具有的这样的服务，期望通过推式信道将通知发送到用户设备1802或1803。推式信道可以一直在使用作为发消息协议的基础的XMPP的TCP/IP连接上。能够被用作发消息的基础的系统的一个示例是Jabber XCP服务器(www.jabber.com)。
图20图示了用于示例性推式信道的服务器侧推式架构2000，其可以通过图18中的推式服务器1830来实现。该推式架构2000包括推式服务通知API 2002、推式服务请求处理机2004、推式服务调度器2006、推式服务XMPP消息生成器2008以及推式服务认证插件2010至Jabber XCP 2012。
推式服务通知API 2002由后端服务(例如，图18的推式服务器1830)用来将通知和数据发送到特定的账户设备。在一个实施例中，API可以被定义为如下：
Figure BDA0000142646310000501
sendPushData方法构造web服务调用，其将调用推式服务请求处理机(PSRH)2004。PSRH 2004是暴露可以被表示为/blur-services-1.0/ws/push/signaldata的RESTful资源的web服务调用的服务器。在一个实施例中，推式服务请求处理机2004在每个POST上执行以下操作：
●对推式数据进行串并转换；
●检查以弄清是否已经存在发布用于这个特定账户id-设备id的数据；
●如果已经存在发布的数据，则基于与每个数据项一起发送的动作来添加/替换或删除该数据；
●如果不存在数据，则为这个账户id-设备id创建新的队列并且将向其添加该数据。
●必要时，终止队列上的任何数据；
●将数据往回保存到数据储存器；
●对于被添加的每个数据项，为该数据项生成新的序列id并且存储它；以及
●如果API调用在其曾经开始这个服务之前失败，则将不记录丢失的消息。一个解决方案是API它本身将这个序列id存储在数据库中使得将捕获其这样的错失。
数据库中的序列id的存储是必要的，因为API被绑定到无国籍的服务器，如果所存储的调度时间大于上述值，则通过数据项中的每一个并且得到最小的最大延迟值以及将其添加到当前时间，然后将调度请求发送到调度器。
当推式服务请求处理机2004接收到触发调度更新的数据项时，其将请求发送到推式服务调度器2006以调度待发送的消息。推式服务调度器2006是经由RESTful url暴露单个资源的服务器。例如，RESTful主体可以是[{″blurAcctId″：″...″，″providers″：[″facebook″，″myspace″，...]}，...]。优选地，每云将存在这些调度器中的仅一个，但是可以存在更多。推式服务调度器2006优选地是专用服务器，然而，在其它实施例中推式服务调度器2006可以是另一服务器的一部分。推式服务调度器2006将所有的其调度保持在内部存储器(未示出)中。推式服务调度器2006能够使用HTTP 1.1持久连接以及二进制协议以确保最佳的吞吐量。在一个实施例中，当进行新的调度请求时，推式服务调度器2006可以对调度进行串并转换(调度仅包含account_id、device_id以及调度时间)并且将调度放在调度队列上。
在后台处理线程中，调度队列等待并且在适当的时刻对推式服务xmpp消息生成器2008进行web服务调用以生成XMPP消息。
响应于来自推式服务调度器2006的请求，推式服务XMPP消息生成器2008创建XMPP消息。在一个实施例中，对于每个请求，推式服务XMPP消息生成器2008都可以从请求中得到account_id和device_id，在数据储存器中找到与account_id和device_id相关联的所有数据，并且对数据进行检索以及将它从数据储存器中删除。推式服务XMPP消息生成器2008可以将数据封装到XMPP消息元素中并且将该XMPP消息发送到XMPP服务器2012。
用于客户端设备(例如，图18的移动设备1802)的账户设定处理能够进行对XMPP服务器2012的调用以创建XMPP账户。替代地，为了解脱这个额外的调用并且帮助认证，组件能够用于XMPP服务器2012，XMPP服务器2012将利用聚合服务认证架构的(例如，对关于特定账户的信息进行验证和检索的核心服务处理器1818)。
在设备设定期间，用户能够创建能够有利地与特定设备相关联的新账户(聚合服务账户)。与这个动作相关联的数据将以账户服务决定存储它的任何方式被存储在账户数据库中。XMPP服务器2012可以具有充当附连到XMPP服务器的分组过滤器的组件。当该组件接收到认证请求时，其从该请求中得到适当的认证令牌。该组件然后使用那些令牌来进行对帐户应用的调用以认证用户。该组件然后将指示用户认证成功或失败的信号发送到XMPP服务器2012。
辅助组件还可以被附连到还能够充当分组过滤器的XMPP服务器2012。这个辅助组件将查找存在分组而非认证分组。由于所有的XMPP客户端发出了存在分组以便于接收消息，所以成功地附连到web服务器(例如，图18中的web服务器1804)的任何XMPP客户端都将发送XMPP存在分组。这个辅助组件能够检测存在分组并且让推式服务请求处理机2004知道何时连接或不连接客户端。这使推式服务请求处理机2004能够告诉推式服务调度器2006是否需要处理对于特定客户端的调度。
推式信道是向设备1802及时提供通知的尽力服务。推式信道可能不确保朝信道下发送的所有数据到达设备1802。实际上，要求是即使当推式信道未被激活时设备也能够操作。很少有支持这个要求的使用情况。首先，有时候会存在由于零星覆盖的原因设备将不能够激活推式信道。在这样的实例中，手动地使数据同步而不用激活推式信道是最理想的。而且，由于推式信道一直在连接，所以如果电话进入漫游模式则服务可能想要关闭推式信道。因此，推式服务的主要责任是及时地提供通知并且提供检测推未达到设备的手段。
推式服务将通知作为不透明的、应用特定的、离散数据发送到设备1802。用从零开始并且在达到例如2^31的阈值之后往回翻转到零的序列id来标记每条数据。在一个实施例中，序列id可以被如下生成。核心服务服务器1828检测推是必要的并且准备待推到设备1802的数据。核心服务服务器1818然后用所准备的数据调用能够被推式服务器1830控制的推式API。推式API然后检索account_id/device_id。推式API使用account_id/device_id来从持久存储器中查找下一个序列id。推式API然后用该序列id来标记数据并且将数据发送到推式请求处理机。推式API然后将成功消息返回给核心服务，例如核心服务服务器1828。核心服务服务器1828接收该成功消息并且认为该消息待发送。
如果推式API未能检索到序列id，则推式API抛出异议并且从不发送推式消息。当这种情况发生时，推式API能够存储事情的历史并且当序列机构返回到工作次序时，其然后能够基于所存储的历史对该序列进行复位。
如果推式API不能够将推式发送到推式请求处理机，则推式API可以抛出不同的异议。当这种情况发生时，因为序列id已经在持久性存储器中递增，所以下一个推式将接收下一个序列id并且如果下一个推式碰巧使其达到设备1802，则设备1802现将发生故障。替代地，如果在推式请求处理机将请求发送到调度器之前推式请求处理机崩溃，则推式消息从不被发送，序列中的间隙可能出现。在这些情况下，设备1802可以请求完全同步。
聚合服务器1804可以向客户端设备1802提供统一订阅源。当用户设备1802请求从中间web服务器1804发送多个订阅源时，能够采用统一订阅源来提供所有的订阅源数据。统一订阅源包含各种订阅源类型中的一个或多个订阅源。统一订阅源的目的是允许客户端用单个请求得到所有其订阅源，而不是进行单独的请求以得到朋友订阅源数据、新闻订阅源数据以及其它数据。订阅源可以是例如可以包括关于可从社交网网站得到的用户的朋友的更新的朋友订阅源，所述社交网网站诸如FacebookTM、MySpaceTM、TwitterTM、LinkedInTM。订阅源还可以是新闻订阅源，该新闻订阅源包括例如可从可以来自各种源的RSS订阅源、YahooTM新闻、DiggTM等中得到的新闻信息。替代地，订阅源可以是可以包括来自诸如YahooTM天气的源的天气信息的天气订阅源；或可以包括服务状态信息的管理订阅源。
如上文所讨论，能够通过聚合服务器1804从各种源收集订阅源，诸如从用于FacebookTM的相应插件1824或新闻订阅源。订阅源能够按用户发布到web服务服务器1828。订阅源特定web服务将具有通用订阅源格式的订阅源发布到订阅源工厂。当订阅源工厂接收到订阅源时，其将低优先级通知发送到推式管理器，如上文所讨论的。订阅源在订阅源工厂中进行积累并且在某个时间或事情之后，推式管理器将推式发送给客户端。例如，客户端1802能够进行单个请求以得到所有其订阅源。
在一个实施例中，聚合服务器1804能够采用两个协议来提供统一订阅源特征。第一协议定义订阅源特定web服务(诸如朋友订阅源web服务、新闻订阅源web服务等)将如何与订阅源工厂web服务进行交互。当订阅源特定web服务具有要发送到订阅源工厂web服务的订阅源数据时，其使用诸如/ws/feedmill/0/feedGrain/accountID的相关请求URI进行HTTP POST方法请求。在请求主体中所包括的将是已经具有通用订阅源格式的订阅源数据以及订阅源类型。服务器将用HTTP状态代码来作出响应。
第二协议定义订阅源工厂将如何与客户端1802进行交互。当客户端1802从订阅源工厂请求它的订阅源时，其进行包含用于被客户端处理的每个订阅源类型的序列号的简单web服务调用。服务器响应将包含所有的订阅源数据。
关于“订阅源工厂”术语，对“统一订阅源”进行了描述。发送到订阅源工厂web服务的订阅源数据将使用通用订阅源格式来发送。这个使得能够以一致的方式来处理来自各种源的任意数据。下文是服务器能够期望接收到的公用和非公用数据。
公用数据能够包括提供商、账户id、主体类型、类别、ID、链接、概要、发布时间标题、动作和/或地理标签。订阅源的提供商在朋友订阅源、新闻订阅源、天气订阅源以及管理订阅源中被找到。账户ID可以是聚合服务账户ID。朋友订阅源还能够包括账户ID。朋友订阅源可以包括主体和主体类型，新闻订阅源和天气订阅源包括atomContent。管理订阅源还能够包括主体和主体类型。一个或多个类目，如由聚合服务所定义的那样。朋友订阅源和管理订阅源包括类型和子类型。订阅源能够包括一个或多个链接。朋友订阅源能够包括一个或多个URL，streamURL或到媒体项的链接。新闻订阅源和天气订阅源能够包括atomLink。管理订阅源还能够包括URL。新闻订阅源和天气订阅源能够包括atomSummary。管理订阅源能够包括概要。订阅源可以包括发布每个项目的时间。订阅源还能够包括标题和用于该订阅源的标题类型或该订阅源中的数据。新闻订阅源和天气订阅源能够包括atomTitle。订阅源还能够包括能够被执行的一个或多个动作和地理标识元数据。
订阅源还可以包括非公用的数据类型，诸如externalID，用户的提供商侧用户ID在朋友订阅源中被发现，contactID、聚合服务ID可以在朋友订阅源和externalContactID中被发现，联系人的内容提供商网站ID在朋友订阅源中被发现。
在下文中使用以下术语来讨论客户端1802与聚合服务器1804之间的示例性交互：
●订阅源类型-订阅源的特定类型(即新闻、朋友、管理、天气...)；
●订阅源颗粒-在给定订阅源类型中的特定条目。作为示例，对于新闻订阅源，订阅源颗粒可以是独立的新闻项目。在每种类型的订阅源内包含的实际数据取决于订阅源的类型，然而他们将全部具有相同的格式(见留置权)。每个订阅源颗粒被看作对订阅源工厂的不透明的字符串；
●订阅源小球-特定类型的订阅源颗粒集；
●订阅源袋-从服务器发送到客户端的数据，由一个或多个小球构成；
●订阅源槽-在处理散发从服务器发送的订阅源小球的客户端上的组件；
●订阅源工厂-在处理从多个源收集订阅源小球并且将它们封装在订阅源袋中以发送到客户端的服务器上的组件；以及
●订阅源仓-在存储订阅源颗粒直到由设备请求为止的组件。基本上其将DB表隐藏在下面。
希望消耗给定的订阅源类型的在客户端1802上的应用将首先使用向订阅源槽注册。这个注册将简单地包括指示给定的应用在消耗中对哪一个订阅源感兴趣和方法，诸如AndroidTM意图，其应当被用来通知应用何时呈现新的数据。可以准许给定应用注册用于许多订阅源类型。当设备1802是AndroidTM设备时，当订阅源小球在客户端上被接收时，Android意图将被发送到所有注册的应用，包含在这个意图中包括的数据的订阅源类型、从服务器发送的实际的订阅源小球(所注册的应用通常具有解析这个数据的方式)、这个订阅源小球的序列号、以及在订阅源槽与应用(在注册时间时设置的)之间共享的应用秘密，使得应用能够认证这个来自订阅源槽的意图。
订阅源槽还将提供应用针对给定的订阅源类型取消注册它们自身的方式。订阅源槽还能够提供应用能够向其通知它们已经完成处理的给定订阅源类型的最后的序列号的机制。这个信息将在与订阅源工厂通信中使用以指示客户端具有仅剩的订阅源小球，因此订阅源工厂能够确定其需要将哪个数据发送给客户端。如果多个应用被注册用于给定的订阅源类型，则最小序列号将被保持并且发送给订阅源工厂。
响应于由推式管理器告知数据正在服务器上等待它，订阅源槽从订阅源工厂中取得数据。潜在地，还将存在使用户能够手动地发起订阅源的取得的机制，如果它们认为其必要的话。将立即准许来自订阅源槽的仅一个取得请求，并且在当一个正在处理过程中时另一个被请求的情况下，第二个将失败(具有适当的错误代码)。
能够存在订阅源槽将开始取得它的订阅源的一个web服务调用。例如，可以具有以下HTTP GET形式(减去需要发送的任何认证/登录数据)，
/ws/feedmill/0/feedMe/accountID？news＝X&admin＝Y&friend＝Z其中accountID是用户的账户ID并且X、Y以及Z是客户端已经分别针对订阅源类型新闻、管理员以及朋友处理过的最后的序列号。仅仅设备为之设置(经由一些外部的设定机构)的订阅源类型将被指定在以上线中。可以向用户指示处理来自这个调用的错误情况(用户不允许(userNotAllowed)、用户未找到(userNotFound)、系统忙(systemBusy)等)。在系统是忙的情况下，服务器能够使用已经被配置的(潜在地经由管理/配置订阅源)一些间隔来退回。
由于实际的订阅源小球的处理在应用处理中被完成，并且潜在地可能是耗时的，所以由于序列号可能不具有更新的机会，所以订阅源槽取得请求可能结果是接收相同的数据。这个发生应当不是频发的但是可能在完成推式管理器订阅源槽取得之后立即由用户发起的订阅源槽取得引发，如果许多推被快速连续从服务器发送，指示存在对客户端可用的订阅源数据，则在部分/完全接收到订阅源袋之后或在准许多个应用注册用于相同的订阅源类型中之后，设备立即崩溃，流氓应用从不更新它的序列号(或更新成假值)。
由于序列号适用于可以包含许多订阅源颗粒的整个订阅源小球，所以注册过的应用将必须告诉订阅源槽它们已经处理了整个订阅源小球，即使实际上它们仅仅关心订阅源颗粒的子集。本质上给定的订阅源小球的处理是全部或没有，不提供精细的颗粒度。没能用序列号更新订阅源槽将导致准许多个应用注册用于相同的订阅源类型。
如上文所提到的，客户端请求采取包含由客户端处理的用于每个订阅源类型的序列号的简单web服务调用的形式。
对客户端请求的服务器响应包含将在下文中描述的实际订阅源袋。
订阅源袋头部(FBH)可以具有若干元素，例如，版本、内容类型(例如，数据或错误)或所包含的订阅源小球数量(仅用于数据情况)或在错误类型情况下的错误代码。每个订阅源小球都还能够包括包含订阅源类型、订阅源小球的长度以及订阅源小球的序列号的头部(FPH)。在一个实施例中，订阅源袋可以看起来如下：(FBH)(FPH)(订阅源小球数据)(FPH)(订阅源小球数据)(FPH)(订阅源小球数据)...例如，错误情况可以简单地包含(FBH)。
订阅源工厂将必须处理从以下两个不同的位置传入的请求，(1)要求它的订阅源的设备，如上文所讨论的，和(2)为给定用户提供特定的订阅源类型订阅源颗粒的应用处理器。应用处理器能够经由HTTPPOST调用向订阅源工厂提供订阅源颗粒，其在一个实施例中可以看起来如下：/ws/feedmill/0/feedGrain/accountID，其中实际的订阅源颗粒(具有公用格式)和订阅源类型将被包括在请求主体中。订阅源工厂用适当的HTTP状态代码来做出响应。在每个成功的订阅源颗粒添加之后，低优先级通知被发送到推式管理器，指示订阅源数据对客户端是可用的。每个用户将具有订阅源仓，其将包含等待传递到设备的所有订阅源颗粒的订阅源颗粒。该表能够有利地包括订阅源类型的列、序列号(无符号整数(单调增加值))以及订阅源准许数据(字符串数组(或许最大大小))。
该表中的每行都可以对应于经由以上HTTP POST调用添加的订阅源颗粒。为了限制用户的订阅源表中的条目的数量，每订阅源类型能够存在可配置的最大数量的行。当这个限制被命中时所发生的将落入到2个类别中：
1.允许老化-在这种情况下，当处理器尝试为已经处于限制的订阅源类型添加订阅源颗粒时，最老的订阅源颗粒被移除。
2.不允许老化-在这种情况下，添加实际上失败并且错误被往回发送(经由HTTP状态代码)到应用处理器。
在存储了订阅源颗粒之后，订阅源工厂用来响应于订阅源槽对其订阅源(信息)的请求(轮询)而提供信息。订阅源工厂得到对于特定用户的订阅源的请求，查询用于所有订阅源的用户的订阅源仓，考虑该请求指定的序列号来构建订阅源袋并且将其发送到设备以及(基于请求序列号)从用户的订阅源仓中移除老的订阅源颗粒。
由于每个订阅源类型订阅源颗粒都是用户的订阅源表中的行，所以存在需要实际上添加订阅源颗粒的多个数据库调用。在一个实施例中，例如，订阅源工厂可以得到当前由这个订阅源类型使用的行的数量。如果行的数量大于行的最大数量并且如果允许老化，则移除最老的条目。如果不允许老化，则订阅源工厂可以返回错误。订阅源工厂然后可以将订阅源颗粒添加到表。
在订阅源表上可以不要求锁定。这是因为每个行都是独立的并且在给定的时间点得到所有的订阅源的处理不应当与新的行的添加发生冲突，因为这两个操作不影响相同的集合。
批处理机制存在可以被用来将相同的订阅源颗粒添加到多个用户(即，告诉所有TwitterTM用户站点当机了)。为了适应批处理机制，能够采用将在一个实施例中将可以采取“/ws/feedmill/0/feedGrainForMany”的形式的另一HTTP POS Tweb服务调用，其中实际的订阅源颗粒以及用户列表将被包括在请求主体中。用户列表的精确格式将取决于主用户表与订阅源工厂之间的交互。
聚合服务客户端应用，例如在客户端设备1802上装载的应用，能够使用具有不同的安全性级别的单独的内容提供商来访问联系人数据。可以记住一些重要的目标来构建聚合服务的联系人设计：
●设备上的联系人存储应当符合客户端设备1802的标准(例如，当使用AndrodTM设备时的AndroidTM标准)。
●联系人数据应当与网络服务联系人数据保持同步。
●每个联系人应当被作为单个个体呈现给用户，因为那是用户怎样想到联系人。
将直接从电子邮件服务器或社交网络网站1806-1808中获得许多联系人。这些网络中的一些具有禁止通过第三方应用访问它们的联系人数据的服务条款。为此，来自社交网络的联系人(在下文中被称为朋友)将被保留在客户端1802中的单独的数据库中。与呈现合并的个体的目标相组合的这个限制提出了技术挑战，因为在UI中正被合并的联系人记录必须从单独的数据库收集。在下文中这个文档使用这些术语：
●联系人-指的是在标准Android数据库中存储的人。
●朋友-指的是在私有社交网数据库中存储的人。
●所有联系人-指的是联系人和朋友的联合。
●合并的联系人-指的是联系人和朋友的交集。
在设备上，联系人被存储在由所有应用共享的数据库中。聚合服务扩展标准联系人以添加另外的数据和能力。聚合服务客户端联系人将是标准联系人的超集；第三方应用将能够使用标准API来访问联系人。
除了扩展的联系人数据库以外，聚合服务联系人针对社交网朋友引入了并行数据库。这个数据库具有另外的安全性以阻止通过第三方应用的访问。在大多数方式中，尽管存在很少的差别，但是数据库的架构和性能对联系人而言是一样的；朋友中不支持组。如果用户将朋友添加到组，则聚合服务自动地用该朋友的数据的副本来创建联系人，并且将该联系人添加到组。而且，为了支持跨越联系人和朋友合并的身份，朋友数据库包含对联系人身份的引用。
用户可以配置设备1802以使用来自各种提供商1806-1808的信息。这个信息可以包括电子邮件、联系人、照片以及社交网事情。公用联系人提供商的示例为GoogleTM、YahooTM以及FacebookTM。例如，用户还可以例如从激活同步导入数据以得到电子邮件联系人，或者经由订户身份模块(SIM)卡或电缆连接从他们的先前的电话中导入数据。通过访问设定，当最初对设备进行配置时或在其后的任何时间可以添加提供商。此外，运营商可以提供商可以将联系人从运营商1820直接提供给插件1824，从而能够将联系人经由服务器前端部分下载到设备。
图21图示了根据一个实施例的用于导入联系人的示例性方法。从内容提供商2110导入的每个联系人都作为单独的联系人记录来存储。指代同一个体的联系人在用户界面(“UI”)中被示出为一个人，但是记录在数据库中仍然保持分开。
聚合服务将支持与核心服务处理器2130进行通信的多个同步适配器2220-2128。这包括用于gmailTM联系人的Google的默认同步适配器、地址簿适配器、以及针对聚合服务编写的适配器，包括交换激活同步(EAS)、社交网联系人以及同步到聚合服务的联系人。这些同步适配器中的每一个都必须将他们同步到设备上的联系人标识为它们自己的，使得联系人的改变仅被往回同步到原始源。对于针对聚合服务编写的适配器，联系人数据库中的新的列被用来标识该同步源。没有用于这个列的值的联系人被假定属于GoogleTM或另一第三方。
联系人源中的一个将被标识为向其添加在设备上创建的联系人的默认地址簿。替代地，默认的联系人源可以是聚合服务的联系人。用户可以能够选择哪一个地址簿是默认的，并且哪一个地址簿应当用于特定的联系人。
虽然来自不同的提供商的联系人被存储为单独的联系人记录，但是不管它们实际上是否指的是同一个体，UI一直尝试将联系人作为个体呈现给用户。
新的“身份”表可以作为客户端联系人在同一数据库中创建。在该表中存在用于每个个体的一个行。新的列能够被添加到“人们”表，指示联系人记录属于哪一个个体。身份表可以不与聚合服务器1804同步。当添加了联系人时，其被动态地创建在客户端设备1802上。例外是用户可以手动地合并或取消合并联系人记录。对身份的这些手动改变应当被保留，并且因此与聚合服务器1804同步。
当联系人被添加在客户端设备1802上时，他们与其它联系人记录匹配以确定他们是否指的是同一个体。如果不存在匹配，则新的行被添加到身份表。在人们表中的身份列被更新以指向身份行。
联系人权限内的新内容URL可能可用来访问身份而非人们。许多聚合服务代码将使用这些URL来访问联系人。
身份表包括用于存储来自人们的最近的社交网状态更新的列。这个数据能够被显示在出现在整个产品中的“身份徽章”微件上，包括各种联系人屏、主屏回路卡以及消息寻址。
联系人的所有用户界面视图或编辑实际上将在聚合服务认为是同一人的联系人记录集合上操作。该联系人记录集合取自身份表。
任何合并策略都包含生成两种类型的错误的危险：过度合并(即，将单独的个体呈现为一个人)和欠合并(即，将一个个体呈现为单独的人)。设想聚合服务服务器将在过度合并方面犯错，为此：
●解决一个类别的错误比解决两者更容易。
●单个个体将被存储在多个提供商中比两个个体将合理地看起来像同一人更有可能。
●如果聚合服务过度合并，则用户容易标识实际上属于不同的人的数据。
●如果聚合服务欠合并，则其将对用户来说看起来像是“缺少的”数据。这对用户来说将是令人苦恼的，并且将难以找到应当已经被合并的其它联系人记录。
用户能够决定何时聚合服务具有过度合并或欠合并的联系人。这个从联系人细节活动的“源”部分来完成。
当以下中的一个为真时，通过聚合服务来合并联系人：记录正好具有相同的名称；记录共享电话号码并且记录中的一个将该号码标识为移动电话或工作电话；记录共享电子邮件地址，除非记录中的两者都将其标识为主电子邮件并且记录双方都已经被标识为电话的所有者。
如果他们从相同的源被同步，则不可以合并记录(例如，将不合并具有相同的名称的两个FacebookTM朋友)。注意当在客户端设备1802上创建联系人时，联系人的副本被创建用于每个可写的源。因此，在电话上用相同名称创建的两个联系人将可能合并在一起，因为第一个的聚合服务版本将与第二个的版本合并。
在联系人应用中，用户能够创建组或从服务提供商导入它们。用户将使用这些组来过滤他查看的联系人的集合而且与他们(电子邮件/短信息(sms))进行通信。
因为组成员关系表包含对联系人的表的引用，所以社交网朋友在技术上不可以是组的成员。当用户将朋友添加到组时，聚合服务通过创建虚设的联系人记录来规避这个问题。没有将联系人的数据(电话或地址)添加到虚设的记录。
人能够属于不止一个组。当创建新的组并且指派成员时，用户具有当联系这个组时哪一个电子邮件或号码用于该成员的选项。例如，可以使用相应的主电话或电子邮件来联系该组。这可能是联系该组的默认方法。替代地，可以使用不同的电子邮件和/或电话或所有的电子邮件和/或电话号码来联系该组。
当修改组时，用户能够改变组的成员。此外，然而，当联系该组时用户还可以改变将被用于每个成员的联系方法。例如，在“查看联系人”屏中可以过滤组，其中用户能够例如经由下拉来按组过滤联系人的集合。
用户能够给组发电子邮件或短消息。在一个实施例中，用户从“查看联系人”屏经由菜单选项来做这个。在电子邮件应用中，用户可以将组选择为电子邮件的接受者。当挑选该组时，用户能够暂时地覆写将用于每个成员的电子邮件地址。如果用户不覆写，则将使用用于每个成员的由用户指定的默认电子邮件。然而更可能地，因为大多数用户将不为组中的每个成员指定明确的电子邮件地址，所以将使用主电子邮件。
当将电子邮件发送给组时(或也许当选择组以向其发送电子邮件时)，UI将指示该组中的每个成员是否都拥有电子邮件并且将能够接收它。
表可以被添加到联系人数据库，以使用每种通信模式跟踪拥有者已经与每个联系人进行的最近的通信。在联系人应用中，列表视图的最近选项卡(tab)提及使用任何通信模式的最近的通信。联系人细节视图的历史选项卡列举了有关所有的联系人通信方法的最近活动。
Figure BDA0000142646310000671
当在设备1802(或聚合服务服务1804)上创建联系人时，其按照默认被添加到所有可写的提供商组。用户可以选择不包括这些组中的一个，因此不将新的联系人同步到该服务。不提供只读提供商组。这个部分被称作“提供商”。术语“只读联系人”意指属于只读提供商组的联系人记录。这样的记录可能从未被修改，包括他们的组成员关系。其它联系人被称为“可写的”。
其它联系人组还被提供给用户，但是这些不按照默认被选择。这个部分能够被称作“组”。新的字段被添加到所有可写的联系人记录。仅属于只读联系人的字段是不可编辑的。在至少一个可写的联系人中的找到的字段是可编辑的。每当编辑字段时，该字段数据就被写入到所有可写的联系人记录，即使该记录先前不包含该字段。实质上，这慢慢地在用户的提供商之中传播联系人信息。如果属于只读联系人和可写的联系人两者的字段被修改，则该字段的旧值和新值这两者现在都将被显示。旧值将不再是可编辑的。
可以不删除属于只读联系人的字段。属于可写的联系人的字段当被删除时消失。可以删除属于只读联系人和可写的联系人两者的字段，但是仅将其从可写的联系人中移除。该字段因此将仍然出现在详情中，但是将不是只读的。
当用户删除联系人时，确认对话框询问是否还应当从联系人所属于的所有的可写提供商中删除联系人。如果回答为是，则所有可写的联系人记录被删除。如果联系人还属于只读提供商，则对话框警告不可以从该提供商中删除该联系人。
正如在导入处理期间，添加到提供商网站的联系人生成新的联系人记录。在提供商上进行的改变被反映在聚合服务中的对应联系人记录中。当联系人在提供商上被删除时，其具有从该提供商组移除对应联系人记录的效果。其不从聚合服务的联系人中删除该联系人。从一个提供商导入的联系人可以被添加到聚合服务的UI中的其它提供商。这个具有将联系人从一个提供商拷贝到另一个的效果-不是通过提供商它们本身容易完成的特征。从提供商组移除联系人将该联系人从提供商的地址簿中删除。如果用户决定不再与提供商同步，则他们被询问是否移除从该提供商导入的所有联系人记录。
在设备1802上，推式服务将接收推式数据通知。其将查看每个数据项的序列号并且检查以弄清是否有任何一个已经失序。如果其检测到这样的场景，则其将广播指示这样的事情的发生的意图。可能要求该意图接收者决定他们想做什么。即使在失序情形的情况下，推式服务也将不丢弃任何数据。其将继续发射用于其检测到的所有数据项的意图。
图23-30中图示了用户界面的示例性部分。社交网状态驻留在主屏2300上。其允许用户查看电话上或社交网站点上他们的最近更新的状态2310，以及提供用于将状态更新推到社交网站点的手段。其为社交网体验的核心部分。状态更新被包括在多个社交网服务中，包括FacebookTM、MySpaceTM以及TwitterTM(其中它被称为tweet)。用户使用状态更新来将他们正在做的、他们正在去哪里、或者任何其它“微博客”想法传送给他们的朋友。
用户有能力从用户设备1802或1803的主屏(图23)更新他们的社交网状态。为了更新他们自己的状态，用户点击当前状态2310并且将呈现使用户能够键入改变的文本字段。
主屏状态2310将显示在已经被链接到用户的聚合服务账户的社交网网站(例如，所图示的屏上的Facebook)上更新的最近的状态。如果用户界面没有在主屏2300上显示状态，则空间可以由指示选定该区域将允许用户键入状态的文本来填充。状态2310将被推到用户所属的一个或多个用户选择的社交网络。例如，一旦选择键入状态2310，用户界面将向用户呈现下拉菜单，从这里能够选择将发送动作的内容提供商网站。用户能够选择内容提供商网站中的一个或多个。
朋友的最近状态2320还可以被显示在主屏内，在示例性头条新闻“事件”下面。图24图示了如果用户点击图23中的事件标题2320时的示例性事件屏2400。如图24中所见，事件屏2400包括来自用户正在跟随的账户的若干状态更新。图25图示了在用户选择了图24中图示的状态更新中的一个之后的示例性屏2500。如图25中所见，用户被呈现有将评论添加到状态更新的选项。图26图示了在用户已经选择将评论添加到图25中图示的状态更新之后的示例性屏2600。如图26中所见，区域2610被提供以供用户键入评论。屏2600还可以提供了用于发送评论的发送按钮2620和用于放弃/取消该评论的放弃按钮2630。在一个实施例中，如果用户选择如图25中图示的朋友的名称2510，则用于所选择的朋友的联系人信息如果可用就可以被提出在屏上。图29图示了在选择了朋友名称之后的朋友联系人信息。如图29中所见，用户可以查看在各种内容提供服务器1806-1808上的用户移动号码和工作号码、多个电子邮件地址以及朋友账户。如果用户选择图29上的向下箭头2910，则在内容提供服务器1806-1808中的一个上的朋友当前状态3010可以被提出在移动设备1802上，如图30中所图示。
如上文所讨论的，设备1802的用户可以直接连接到web内容提供商1806-1808中的一个。图27图示了在用户已经选择图25中所图示的朋友之后的示例性屏2700。如图27中所见，在选择了图25中的朋友“Tim”之后，客户端设备1802被直接带到在这个示例性实施例中为Tim的FacebookTM页面的朋友账户。图28图示了另一屏2800，其中已经发生到web内容提供商中的一个的直接连接。如图23中所见，屏2300可以包括接近相称的框的服务中的每一个的视觉指示(徽标)2340以指示该状态是用于哪个服务。因此，如果用户选择徽标2340，则用户可以被直接带到对应的服务，如图28中所见。
状态更新应当以及时的方式到达设备上。例如，他们应当在正由设备设置的时间的90+％的不到15分种内到达到设备屏上。换句话说，用户在设备1802用户界面上设置他们的状态，它在内容提供商网站1806上被更新，并且在不到15分钟内正被聚合服务更新之后返回到设备1802。设想在用户在设备1802上活动时状态将优选地在不到5分钟内被更新。
从网站1806-1808(例如，FacebookTM、MySpaceTM)设置的清除的状态可以不被反映在主屏上。主屏2300将仅反映来自每个服务的最近设置的状态。MySpaceTM具有现有的功能性，如果用户将情绪和状态二者设置为空，则状态被自动地设置成“是在你的扩展网络中”。由于这是MySpaceTM使他们的API工作并且MySpace用户所习惯于它的方式，所以当从服务在线或从设备设置空状态和情绪时，这个功能性将继续出现。
对于MySpaceTM状态更新(最新的更新是来自MySpaceTM网站或来自设备的最近的更新是仅MySpaceTM更新)，“情绪”被支持并且同时被显示为状态。主页用户界面(UI)2300还优选地包括最后状态更新2330的日期和时间。
如果用户尚未将社交网账户链接到他们的聚合服务账户，则社交网络状态区域将不出现。设想主屏芯片将重组，垂直地集中以占用由于SN状态的缺席所留下的空间的部分。
如上文所讨论的，用户可以选择或点击状态2310以更新状态，将用户带到状态更新用户界面。UI包括在用户已经将他们的web服务器1804聚合服务账户链接到的所有社交网络上的所有的他们的当前状态的列表。还可能存在接近于相称的框的服务中的每一个的视觉指示(徽标)2340以指示该状态是用于哪个服务。用于键入新的状态的UI空间可以用“是...”来预填充，其能够通过退格来擦除。
当诸如MySpaceTM的一个服务是选择的唯一服务时，状态和情绪二者都在MySpaceTM上用用户的当前状态和情绪来预填充。这支持用户仅更新状态或情绪而没有意外地清除任何一个。每个服务都能够通过改变每个个体的社交网站点的状态文本来(一次一个地)单独地更新。当仅更新MySpaceTM时，UI还支持情绪的选择。选择情绪允许用户键入文本以跳到情绪列表中的特定点(不是过滤器)并且允许用户滚动列表。
用户可能具有选择“所有”以立刻更新所有服务的选项。更新状态并且选择“所有”服务用新的状态更新来替换所有下面的服务。状态被推到用户已经将他们的web服务器104聚合服务账户链接到的所有社交网络。当更新“所有”服务包括MySpace时，情绪不是为MySpace更新的选项并且情绪被设置成没有情绪。
如果用户仅具有链接到支持状态的他们的web服务器1804聚合服务账户的一个服务，则不存在下拉菜单并且没有用于“所有”的选项。唯一的服务链路被简单地列举为目的地服务。在一个实施例中，在主屏上的状态是最近更新状态，不管它是来自移动设备还是来自社交网服务。在主屏上的状态应当具有标识该状态更新源自哪里(例如，移动设备、Facebook、Twitter等)的接近于它的某个图标2340。在一个实施例中，用户能够点击屏2300中的内容提供商图标2340并且跳转以直接访问内容提供商。
发送空白状态能够从所选择的特定服务，或者如果选择的所有服务(注意，Twitter不具有清除状态的概念，因此先前的状态将保持原封不动)中清除状态。在电话上的其它活动期间将存储应用的最后的屏/状态，并且一旦完成在SN状态更新实用程序中中断了用户的活动的任何活动(例如在接收到了电话呼叫以后)，则用户将返回到这个最后的屏。
在事件应用中支持的一个反应是以Reply对Twitter项目作出响应。这将导致新的“me”状态被发送到核心服务，并且将被反映在主屏上、以及状态的列表的Twitter线中(如果用户具有支持的Twitter账户)。
当状态被发送到web服务器1804聚合服务服务时，状态可以以“发射并且忘记”方法被发送，意味着将不向用户发送该动作进入社交网服务(尽管作为每UE，但是示出了反应已经被从设备发送出去的欢迎(toast)确认)的确认。如果他们的字符不超过所允许的最大字符，则将仅能够发布状态更新。所允许的状态更新的长度取决于正向其上传状态的服务。例如，FacebookTM当前允许160个字符，MySpaceTM当前允许160个字符，并且TwitterTM当前允许140个字符。如果选择了“所有的服务”，则最小的公分母将是限制器(例如，如果包括TwitterTM，则最大值为140)。
当允许30个字符或更少时，可以倒计数地显示计数器。当超过字符的最大数量时，计数器能够显示负数。如果用户切换发布模式(例如，从Twitter改变到FacebookTM)，则能够相应地对计数器进行调整(或者如果用户现在具有还剩超过30个字符要键入，则消失)。
当计数为负的时如果用户选择“发布”，则出现指示发布不能够进行并且解释哪些服务具有超过的最大值的对话。
web服务器1804聚合服务用户界面提供FacebookTM页面的有限的图像。例如，在事件2320中其可以示出列表中的朋友图片和名称。FacebookTM图片可以直接从FacebookTM下载，并且作为联系人保留在设备上。当设备同步到服务器时，其将被保存在服务器上。点击屏的该区域示出了名称、他们的主图片、他们的最后状态以及关于该状态的任何评论。你能点击人的名称以打开用于该人的背景墙的到FacebookTM移动装置的直接访问连接。替代地，你能够点击FacebookTM图标以跳到FacebookTM直接访问(不通过聚合服务)。
对于新闻订阅源，诸如上文中所讨论的RSS订阅源，简短的评论和图片可以被推到设备。图片将与简短的概要一起被显示。用户可以点击文章以从内容提供商得到另外的信息。这个处理能够通过识别文件输入字段来自动进行——他们是特殊的HTML类型文件——并且提示用户选择要包括的图片。然而，这个能够通过配置进行更新所需要的步骤来进一步增强。对于每个社交网站，服务器能够包括指定用户在该站点上能够执行的动作的脚本，和如何通过标准HTTP连接将那些动作发送到该站点；浏览器然后在菜单中将这些动作呈现给用户，提示所要求的输入，并且将全体发出到该站点。
核心web服务将通过同步框架来支持社交网络发消息和通过SNMAIL应用(处理器代理)对消息的动作。
图31图示了示例性聚合服务系统3100中的示例性发消息层。将诸如状态更新、照片上传、消息以及评论的动作从设备3102发送到web服务器前端部分3118。动作是独立于目的地内容提供商网站的具有通用格式的输入，而不是被包括的目标的身份。前端对该消息进行传送，并且后端处理器3116在专用于内容提供商网站的插件中处理该动作。例如，如果动作是将消息发布到FacebookTM和TwitterTM，则设备的通用消息在Facebook插件中和Twitter插件中被格式化。插件中的每一个都将坚持将其相应的适当地格式化的内容上传到FacebookTM和TwitterTM的内容提供商网站。
还如图31中所图示的，消息和他们的属性以及动作状态码在由后端3116拉之后经由单向同步被发送到设备，并且发送到前端3118。更新消息和动作状态的服务调用将经由同步单向同步调用来完成。
后端3116他们本身支持去往和来自社交网络的通信。前端3118和设备3102保持同步引擎，通过该同步引擎诸如联系人的某些信息在设备与服务器104之间同步。
服务器3104能够经由账户设定服务将提供商设置发送到设备3102。这个仅是单向的(从服务到设备)，并且不要求同步来进行这个工作。在设备上创建了用于消息的类别，其能够包含由每个提供商支持的所允许的消息属性和能够对数据执行的所允许的动作。
web服务器3104聚合服务电话应当维持包含提供商ID和所有字段的消息的数据库，以支持消息加同步元数据。对于从服务接收数据，设备必须处理消息属性的改变列表和来自服务的动作状态。这个包括消息的所有的属性。例如，改变列表可以包含：
Figure BDA0000142646310000751
Figure BDA0000142646310000752
在括号中的项目是为可选的那些。例如，不是所有的提供商都支持对象。具有‘*’的数据类型是可选列表，其中1或无可以在列表中(例如，FacebookTM支持多个地址，而其它的仅支持一个)。mesgGUID是在设备与服务之间共享的全局ID。提供商与服务之间的ID可以是不同的ID。假定所有的提供商都支持按GUID引用消息。
在这个方法中，以下是假定：1.动作经由WS调用被传递给服务。在下文中定义了动作格式；2.服务器返回立即确定，表明动作被接受以供处理，或者如果其不能够排队等待这个动作则返回错误；3.服务器(在处理器中)异步地处理这个请求，并且当完成时，用推式管理器将推式发出到设备；以及4.设备，使用单向同步，客户端用其最后的服务器锚来提交GET请求，并且这导致包含如由同步协议所定义的消息和动作状态的响应主体(例如，到/ws/sync/1/update/{account_id}/{device_id}/{app_id}/{last_server_anchor}？devkey＝android&format＝json的HTTP GET)。对于SNMail同步app_id字段将是3。
设备识别到PUSH不是可靠的并且必须超时，以及如果其期望推式响应，则再次重试该动作。如果推式信道被有意地断开连接(例如在漫游情况下)，则设备必须以轮询间隔执行动作和消息同步。在一个实施例中，存在2个超时条件：1.发送WS调用的动作可能超时；和2.可能从未接收到推式。在任一情况下，客户端应用必须处理这些超时。
状态表可以包含对客户端有用的信息。在一个实施例中，1的状态码指示处理成功地完成，0的状态码指示数据被接收并且动作在进行中，并且-1的状态码可以指示错误发生。动作ID可以由服务和设备来共享。这可能需要允许服务报告返回关于动作的状态(同步回到设备，其中单向同步到状态表)。经由同步使往回接收到的数据同步是通过经典同步的单向同步，不存在同步框架所需要的改变。
图32图示了根据一个实施例的示例性协议。能够利用类似朋友订阅源的协议将消息动作发送到SNMail应用。服务器可能需要动作的自变量，其是服务器正在作用于的消息ID。例如，snmail动作WS调用具有以下这种格式：
/ws/snmail/$version/$res/$accountid/$deviceid？<standardparams>(版本1 SNMAIL动作WS API，$res是作为用于动作的“a“的资源)
示例性消息属性是：
Figure BDA0000142646310000771
动作能够以动作头部开始。动作头部可以包含以下：
  名称   描述
  actionID   标识这个动作的长GUID
  actionType   要执行的动作的类型(见下文中的动作)
  providerName   提供商的标识符
动作可以是以下中的一个或多个：
Figure BDA0000142646310000772
Figure BDA0000142646310000781
动作和参数能够作为JSONArray被发送，并且lilts能够作为JSON阵列被发送。动作结果能够由服务器存储在状态表中，其随后由客户端来同步。为了代码级实施和效率目的，动作类型将作为ENUM而不是将由客户端和服务器来共享其值的名称被发送。syncMessages动作具有作为参数的锚，因为同步动作在后台中被完成。锚将告诉处理器设备是否可能已经通过发送锚0擦掉其消息。
snmail应用能够具有通知API，以当要求同步时向设备实现推式。这可以是例如URI：/ws/snmail/0/n。
特别预期的是，本发明不限于本文中所包含的实施例和说明，但是包括那些实施例的修改形式，包括实施例的部分和落入以下权利要求的范围内的不同实施例的元素的组合。

Claims (20)

1.一种聚合服务服务器，所述聚合服务服务器被配置成与用户设备和多个不同的内容提供商进行通信，包括：
处理器，所述处理器被配置成从所述多个不同的内容提供商获得内容并且进一步被配置成将所获得的内容推到所述用户设备。
2.根据权利要求1所述的聚合服务服务器，其中，所述处理器进一步被配置成从所述用户设备接收状态更新并且将所述状态更新发送到所述多个内容提供商中的对应的内容提供商。
3.根据权利要求1所述的聚合服务服务器，进一步包括：
多个插件，每个插件对应于所述多个内容提供商中的相应的内容提供商并且被配置成传送和接收来自所述对应的内容提供商的通信。
4.根据权利要求3所述的聚合服务服务器，进一步包括：
存储器，
其中，所述处理器进一步被配置成从所述插件中的一个插件接收更新，以将优先级指派给所述更新并且将所述更新和所指派的优先级存储在所述存储器中。
5.根据权利要求4所述的聚合服务服务器，其中，所述处理器进一步被配置成基于向所接收到的更新所指派的优先级来对到所述用户设备的推进行调度。
6.根据权利要求5所述的聚合服务服务器，其中，所述处理器进一步被配置成从所述用户设备接收对于数据的请求并且被进一步配置成将存储在所述存储器中的任何更新推到所述用户设备。
7.根据权利要求6所述的聚合服务服务器，其中，所述对于数据的请求是对于来自所有所述内容提供商的更新的单个请求。
8.根据权利要求4所述的聚合服务服务器，其中，每个插件被配置成将所接收到的更新重新格式化成与所述用户设备兼容的格式。
9.根据权利要求7所述的聚合服务服务器，其中，所述处理器进一步被配置成通过以下将所接收到的内容推到与单个账户相关联的多个用户设备：
监视推到所述用户设备中的每一个用户设备的所述内容；以及
基于所述监视将内容推到所述用户设备中的每一个用户设备。
10.一种使用中间服务器来控制客户端设备与多个内容提供商之间的通信的方法，包括：
由所述中间服务器从所述多个内容提供商中的一个内容提供商接收更新；
由所述中间服务器将优先级指派给所接收到的更新；以及
由所述中间服务器基于所指派的优先级对所接收到的更新到所述客户端设备的推进行调度。
11.根据权利要求10所述的方法，进一步包括：
由所述中间服务器从所述客户端设备接收对于更新的单个请求；以及
响应于所述单个请求，由所述中间服务器将更新从所有所述内容提供商推到所述客户端设备。
12.根据权利要求10所述的方法，进一步包括：
监视已经被推到所述客户端设备的所述更新；以及
基于所述监视，将更新推到所述用户设备。
13.根据权利要求10所述的方法，进一步包括：
将所接收到的更新重新格式化成与所述客户端设备兼容的格式。
14.根据权利要求10所述的方法，进一步包括：
定期性地将更新推到所述客户端设备。
15.根据权利要求10所述的方法，进一步包括：
当更新被指派了高优先级时，将所述更新推到所述客户端设备。
16.一种中间服务器，所述中间服务器被配置成与用户设备和多个不同的内容提供商进行通信，包括：
存储器；
内容提供商处理器，所述内容提供商处理器被配置成从所述多个不同的内容提供商获得更新并且将所述更新存储在所述存储器中；以及
核心服务处理器，所述核心服务处理器被配置成将存储在存储器中的所述更新推到所述用户设备。
17.根据权利要求16所述的中间服务器，其中，所述内容提供商处理器进一步被配置成将从所述多个不同的内容提供商所获得的更新重新格式化成与所述用户设备兼容的格式。
18.根据权利要求16所述的中间服务器，其中，所述核心服务处理器将优先级指派给所获得的存储在所述存储器中的更新。
19.根据权利要求18所述的中间服务器，其中，所述核心服务处理器基于所指派的优先级对所获得的存储在存储器中的更新到所述用户设备的推进行调度。
20.根据权利要求16所述的中间服务器，其中，在所获得的更新已经被推到所述用户设备之后，所述核心服务处理器从所述存储器中删除所获得的更新。
CN2010800404895A 2009-09-10 2010-09-10 内容提供商网站交互的系统、服务器和移动设备及其方法 Pending CN102498486A (zh)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US24137009P 2009-09-10 2009-09-10
US61/241,370 2009-09-10
US12/878,705 US20110231478A1 (en) 2009-09-10 2010-09-09 System, Server, and Mobile Device for Content Provider Website Interaction and Method Therefore
US12/878,705 2010-09-09
PCT/US2010/048420 WO2011031962A1 (en) 2009-09-10 2010-09-10 System, server, and mobile device for content provider website interaction and method therefore

Publications (1)

Publication Number Publication Date
CN102498486A true CN102498486A (zh) 2012-06-13

Family

ID=43014150

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2010800404895A Pending CN102498486A (zh) 2009-09-10 2010-09-10 内容提供商网站交互的系统、服务器和移动设备及其方法

Country Status (5)

Country Link
US (1) US20110231478A1 (zh)
EP (1) EP2476068A1 (zh)
KR (2) KR20140061482A (zh)
CN (1) CN102498486A (zh)
WO (1) WO2011031962A1 (zh)

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103685407A (zh) * 2012-09-18 2014-03-26 高德软件有限公司 一种基于云技术的Telematics平台系统
CN109448427A (zh) * 2018-11-09 2019-03-08 易的物联科技无锡有限公司 一种面向各类停车场的智慧停车管理的系统
CN109660606A (zh) * 2018-12-05 2019-04-19 新华三大数据技术有限公司 网络消息代理方法、装置及系统
CN109657179A (zh) * 2018-12-07 2019-04-19 北京奇虎科技有限公司 一种业务处理方法、系统及存储介质
CN110113437A (zh) * 2014-04-25 2019-08-09 微软技术许可有限责任公司 一种用于提供web服务的增强的可靠性的方法和装置
CN110929129A (zh) * 2018-08-31 2020-03-27 阿里巴巴集团控股有限公司 一种信息检测方法、设备及机器可读存储介质
CN113141383A (zh) * 2020-01-18 2021-07-20 佛山市云米电器科技有限公司 设备信息订阅方法、客户端、服务器、系统及存储介质
US11263492B2 (en) 2011-02-18 2022-03-01 Google Llc Automatic event recognition and cross-user photo clustering
CN114765697A (zh) * 2021-01-13 2022-07-19 德高公司 数字显示方法及系统、数字显示设备及数字显示服务器

Families Citing this family (77)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9213961B2 (en) 2008-09-21 2015-12-15 Oracle International Corporation Systems and methods for generating social index scores for key term analysis and comparisons
US20120011432A1 (en) 2009-08-19 2012-01-12 Vitrue, Inc. Systems and methods for associating social media systems and web pages
US10339541B2 (en) 2009-08-19 2019-07-02 Oracle International Corporation Systems and methods for creating and inserting application media content into social media system displays
US11620660B2 (en) 2009-08-19 2023-04-04 Oracle International Corporation Systems and methods for creating and inserting application media content into social media system displays
US20120109752A1 (en) * 2009-08-19 2012-05-03 Vitrue, Inc. Systems and methods for delivering targeted content to a consumer's mobile device based on the consumer's physical location and social media memberships
US8990338B2 (en) 2009-09-10 2015-03-24 Google Technology Holdings LLC Method of exchanging photos with interface content provider website
US9026581B2 (en) 2009-09-10 2015-05-05 Google Technology Holdings LLC Mobile device and method of operating same to interface content provider website
US9047612B2 (en) 2009-09-11 2015-06-02 Oracle International Corporation Systems and methods for managing content associated with multiple brand categories within a social media system
US9241012B2 (en) * 2010-04-18 2016-01-19 Tropo, Inc. System and method for telephony and communication services with message-based API
US9704165B2 (en) 2010-05-11 2017-07-11 Oracle International Corporation Systems and methods for determining value of social media pages
CN102263799A (zh) * 2010-05-25 2011-11-30 腾讯数码（天津）有限公司 一种sns网络中好友推荐系统和方法
US20110314048A1 (en) * 2010-06-22 2011-12-22 Microsoft Corporation Social network user list detection and searching
TWI418224B (zh) * 2010-06-30 2013-12-01 Htc Corp 自動設定網路推播服務之語言種類的方法、用戶端及伺服器
US9100385B1 (en) * 2010-10-01 2015-08-04 Google Inc. Management and synchronization of electronic media content information
US10474720B2 (en) * 2010-11-30 2019-11-12 Tw Seagull Acquisition Corp. Information feed update mechanism
US9153000B2 (en) * 2010-12-13 2015-10-06 Microsoft Technology Licensing, Llc Presenting content items shared within social networks
US20120158842A1 (en) * 2010-12-20 2012-06-21 Motorola-Mobility, Inc. Method and System for Facilitating Interaction with Multiple Content Provider Websites
US9037656B2 (en) 2010-12-20 2015-05-19 Google Technology Holdings LLC Method and system for facilitating interaction with multiple content provider websites
US9419880B2 (en) * 2010-12-21 2016-08-16 Koninklijke Kpn N.V. Method and system for handling service requests in a telecommunications network
US9483570B2 (en) * 2010-12-30 2016-11-01 International Business Machines Corporation Driving a user experience of a web application using rules that establish or change requests based on user behavior
US8666984B2 (en) * 2011-03-18 2014-03-04 Microsoft Corporation Unsupervised message clustering
KR101250028B1 (ko) * 2011-04-25 2013-04-03 한국과학기술원 컨텐츠 프로바이더로부터 미디어 컨텐츠를 수집하는 정보 전달 장치 및 방법
US9529417B2 (en) 2011-04-28 2016-12-27 Facebook, Inc. Performing selected operations using low power-consuming processors on user devices
US8825842B2 (en) * 2011-04-28 2014-09-02 Facebook, Inc. Managing notifications pushed to user devices
US9251021B2 (en) 2011-05-23 2016-02-02 Bradley Gene Calder Asynchronous replication in a distributed storage environment
US9161249B1 (en) * 2011-07-07 2015-10-13 Symantec Corporation Systems and methods for performing internet site security analyses
KR20130017264A (ko) * 2011-08-10 2013-02-20 한국전자통신연구원 지능형 사물에 대한 웹 서비스 제공 시스템 및 방법
CN102438033A (zh) * 2011-08-11 2012-05-02 赵冬 手持终端内容配置系统和方法
US8549047B2 (en) 2011-08-25 2013-10-01 Salesforce.Com, Inc. Computer implemented methods and apparatus for feed-based case management
US20130086072A1 (en) * 2011-10-03 2013-04-04 Xerox Corporation Method and system for extracting and classifying geolocation information utilizing electronic social media
CN102355500B (zh) * 2011-10-08 2018-02-13 中兴通讯股份有限公司 业务推送方法和装置
US8560933B2 (en) * 2011-10-20 2013-10-15 Microsoft Corporation Merging and fragmenting graphical objects
US20130132861A1 (en) * 2011-11-22 2013-05-23 Salesforce.Com, Inc. Social media dashboards
JP5887507B2 (ja) * 2011-11-28 2016-03-16 パナソニックＩｐマネジメント株式会社 通信機器間の接続確立方法、通信機器、及びサーバ装置
US20130139067A1 (en) * 2011-11-30 2013-05-30 Jeffrey Andrew Kanter Changing Identities in a Social Networking System
US9081749B2 (en) * 2011-12-12 2015-07-14 Microsoft Technology Licensing, Llc Automatic language sensitive, event based activity feeds
US20180253189A1 (en) * 2011-12-16 2018-09-06 Google Inc. Controlling display of content
US8996069B2 (en) 2011-12-27 2015-03-31 Vonage Network, Llc Systems and methods for communication notification and handling
US9069648B2 (en) * 2012-01-25 2015-06-30 Martin Kelly Jones Systems and methods for delivering activity based suggestive (ABS) messages
US9009258B2 (en) 2012-03-06 2015-04-14 Google Inc. Providing content to a user across multiple devices
US9514446B1 (en) 2012-04-27 2016-12-06 Google Inc. Remarketing content to a user associated with multiple devices
US9258279B1 (en) 2012-04-27 2016-02-09 Google Inc. Bookmarking content for users associated with multiple devices
US9881301B2 (en) 2012-04-27 2018-01-30 Google Llc Conversion tracking of a user across multiple devices
US8978158B2 (en) 2012-04-27 2015-03-10 Google Inc. Privacy management across multiple devices
US8966043B2 (en) * 2012-04-27 2015-02-24 Google Inc. Frequency capping of content across multiple devices
US8892685B1 (en) 2012-04-27 2014-11-18 Google Inc. Quality score of content for a user associated with multiple devices
KR101401236B1 (ko) * 2012-07-23 2014-05-30 한국과학기술원 인텐트에 기반하여 이동된 웹 객체를 처리하는 방법 및 장치
KR101414900B1 (ko) * 2012-07-23 2014-07-04 한국과학기술원 인텐트에 기반하여 웹 객체를 이동시키는 방법 및 장치
KR101414844B1 (ko) * 2012-07-23 2014-07-07 한국과학기술원 푸쉬를 사용하여 웹 객체를 이동시키는 방법 및 장치
US9710861B2 (en) * 2012-10-15 2017-07-18 At&T Intellectual Property I, L.P. Optimizing social information signaling
KR102026729B1 (ko) * 2012-12-10 2019-09-30 엘지전자 주식회사 스케줄 인터페이스를 처리하는 방법 및 장치
US20140172805A1 (en) * 2012-12-19 2014-06-19 Microsoft Corporation Contact management
US9930139B2 (en) * 2013-01-31 2018-03-27 International Business Machines Corporation Enabling access to user-chosen and/or preferred content via remote trusted third-party systems
CN104022938A (zh) * 2013-02-28 2014-09-03 腾讯科技（深圳）有限公司 消息同步方法、系统、服务器及客户端
US10303802B2 (en) 2013-03-15 2019-05-28 Gadget Software, Inc. System for mobile application search
WO2015042611A1 (en) * 2013-09-23 2015-03-26 Visible World, Inc. Systems and methods for cache-based content delivery
US9729410B2 (en) * 2013-10-24 2017-08-08 Jeffrey T Eschbach Method and system for capturing web content from a web server
KR101508307B1 (ko) * 2013-12-31 2015-04-07 배재대학교 산학협력단 휴대용 단말기 정보 푸쉬 방법 및 시스템
CN104137520B (zh) * 2014-01-10 2017-09-08 华为技术有限公司 一种消息推送方法及装置
US10460098B1 (en) 2014-08-20 2019-10-29 Google Llc Linking devices using encrypted account identifiers
RU2610418C2 (ru) 2014-08-29 2017-02-10 Общество С Ограниченной Ответственностью "Яндекс" Способ координации сетевого обмена данными
US9894154B2 (en) * 2014-10-11 2018-02-13 Papaya Mobile, Inc. Data synchronization methods and systems
US11574621B1 (en) 2014-12-23 2023-02-07 Amazon Technologies, Inc. Stateless third party interactions
KR102252225B1 (ko) * 2015-02-27 2021-05-14 삼성전자주식회사 하나 이상의 통지들을 관리하는 방법 및 이를 위한 전자 장치
GB2536067B (en) * 2015-03-17 2017-02-22 Openwave Mobility Inc Identity management
KR101582620B1 (ko) * 2015-03-27 2016-01-06 주식회사 비주얼다이브 소셜 액티비티 통합 서비스 제공 방법
US20170208354A1 (en) * 2016-01-15 2017-07-20 Hi Pablo Inc System and Method for Video Data Manipulation
US9946638B1 (en) * 2016-03-30 2018-04-17 Open Text Corporation System and method for end to end performance response time measurement based on graphic recognition
US10270745B2 (en) 2016-10-24 2019-04-23 Fisher-Rosemount Systems, Inc. Securely transporting data across a data diode for secured process control communications
US10877465B2 (en) 2016-10-24 2020-12-29 Fisher-Rosemount Systems, Inc. Process device condition and performance monitoring
US10257163B2 (en) 2016-10-24 2019-04-09 Fisher-Rosemount Systems, Inc. Secured process control communications
US10619760B2 (en) 2016-10-24 2020-04-14 Fisher Controls International Llc Time-series analytics for control valve health assessment
US10530748B2 (en) * 2016-10-24 2020-01-07 Fisher-Rosemount Systems, Inc. Publishing data across a data diode for secured process control communications
US10394654B2 (en) * 2017-03-31 2019-08-27 Intel Corporation Method and apparatus for hybrid firmware boot
US10819669B2 (en) * 2017-04-02 2020-10-27 Charles Russell McNeill Unified computing device interface for assembly of a plurality of types of digital content for transmission to a plurality of target destinations
US10193623B2 (en) * 2017-05-09 2019-01-29 Lenovo Enterprise Solutions (Singapore) Pte. Ltd. Wireless transmission of server status information
CN115118773B (zh) * 2022-06-29 2023-08-18 宁波三星智能电气有限公司 数据文件推送方法、服务器和计算机可读存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090119375A1 (en) * 2007-11-05 2009-05-07 Research In Motion Limited Method and system for optimizing delivery of mobile content using differential metadata updates
US20090164554A1 (en) * 2007-12-20 2009-06-25 Jeremy Chi Ching Wei Novel system and method to push content from a website to a remote device
US20090204666A1 (en) * 2008-02-13 2009-08-13 Microsoft Corporation Push mechanism for efficiently sending aggregated data items to client

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6229534B1 (en) * 1998-02-27 2001-05-08 Sabre Inc. Methods and apparatus for accessing information from multiple remote sources
US7043231B2 (en) * 2000-09-22 2006-05-09 Ericsson Inc. System, method and apparatus for polling telecommunications nodes for real-time information
US20020095312A1 (en) * 2000-09-22 2002-07-18 Tammy Wheat Facilitating realtime information interexchange between a telecommunications network and a service provider
US6976010B2 (en) * 2001-06-28 2005-12-13 International Business Machines Corporation Method for syndicating online content
CA2394503A1 (en) * 2001-07-23 2003-01-23 Research In Motion Limited System and method for pushing information to a mobile device
US6757684B2 (en) * 2001-10-01 2004-06-29 Ipac Acquisition Subsidiary I, Llc Network-based photosharing architecture
US7461094B2 (en) * 2003-02-27 2008-12-02 Qurio Holdings, Inc. Photosharing server filters for automatic storage and sharing of digital files
US20060036674A1 (en) * 2004-05-11 2006-02-16 Walden Chris S Broadcasting network and content delivery system
US20060155698A1 (en) * 2004-12-28 2006-07-13 Vayssiere Julien J System and method for accessing RSS feeds
US7720935B2 (en) * 2005-03-29 2010-05-18 Microsoft Corporation Storage aggregator
US20060271384A1 (en) * 2005-05-31 2006-11-30 Microsoft Corporation Reference data aggregate service population
US9569556B2 (en) * 2005-08-19 2017-02-14 Google Inc. Software architecture for displaying information content from plug-in modules in a user interface
US20080242370A1 (en) * 2006-03-31 2008-10-02 Ixi Mobile (R&D) Ltd. Efficient server polling system and method
US8843560B2 (en) * 2006-04-28 2014-09-23 Yahoo! Inc. Social networking for mobile devices
US8176058B2 (en) * 2006-11-30 2012-05-08 Yahoo! Inc. Method and systems for managing playlists
US8504711B1 (en) * 2006-12-12 2013-08-06 Google Inc. Integrating web services with a content item
US20080155112A1 (en) * 2006-12-22 2008-06-26 Nokia Corporation System and method for updating information feeds
US8949340B2 (en) * 2007-02-05 2015-02-03 Boadin Technology, LLC Systems and methods for organizing content for mobile media services
CA2679094A1 (en) * 2007-02-23 2008-08-28 1698413 Ontario Inc. System and method for delivering content and advertisements
US20080267218A1 (en) * 2007-04-27 2008-10-30 Liquid Air Lab Gmbh Media proxy for providing compressed files to mobile devices
US8683065B2 (en) * 2007-06-29 2014-03-25 Microsoft Corporation Multicast content provider
US7853558B2 (en) * 2007-11-09 2010-12-14 Vibrant Media, Inc. Intelligent augmentation of media content
GB0723553D0 (en) * 2007-11-30 2008-01-09 The Technology Partnership Plc Media providing service
US8869256B2 (en) * 2008-10-21 2014-10-21 Yahoo! Inc. Network aggregator
US8468158B2 (en) * 2008-11-06 2013-06-18 Yahoo! Inc. Adaptive weighted crawling of user activity feeds
US20100179915A1 (en) * 2009-01-13 2010-07-15 International Business Machines Corporation Apparatus, system, and method for aggregating a plurality of feeds
US20100211651A1 (en) * 2009-01-18 2010-08-19 Iskoot, Inc. Method and system for multimedia file transfer to a mobile device
US20100299455A1 (en) * 2009-05-21 2010-11-25 Motorola, Inc. Mobile Computing Device and Method with Enhanced Poling Management

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090119375A1 (en) * 2007-11-05 2009-05-07 Research In Motion Limited Method and system for optimizing delivery of mobile content using differential metadata updates
US20090164554A1 (en) * 2007-12-20 2009-06-25 Jeremy Chi Ching Wei Novel system and method to push content from a website to a remote device
US20090204666A1 (en) * 2008-02-13 2009-08-13 Microsoft Corporation Push mechanism for efficiently sending aggregated data items to client

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11263492B2 (en) 2011-02-18 2022-03-01 Google Llc Automatic event recognition and cross-user photo clustering
CN103685407A (zh) * 2012-09-18 2014-03-26 高德软件有限公司 一种基于云技术的Telematics平台系统
CN110113437A (zh) * 2014-04-25 2019-08-09 微软技术许可有限责任公司 一种用于提供web服务的增强的可靠性的方法和装置
CN110929129A (zh) * 2018-08-31 2020-03-27 阿里巴巴集团控股有限公司 一种信息检测方法、设备及机器可读存储介质
CN110929129B (zh) * 2018-08-31 2023-12-26 阿里巴巴集团控股有限公司 一种信息检测方法、设备及机器可读存储介质
CN109448427A (zh) * 2018-11-09 2019-03-08 易的物联科技无锡有限公司 一种面向各类停车场的智慧停车管理的系统
CN109660606A (zh) * 2018-12-05 2019-04-19 新华三大数据技术有限公司 网络消息代理方法、装置及系统
CN109657179A (zh) * 2018-12-07 2019-04-19 北京奇虎科技有限公司 一种业务处理方法、系统及存储介质
CN109657179B (zh) * 2018-12-07 2024-04-16 北京奇虎科技有限公司 一种业务处理方法、系统及存储介质
CN113141383A (zh) * 2020-01-18 2021-07-20 佛山市云米电器科技有限公司 设备信息订阅方法、客户端、服务器、系统及存储介质
CN114765697A (zh) * 2021-01-13 2022-07-19 德高公司 数字显示方法及系统、数字显示设备及数字显示服务器
CN114765697B (zh) * 2021-01-13 2023-12-01 德高公司 数字显示方法及系统、数字显示设备及数字显示服务器

Also Published As

Publication number Publication date
EP2476068A1 (en) 2012-07-18
WO2011031962A1 (en) 2011-03-17
US20110231478A1 (en) 2011-09-22
KR20140061482A (ko) 2014-05-21
KR20120063518A (ko) 2012-06-15

Similar Documents

Publication Publication Date Title
CN102498486A (zh) 内容提供商网站交互的系统、服务器和移动设备及其方法
JP7228668B2 (ja) インターネットクラウドでホストされる自然言語による対話型メッセージングシステムサーバ連携
US20180167426A1 (en) Multiplatform Screen Sharing Solution for Software Demonstration
US8051057B2 (en) Processing of network content and services for mobile or fixed devices
CA2707536C (en) Processing of network content and services for mobile or fixed devices
CN101711386B (zh) 在外部和/或本地电子邮件服务器和/或无线设备之间同步电子邮件消息
TWI479329B (zh) 用於自動對話技術的方法、物件及設備
JP4824390B2 (ja) 動的なコンテンツ変更通知
CN102272721B (zh) 移动通信设备
US8086676B2 (en) Contact aggregator
US20160261669A1 (en) Generating a Website to Share Aggregated Content
CN102498697A (zh) 强加消息大小限制的生成用于一个或多个内容提供商网站的消息的方法
US9332073B2 (en) Method and system for maintaining contact information
US20100211638A1 (en) Method and device for creating computer applications
CN101953189A (zh) 本地及远程社交信息的集合视图
CN103023759A (zh) 在用户之间共享和传输消息内容
CN101702943A (zh) 用于高速缓存无线数据服务中的电子邮件消息的装置和方法
CN1825311A (zh) 用于从多个联系人源聚集联系人信息的方法和系统
CN102567299A (zh) 使用文本消息与电子表格交互
CN102484646A (zh) 用于对内容提供商网站与移动设备进行中介的方法和系统
WO2012009362A1 (en) Methods and apparatus for automated workflow management
US20100255861A1 (en) System and Method for Transferring Contact Information to a Recipient
US20140108621A1 (en) System and method for internet services aggregation
US20160330158A1 (en) Messaging Sharing System and Method of Use
US20140173011A1 (en) Methods and systems for structuring information of email messages

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20120613