调度移动设备上的后台服务中的数据的制作方法
【专利说明】
【背景技术】
[0001]移动设备使用持续增加。例如，在2011年，在美国的移动设备业务量计及总网络业务量的几乎百分之七。移动设备用户面对的一些最大挑战由能量约束所强加。
[0002]移动设备中的能量约束包括但不限于，鉴于现代移动设备的日益增加的电力要求的电池容量中的缓慢改进。例如，电子器件中的改进(例如更大的屏幕、增加数目的传感器)和执行更加复杂的软件应用程序的处理能力计及移动设备的增加的能量消耗中的一些。数据通信也对移动设备的增加的能量消耗有贡献。而仅仅在10年前，移动电话可以依靠单次电池充电维持若干天，但是现在对于用户而言常见的是，不得不至少一天一次地对其移动设备中的电池再充电，并且通常甚至更加频繁。期望电池容量将努力跟上移动设备中的能量消耗。
【附图说明】
[0003]图1是可以实现以用于调度后台服务中的数据的示例联网计算机系统的高级图不O
[0004]图2图示了移动设备中的示例信息流。
[0005]图3示出示例数据代理架构。
[0006]图4示出示例时延敏感性分类器。
[0007]图5图示了在没有预取的情况下用于应用程序的事件的示例序列。
[0008]图6图不了具有预取的情况下用于应用程序的事件的不例序列。
[0009]图7图示了用于即时消息传递的事件的示例序列。
[0010]图8a-c是图示了可以实现调度后台服务中的数据的示例操作的流程图。
【具体实施方式】
[0011]数据使用消耗移动设备中的大量能量，并且影响电池再充电周期。由移动设备使用的能量的一部分未被用于实际数据传递，而是在数据传递发生之前和/或之后被消耗。例如，移动设备在与无线接入点(WAP)相关联以建立无线局域网或“WiFi”连接时可能招致“斜坡成本(ramp cost)”(在数据传递开始之前消耗能量)。同样地，移动设备可能通过甚至在完成数据传递之后仍保持在高功率状态而招致“拖尾成本(tail cost)”(例如通过继续为通信无线电器件供电并且因此消耗“拖尾能量”)。此外，移动应用程序或“应用(app)”可能在后台继续访问数据服务。例如，甚至在用户并未主动使用移动设备时，应用可能使得能够实现社交网络更新、部署软件更新，并且取得电子邮件。
[0012]公开了调度移动设备上的后台服务中的数据的示例系统和方法。在示例中，在移动设备上标识数据消耗模式。基于数据消耗模式确定到达移动设备的数据的敏感性。调度用于基于到达移动设备的数据的敏感性来聚合通过移动设备上的后台服务的网络访问。
[0013]本文所描述的系统和方法可以用于通过确定用户对延迟某些数据的容忍度，并且然后拦截和聚合后台服务中的数据业务来减少与数据业务相关联的电力消耗。聚合可以是基于用户对于所延迟的数据的容忍度。可以聚合容忍延迟的数据，而可以立即推送更敏感的数据。在示例中，由移动设备消耗的数据可以比用户消耗的数据更加容忍延迟。还设想到其它示例。此外，对进入业务的分析可以用于预取相关联的数据并且将经预取的数据与容忍延迟的数据捆绑以进一步减少与数据使用相关联的能量消耗。
[0014]包括诸如基于端口的分类之类的简单方案的业务分类可以用于试图推断应用程序类型，并且因此推断行为，以减少后台数据使用。但是这些方案可能是不准确的，导致当用户预期的数据未以及时的方式到达移动设备时的用户受挫。同样地，误分类可能给出比所期望的更高的优先级，导致浪费电力。也可以使用诸如基于有效载荷的分类之类的更复杂的方案，除了端口使用和传输协议的基本语义之外，其依赖于分组数据来重构应用程序信息。但是有效载荷检查可能通过增加标识过程的复杂性而添加显著的开销。
[0015]所描述的系统和方法不限于使用协议信息、信息有效载荷或业务性质的统计推断。替代地，系统和方法是基于通过移动设备自身的信息流。尽管如此，本文所描述的系统和方法可以独立地利用或者正交地应用于其它方案以进一步减少与移动设备中的数据使用相关联的电力消耗(例如斜坡和拖尾成本)。此外，数据传递可以被推迟直到更加电力高效的无线电器件可用，如果优先级允许的话。例如，低优先级业务可以仅在处于W1-Fi连接上时下载，W1-Fi连接比3G更加电力高效。
[0016]在继续之前，要指出的是，如本文所使用的，术语“包括”和“包含”意指但不限于“包括”或“包含”和“至少包括”或“至少包含”。术语“基于”意指“基于”和“至少部分地基于”。
[0017]图1是可以实现以用于调度后台服务中的数据的示例联网计算机系统的高级图示。系统100可以利用任何多种多样的计算设备来实现，仅举几个示例，诸如但不限于(多个)移动设备110 (例如平板IlOa和移动电话110b)、(多个)网络服务器120和(多个)代理服务器130。每一个计算设备可以包括存储器、存储装置和至少足以管理与彼此直接或间接(例如经由网络140)的通信连接的一定程度的数据处理能力。至少一个计算设备还配置有执行本文所描述的程序代码150的充足处理能力。
[0018]在示例中，系统100可以包括提供一个或多个服务(例如服务A-D……η)的(多个)网络主机160，该一个或多个服务可以由(多个)用户101经由移动设备110访问。出于说明的目的，服务可以是在配置为服务器计算机的网络主机160上执行的在线数据处理服务。示例服务可以包括通用计算服务(例如电子邮件)、应用程序引擎(例如社交媒体应用程序)和在因特网上托管或者作为用于任何数目的客户端应用程序或移动“应用”的动态数据端点的托管商业服务(例如在线银行系统和在线零售商)。服务还可以包括到应用程序编程接口(API)和相关支持基础设施的接口。要指出的是，这些网络主机不必由管理代理的相同实体也不必由管理通知服务器的相同实体所拥有或管理。
[0019]服务可以包括数据的至少一个远程源。在示例中，数据是动态的(即随时间改变)。为了为用户101提供最新内容，网络主机160可以可操作成与通知服务器120通信。例如，当针对服务维护的用户账户的数据改变(例如针对用户101的新电子邮件到达)时，网络主机160可以向通知服务器120发布通知(例如“推送”通知)。
[0020]要指出的是，可能存在对服务可以提供的数据类型或数据量的限制。例如，一般为制作移动设备的操作系统的方的通知平台的拥有者可以强加限制。例如，通知可以限于4千字节的数据。移动设备在接收通知时必须取得其余内容。还要指出的是，数据可以包括未经处理或“原始”的数据，或者数据可以经历至少某种水平的处理。
[0021]要指出的是，尽管在图1中分离地示出，但是通知服务器120可以是服务的部分，和/或通知服务器120可以在物理上分布在网络中并且在操作上与服务相关联。在任何实现中，可以经由代理130向移动设备110发布通知，如箭头172所图示的。还要指出的是，本文所描述的计算设备在功能上不受限制。计算设备还可以提供系统100中的其它服务。例如，主机160还可以处理其它事务。
[0022]代理130可以是能够处理来自通知服务器120的通知的任何合适的计算机或计算设备132。在示例中，代理130从移动设备110接收数据消耗模式，如箭头174所图示的，并且基于数据消耗模式确定来自用于移动设备的服务的数据的敏感性。代理根据基于由服务提供的数据的敏感性的调度来聚合通过在移动设备110上执行的后台服务(例如应用)对数据的网络访问。例如，代理130可以聚合来自通知服务器120的通知并且同时(或者基本上同时)向移动设备110发布通知的捆绑，如箭头176所图示的。
[0023]要指出的是，响应于接收到通知，用户101可以从服务请求附加信息，如箭头178所图示的。例如，用户101可以接收针对已经到