的用户网页的请求发 送到服务器1〇9(步骤440)。当服务器109接收到对用户化身的请求(步骤431)时，服务器109 将化身更新请求发送到移动装置(步骤455)。响应于接收到来自服务器109的对化身的请求 或"试通"，移动装置301的处理器391进行W下过程:轮询传感器(步骤401)、检查日历数据 (步骤402 )、检查装置设定（步骤403 )、将数据存储在初级值表中（步骤409 )、通过将参数值 与化身选择进行比较来选择供显示的化身(步骤410、412)，且将选定化身发射到服务器109 (步骤415)，所有运些均是W类似于上文参看图5所述方式的方式进行的。在从移动装置接 收到选定化身文件（步骤420)后，服务器109可即刻将所述化身插入用户的网页中（步骤 430)，且将包含所述化身的网页发射给请求者(步骤432)，其中请求者的浏览器可显示所述 化身(步骤441)。W此方式，当第二用户想要观看所述用户的化身时，移动装置301仅须轮询 传感器且检索日历和装置设定数据。运使移动装置109的专用于提供当前状态化身的处理 资源减到最少。虽然图9中所说明的实施例可在请求者可观看化身之前导致轻微的延迟，但 所得化身将准确地反映用户的当前状态。
[0104] 图10是其中化身的选择是由代管用户的网页的服务器109作出的实施例的过程流 程图。在此实施例中，轮询传感器、检查日历数据和将装置设定记录在任一参数值表中（步 骤401到409)的过程大体上与上文参看图5所述的过程相同。代替于将参数值与移动装置 301内的化身选择准则进行比较，移动装置将参数值表发射到服务器109(步骤416)。如上文 所论述，视实施方案而定，保存在参数值表600中且在步骤416中发射到服务器109的数据可 为经处理的数据或原始传感器数据。一旦将参数值表600发射到服务器109(步骤416)，移动 装置301的处理器391就可重复轮询传感器等(步骤4(n到409)的过程，使得反映用户的当前 状态的传感器和设定数据被周期性地发射到服务器109。任选地，移动装置处理器391可在 重复轮询和记录步骤401到404之前暂停(步骤450)。
[0105] 服务器109接收参数值表600(步骤417)，其中所述表可存储在硬盘存储器中。在替 代实施例中，移动装置301可将传感器参数值循序地发射到服务器109,服务器109接着可随 着在步骤417中接收到数据而填充参数值表600。一旦己接收到参数值表600,就可将值与化 身选择逻辑表601中的化身选择准则进行比较(步骤418)。将参数值与化身选择准则进行比 较的过程可在服务器109中W大体上类似于上文参考步骤411和图5所述方式的方式来完 成。基于步骤418中的比较，服务器109选择适当的供显示的化身（步骤419)，且(例如)通过 将化身插入到由服务器109代管的用户网页中来准备所述供显示的化身。通过使用户的参 数值表600保持为最新，当响应于某人存取反映用户的当前状态的化身（步骤440)，服务器 109发射所述化身（步骤432) W供在请求者的计算装置上显示（步骤441)时将显示所述化 身。此实施例排除了移动装置选择适当的化身并将所述化身发射到服务器的需要，从而减 少处理器开销并节约电力。因为大多数移动装置301在其处理能力和电池电位方面受限，所 W将化身选择推卸给服务器109的处理器可使移动装置301能够在单次电池充电下较久地 操作。
[0106] 图11说明替代实施例，其中化身选择由服务器109执行，但移动装置301仅发射传 感器、日历和设定数据(如果此数据己改变）。此实施例的处理大体上与上文参看图10所述 的处理相同，但添加了测试(步骤405) W确定任何参数值是否己因参数值表的最后发射而 改变(步骤416)。如果无参数值己改变，那么移动装置301的处理器391在任选的暂停(步骤 450)之后重复轮询传感器等(步骤401到409)的过程。仅在参数值己改变的情况下，移动装 置才将经更新的参数值表发射到服务器1〇9(步骤416)。此实施例具有仅在需要对存储在服 务器109上的值进行更新时才发射参数值表的额外优点。因此，此实施例进一步节约了移动 装置的电池使用。
[0107] 图12说明其中化身选择由周期性地请求来自移动装置301的更新的服务器109进 行的替代实施例。W类似于上文参看图8所述方式的方式，服务器109周期性地请求参数值 表600的更新(步骤455)。作为响应，移动装置301轮询传感器等，且将参数值表600发射到服 务器109,如上文参考图10中的步骤4(n到416所述。此实施例中的步骤的其余部分大体上与 上文参看图10所述的部分相同。此实施例通过将传感器的轮询等限制于由服务器109控制 的周期性来进一步减少移动装置301的电池消耗。如上文参看图8所阐释，可通过改变向移 动装置301作出请求的周期性来控制化身流通与电池消耗之间的折衷。替代实施例还可使 用"休眠"且仅在检测到某一参数(例如噪声、光、加速度、位置改变等)时才苏醒的传感器。
[0108] 图13说明其中化身选择由服务器109响应于来自他人的观看所述化身的请求而进 行的另一替代实施例。W类似于上文参看图9所述方式的方式，当某人发送存取用户的化身 的请求(步骤440)时，服务器109接收所述请求(步骤431)，且作为响应将化身更新请求发送 到移动装置(步骤455)。作为响应，移动装置301轮询传感器等，且将参数值表600发射到服 务器109,如上文参考图10和图12中的步骤4(n到416所述。此实施例中的步骤的其余部分大 体上与上文参考图10中的类似编号的步骤所述的步骤相同。此实施例通过将传感器的轮询 和数据发射限制于当某人存取用户的化身时的情形来更进一步保存电池电力。
[0109] 参考充当用户化身的主机或接入点的服务器109而描述了前面的实施例。运些实 施例利用当前因特网架构，其中将化身保存在服务器上W提供其可存取性。然而，替代实施 例可准许在第二用户的计算装置(例如113到117)上显示用户的化身，而不需要接入服务器 109。在运些实施例中，将化身文件存储在第一用户的移动装置301或第二用户的装置313到 317或两者上。因为化身文件的存储和显示可能需要相当大的存储器存储空间和处理器时 间(特别是在化身文件为=维或动画的情况下），所W可能需要用户之间的对请求和接收化 身文件的预授权。图Ha中展示用W显示用户的化身的此方法的说明性实施例。
[0110] 参看图14a，移动装置301内的处理大体上类似于上文参看图5而描述的处理，直到 选择化身(步骤411)的点为止。移动装置301可连续地轮询传感器(步骤401)，且检查日历和 设定数据(步骤402、403) W收集关于用户的当前状态的数据。可将捜集到的数据存储在参 数值表600中（步骤409)，且对照化身选择化身选择逻辑表601进行比较(步骤410)。基于所 述比较，选择要显示的化身文件(步骤411)。W此方式，连续地更新化身选择，使得所选择的 化身反映用户的当前状态。为了保存电池电力且减少处理器开销，可在轮询周期之间采用 任选的暂停或延迟(步骤450)。
[0111] 前面的过程步骤确保移动装置301具有存储在存储器中的当前化身选择。第二用 户可通过电子邮件、SMS消息和/或电话呼叫来发送对化身的请求(步骤460)。响应于接收到 对化身的请求(步骤461)，移动装置301的处理器391从存储器再调用化身文件，且将所述文 件发射给请求者(步骤462)。在接收到化身文件(步骤463)后，请求计算装置可接着即刻显 示所述化身(步骤441)。
[0112] 在一实施例中，处理器391可对照预核准的第二用户装置(例如113到117)的列表 来比较联系请求的来源(例如返回地址或电话号码），W确定请求装置是否被授权接收所述 用户的化身。此预核准用户列表可类似于朋友和家人电话号码W及电子邮件地址的列表。
[0113] 在一实施例中，可将多个用户化身文件预存储在发起联系的装置上，例如预存储 在被预核准接收用户的化身的所有计算装置上。不同于前面的实施例（其中将整个化身文 件发射给请求者），仅须发射化身名称W供任何请求者从其自己的存储器再调用化身文件。 通过将化身文件预存储在预核准的计算装置上，化身请求与其向请求者的呈现之间的延迟 被减到最小，因为仅发射化身名称。然而，此些实施例可能需要对多个装置的相当大的存储 要求，W及将所有的用户化身文件下载到每一经预核准计算装置所需的时间。
[0114] 在替代实施例中，可将化身文件预存储在经预核准的计算装置上，W及直接发射 到经预核准的计算装置。为了使移动装置301和请求装置两者所需的功率消耗减到最少，仅 将选定化身文件的识别符发射到第二用户的装置。替代实施例检查请求装置的局部存储 器，W确定化身文件的发射是否有必要。如果化身文件己经存在于请求装置的局部存储器 中，那么立即显示所述化身文件。如果化身文件不存在于局部存储器中，那么作出对化身文 件的请求，且随后发射化身文件W供显示。图Hb说明除了在步骤504中将化身文件识别符 (ID)发射到请求装置W外大体上与上文参看图14a所述的实施例相同的替代实施例。请求 装置接收化身ID(步骤506)，且使用所述ID来确定相关联的化身文件是否己经存储在其存 储器中（测试507)。如果对应于所述ID的化身文件己经存在于局部存储器中（即，测试507 = 是），那么迅速显示所述化身（步骤441)。然而，如果对应于所述ID的化身文件尚未在存储器 中（即，测试507 =否），那么请求装置请求发射所述文件(步骤508)。移动装置301接收所述 请求（步骤505)，且发射对应的化身文件（步骤462)。此后，请求装置接收化身文件（步骤 463)，且显示化身文件(步骤441)。作为任选步骤(未图示），可将接收到的化身文件存储在 局部存储器中W供将来使用。W此方式，替代实施例允许显示新的或经更新的化身文件。另 夕h通过仅在请求装置尚未在局部存储器中具有化身文件时要求发射较大的化身文件，移 动装置301和请求装置两者节省了电力消耗。通过限制所发射的数据的量，替代实施例还节 省了发射带宽。
[0115] 图15a说明图14a中所示的前述实施例的替代方案，其包含测试(步骤405) W确定 任一参数是否己改变。如上文参考图7中的步骤405更全面地描述，如果没有参数己因最后 的化身选择而改变（步骤411)，那么处理器391可继续收集传感器、日历和设定数据（步骤 401到409)。如果参数己改变，那么所述方法可继续，如上文参考图14中的类似编号的步骤 而描述。
[0116] 类似于图14b中所说明的实施例修改图14a的方法的方式，图15b中所示的实施例 修改图15a中所示的方法。图15b中所示的替代实施例节省了处理能力、电池寿命和发射带 宽，且进一步允许使用经更新的或新的化身文件。类似于图14b中所示的实施例，图15b中所 示的实施例通过进一步包含仅将选定化身文件的识别符发射到第二用户的装置的步骤504 至化08来修改图15a中所示的方法。检查请求装置的局部存储器W确定化身文件的发射是否 有必要。如果化身文件己经存在于请求装置的局部存储器中，那么立即显示所述化身文件。 如果化身文件不存在于局部存储器中，那么作出对化身文件的请求，且随后发射化身文件 W供显示。
[0117] 图16说明通过响应第二用户作出的化身请求来进一步节省移动装置301的处理器 和电池时间的替代实施例。第二用户可将化身请求发射到移动装置301(步骤460)。移动装 置301接收化身请求(步骤461)，且作为响应，处理器391捜集并存储传感器、日历和设定数 据(步骤401到409)，如上文参看图5所述。处理器391接着将参数值表600中的捜集到的数据 与化身选择逻辑表601进行比较(步骤410)，W选择供显示的化身（步骤411)。处理器391接 着将选定化身文件发射到请求计算装置(步骤415)，所述请求计算装置接收化身文件(步骤 462)，且显示选定化身(步骤441)。
[0118] 在一实施例中，处理器391可对照预核准的第二用户装置(例如113到117)的列表 来比较联系请求的来源(例如返回地址或电话号码），W确定请求装置是否被授权接收所述 用户的化身。此预核准用户列表可类似于朋友和家人电话号码W及电子邮件地址的列表。
[0119] 在一实施例中，可将多个用户化身文件预存储在发起请求化身的计算装置上。举 例来说，可将用户的化身文件存储在被预核准接收用户的化身的所有计算装置上。不同于 前面的实施例(其中将整个化身文件发射给请求者），仅须发射化身名称W供任何请求者从 其自己的存储器再调用化身文件。通过将化身文件预存储在预核准的计算装置上，化身请 求与其向请求者的呈现之间的延迟被减到最小，因为仅发射化身名称。然而，此些实施例可 能需要对多个装置的相当大的存储要求，W及将所有的用户化身文件下载到每一经预核准 计算装置所需的时间。
[0120] 或者，类似于图14b和图15b中所示的实施例，图16b中所示的实施例通过添加仅将 选定化身文件的识别符发射到第二用户的装置的步骤504至化08来修改图16a中所示的实施 例方法。检查请求装置的局部存储器W确定化身文件的发射是否有必要。如果化身文件己 经存在于请求装置的局部存储器中，那么立即显示所述化身文件。如果化身文件不存在于 局部存储器中，那么作出对化身文件的请求，且随后发射化身文件W供显示。
[0121] 在图17中所说明的实施例中，将化身文件和化身选择逻辑表601预存储在被授权 请求用户的化身的计算装置上。在此实施例中，经预核准的计算装置(例如)通过向用户呼 口 4、发送电子邮件或发送SMS消息来请求化身(步骤460)。响应于接收到对化身的请求(步骤 461) ，移动装置301的处理器391轮询传感器、检查日历数据并检查装置设定（步骤401到 403)，且将数据存储在参数值表600中（步骤409)，且如上文参看图5更全面地描述。处理器 391接着将参数值表600发射到请求计算装置(步骤416)。请求计算装置接收参数值表(步骤 462) ，且将值与存储在计算装置上的化身选择逻辑表601进行比较(步骤464)，W便选择适 当的供显示的化身(步骤466)。在己选择了适当的化身后，计算装置接着从其存储器调用化 身，并显示所述化身(步骤441)。化身请求计算装置将参数值与化身选择准则进行比较的过 程(步骤464到466)大体上与上文所述的如由移动装置301或服务器109执行的类似步骤相 同。
[0122] 在替代实施例中，用户还可设定授权选择准则，W控制谁可在什么时间且在什么 活动期间观看每一化身。用户可提供对应于相同的传感器设定但依据请求者（即，作出请求 的第二用户）的身份而不同的多个化身。一些化身可提供关于用户的具体活动的较少细节， 或可与用户实际参加的活动显著不同。另外，用户可将授权控制设定为超驰传感器信息，W 确保所显示的化身不对应于用户的实际活动。
[0123] 举例来说，用户可设定授权等级，W确保用户的老板可仅观看到详述用户在工作 时间期间的活动的化身。在其它时间，可拒绝或隐藏化身，或如果化身存在，那么其可为指 示用户正忙而不描绘用户参加的活动的简单化身。在另一实例中，用户可设定授权等级(也 称为准许控制），使得当传感器数据指示用户在体育馆时，用户的老板可观看到描绘用户在 工作的化身。
[0124] 图18说明部分地基于请求者的授权等级来选择化身的实施例中可使用的实例过 程步骤。如上文参看图4所描述，移动装置处理器391可检索关于用户的当前活动的各则数 据(步骤401到403)。一旦收集到关于用户的当前活动的相关数据，就确定请求者的授权等 级(步骤501)。下文更详细地描述确定请求者的授权等级的各种方法。一旦确定请求者的授 权等级，就可将其用作选择要显示的适当化身的另一参数。在将化身直接从移动装置301发 送到请求者的装置的实施例中，移动装置的处理器391可检查请求者的授权等级。在存储化 身并将其插入到中央服务器位置处的网页中的例子中，服务器的处理器或移动装置的处理 器可执行检查请求者的授权等级的步骤。
[0125] 可实施多种方法中的任一者来检查请求者的授权等级。举例来说，可让请求者提 供某一形式的验证凭证，例如用户名和口令，W检验请求者是否被授权接收化身和/或具有 特定授权等级。或者，可授权一些特定计算装置观看选定化身。处理器可检查提交对化身的 请求的计算装置的静态因特网协议(IP)地址，W例如通过将在化身请求消息中接收到的静 态IP地址与被授权接收化身的静态IP地址列表进行比较，来确定计算装置是否被授权接收 化身。可在执行检查请求者的授权等级的步骤的各种方法中使用将发射接收化身的请求的 请求者或计算装置验证为经授权用户/装置或将请求者或装置分类成各种授权等级的任何 方法。一旦作出请求者是否被授权接收特定化身(或请求者的授权等级）