Browse Prior Art Database

Method of User Context-Based Network Scheduling

IP.com Disclosure Number: IPCOM000243449D
Publication Date: 2015-Sep-22
Document File: 1 page(s) / 27K

Publishing Venue

The IP.com Prior Art Database

Abstract

Described is a mechanism for scheduling network traffic based on the context of a user. Context can be obtained by a plurality of devices, and many sensors may be used.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 01 of 1

Method of User Context -

This invention provides a mechanism for scheduling network traffic based on the context of a user. Context can be obtained by a plurality of devices, and many sensors may be used. Once the context is derived, policies can dictate the behavior assigned to incoming or outgoing network traffic on a device, such as assigning quality-of-service levels, scheduling or delaying traffic, dropping traffic, or encoding traffic with different amounts of resiliency.

    The context can be derived in a way that one vested in the art will readily understand. For example, mobile operating systems, such as Android*, already provide function calls to give context through calls like the ActivityRecognitionClient. Other devices, either collocated devices or cloud-based devices, can also provide information to infer context. Devices contain many sensors that can provide context about the user, such as GPS, camera, microphone, gyroscope, accelerometer, heart monitor, blood pressure monitor, glucose monitor, touch sensors, and so on. "Apps" (mobile phone applications) can also help infer or provide context. Once context is inferred, a set of policies can enforce specific assignment of network scheduling or quality-of-service (QoS) levels. The context of the user and device can both be used. Examples of context of the user and specific assignments include:
1. Assign all traffic corresponding to a health application the highest QoS level when the user's heart-rate exceeds a threshold.

2. When the user is in a meeting, delay all non-email traffic until after the meeting is over.

3. Restrict YouTube* traffic when a user is within a school zone.

4. Of all the background applications, give highest prior...