位置感知移动应用管理的制作方法
【技术领域】
[0001]本发明涉及通信领域，具体地，涉及位置感知移动应用管理。
【背景技术】
[0002]使用诸如智能手机之类的移动设备几乎是很普遍的。这些移动设备中的大多数都包括确定其物理位置的能力。即，移动设备能够确定其在实体世界中的位置。常用的位置确定通常是通过使用如下方式来完成的:全球定位系统(GPS)、多个无线信号的某种形式的三角法或插值法、互联网协议(IP)地理定位或它们的某种组合。
[0003]如今出现了很多所谓基于位置的服务(locat1n-based service，LBS)，该服务利用许多人每天携带的移动设备的位置检测功能。例如，LBS包括定向广告、社交网络、定位朋友(“签到”)、照片标签、生命记录、基于位置的游戏、健身监测、以及其他。基于位置的服务也可以包括车辆或包裹的追踪。
[0004]随着移动设备的普及使得在这种移动设备上使用移动应用(app)也变得很普遍。通常，用户从应用发布平台下载这种app并将app安装到移动设备。
【发明内容】
[0005]一个实施例提供了一种移动设备，包括:位置感知系统，位置感知系统被配置为确定移动设备的位置；移动应用app管理辅助器，app管理辅助器被配置为:选择与不同于所确定位置的位置相关联的一个或多个app ;帮助改变移动设备上的所选择app中的一个或多个app的使用状态。
[0006]一个实施例提供了一种位置感知移动应用的选择和管理方法，方法包括:确定移动设备的位置；选择与不同于所确定位置的位置相关联的一个或多个移动应用app ;帮助改变移动设备上的所选择app中的一个或多个app的使用状态。
[0007]一个实施例提供了在其上存储有处理器可执行指令的一个或多个计算机可读介质，当处理器可执行指令被一个或多个处理器执行时，使得如下操作被执行:确定移动设备的位置；选择与不同于所确定位置的位置相关联的一个或多个移动应用app ;帮助改变移动设备上的所选择app中的一个或多个app的使用状态。
【附图说明】
[0008]图1示出了根据本文所述技术的说明实现的示例场景。
[0009]图2是根据本文所述技术示出的示例方法的流程图。
[0010]图3是根据本文所述技术示出的示例方法的状态图。
[0011]图4示出了根据本文所述技术的示例系统。
[0012]图5示出了根据本文所述技术实现的示例计算系统。
[0013]图6示出了根据本文所述技术实现的示例设备。
[0014]以下的详细描述参考了附图。在附图中，(一个或多个)标号最左边的数字标识该标号第一次出现的附图。在全部附图中使用的相同标号涉及相似的特征和组件。
【具体实施方式】
[0015]本文公开的是用于根据(至少部分根据)确定的移动设备位置来管理设备移动应用(app)的技术。这可以包括例如，帮助移动设备的用户轻易地查找到针对当前位置适合的并且是最好的app。这种app可以是已经安装在移动设备上的应用或者是针对特定位置推荐安装的app。本公开的技术还可以包括自动激活或推荐激活的指定位置app。相似地，这种技术可以包括自动去激活或推荐去激活的指定位置app。
[0016]在移动设备(比如，智能手机和平板计算机)上运行的app通常被设计用于指定的位置或是指定类型的位置。一些示例包括大学校园地图、地区地铁应用、或与特定邻域或城市位置相关的信息。在指定类型位置有用的应用示例是棒球计分应用，该应用在棒球比赛时起作用。
[0017]不幸地是使用常规方法，移动设备用户发现很难查找到与指定位置相关联的或者适合于指定位置的应用，并且很难从数以百万的可用应用中的比较无用的应用中精选出有价值的应用。使用本公开的技术，用户能够到达一个位置并且会在他或她的移动设备上提供适合于该指定位置的一个或多个app的列表。
[0018]例如，如果用户到达纽约，就会有极为大量的帮助查找博物馆、饭店、甚至地铁时刻表的可用应用。这些可用应用会根据质量和位置的合适程度变化。本文描述的技术会帮助用户查找哪些指定位置app是可用的，以及帮助查找哪些app是对用户有价值的app。
[0019]另外一个没有被常规方法充分解决的关注点是如何基于针对当前位置的适用性管理已经安装的指定位置应用。当用户离开适用指定位置应用的特定位置时，本文描述的技术终止或去激活指定位置应用。例如，用户在华盛顿州斯波坎市时不会关心纽约地铁系统的延误警报。另一方面，当用户回到纽约时，用户想要更新并启用与纽约相关联的应用。
[0020]适用于特定位置的app的标识也可以更普遍地被用来预测用户在一天的任意时间点运行/使用的app。随着用户经过他正常行程中的不同地方和路线，移动设备会保持追踪与每个位置(地方/路线)相关联的app。
[0021]经过一段时间之后，移动设备建立了针对每个位置最有可能运行的app的认知，并且能够使用该信息来确定例如在设备处于低功率状态下，哪些app被卸载到用于运行主要应用的低功率内核。
[0022]简而言之，本文描述的技术帮助用户在不需要大量手动搜索、维持、并处理应用的情况下获得指定位置应用的益处。
[0023]常规方法需要大量的用户时间和手动输入。当搜索应用时，用户可以查询指定应用，但是他们不得不主动去进行关键字搜索或了解他们查找应用的类型。当处理用户设备上安装的应用时，用户必须手动关闭每个应用的通知并且在他们再次需要这些应用时手动打开这些应用。此外，用户必须记住哪些应用与哪些位置相关或者尝试以使得该过程变得更简单的方式手动排列这些应用。
[0024]有限资源
[0025]移动设备具有有限资源。该资源中的一些包括屏幕基板面、存储器、电池寿命、和其它可分配的资源。另外，用户自身的资源是有限的。本文公开的技术基于确定的设备位置管理移动设备的这些资源。
[0026]移动设备具有确定的并且有限的显示尺寸，也被称为屏幕基板面。由此，设备只能在一个屏幕上显示有限数量的图标。该图标与安装在设备上的app相关联，用户通过选择图标来激活app。本文描述的技术选择已经安装的指定位置app来对用户进行展示。
[0027]移动设备的每个用户对于哪些指定位置app适合于特定位置具有有限的认识和理解。例如，参加小职业球队联盟棒球比赛的用户很可能没有意识到有特定于棒球场的提供比赛现场数据的app。用户可能通过搜索永远找不到这个app。本文描述的技术提供了对还没有安装的指定位置app的选择。可以基于关于其他人在特定位置或在特定位置附近的源于大众(crowd-sourced)的使用信息进行对app的选择。
[0028]移动设备具有有限的可分配资源和有限的内存，该内存分配给活动的app、特别是分配给在后台的app。而且，移动设备具有有限的电池寿命，并且通常活动的app越多，移动设备的电量就消耗得越快。本文描述的技术在与特定app相关联的指定位置不是当前位置或在当前位置附近时会去激活和/或卸载设备上的特定app。
[0029]此外，用户可能只想要app在通知是相关的情况下才通知他或她。当用户远离与活动的指定位置app相关联的位置时，来自该app的通知通常是不相关的，如上纽约客运系统的示例。本文描述的技术在与特定app相关联的指定位置不在附近时去激活和/或调整由特定app提供的通知。
[0030]位置感知APP管理场景示例
[0031]图1示出了一组示例场景100，其中使用本文描述的技术的一个或多个实现。如所述的，该场景包括四个位置，在每个位置都有操作的移动设备。用户102正拿着智能手机110走近他第一次游览城市的大都会客运中心112中的火车。另一个用户(未示出)带着手机120在机场122等待中转。饥饿的旅行者(未示出)在餐厅132就餐时使用他的平板计算机130。还有一个用户(未示出)在家142中，她有智能手机140。
[0032]这些移动设备中的每一个移动设备经由无线连接被连接到通信网络150。这种连接可以是W1-F1、蓝牙、蜂窝、或其他。该连接将移动设备链接到互联网、个人内联网、和/或链接到所谓的云。数据库服务器160可以是互联网、个人内联网的一部分，或至少部分在云上。当然，数据库服务器160可以被实现为一个或多个服务器。
[0033]参考图1，其中讨论了各种示例场景100。当在客运中心112时，用户102在他的智能手机110上使用了几种app。那些app中的一些可能包括针对该市客运系统的app。例如，可能包括带有地铁时刻表的app。使用已知或新的技术，智能手机110确定其当前位置是客运中心112。
[0034]该当前位置(客运中心112)与用户102在此处使用的智能手机110上的app相关联。该使用的其他情景因素与该app和当前位置相关联。例如，在该位置处使用了该app的多少、在该位置处使用该app的频率、在该位置处下载该app的频率、在该位置处安装该app的频率、以及其他类似因素。除了使用之外，情景因素中的一些可以包括由在特定位置app的用户提供的评定等级。
[0035]该关联的信息可以被存储在智能手机110上。另外，很多移动设备在客运中心112期间可以执行这种位置感知关联。那些各种关联可以经由通信网络150被上传到数据库服务器160，其中这种关联被采集并且被组织在数据库服务器160上。由于关于app与位置之间，也许还有与情景因素之间的各种关联的信息是随着时间从一大群用户处收集而来的，所以这些收集的信息可以被称为源于大众的信息。
[0036]用户在机场122花费几个小时等待他回家的转机航班时，会希望探索到在机场什么应用是对他可用的。使用本文描述技术的实现，手机120将它的当前