Source: http://patents.com/us-9681387.html
Timestamp: 2018-09-24 19:19:46
Document Index: 637680357

Matched Legal Cases: ['application No. 11818512', 'Application No. 2', 'Application No. 201180063972', 'Application No. 11842623', 'Application No. 11818512', 'Application No. 2', 'Application No. 11818512', 'Application No. 11814939', 'Application No. 11814940', 'Application No. 11814973', 'Application No. 11814971', 'Application No. 11748780', 'Application No. 11838705', 'Application No. 11842623', 'Application No. 11843111', 'Application No. 2806557', 'Application No. 2857458', 'Application No. 2806529', 'Application No. 2806549', 'Application No. 2798523', 'Application No. 11748780']

US Patent # 9,681,387. Mobile traffic optimization and coordination and user experience enhancement - Patents.com
United States Patent 9,681,387
Luna , et al. June 13, 2017
Systems and methods for prediction of activity session for mobile network use optimization and user experience enhancement are disclosed. In one aspect, embodiments of the present disclosure include a method, which may be implemented on a system for enhancing user experience with a mobile application on a mobile device including, using user activity characteristics at a mobile device and server activity characteristics of a host server to anticipate a future activity session at the mobile device and transferring impending content from the host server the mobile device to pre-cache content on the mobile device to support predicted data activity for the future activity session that has been predicted.
Luna; Michael (San Carlos, CA), Backholm; Ari (San Carlos, CA)
Seven Networks, LLC (Marshall, TX)
Family ID: 1000002648440
14/745,796
US 20150365904 A1 Dec 17, 2015
13178598 Jul 8, 2011
61416033 Nov 22, 2010
61416020 Nov 22, 2010
61408846 Nov 1, 2010
61408854 Nov 1, 2010
61408858 Nov 1, 2010
61408829 Nov 1, 2010
61408826 Nov 1, 2010
61408820 Nov 1, 2010
61408839 Nov 1, 2010
61367870 Jul 26, 2010
61367871 Jul 26, 2010
Current CPC Class: H04W 52/0254 (20130101); H04L 12/12 (20130101); H04W 52/0258 (20130101); Y02B 60/50 (20130101)
Current International Class: H04B 1/38 (20150101); H04W 52/02 (20090101); H04L 12/12 (20060101)
Field of Search: ;455/574
4980836 December 1990 Carter et al.
5355501 October 1994 Gross et al.
5617572 April 1997 Pearce et al.
5710929 January 1998 Fung
5944829 August 1999 Shimoda
5954820 September 1999 Hetzler
6118771 September 2000 Tajika et al.
6278887 August 2001 Son et al.
6934267 August 2005 Mannerstrale
6981041 December 2005 Araujo et al.
7035914 April 2006 Payne et al.
7062567 June 2006 Benitez et al.
7145454 December 2006 Linjama et al.
7152172 December 2006 Tsirkel et al.
7254130 August 2007 Bale et al.
7302280 November 2007 Hinckley et al.
7505448 March 2009 Sheng et al.
7505795 March 2009 Lim et al.
7539497 May 2009 Beale
7587510 September 2009 Klager et al.
7786623 August 2010 Farmer et al.
7801959 September 2010 Lennie et al.
7974194 July 2011 Tripathi et al.
8078896 December 2011 Karlsson
8176027 May 2012 Shuman et al.
8180407 May 2012 Kindred et al.
8181211 May 2012 Olson et al.
8259738 September 2012 Sgouros et al.
8271057 September 2012 Levine et al.
8417823 April 2013 Luna et al.
8509159 August 2013 Shao et al.
8762546 June 2014 Ralph et al.
8811903 August 2014 Chandra et al.
8826308 September 2014 Jolfaei et al.
8861445 October 2014 Jing et al.
8873580 October 2014 Chandramouli et al.
8879389 November 2014 Palijala et al.
8886176 November 2014 Luna et al.
8902862 December 2014 Yu et al.
8903954 December 2014 Luna et al.
8904206 December 2014 Black et al.
9088622 July 2015 Erbe
9100873 August 2015 Luna et al.
9125158 September 2015 Ly-Gagnon et al.
9173197 October 2015 Dhanda
9185697 November 2015 Kuchibhotla et al.
9237453 January 2016 Steer et al.
9247019 January 2016 Luna et al.
9256484 February 2016 Stanley-Marbell et al.
9276917 March 2016 McColgan
9277499 March 2016 Paliwal et al.
9392393 July 2016 Wood et al.
9407713 August 2016 Luna
9408187 August 2016 Kneckt
9430941 August 2016 Huang et al.
9467483 October 2016 Jolfaei et al.
9503544 November 2016 Luna et al.
9510132 November 2016 Xu et al.
2001/0036822 November 2001 Mead et al.
2002/0107042 August 2002 Murnaghan et al.
2002/0108121 August 2002 Alao et al.
2002/0156921 October 2002 Dutta et al.
2003/0009571 January 2003 Bavadekar
2003/0046433 March 2003 Luzzatti et al.
2003/0055555 March 2003 Knockeart et al.
2003/0148760 August 2003 Takayanagi
2004/0081088 April 2004 Schinner et al.
2004/0125800 July 2004 Zellner
2004/0219940 November 2004 Kong et al.
2004/0259542 December 2004 Viitamaki et al.
2004/0264396 December 2004 Ginzburg
2005/0136882 June 2005 Boulton
2005/0216844 September 2005 Error et al.
2005/0221758 October 2005 Busse
2005/0239518 October 2005 D'Agostino et al.
2006/0052109 March 2006 Ashman, Jr. et al.
2006/0240805 October 2006 Backholm et al.
2006/0294388 December 2006 Abraham et al.
2007/0021065 January 2007 Sengupta et al.
2007/0073766 March 2007 Porter
2007/0202850 August 2007 Pantalone et al.
2007/0260718 November 2007 Shenfield
2008/0005599 January 2008 Theocharous et al.
2008/0008313 January 2008 Fyke
2008/0045253 February 2008 Mousseau et al.
2008/0140794 June 2008 Rybak
2008/0242370 October 2008 Lando et al.
2008/0278312 November 2008 Kristensson
2008/0279212 November 2008 Tominaga
2008/0305839 December 2008 Karaoguz et al.
2009/0011791 January 2009 Tashiro
2009/0028084 January 2009 Ping
2009/0049482 February 2009 Auerbach et al.
2009/0055467 February 2009 Petersen
2009/0227251 September 2009 Lei et al.
2009/0239574 September 2009 Hussain
2009/0239581 September 2009 Lee
2009/0275349 November 2009 Bae et al.
2009/0305721 December 2009 Dunko
2009/0327491 December 2009 Tran et al.
2010/0083255 April 2010 Bane
2010/0093273 April 2010 Hohl
2010/0241312 September 2010 Preston et al.
2010/0250695 September 2010 Shenfield et al.
2011/0019555 January 2011 Gotoh et al.
2011/0045847 February 2011 Roin et al.
2011/0177847 July 2011 Huang
2011/0194539 August 2011 Blasinski et al.
2011/0216681 September 2011 Tao
2011/0255444 October 2011 Soliman et al.
2011/0275321 November 2011 Zhou et al.
2012/0112908 May 2012 Prykari et al.
2012/0155348 June 2012 Jacobson
2012/0155398 June 2012 Oyman et al.
2012/0260118 October 2012 Jiang et al.
2013/0163431 June 2013 Backholm et al.
2013/0272227 October 2013 Gallagher et al.
2014/0051485 February 2014 Wang et al.
2015/0085729 March 2015 Majjigi et al.
2015/0131453 May 2015 Tofighbakhsh et al.
2015/0181617 June 2015 Luna
2015/0241941 August 2015 Luna et al.
104010349 Aug 2014 CN
1 063 837 Dec 2000 EP
1 617 315 Jan 2006 EP
2008-113366 May 2008 JP
2010-061644 Mar 2010 JP
2006/103681 Oct 2006 WO
2008061042 May 2008 WO
2009070415 Jun 2009 WO
2012128792 Sep 2012 WO
Mirco Musolesi et al.; "Supporting Energy-Efficient Uploading Strategies for Continuous Sensing Applications on Mobile Phones", 1. School of Computer Science, University of St. Andrews, U.K.; 2. DEIS, University of Bologna, IT; 3. Ericsson Research, Hungary; 4. Department of Computer Science, Dartmouth College, NH, USA. (May 17, 2010). cited by applicant .
Joyce Ho and Stephen S. Intille; "Using Context-Aware Computing to Reduce the Perceived Burden of Interruptions from Mobile Devices", Massachusetts Institute of Technology, Cambridge, MA. (Jan. 18, 2005). cited by applicant .
Final rejection for U.S. Appl. No. 13/477,625 mailed on Aug. 20, 2015. cited by applicant .
Non-final rejection for U.S. Appl. No. 13/407,406 mailed on Sep. 9, 2015. cited by applicant .
EPO exam report mailed Jul. 14, 2015 for international application No. 11818512.3. cited by applicant .
Final Rejection mailed Aug. 20, 2015 for U.S. Appl. No. 13/477,625. cited by applicant .
Final rejection for U.S. Appl. No. 14/494,526 mailed on Nov. 13, 2015. cited by applicant .
Final Rejection mailed Aug. 7, 2015 for U.S. Appl. No. 14/050,211. cited by applicant .
CIPO, Commissioner's Decision for Canadian Patent Application No. 2,806,527, dated Jul. 20, 2016. cited by applicant .
Gigaom: "How to Stretch Battery Life on the HTV EVO 4G", Jun. 10, 2010, https://gigaom.com/2010/06/10/how-to-stretch-battery-life-on-the-htc-evo-- 4g/. cited by applicant .
Quintana, D.: "Mobile Multitasking", Apr. 14, 2010, http://davidquintana.com/entry/mobile-multitasking/. cited by applicant .
USPTO, Non-Final Rejection for U.S. Appl. No. 15/133,208, mailed on Jul. 29, 2016. cited by applicant .
Patent Office of the People's Republic of China, Second Office Action in Chinese Patent Application No. 201180063972.X dated Nov. 14, 2016. cited by applicant .
European Patent Office, Examination Report in Application No. 11842623.8-1853 dated Nov. 10, 2016. cited by applicant .
USPTO, Notice of Allowance for U.S. Appl. No. 15/205,036, mailed Nov. 17, 2016. cited by applicant .
USPTO, Notice of Allowance for U.S. Appl. No. 15/132,400, mailed on Jul. 14, 2016. cited by applicant .
USPTO, Notice of Allowance for U.S. Appl. No. 14/467,838, mailed on Jul. 15, 2016. cited by applicant .
USPTO, Non-Final Rejection for U.S. Appl. No. 14/872,009, mailed on Jun. 29, 2016. cited by applicant .
USPTO, Non-Final Rejection for U.S. Appl. No. 14/147,468, mailed on Jul. 13, 2016. cited by applicant .
USPTO, Non-Final Rejection for U.S. Appl. No. 14/147,434, mailed on Jul. 11, 2016. cited by applicant .
USPTO, Notice of Allowance for U.S. Appl. No. 15/099,254, mailed Dec. 19, 2016. cited by applicant .
USPTO, Final Rejection for U.S. Appl. No. 13/178,598, Jan. 4, 2016. cited by applicant .
USPTO, Non-Final Rejection for U.S. Appl. No. 14/872,009, Jan. 13, 2016. cited by applicant .
USPTO, Non-Final Office Action for U.S. Appl. No. 14/872,009 dated Jan. 13, 2016. cited by applicant .
USPTO, Non-Final Rejection for U.S. Appl. No. 14/873,143, Feb. 11, 2016. cited by applicant .
USPTO, Non-Final Rejection for U.S. Appl. No. 14/551,107, Feb. 4, 2016. cited by applicant .
EPO Exam Report dated Feb. 29, 2016 for EP Patent Application No. 11818512.3. cited by applicant .
USPTO, Final Rejection for U.S. Appl. No. 13/407,406, mailed on Feb. 26, 2016. cited by applicant .
USPTO, Final Rejection for U.S. Appl. No. 14/872,009, mailed on Apr. 15, 2016. cited by applicant .
USPTO, Non-Final Rejection for U.S. Appl. No. 13/477,625, mailed on Mar. 23, 2016. cited by applicant .
USPTO, Notice of Allowance for U.S. Appl. No. 14/467,881, mailed on Apr. 11, 2016. cited by applicant .
USPTO, Notice of Allowance for U.S. Appl. No. 13/351,176, mailed on Mar. 25, 2016. cited by applicant .
USPTO, corrected Notice of Allowance for U.S. Appl. No. 13/351,176, mailed on Apr. 13, 2016. cited by applicant .
CIPO, Letter from Patent Appeal Board for Canadian Patent Application No. 2,806,527, mailed on Mar. 30, 2016. cited by applicant .
EPO, Application No. 11818512.3, File history from Jul. 8, 2011 to Apr. 7, 2016. cited by applicant .
EPO, Application No. 11814939.2, File history from May 25, 2011 to Apr. 7, 2016. cited by applicant .
EPO, Application No. 11814940, File history from May 25, 2011 to Apr. 7, 2016. cited by applicant .
EPO, Application No. 11814973.1, File history from Jul. 8, 2011 to Apr. 7, 2016. cited by applicant .
EPO, Application No. 11814971.5, File history from Jul. 8, 2011 to Apr. 7, 2016. cited by applicant .
EPO, Application No. 11748780.1, File history from Jul. 22, 2011 to Apr. 7, 2016. cited by applicant .
EPO, Application No. 11838705.9, File history from Nov. 1, 2011 to Apr. 7, 2016. cited by applicant .
EPO, Application No. 11842623.8, File history from Nov. 22, 2011 to Apr. 7, 2016. cited by applicant .
EPO, Application No. 11843111.3, File history from Nov. 18, 2011 to Apr. 7, 2016. cited by applicant .
Canadian Patent Office, Application No. 2806557, file history from Jul. 22, 2011 to Apr. 7, 2016. cited by applicant .
Canadian Patent Office, Application No. 2857458, File history from Jul. 22, 2011 to Apr. 7, 2016. cited by applicant .
Canadian Patent Office, Application No. 2806529, File history from May 25, 2011 to Apr. 7, 2016. cited by applicant .
Canadian Patent Office, Application No. 2806549, File history from Jul. 8, 2011 to Apr. 7, 2016. cited by applicant .
Canadian Patent Office, Application No. 2798523, File history from Nov. 18, 2011 to Apr. 7, 2016. cited by applicant .
Great Britain Property Office, Application No. GB1301258.8, File history from Jul. 8, 2011 to Apr. 7, 2016. cited by applicant .
Great Britain Property Office, Application No. GB1310340.3, File history from Jul. 22, 2011 to Apr. 7, 2016. cited by applicant .
Great Britain Property Office, Application No. GB1400059, File history from Jul. 22, 2011 to Apr. 4, 2016. cited by applicant .
Great Britain Property Office, Application No. GB1307573.4, File history from Nov. 1, 2011 to Apr. 7, 2016. cited by applicant .
Great Britain Property Office, Application No. GB1309234.1, File history from Nov. 22, 2011 to Apr. 7, 2016. cited by applicant .
Great Britain Property Office, Application No. GB1309373.7, File history from May 25, 2044 to Apr. 7, 2016. cited by applicant .
Great Britain Property Office, Application No. GB1316847.1, File history from Nov. 1, 2011 to Apr. 7, 2016. cited by applicant .
USPTO, Final Rejection for U.S. Appl. No. 14/748,218, mailed on May 6, 2016. cited by applicant .
USPTO, Advisory Action for U.S. Appl. No. 14/748,218, mailed on Jun. 7, 2016. cited by applicant .
USPTO, Non-Final Rejection for U.S. Appl. No. 15/077,370, mailed on Jun. 10, 2016. cited by applicant .
InnovationQ--IP.com: Search results of "Optimizing Mobile Network Traffic Across . . . ", May 30, 2016, https://iq.ip.com/discover. cited by applicant .
IEEE Xplore Search Results: Search results of "Optimizing Mobile Network Traffic Across Multiple Application Running on a Mobile Device", May 30, 2016, http://ieeexplore.ieee.org/search. cited by applicant .
USPTO, Non-Final Rejection for U.S. Appl. No. 14/710,167, mailed on Jun. 6, 2016. cited by applicant .
InnovationQ--IP.com: Search results of "Mobile traffic optimization and coordination and . . . ", May 30, 2016, https://iq.ip.com/discover. cited by applicant .
IEEE Xplore Search Results: Search results of "Mobile traffic optimization and coordination and user experience enhancement", May 30, 2016, http://ieeexplore.ieee.org/search. cited by applicant .
USPTO, Notice of Allowance for U.S. Appl. No. 15/077,370, mailed Sep. 14, 2016. cited by applicant .
InnovationQ--IP.com: Search results of "Optimizing mobile network traffic across multiple . . . ", Sep. 2, 2016, https://iq.ip.com/discover. cited by applicant .
IEEE Xplore Search Results: Search results of "Optimizing mobile network traffic across multiple application to save power on the battery and refined by", Sep. 2, 2016, http://ieeexplore.ieee.org/search. cited by applicant .
EPO, Examination Report for European Patent Application No. 11748780.1, dated Feb. 14, 2017. cited by applicant .
USPTO, Notice of Allowance for U.S. Appl. No. 14/629,520, dated Jan. 11, 2017. cited by applicant .
USPTO, Notice of Allowance for U.S. Appl. No. 14/710,167, dated Feb. 8, 2017. cited by applicant .
Search result of Jan. 6, 2017, performed by the Examiner on https://iq.ip.com/discover (InnovationQ--IP.com) and attached to the Notice of Allowance for U.S. Appl. No. 14/710,167, dated Feb. 8, 2017. cited by applicant .
Search result of Jan. 6, 2017, performed by the Examiner on http://ieeexplore.ieee.org/search (IEEE Xplore Search Results) and attached to the Notice of Allowance for U.S. Appl. No. 14/710,167, dated Feb. 8, 2017. cited by applicant .
USPTO, Supplemental Notice of Allowance in U.S. Appl. No. 14/629,520 mailed Apr. 4, 2017. cited by applicant.
This application is a continuation of U.S. application Ser. No. 13/178,598 filed Jul. 8, 2011, which claims the benefit of U.S. Provisional Application 61/430,828 filed Jan. 7, 2011, 61/416,033 filed Nov. 22, 2010, 61/416,020 filed Nov. 22, 2010, 61/408,846 filed Nov. 1, 2010, 61/408,854 filed Nov. 1, 2010, 61/408,858 filed Nov. 1, 2010, 61/408,829 filed Nov. 1, 2010, 61/408,826 filed Nov. 1, 2010, 61/408,820 filed Nov. 1, 2010, 61/408,839 filed Nov. 1, 2010, 61/367,870 filed Jul. 26, 2010, and 61/367,871 filed Jul. 26, 2010, each of which is incorporated herein by reference in its entirety.
1. A method of conserving battery consumption on a mobile device, the method, comprising: monitoring at least one characteristic of user activity on the mobile device, wherein one of the at least one characteristic of user activity is a determined inactivity of the user; locally adjusting behavior of the mobile device to optimize battery consumption on the mobile device by entering the mobile device into a power save mode, wherein entry into the power save mode occurs in response to a duration of determined inactivity of the user exceeding a first predetermined amount of time; when in the power save mode: suppressing outgoing network communications to a first application server from the mobile device for a first suppression period for a first application while user activity is not detected; suppressing outgoing network communications to a second application server from the mobile device for the first suppression period for a second application while user activity is not detected; receiving a message during the first suppression period directed towards the first application, wherein the message is received from a remote server distinct from the first application server, wherein the message contains data from the first application server; transmitting communications after expiration of the first suppression period while user activity is not detected; when user activity is detected after entry into the power save mode, exiting the power save mode and transmitting outgoing network communications from the first application to the first application server and from the second application to the second application server.
2. The method of claim 1, wherein monitoring at least one characteristic includes monitoring a backlight status of the mobile device.
3. The method of claim 1, wherein monitoring at least one characteristic includes monitoring a duration since last key press.
4. The method of claim 1, wherein monitoring at least one characteristic includes monitoring key presses on the mobile device.
5. The method of claim 1, further comprising, when in the power save mode, suppressing outgoing network communications from the mobile device for a second suppression period while user activity is not detected.
6. The method of claim 1, wherein the first application server delays sending communications to the mobile device during the first suppression period.
7. The method of claim 1, wherein the method includes not placing the mobile device in the power save mode if the mobile device is plugged in to a power source.
8. The method of claim 1, further including exiting the power save mode when any one of each of the following conditions occur: the mobile device is plugged into a power source; a backlight of the mobile device is on; and it is detected that keys are being pressed on the mobile device.
9. The method of claim 1, wherein transmitting communications after expiration of the first suppression period is transmitted during a transmission period, wherein receipt of the message during the first suppression period directed to the first application does not alter an initiation timing of the transmission period that follows expiration of the first suppression period.
10. The method of claim 9, wherein a connection is maintained for receipt of the message.
11. The method of claim 9, further comprising suppressing outgoing network communications from the mobile device for a second suppression period.
12. The method of claim 11, where the second suppression period is longer than the first suppression period.
13. The method of claim 1, wherein monitoring at least one characteristic of user activity on the mobile device comprises sensing motion of the mobile device.
14. The method of claim 13, wherein sensed motion is indicative of user activity of the mobile device.
15. The method of claim 1, wherein an outgoing network communication is allowed in response to receipt of the message during the first suppression period.
16. A mobile device comprising: a radio; a memory; and a processor configured to allow the mobile device to: monitor at least one characteristic of user activity on the mobile device, wherein one of the at least one characteristic of user activity is a determined inactivity of the user; and locally adjust behavior of the mobile device to optimize battery consumption on the mobile device by entering the mobile device into a power save mode, wherein entry into the power save mode occurs in response to a duration of determined inactivity of the user exceeding a first predetermined amount of time, when in the power save mode: suppress outgoing network communications to a first application server from the mobile device for a first suppression period for a first application while user activity is not detected, suppress outgoing network communications to a second application server from the mobile device for the first suppression period for a second application while user activity is not detected, and receive a message during the first suppression period directed towards the first application, wherein the message is received from a remote server distinct from the first application server, wherein the message contains data from the first application server, transmit communications after expiration of the first suppression period while user activity is not detected; when user activity is detected after entry into the power save mode, exit the power save mode and transmit communications.
17. The mobile device of claim 16, wherein the monitored at least one characteristic includes a monitored backlight status of the mobile device.
18. The mobile device of claim 16, wherein the monitored at least one characteristic includes a monitored duration since last key press.
19. The mobile device of claim 16, wherein the monitored at least one characteristic includes monitored key presses on the mobile device.
20. The mobile device of claim 16, wherein the monitored at least one characteristic includes a monitored duration since a last key press; and the locally adjusted behavior of the mobile device further allows the mobile device to suppress outgoing network communications from the mobile device for the first suppression period, when a duration of user inactivity exceeds a second predetermined amount of time.
21. The mobile device of claim 20, wherein the processor is further configured to allow the mobile device to, when in the power save mode: suppress outgoing network communications from the mobile device for a second suppression period while user activity is not detected.
22. The mobile device of claim 20, wherein the first application server delays sending communications to the mobile device during the first suppression period.
23. The mobile device of claim 16, wherein the processor is configured to not place the mobile device into the power save mode if the mobile device is plugged into a power source.
24. The mobile device of claim 16, wherein the processor is configured to allow the mobile device to: detect that the mobile device is plugged into a power source; detect that a screen of the mobile device transitions from off to on; detect key presses on the mobile device; and exit the power save mode when any one of the following occurs: the mobile device is plugged into the power source; the screen of the mobile device transitions from off to on; key presses are detected on the mobile device.
25. The mobile device of claim 16, wherein, when in the power save mode, an outgoing network communication is allowed in response to receipt of the message during the first suppression period.
26. A method of conserving battery consumption on a mobile device, the method, comprising: monitoring at least one characteristic of user activity on the mobile device, wherein one of the at least one characteristic of user activity is a determined inactivity of the user; locally adjusting behavior of the mobile device to optimize battery consumption on the mobile device by entering the mobile device into a power save mode, wherein entry into the power save mode occurs in response to a duration of determined inactivity of the user exceeding a first predetermined amount of time; while in the power save mode: suppressing outgoing network communications to a first application server from the mobile device for a first suppression period for a first application while user activity is not detected; suppressing outgoing network communications to a second application server from the mobile device for the first suppression period for a second application while user activity is not detected; receiving a message during the first suppression period directed towards the first application, wherein the message is received from a remote server distinct from the first application server, wherein the message contains data from the first application server, allowing transmission of communications for the second application from the mobile device at expiration of a first suppression period having a second predetermined amount of time, wherein receipt of the message directed towards the first application during the first suppression period does not alter a timing of the expiration of the first suppression period.
27. A mobile device comprising: a radio; a memory; and a processor configured to allow the mobile device to: monitor at least one characteristic of user activity on the mobile device, wherein one of the at least one characteristic of user activity is a determined inactivity of the user; locally adjust behavior of the mobile device to optimize battery consumption on the mobile device by entering the mobile device into a power save mode, wherein entry into the power save mode occurs in response to a duration of determined inactivity of the user exceeding a first predetermined amount of time; while in the power save mode: suppressing outgoing network communications to a first application server from the mobile device for a first suppression period for a first application while user activity is not detected; suppressing outgoing network communications to a second application server from the mobile device for the first suppression period for a second application while user activity is not detected; receiving a message during the first suppression period directed towards the first application, wherein the message is received from a remote server distinct from the first application server, wherein the message contains data from the first application server, allowing transmission of communications for the second application from the mobile device at expiration of a first suppression period having a second predetermined amount of time, wherein receipt of the message directed towards the first application during the first suppression period does not alter a timing of the expiration of the first suppression period.
When WCDMA was specified, there was little attention to requirements posed by applications whose functions are based on actions initiated by the network, in contrast to functions initiated by the user or by the device. Such applications include, for example, push email, instant messaging, visual voicemail and voice and video telephony, and others. Such applications typically require an always-on IP connection and frequent transmit of small bits of data. WCDMA networks are designed and optimized for high-throughput of large amounts of data, not for applications that require frequent, but low-throughput and/or small amounts of data. Each transaction puts the mobile device radio in a high power mode for considerable length of time--typically between 15-30 seconds. As the high power mode can consume as much as 100.times. the power as an idle mode, these network-initiated applications quickly drain battery in WCDMA networks. The issue has been exacerbated by the rapid increase of popularity of applications with network-initiated functionalities, such as push email.
FIG. 11 illustrates a diagram of a power saving mode.
FIG. 12 shows a diagrammatic representation of a machine in the example form of a computer system within which a set of instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed.
One embodiment of the disclosed technology includes, a system that optimizes multiple aspects of the connection with wired and wireless networks and devices through a comprehensive view of device and application activity including: loading, current application needs on a device, controlling the type of access (push vs. pull or hybrid), location, concentration of users in a single area, time of day, how often the user interacts with the application, content or device, and using this information to shape traffic to a cooperative client/server or simultaneously mobile devices without a cooperative client. Because the disclosed server is not tied to any specific network provider it has visibility into the network performance across all service providers. This enables optimizations to be applied to devices regardless of the operator or service provider, thereby enhancing the user experience and managing network utilization while roaming. Bandwidth has been considered a major issue in wireless networks today. More and more research has been done related to the need for additional bandwidth to solve access problems--many of the performance enhancing solutions and next generation standards, such as those commonly referred to as 4G, namely LTE, 4G, and WiMAX are focused on providing increased bandwidth. Although partially addressed by the standards a key problem that remains is lack of bandwidth on the signaling channel more so than the data channel. Embodiments of the disclosed technology includes, for example, alignment of requests from multiple applications to minimize the need for several polling requests; leverage specific content types to determine how to proxy/manage a connection/content; and apply specific heuristics associated with device, user behavioral patterns (how often they interact with the device/application) and/or network parameters.
In addition, communications can be achieved via one or more networks, such as, but are not limited to, one or more of WiMax, a Local Area Network (LAN), Wireless Local Area Network (WLAN), a Personal area network (PAN), a Campus area network (CAN), a Metropolitan area network (MAN), a Wide area network (WAN), a Wireless wide area network (WWAN), enabled with technologies such as, by way of example, Global System for Mobile Communications (GSM), Personal Communications Service (PCS), Digital Advanced Mobile Phone Service (D-Amps), Bluetooth, Wi-Fi, Fixed Wireless Data, 2G, 2.5G, 3G, 4G, IMT-Advanced, pre-4G, 3G LTE, 3GPP LTE, LTE Advanced, mobile WiMax, WiMax 2, WirelessMAN-Advanced networks, enhanced data rates for GSM evolution (EDGE), General packet radio service (GPRS), enhanced GPRS, iBurst, UMTS, HSPDA, HSUPA, HSPA, UMTS-TDD, 1.times.RTT, EV-DO, messaging protocols such as, TCP/IP, SMS, MMS, extensible messaging and presence protocol (XMPP), real time messaging protocol (RTMP), instant messaging and presence protocol (IMPP), instant messaging, USSD, IRC, or any other wireless data networks or messaging protocols.
In general, the local proxy 175 and the proxy server 125 are transparent to the multiple applications executing on the mobile device. The local proxy 175 is generally transparent to the operating system or platform of the mobile device and may or may not be specific to device manufacturers. For example, he local proxy can be implemented without adding a TCP stack and thus act transparently to both the US and the mobile applications. In some instances, the local proxy 175 is optionally customizable in part or in whole to be device specific. In some embodiments, the local proxy 175 may be bundled into a wireless model, into a firewall, and/or a router.
As used herein, a "module," "a manager," a "handler," a "detector," an "interface," or an "engine" includes a general purpose, dedicated or shared processor and, typically, firmware or software modules that are executed by the processor. Depending upon implementation-specific or other considerations, the module, manager, hander, or engine can be centralized or its functionality distributed. The module, manager, hander, or engine can include general or special purpose hardware, firmware, or software embodied in a computer-readable (storage) medium for execution by the processor. As used herein, a computer-readable medium or computer-readable storage medium is intended to include all mediums that are statutory (e.g., in the United States, under 35 U.S.C. 101), and to specifically exclude all mediums that are non-statutory in nature to the extent that the exclusion is necessary for a claim that includes the computer-readable (storage) medium to be valid. Known statutory computer-readable mediums include hardware (e.g., registers, random access memory (RAM), non-volatile (NV) storage, to name a few), but may or may not be limited to hardware.
The proxy 275 is generally application independent and can be used by applications (e.g., both proxy aware and proxy-unaware mobile applications 210 and 220) to open TCP connections to a remote server (e.g., the server 100 in the examples of FIGS. 1A-1B and/or server proxy 125/325 shown in the examples of FIG. 1B and FIG. 3). In some instances, the local proxy 275 includes a proxy API 225 which can be optionally used to interface with proxy-aware applications 220 (or mobile applications on a mobile device).
In one embodiment, the user activity module 215 interacts with the context API 206 to identify, determine, infer, detect, compute, predict, and/or anticipate, characteristics of user activity on the device 250. Various inputs collected by the context API 206 can be aggregated by the user activity module 215 to generate a profile for characteristics of user activity. Such a profile can be generated by the module 215 with various temporal characteristics. For instance, user activity profile can be generated in real-time for a given instant to provide a view of what the user is doing or not doing at a given time (e.g., defined by a time window, in the last minute, in the last 30 seconds, etc.), a user activity profile can also be generated for a `session` defined by an application or web page that describes the characteristics of user behavior with respect to a specific task they are engaged in on the device 250, or for a specific time period (e.g., for the last 2 hours, for the last 5 hours).
TABLE-US-00001 TABLE I Change Change (initiated on device) Priority (initiated on server) Priority Send email High Receive email High Delete email Low Edit email Often not (Un)read email Low possible to sync (Low if possible) Move message Low New email in Low Read more High deleted items Down load High Delete an email Low attachment (Un)Read an email Low New Calendar event High Move messages Low Edit/change Calendar High Any calendar change High event Any contact change High Add a contact High Wipe/lock device High Edit a contact High Settings change High Search contacts High Any folder change High Change a setting High Connector restart High (if no Manual send/receive High changes nothing is sent) IM status change Medium Social Network Medium Status Updates Auction outbid or High Sever Weather High change notification Alerts Weather Updates Low News Updates Low
Inbox pruning events (e.g., email, or any other types of messages), are generally considered low priority and absent other impending events, generally will not trigger use of the radio on the device 250. Specifically, pruning events to remove old email or other content can be `piggy backed` with other communications if the radio is not otherwise on, at the time of a scheduled pruning event. For example, if the user has preferences set to `keep messages for 7 days old,` then instead of powering on the device radio to initiate a message delete from the device 250 the moment that the message has exceeded 7 days old, the message is deleted when the radio is powered on next. If the radio is already on, then pruning may occur as regularly scheduled.
In general, the network interface 308 can include one or more of a network adaptor card, a wireless network interface card (e.g., SMS interface, WiFi interface, interfaces for various generations of mobile communication standards including but not limited to 1G, 2G, 3G, 3.5G, 4G type networks such as, LTE, WiMAX, etc.), Bluetooth, WiFi, or any other network whether or not connected via a a router, an access point, a wireless router, a switch, a multilayer switch, a protocol converter, a gateway, a bridge, bridge router, a hub, a digital media receiver, and/or a repeater.
As used herein, a "module," "a manager," a "handler," a "detector," an "interface," a "controller," or an "engine" includes a general purpose, dedicated or shared processor and, typically, firmware or software modules that are executed by the processor. Depending upon implementation-specific or other considerations, the module, manager, handler, or engine can be centralized or its functionality distributed. The module, manager, handler, or engine can include general or special purpose hardware, firmware, or software embodied in a computer-readable (storage) medium for execution by the processor. As used herein, a computer-readable medium or computer-readable storage medium is intended to include all mediums that are statutory (e.g., in the United States, under 35 U.S.C. 101), and to specifically exclude all mediums that are non-statutory in nature to the extent that the exclusion is necessary for a claim that includes the computer-readable (storage) medium to be valid. Known statutory computer-readable mediums include hardware (e.g., registers, random access memory (RAM), non-volatile (NV) storage, to name a few), but may or may not be limited to hardware.
In one embodiment, content caching is performed locally on the device 350 with the assistance of host server 300. For example, proxy server 325 in the host server 300 can query the application server/provider 310 with requests and monitor changes in responses. When changed, different or new responses are detected (e.g., by the new data detector 347), the proxy server 325 can notify the mobile device 350, such that the local proxy on the device 350 can make the decision to invalidate (e.g., indicated as out-dated) the relevant cache entries stored as any responses in its local cache. Alternatively, the data invalidator module 368 can automatically instruct the local proxy of the device 350 to invalidate certain cached data, based on received responses from the app application server/provider 310. The cached data is marked as invalid, and can get replaced or deleted when new content is received from the content server 310.
In process 602, characteristics of user activity on the mobile device are detected. In process 604, behavior of the mobile device is adjusted to optimize battery consumption on the mobile device. The adjustment of the behavior of the mobile device can include, for example, adjusting the use of radio on the mobile device, as in process 606. In addition, in process 608, the radio can be switched on/off. Further, the radio can also be placed in low power or high power radio mode in process 612.
In addition, data can be cached at the mobile device in process 610 to adjust radio use. Data may also be cached at the server in wireless communication with the mobile device to in order to modify communication frequency with the mobile device. In one embodiment, in response to detection of user activities on the mobile device, the characteristics of the user activity can be communicated from the mobile device to the server, in process 614.
Similarly, based on the user activity characteristics, communication frequency of a server with the mobile device can be adjusted in process 616. For example, data push frequency from the server to the mobile device is decreased, in process 618. Similarly, data can be cached at the server in process 620 to adjust communication frequency.
In addition, characteristics of transactions occurring at the mobile device can also be used to locally adjust radio use on the mobile device. For example, characteristics of transactions include time criticality of the transactions and that a low power radio mode or a high power radio mode can be selected for use on the mobile device based on the time criticality of the transactions. Additionally, a low power radio mode or a high power radio mode is selected for use on the mobile device based on amount of data to be transferred in the transactions.
In process 702, it is determined if the user actively interacting with the mobile device. If the user is actively interacting with the mobile device, the mobile device 714 can be notified, as in process 714, of new data or changes in data.
If not, in process 704, device can wait to send low priority transactions until after the user activity has been dormant for a period of time, for example, low priority transactions include, one or more of, updating message status as being read, unread, and deleting of messages. In addition, low priority transactions can be sent when a higher priority transaction needs to be sent, thus utilizing the same radio power-up event. Low priority transactions can generally include application maintenance events, events not requested by a user, events scheduled to be in the future, such as, by way of example but not limitation, one or more of, updating message status as being read, unread, and deleting of messages.
Similarly, if the user is not active, data push frequency from the server can be decreased in process 706. In process 708, if the user is detected to be subsequently active after being inactive, then data buffered as a result of decreased communication frequency can be sent to the mobile device, in process 710.
Alternatively, even if the user is not actively interacting with the mobile device, an assessment can be made as to whether high importance data (e.g., data importance or priority meeting a threshold level) is pending to be sent to the mobile device, in process 712. If so, the mobile device is notified, in process 714. As a result of the notification, the mobile device radio can be enabled such that the high importance data can be sent to the mobile device. In general, the importance of data can be determined based on one or more of several criteria including but not limited to, application to which the data is relevant, time criticality, and time sensitivity, etc. An example of a time critical transaction includes a transaction resulting from a user-initiated data transfer.
In process 802, user activity is detected at a device separate from a mobile device. In process 804, it is determined whether the user activity at the device is able to access the same data, content, or application, which is also setup to be delivered to or accessed at the mobile device. For example, user activity at the device separate from the mobile device can include user access of an email inbox or other types applications via an interface other than that accessed from the mobile device (e.g., from a laptop or desktop computer). Since the user is now accessing the client from another device, the user now may not need content to be updated as frequently on the mobile device. Thus, in process 806, communication frequency from a server to the mobile device is decreased.
In process 902, multiple occurrences of events having a first priority type initiated on the mobile device are detected.
In process 904, the mobile device cumulates multiple occurrences of events having a first priority type initiated on the mobile device, before transfer over the wireless network. The first priority type can be a generally low priority type indicating a request or update which is not time critical or time sensitive. Thus, if the device radio is currently off, the radio may not be immediately turned on to transmit individual events which are not time critical, until other triggering events occur or other criteria is met.
For example, in process 906, occurrence of an event of a second priority type is detected, which can trigger batch transfer of the cumulated events to a server in wireless communication with the mobile device, in process 916, where the second priority type is of a higher priority than the first priority type.
In another example, in process 908, data transfer from the server can trigger the radio use on the mobile device, which can trigger batch transfer of the cumulated events to a server in wireless communication with the mobile device, in process 916. Alternatively, in process 910, after a period of time elapses, batch transfer of the cumulated events to a server in wireless communication with the mobile device can be triggered, in process 916.
In one embodiment, in process 912, a user trigger (e.g., a manual sync request) or in response to a user prompt, batch transfer of the cumulated events to a server in wireless communication with the mobile device can be triggered, in process 916. In process 914, when it is detected that an application is exited and/or moved into the background, batch transfer of the cumulated events to a server in wireless communication with the mobile device can be triggered, in process 916.
In process 1002, multiple occurrences of events having a first priority type are detected at a server wirelessly coupled to a mobile device. In process 1004, the server cumulates the multiple occurrences of events having a first priority type, before transfer over the wireless network. The first priority type may not be of a high priority type or having a priority exceeding a certain threshold level indicating a level or time criticality or urgency. Thus, such events, upon occurrence, may not be immediately transferred to the mobile device, until certain criterion is met, or until one or more triggering events occur.
For example, in process 1006, occurrence of an event of a second priority type is detected at the server, which can trigger batch transfer of the cumulated events to the mobile device, in process 1016, when the second priority type is of a higher priority than the first priority type. In another example, in process 1008, data transfer from the mobile device indicates the radio use on the mobile device, which can trigger batch transfer of the cumulated events to the mobile device, in process 1016.
Alternatively, in process 1010, after a period of time elapses, batch transfer of the cumulated events to the mobile device can be triggered, in process 1016. In process 1012, a user trigger or in response to a user prompt, batch transfer of the cumulated events to the mobile device can be triggered, in process 1016. In process 1014, when it is detected that an application is exited and/or moved into the background, batch transfer of the cumulated events to the mobile device can be triggered, in process 1016. In general, manual overrides or manual syncs can cause batch transfers to occur, either from the mobile device to the server or vice versa.
Sensing User Activity
In order to minimize the negative battery drain, there is a process for collecting large numbers of new emails (or high priority changes) and syncing them in batches rather than individually. This is achieved by introducing a `power save` mode. This change is targeted at improving the power performance especially for users who receive a large number of emails during the day.
The proposed changes affect all accounts/products and are fundamental changes to the `always in sync` nature.
Power Save Mode (IP & Hybrid SMS Mode)
The over view of this mode is as follows: 1. The client monitors user activity on the device (see section below). Each platform will do this in their own way but is it usually done with a backlight state API or monitoring keyboard clicks. If the user is active on the device, push behavior is as currently implemented. In IP only mode always-on-push is maintained in hybrid mode SMS triggers are immediately sent and responded too. 2. After @client.inactivity_power_save_secs@ set to 1200 (20 mins) by default time has expired since the last end user device activity then the device goes into power saving mode. 3. The client waits for the next new email to be delivered by the server (Connect to receive email etc) and responds with a power save RPC call to all the account end points it currently has registered. NOTE this requires a new Sync layer RPC. NOTE this may require multiple RPC calls (one per registered account) but they should be timed to use the same high power radio event, as each other and the reason for the power event in the first place (receiving an email), for example, timed within milliseconds of each other. 4. The power save RPC call will include a time (power save period) indicating to the connectors when the client next wants to receive any changes. 5. The 1.sup.st, N power saving periods in a single power save event will be @client.push_batch_period_one_power_save_secs@ set to 900 (15 mins) by default long any additional consecutive power saving periods will be @client.push_batch_period_two_power_save_secs@ set to 3600 (1 hour) by default N=@server.push_batch_period_one_repeat_power_save_secs@ set to 4 by default Any activity on the device takes the client out of power saving mode and end that particular power save event. If additional data is received before the end of any one power saving period, then the wait period communicated to the connectors will be the existing period--elapsed time since the power save RPC was sent. 6. When a connector receives a power save notification from a device it stops sending changes (data or SMS's) for the period of time requested (the wait period). At the end of the wait period any notifications received will be acted upon and changes sent to the device as a single event if no notifications come in then true push will resume with the data or an SMS being sent immediately to the device. 7. The wait period must be able to be updated as the client may send additional power saving RPCs (with updated wait times) if multi accounts respond to the end of a wait period with different delays. 8. Coordinating all connectors for a particular device (7TP) address to reach the end of a wait period together would be ideal but is not easily possible and will not be done at this time. This maximizes the chance that any change batches sent to the client from multiple accounts will arrive at the device at the same time and will only cause one power event by strictly adhering the to the wait periods send from the client unless the connector knows that it is `running` slow or always takes x more seconds to complete than our standard WE/EE backend. In this case the connector may start the poll or data collect event x seconds early in order to increase the chance that the client will receive data at their specified time. NOTE this is at best going to increase chances of hitting the powered up window. 9. Whenever new email comes into the client while it is in a power saving mode it responds with the power saving RPC to all end points currently registered. The next power save period will be communicated based on the logic in point 5 above. 10. If the client needs to send a keep-alive while it is in power saving mode then it sends the keep-alive and reconnects if necessary.--optimizing the keep-alive and reconnection logic during power saving mode is an area we will improve on in the future. 11. Whenever the device detects user activity (key press' or backlight on) then it exits' power saving mode, if a power saving period is currently in progress then the client sends a power save cancel RPC to its backend connectors and immediately receives any changes associated with any pending notifications. This may require a poll to be run by the connector after receiving the power saving cancel RPC. If the latest power saving period has expired then no power save cancel RPC is required as the connectors will already be in normal true push operational mode. 12. Devices should come out of and not go into power save mode if they are `plugged in` to charge. 13. Quiet time hours should not affect the calculation of entering power save mode. However we should still respect the quiet time hours and disconnect during them. At the end of a quiet time the client should reconnect and receive any data waiting on the connector but should then immediately send another power save RPC if the device has not shown any end user activity. Note the timing here is critical so that the power event that receives the data should also cover the power save RPC. 14. Power save RPCs should not be retried. We should just wait for the next new mail and send another power save RPC if appropriate. 15. There needs to be a brandable parameter to turn support for power save mode on and off. The default for this parameter should be `on`. Off may be needed for automated testing and load testing. Future requirements may need this on/off control to be visible in the client UI. 16. Currently the CE server optimizes load by only polling a CE account once even if a user is accessing that account with two devices. We will poll the account any time either device/account require us too but will only send data to devices who want it (ie are not in power save mode). 17. Calendar and contact changes will continue to be delivered as soon as they are discovered. They will also not trigger a power save response from the client. If sending calendar or contact data. any pending email data is sent.
The end result of these changes is that a user that receives multiple emails while not interacting with their phone will have a significantly prolonged battery life. The more emails a user receives the greater the power savings for their phone.
The two user cases that have driven the default parameter settings are the 1-2 hour lunch or meeting--where the system now moves into power saving mode after 30 minutes and then only sync 4 times even if a user received 35 emails in that hour. The other is leaving a phone on over night but with quiet hours set poorly (for example, only quiet for 4 hours 00:00 to 04:0). In this case, a once an hour sync state is provided to thereby preserve your battery despite the short quiet time you have set.
In the initial implementation power saving mode will not be respected by the CE connector for accounts that are activated on more than one device. This is because the CE account manager combines accounts into a single poll request for the same account if it is activated on more than one device. The complexity of supporting two polls at different times due to different power saving status of two or more devices is not wanted for the initial implementation.
Various platforms implement detection of device activity differently. In one embodiment, the system forms a plug-in to the base Operating System in this platform. One method for monitoring the user device activity is to request the device to notify us when the backlight turns off. The user idle logic is thus: 1. Enter power saving mode: device screen goes idle and stays idle for @client.inactivity_power_save_secs@ set to 1200 by default 2. Exit power saving mode: device screen turns on
Another embodiment forms a plug-in to the base Operating System in this platform. One method for monitoring the user device activity is to use a device API that returns the `time since last user activity` (usually a key press). The user idle logic is thus: 1. Enter power saving mode: device screen goes idle and stays idle for @client.inactivity_power_save_secs@ set to 1200 by default Detect this by calling the last user activity API and then waiting until the timer might be up and calling it again to see if the user has remained inactive. 2. Exit power saving mode: Detect activity by calling the last user activity API regularly--every 5 mins.
In another embodiment, one method for monitoring the user device activity is to periodically poll the device to identify if the backlight is off. This is similar to our current polling for battery level. The user idle logic is therefor: 1. Enter power saving mode: device screen goes idle and stays idle for @client.inactivity_power_save_secs@ set to 1200 by default We will need to detect this by calling the last user activity API and then waiting until our timer might be up and calling it again to see if the user has remained inactive. 2. Exit power saving mode: Detect activity by calling the last user activity API regularly, such as every 5 mins.
In another embodiment, one method for monitoring the user device activity is to watch for key press'. The user idle logic therefore needs to be: 1. Enter power saving mode: if no keys are pressed for @client.inactivity_power_save_secs@ set to 1200 by default 2. Exit power saving mode: on first device key press.
Provided herein is an email application that is limited to working within the Java Platform ("J2ME") `sand box` on the device. Two `styles` of J2ME exist on phones, one that supports a background mode and one that does not. J2ME can detect key strokes while we are in the foreground mode but not in background. One method is to query the device screen and find out if the last screen load that was sent is still being shown. The J2ME client also has to deal with the red key which acts as an immediate `kill`. The user logic therefore needs to be: 1. If the application is exited then no changes--there is provided a "would you like to sync?" screen shown on client launch. 2. Enter power saving mode: enters background mode and has been in it for at least @client.inactivity_power_save_secs@ set to 1200 by default OR we are in foreground mode and no keys have been pressed for that amount of time 3. Exit power saving mode: This may be done by going from background mode into foreground mode. OR a key is pressed while we are in foreground mode. 4. All connection errors and retries should apply in the same way that they currently do to any device data sends.
FIG. 11 shows a diagrammatic representation of a power saving mode disclosed herein to accompany the prior description.
While the machine-readable medium or machine-readable storage medium is shown in an exemplary embodiment to be a single medium, the term "machine-readable medium" and "machine-readable storage medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "machine-readable medium" and "machine-readable storage medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the presently disclosed technique and innovation.
In general, the routines executed to implement the embodiments of the disclosure, may be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as "computer programs." The computer programs typically comprise one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processing units or processors in a computer, cause the computer to perform operations to execute elements involving the various aspects of the disclosure.
The network interface device enables the machine 1100 to mediate data in a network with an entity that is external to the host server, through any known and/or convenient communications protocol supported by the host and the external entity. The network interface device can include one or more of a network adaptor card, a wireless network interface card, a router, an access point, a wireless router, a switch, a multilayer switch, a protocol converter, a gateway, a bridge, bridge router, a hub, a digital media receiver, and/or a repeater.
Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise," "comprising," and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to." As used herein, the terms "connected," "coupled," or any variant thereof, means any connection or coupling, either direct or indirect, between two or more elements; the coupling of connection between the elements can be physical, logical, or a combination thereof. Additionally, the words "herein," "above," "below," and words of similar import, when used in this application, shall refer to this application as a whole and not to any particular portions of this application. Where the context permits, words in the above Detailed Description using the singular or plural number may also include the plural or singular number respectively. The word "or," in reference to a list of two or more items, covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.
While certain aspects of the disclosure are presented below in certain claim forms, the inventors contemplate the various aspects of the disclosure in any number of claim forms. For example, while only one aspect of the disclosure is recited as a means-plus-function claim under 35 U.S.C. .sctn.112, 6, other aspects may likewise be embodied as a means-plus-function claim, or in other forms, such as being embodied in a computer-readable medium. (Any claims intended to be treated under 35 U.S.C. .sctn.112, 6 will begin with the words "means for".) Accordingly, the applicant reserves the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the disclosure.
Previous Patent US 9,681,386 | Next Patent US 9,681,388