Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
  • G06F1/26—Power supply means, e.g. regulation thereof
  • G06F1/32—Means for saving power
  • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
  • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
  • G06F1/3209—Monitoring remote activity, e.g. over telephone lines or network connections
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
  • G06F1/26—Power supply means, e.g. regulation thereof
  • G06F1/32—Means for saving power
  • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
  • G06F1/3234—Power saving characterised by the action undertaken
  • G06F1/329—Power saving characterised by the action undertaken by task scheduling
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/12—Protocol engines
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
  • H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
  • H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
  • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
  • H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
  • H04W52/02—Power saving arrangements
  • H04W52/0209—Power saving arrangements in terminal devices
  • H04W52/0261—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level
  • H04W52/0264—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by selectively disabling software applications
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/2866—Architectures; Arrangements
  • H04L67/289—Intermediate processing functionally located close to the data consumer application, e.g. in same machine, in same home or in same sub-network
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
  • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
  • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
  • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
  • Y02D30/00—Reducing energy consumption in communication networks
  • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

• a wireless device interfaces with one or more communication networks using any of a number of radios.
• the wireless device may include a variety of radios providing communications using Cellular, WiFi, Bluetooth, or other types of radio access technologies.
• applications executing on the wireless device interface with a radio to establish a communications channel and the channel is used by the applications to communicate with the appropriate network.
• Applications may continue to interface with radios on the wireless device to establish communication channels even when the device is in a background mode.
• the battery power of the device may be unnecessarily consumed from the repeated establishment of network communications while the device is not active.
• the increasing usage of wireless devices, such as smartphones, data networks may become overloaded by network signaling associated with the setup of communication channels.
• a request for network access from the application executing on the device may be intercepted.
• a wrapper may be placed between the application and the operating system of the mobile device to intercept the request.
• the request may be held from reaching a Transmission Control Protocol/Internet Protocol (TCP/IP) stack of the operating system.
• TCP/IP Transmission Control Protocol/Internet Protocol
• the request may be released to the operating system when a triggering event occurs. The capturing, holding, and releasing of requests may occur when the mobile device is in a background mode.
• the request may be aggregated with other intercepted requests to perform a communication for the mobile device.
• the interception of the request from the application and the interception of the other requests may occur at different times.
• instructions for a wrapper may be executed.
• the executed wrapper may perform the interception of the request from the first application.
• the wrapper may be located between an application layer and a socket layer of the operating system of the mobile device.
• the first application may be identified as a class of application from which requests are held.
• An application may be identified as a critical application or a non-critical application. Only requests from non-critical applications may be held.
• the triggering event may include at least one of an expiry of a timer, a status change of a display, a status change of a microphone, a status change of a speaker, a status change of a global positioning system (GPS) sensor of the mobile device, an indication that a universal serial bus port is in use, an indication that an audio equipment is connected to the mobile device, an indication that a video equipment is connected to the mobile device, an indication that a connection to a Wi-Fi type of network is available, or an indication that a radio connection to a cellular type of network is open.
• a delay tolerance of the first application may be determined.
• a callback function may be provided to the first application based on the determined delay tolerance. The callback function may instruct the first application to connect to the communication resources.
• an expiration time of a first timer associated with the first application may be determined, a tolerance and expiration time of a second timer associated with a second application may also be determined.
• the second timer may be forced to expire based on the expiration time of the first timer, the tolerance, and the expiration time of the second timer.
• the request from the first application and an intercepted request from the second application may be released to perform a communication for the mobile device.
• a deadline may be received from the application.
• the request may be held until before the deadline.
• the request to connect to the communications resources may be released prior to the deadline.
• the request may include a system call to establish a communications channel for the mobile device.
• the request may be released to a socket layer of the operating system upon detecting the triggering event.
• an indication for an interval pertaining to how often the releasing of the request occurs may be received.
• the interval may be less than a timeout value in a stateful Internet Protocol (IP) middlebox in a network.
• IP Internet Protocol
• a mobile device configured for wireless communication is also described.
• the device may include a processor and memory in electronic communication with the processor.
• the memory may include an operating system.
• the processor may include a connectivity engine.
• the engine may be configured to execute instructions to intercept a request from a first application on the mobile device.
• the request may be a request to perform a communication for the mobile device.
• the engine may be further configured to hold the request from reaching TCP/IP stack of an operating system executing on the mobile device, and release the request to the operating system upon detecting a triggering event.
• An apparatus configured to manage requests for network access from applications on a mobile device is also described.
• the apparatus includes means for intercepting a request from an application on the mobile device.
• the request may be a request to perform a communication for the mobile device.
• the apparatus may further include means for holding the request from reaching a TCP/IP stack of an operating system executing on the mobile device, and means for releasing the request to the operating system upon detecting a triggering event.
• a computer program product configured to manage requests for network access from applications on a mobile device.
• the product may include a non-transitory computer-readable medium.
• the medium may include code to intercept a request from an application on the mobile device.
• the request may be a request to perform a communication for the mobile device.
• the medium may further include code to hold the request from reaching a TCP/IP stack of an operating system executing on the mobile device, and code to release the request to the operating system upon detecting a triggering event.
• FIG. 1 shows a block diagram of a network environment
• FIG. 2 shows a block diagram illustrating an architecture for a mobile device
• FIG. 3 shows a block diagram of a mobile device providing delaying of requests for network access
• FIG. 4 shows a sample block diagram of architecture on a mobile device for delaying requests for network access
• FIG. 5 shows an example timing diagram for aggregating requests for network access
• FIG. 6 shows one example of an architecture implemented on a mobile device
• FIG. 7 is a flow chart illustrating one example of a method for delaying requests for network access
• FIG. 8 is a flow chart illustrating one example of a method for delaying requests for network access based on a classification of an application
• FIG. 9 is a flow chart illustrating one example of a method for aggregating requests for network access received from a number of mobile device
• FIG. 10 is a flow chart illustrating one example of a method to synchronize data connection requests
• FIG. 11 illustrates a timing diagram wherein three applications periodically initiate connection requests
• FIG. 12 illustrates the timing diagram of FIG. 11, wherein certain of the connection requests have been synchronized
• FIG. 13 illustrates a timing diagram wherein three applications periodically initiate connection requests
• FIG. 14 illustrates the timing diagram of FIG. 13, wherein certain of the connection requests have been synchronized.
• the requests may be system calls that establish communication channels for the mobile device.
• the terms "requests” and “system calls” may be used interchangeably.
• the requests may be captured and held from reaching a TCP/IP stack of an operating system executing on the mobile device.
• An intercepted request may be aggregated with other intercepted requests.
• the aggregated requests may be bundled together and released to the operating system at approximately the same time upon detecting a triggering event on the mobile device.
• the capture, holding, and aggregation of requests from applications may occur when the mobile device is in a background mode.
• the applications may trigger frequent transitions by the mobile device from background mode to connected mode, or they may otherwise interfere with the device entering background mode or other alternate connection modes such as discontinuous reception (DRX).
• DRX discontinuous reception
• a mobile device may be in background mode when certain inputs of the device are not operational or are in a sleep state.
• the device may be in background mode when a user is not using the device.
• audio inputs such as a microphone
• visual inputs such as a display of the device
• the device may be determined to be in a background mode. Additional inputs may be used to determine whether or not the mobile device is in a background mode, as will be described below.
• a first application may initiate a system call to establish a communication channel and then after the data have been transmitted/received, the channel may be discontinued.
• a second application may then initiate a system call to also establish a communication channel to
• the present systems and methods may hold and aggregate requests for network access to reduce network signaling and conserve batter power. As previously mentioned, this may occur when the device is not active. In addition, the holding and aggregation of system calls may occur when the battery power of the device falls below a certain threshold amount.
• a triggering event e.g., the device enters an active mode
• the aggregated requests may be released together to reduce the amount of network signaling as well as reduce the consumption of batter power associated with each separate request.
• the holding and aggregation of requests may be performed when a mobile device is in an inactive mode so as to not interfere with the use of the device by a user.
• a request for network access from an application on a user device may be intercepted.
• a wrapper may be placed between an application layer of the mobile device and an operating system layer of the device to intercept requests.
• the wrapper may be a software entity which intercepts requests.
• the wrapper may be transparent to the applications in the application layer as well as the operating system in the operating system layer.
• the request may be held or delayed from reaching the operating system.
• the request may be aggregated with other intercepted requests received from additional applications in the application layer.
• the aggregated requests may be released to the operating system.
• the wrapper may transparently intercept and aggregate requests and then relay the aggregated requests when additional processing is completed.
• an interval may be determined that indicates how often held requests are to be released to the operating system of the device.
• the interval may be determined so as to maintain a state of a middlebox, which is described below.
• IP Internet Protocol
• a stateful middlebox may perform firewall and network address translation (NAT) functions.
• a function of a firewall may be to determine which inbound/outbound ports of the device are open or available.
• NAT functions may not be constantly deployed on cellular networks, but may be continuously deployed on LAN/WLAN.
• Applications executing on the mobile device may not differentiate between a cellular network and a Wi-Fi-network, as a result, the applications may use a timer to originate "keep-alive" requests to keep NAT functions operable on a cellular network.
• the state of the middleboxes may be maintained until the timer expires. If a long-lived connection (TCP or UDP) is needed, the middleboxes may keep their state throughout the connection.
• Applications executing on mobile devices e.g., smartphones
• these applications may select keep-alive/reconnect intervals that work anywhere, regardless if the interval causes a peak is signaling for cellular networks.
• the following describes systems and methods to conserve power and reduce signaling by reducing the number of system calls for network access by holding these requests for network access while the device is in a background mode and releasing the requests when a certain triggering event occurs or at intervals determined by a particular network.
• FIG. 1 a block diagram illustrates an example of a wireless network environment 100.
• the network environment 100 may include a mobile device 102 and a communication network 1 15.
• the device 102 may communicate with the network 1 15 using a number of radio channels 1 10-a.
• a control channel 1 10-a-l may be established between the device 105 and the network 1 15.
• other types of channels 1 10-a-2 through 1 10-a-/? may also be established. These other types of channels may include data channels, voice channels, etc.
• the device 102 may execute applications which may interface with the network 1 15 using any of a number of radios.
• an executing application may issue a request to establish communications with the network 1 15.
• the requests may be a networking system call, such as a socket layer call.
• the request may be intended for the socket layer of an operating system on the device 105.
• Conventional devices typically allow these types of requests to proceed directly to the operating system to be processed.
• network signaling processes to establish the control channel 1 10-a-l through a data connection setup procedure.
• data connection setup procedures are executed on the mobile device 105, battery power is consumed and the level of signaling across the network may increase. This may reduce the efficiency of the mobile device 105 and the network 1 15.
• the device 105 may include an architecture to delay the release of a request to the operating system.
• This architecture may intercept a request for network access from an application. Upon intercepting the request, the architecture may hold or delay the request from reaching a TCP/IP stack of the operating system.
• the TCP/IP stack may include communication protocols that may be built into the operating system, providing the operating system with a standard for transmitting data over a network
• the intercepted request may be aggregated with other intercepted requests for network access received from additional applications.
• the aggregated requests may be bundled together and released as a single request for network access. In another example, the aggregated requests may be released upon the occurrence of a particular event (e.g., the mobile device becomes active).
• FIG. 2 shows one example of an architecture 200 of a mobile device 105-a, which may be an example of the mobile device 105 of FIG. 1.
• the architecture 200 of the device 105-a may include a connectivity engine 225.
• the connectivity engine 225 may manage when an application executing in an application layer 220 on the device 105-a may access a network, such as the network 115 of FIG. 1.
• the application layer 220 may include applications which may execute to provide various functions and communicate with outside networks, such as the network 115, using one or more of radios 250-a of a radio unit 245.
• the connectivity engine 225 may execute a wrapper 230.
• the wrapper 230 may intercept a system call for network access originating from an application in the application layer 220.
• the wrapper 230 may hold the request from reaching an operating system 235 executing on the device 105-a.
• the wrapper 230 may also aggregate the intercepted system call with other system calls intercepted from additional applications.
• the wrapper 230 may hold the aggregated system calls from reaching a socket layer 240 of the operating system 235.
• the process to establish a communication channel using one or more of the radios 250-a may be initiated.
• the socket layer 240 may process the request and notify a particular radio to begin the connection setup procedure to establish a connection between the application that initiated the request and the network 115. For example, the socket layer 240 may issue calls (or requests) to establish a binding between a particular application and a radio, for example radio 1 250-a-l . Radio 1 250-a- 1 may begin transmitting signals to the network 115 to begin the connection setup procedure by establishing a control channel, which may be an example of the control channel 110-a-l of FIG. 1.
• socket layer functions may be initiated a single time to establish a connection between the applications that sent the requests and a particular radio 250-a, rather than initiating the setup procedures each time an application provides a system call for network access.
• the selected radios may then begin network signaling to establish a data connection with the network 115 and the applications that originated the requests.
• the device architecture 200 provides aggregation of system calls access a network by applications executing on the device 105-a.
• the aggregation may serve to reduce battery consumption and network signaling by releasing a number of system calls as a bundle to the socket layer 235.
• FIG. 3 shows a block diagram 300 of a mobile device 105-b implementing the holding and aggregation of requests for network access.
• the device 105-b may be an example of the device 105 of FIGS. 1 or 2.
• the device 105-b may include a processor 360, memory 355, an application layer 220, a wrapper 230 a connectivity engine 225, an operating system 235, and a radio unit 245 all coupled to communicate using a communication bus 314.
• the memory 355 may store the application layer 220, the wrapper 230 and the operating system 235.
• the processor 360 may include the connectivity engine 225.
• the connectivity engine 225 may be implemented as a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein.
• the connectivity engine 225 may include means for intercepting a request from an application on a mobile device, means for holding the request from reaching an operating system on the mobile device, and means for releasing the request to the operating system upon detecting a triggering event. Further, the connectivity engine 225 may include means for aggregating the request with other intercepted requests to perform a communication for the mobile device 105.
• the connectivity engine 225 may also include means for executing the wrapper 230 of FIGS. 2, 3, or 4.
• the executed wrapper may intercept a request from an application.
• the engine 225 may include means for identifying the application as a class of application from which requests are held.
• the connectivity engine 225 may include means for identifying the application as a critical application or a non-critical application, and means for holding only requests from non-critical applications. It should be noted that the device 105-b is just one implementation and that other implementations are possible.
• processor 360 includes at least one of a central processing unit (CPU), processor, gate array, hardware logic, memory elements, and/or hardware executing software.
• the processor 360 operates to control the operation of the device 105-b so that system calls for network access initiated by applications executing at the application layer 220 may be held from reaching the operating system 235 and aggregated with other system calls.
• the processor 360 may execute computer-readable instructions related to performing any of a number of functions. For example, the processor 360 may operate to analyze information received or communicated from the device 105-b to effectuate the interception and aggregation of requests for network access.
• the processor 360 may operate to generate information that may be utilized by the memory 355, radio unit 245, application layer 220, the wrapper 230 operating system 235, and/or connectivity engine 225 to effectuate aggregation of system calls for network access from a number of applications.
• the radio unit 245 may include hardware and/or a processor executing software that may provide a number of radios/interfaces that may be used to interface the device 105-b with a number of external entities, such as external communication networks using a number of channels 110-a.
• radio unit 245 may provide radios/interfaces to communicate using Cellular, WiFi, Bluetooth, or any other technologies to communicate with communication networks using the channels 110-a.
• the application layer 220 may include hardware and/or a processor executing software that may store and/or execute one or more applications on the device 105-b.
• the application layer 220 may allow applications to initiate networking function calls to request networking services, such as requesting connection to a radio/interface for the purpose of communicating with an external network or system.
• the operating system 235 may include a socket layer.
• the socket layer may include hardware and/or a processor executing software that may perform socket layer functions.
• the socket layer functions may include such functions as Connect(), Bind(), and Setsockopt().
• a Connect() function operates to establish a connection between an application and a particular radio/interface.
• the particular radio/interface may be selected from the number of candidate radios provided by the radio unit 245.
• the socket layer may perform a variety of socket layer functions or commands.
• the connectivity engine 225 may include hardware and/or a processor executing software that may execute the wrapper 230 to cause the wrapper to intercept a request for network access from an application executing on the mobile device 105-b.
• the wrapper 230 may also hold the intercepted request from reaching the operating system 235.
• the wrapper 230 may aggregate the intercepted request with other intercepted requests. The aggregated requests may be released to the socket layer of the operating system when a triggering event occurs (e.g., the mobile device 105-b enters an active mode).
• the connectivity engine 225 may cause the wrapper 230 to capture, hold, and aggregate requests for network access in various ways. For example, when the device 105-b is in a background mode, the connectivity engine 225 (via the wrapper 230) may intercept a number of requests from a number of applications executing on the device 105 -a. The intercepted requests may be aggregated together and held until a certain triggering event occurs. For example, requests may be released when the mobile device 105-b enters an active state. In one configuration, the aggregated requests currently being held may be released together. For example, the aggregated requests may be bundled and released together to the socket layer as a single system call. The socket layer may initiate procedures to establish communication channels for data connection with the network 1 15.
• the memory 355 may include RAM, ROM, EEPROM or any other type of memory device that operates to allow information to be stored and retrieved at the device 105-b.
• the memory 355 may store computer-readable instructions executed by the processor 360.
• Memory 355 may also store any of a number of other types of data including data generated by any of the processor 360, radio unit 245, application layer 220, wrapper 230, operating system 235, and/or connectivity engine 225.
• Memory 355 may include a number of different
• the device 105-b may include a computer program product having one or more program instructions ("instructions") or sets of "codes" stored or embodied on a non-transitory computer-readable medium.
• the codes When the codes are executed by at least one processor, for instance, processor 360 and/or the connectivity engine 225, their execution may cause the processor 360 and/or the connectivity engine 225 to control the device 105-b to provide the functions of the aggregation architecture described herein.
• the non-transitory computer-readable medium may be a floppy disk, CDROM, memory card, FLASH memory device, RAM, ROM, or any other type of memory device or computer-readable medium that interfaces to the device 105-b.
• the sets of codes may be downloaded into the device 105-b from an external device or communication network resource. The sets of codes, when executed, operate to provide aspects of the system call aggregation architecture described herein.
• FIG. 4 shows a sample block diagram 400 of an architecture on a mobile device 105-c useful for intercepting and aggregating requests for network access as described above.
• the mobile device 105-c may be an example of the mobile device 105 of FIGS. 1, 2, or 3.
• An application layer 220 may interact with an application connection engine (APP CnE) 475 and a socket layer 240.
• the application connection engine 475 may communicate with a modem connection engine (Modem CnE) 485.
• the modem connection engine may manage communication resources such as a radio unit 245 and the number of radios 250-a therein.
• a wrapper 230 may be executed in the application processor 490 between the application layer 220 and the socket layer 240 of an operating system. The wrapper 230 may capture data passed between the application layer 220 and the socket layer 240.
• the wrapper 230 may be placed between the application 220 and the socket layer 240 to intercept system calls sent from the application layer 220 and intended for the socket layer 240.
• the wrapper 230 may intercept system calls from the application layer 220 during a period of inactivity by the device 105-c and the wrapper may hold the intercepted call until a triggering event has occurred before releasing the system call to the socket layer 240.
• the system call may be a request to establish a communications channel using a radio 250 within the radio unit 245.
• the wrapper 230 may aggregate system calls intercepted from the application layer 220 during a period of inactivity by the device 105-c. The wrapper 230 may hold the intercepted aggregated calls until a particular event has occurred before releasing the aggregated system calls to the socket layer 240 and ultimately the radio unit 245 for operation/transmission. [0060] In one configuration, the wrapper 230 may be invisible to the applications at the application layer 220 so that the applications are unaware that their requests are being held from reaching the socket layer 240. The wrapper 230 may be a separate software component or may be incorporated into another component such as the connectivity engine 225 or the application connection engine 475.
• FIG. 5 shows timing diagrams 500 for a number of applications, such as a first application and a second application.
• the applications may be located in the application layer 220 of the mobile device 105.
• the timing diagrams 500 may be the result of the implementation of the connectivity engine 225 of FIGS. 2 or 3.
• a first request 505-a-l may be sent from the first application at time to.
• the first request 505-a-l may be a Connect() system call.
• the first request 505-a-l may be held from reaching the operating system 235 executing on the mobile device.
• the first request may be held from reaching a TCP/IP stack of the operating system.
• the time the request is held may be represented as H 0 .
• the first request 505-a-l may be released to the operating system 235 at time t 2 .
• a second request 505-a-2 may be sent from the second application at time ti.
• the time ti may be after the time to.
• the second request 505-a-2 may also be a Connect () system call.
• the second request 505-a-2 may be held from reaching the operating system 235 for a period of time represented as Hi.
• the second request may also be held from reaching the TCP/IP stack of the operating system.
• the second request 505-a-2 may be released at time t 2 .
• the first request 505-a-l and the second request 505-a-2 may be released together or at the same time (i.e. time t 2 ).
• the time period Hi may be less than the time period Ho. In other words, the second request 505-a-2 may be held for less time than the first request 505-a- 1.
• the first request may be aggregated with the second request 505-a-2 when the second request 505-a-2 is intercepted at time t .
• the aggregation of the requests allows both requests to be released at substantially the same time (i.e., time t 2 .).
• the timing diagram 500 illustrates that requests sent at different times (to and ti) may be held for different periods of time (Ho and Hi) and then released at the same time (t 2 ).
• FIG. 6 shows an example of an aggregation architecture that may be implemented on a mobile device 105-d.
• the mobile device 105-d may be an example of the device 105 of FIGS. 1, 2, 3, and 4.
• the device 105-d may include an application layer 220-a, a wrapper 230-b, and an operating system 235.
• the operating system 235 may include a socket layer 240.
• the connectivity engine 225 of FIGS. 2 or 3 may execute instructions to run the wrapper 230-b software.
• the device 105-d may be in a background mode.
• the mobile device 105- d may be considered to be in a background mode when, for example, a screen or display of the device 105-d is off, when a microphone, speaker, or other audio output of the device 105-d is off, when a global positioning system (GPS) mechanism in the device 105-d determines the device 105-d is stationary, when the battery level of the device falls below a certain threshold level, etc.
• GPS global positioning system
• a number of applications 605-a executing at the application layer 220-a may send a system call 505-a for network access, such as a Connect () system call.
• the system calls 505-a may be sent from each application at different times.
• the wrapper 230-b may capture and hold these requests from reaching the operating system 235.
• the calls may be held from reaching the socket layer 240 of the operating system 235.
• an aggregation module 610 may aggregate the intercepted system calls 505-a.
• the aggregated requests may be released together (or at substantially the same time) from the wrapper 230-a-l to the socket layer 240 of the operating system 235.
• the socket layer 240 may proceed to establish a connection with the network 115.
• the procedure may include transmitting signaling messages between the mobile device 105- d and the network 115 to establish a control channel 110-a-l .
• the interception, holding, and aggregation, of requests for network access may reduce the power consumption of the mobile device 105-d because multiple system calls are not executed at the socket layer 240 at different times. Instead, the multiple requests are bundled together and released to the socket layer 240 at approximately the same time. Further, the aggregation of requests may reduce the frequency of connection setup procedures with the network 115, thus reducing the network traffic.
• the holding and aggregation of requests from applications 605 -a may be done selectively, (i.e., implemented such that a user may not be disrupted). A variety of factors may be employed to determine when to hold and aggregate requests from applications 605-a to establish communication channels. For example, the
• determination to intercept a request may be made based on certain characteristics of the mobile device 105-d such as the screen is off, or the audio output is off, etc. Holding requests may only be implemented for applications known to be able to handle such delays, when a radio is not loaded, when the mobile device 105-d is not otherwise in use (no phone calls, audio streaming, etc.).
• the interception and holding of systems calls from an application may be implemented based on whether a user subscribes to a service provided by the application. If the user subscribes to the service, the requests from the application may not be held from reaching the operating system. Instead, the requests from this subscription-based application may be allowed to pass immediately to the socket layer. In one example, applications executing on the mobile device 105-d may be classified.
• the first application 605-a- 1 may be classified as a non- critical application and the second application 605 -a-2 may be classified as a critical application.
• a non-critical application may be an application with a certain delay tolerance. In other words, system calls from a non-critical application to establish a communication channel may be delayed.
• a critical application may be an application with little or no delay tolerance. Examples of critical applications may include, but are not limited to, child tracking applications, emergency-based
• the holding an aggregation of requests may occur for requests originating from non-critical
• Requests sent from critical applications may not be held (or aggregated), but may instead proceed directly to the socket layer of the operating system.
• the holding and aggregation may also be implemented utilizing a combination of the factors above or other factors.
• a variety of factors may be employed to determine when to release aggregated requests and permit application connectivity. For example, if there is a trigger to establish a data connection setup procedure (such as receiving a system call from a critical application, such as an emergency application that cannot be delayed), held requests may be released to the socket layer 240 so that communications channels may be established in conjunction with the emergency application and reduce the number of transitions between background and connected states.
• a more desirable radio is activated or selected as a default (e.g., a wide local area network (WLAN) radio
• WLAN wide local area network
• Requests may also be released if a radio channel is very good (e.g., high signal strength, SNR, or other desirable performance metrics).
• Requests may also be released periodically as predetermined or as selectively determined by the mobile device 105-d. Another heuristic to release the requests may be when the user approaches the device (before he/she turns the screen on) in order to operate incognito. In this example, an accelerometer may detect the user grabbing the phone, or a user proximity sensor may indicate the user is approaching. In another aspect, while running on batteries, requests may be released as soon as the screen is unlocked, (e.g. , after a PIN is entered correctly). In this aspect, no release of requests may occur when a random button is pressed (device 105-d is in a purse or pocket).
• a triggering event that causes a held request to be released may be the expiration of a timer.
• the event may also be a status change of a display.
• the display may change from an "off state to an "on" state.
• a status change of a microphone (off to on) may also be a trigger event.
• a status change of a GPS sensor may be a triggering event.
• the sensor may change states when it detects movement of the mobile device. Additional triggering events to release a request may include an indication that a universal serial bus port is in use or an indication that an audio equipment is connection to the device.
• an indication that a video equipment is connected to the mobile device may also serve as a triggering event to release a held request to the operating system of the mobile device.
• an indication that a connection to a certain network is available may trigger the release of a request.
• an indication that a connection to a Wi-Fi type of network may cause the request to be released.
• an indication that a radio connection to a cellular type of network is already open may also trigger the release of the request to the operating system of the device.
• requests may be released according to some combination of the above or other factors.
• an application may be associated with a timer.
• the time period before the expiration of the timer may indicate the tolerance level of the associated application.
• a timer which receives no tolerance may be referred to as a "hard-timer".
• a hard-timer may be a timer which is intended to expire at a relatively fixed point in time.
• a timer which does receive a tolerance value may result in a "soft-timer”.
• a soft-timer may expire at an intended expiration time, but may also permit expiration within a specified tolerance range.
• certain applications such as an email update service may not require that connection requests occur at definite, fixed times.
• the timer for such an application may accordingly be given a wide tolerance and a soft-timer may be generated and associated with such applications.
• a stock program used by a stock trader may require consistent updates at fixed times to ensure the accuracy of the stock quotes.
• Such an application may receive little or no tolerance and would accordingly be associated with a hard timer.
• a timer such as one of soft-timer or hard-timer, may be expiring.
• the connectivity engine 225 of FIGS. 2 or 3 may determine whether the expiration time falls within any soft-timer's tolerance of various applications. For all those soft-timers whose tolerance falls within the expiration time, the connectivity engine may execute instructions to force those timers to prematurely expire. Intercepted network access requests from the applications whose timers have expired may be released to the operating system of the mobile device. In some configurations, a network connection may remain open until each of the applications whose timers have expired completes their necessary communication activities. As communication requests are made when the timers expire, more efficient resource management will result as a consequence of the applications' shared usage of the communications system.
• an interval or refresh rate may be determined that indicates how often requests should be released. Intervals may be determined in order to maintain the state of middleboxes that perform firewall and NAT functions. The state of the middleboxes may be maintained by applications issuing keep-alive messages or a succession of shorter connection requests.
• the network may provide information about a minimum refresh rate to maintain the state in middleboxes on the mobile device.
• a refresh rate may be provided for UDP vs. TCP connections.
• the network may adapt the refresh rate in the middleboxes based on the radio load incurred due to the amount of keep-alive/reconnect messages.
• the state may be maintained for a longer period of time in the middleboxes and the refresh rate for the mobile device may be slowed down.
• the interval (or refresh rate) may be less than a timeout value in the stateful middleboxes.
• the mobile device may open a gate to an uplink (i.e., release the requests) according to the refresh rate (or interval) indicated by the network.
• the gate may be opened when the device is not in the background mode and closed when the mobile device is in the background mode.
• FIG. 7 is a flow chart illustrating one example of a method 700 for holding requests for network access.
• the method 700 is described below with reference to the mobile device 105 shown in FIGS. 1,2, 3, or 4.
• the processor 360 may execute one or more sets of codes to control the functional elements of the device 105 to perform the functions described below.
• the method 700 described below may be implemented when the device 105 is in a background mode.
• a request from an application on the mobile device 105 may be intercepted.
• the request may be a request to perform a communication for the mobile device, such as establish a communication channel for the mobile device 105.
• the request may be sent from an application executing at the application layer 220 of the mobile device 105.
• the request may be a request to initiate a data connection setup procedure to enable the application to interface with an external network, such as the network 115.
• the request may be a system call to the socket layer 240 of the operating system 235 on the mobile device 105.
• the request may be held from reaching the operating system 235 executing on the mobile device 105.
• the request may be held from reaching the socket layer 240 of the operating system 235.
• the wrapper 230 may intercept and hold the request.
• the request may be released to the operating system upon detecting a triggering event.
• the device 105 may enter an active mode as described above.
• the method 700 may provide for interception and holding of requests for network access submitted by applications executing at the application layer
• the method 700 is just one implementation and that the operations of the method 700 may be rearranged or otherwise modified such that other implementations are possible.
• FIG. 8 is a flow chart illustrating one example of a method 800 for
• the method 800 is described below with reference to the device 105 shown in FIGS. 1, 2, 3, or 4.
• the processor 360 may execute one or more sets of codes to control the functional elements of the device 105 to perform the functions described below.
• a request for network access is intercepted.
• the request may be sent from an application executing at the application layer 220 of the mobile device 105.
• the request may be a request to establish a communication channel with an external network, such as the network 115.
• the request may be a system call to the socket layer 240 of the operating system 235 on the device 105.
• the socket layer 240 may initiate procedures to establish the communication channel and provide a callback function to the application when the channel is established.
• a determination may be made as to whether the device 105 is in a background mode. For example, a determination may be made as to whether the device 105 is powered down, in a sleep mode, etc. The device 105 may also be determined to be in a background mode if, for example, the display of the device 105 is inactive, audio outputs are inactive, etc. If it is determined that the device 105 -a is inactive a second determination may be made at block 815 to determine whether the application that initiated the system call is a non-critical application.
• a critical application may be an emergency application with a priority for network access, an subscription-based application, an application with a low tolerance for delay, etc.
• the request may be released to the socket layer 240 of the operating system 235. In other words, the request may be released to allow the socket layer to initiate the procedures to establish a communication channel with the network 115. If it is determined that the device is in a background mode and the application is classified as a non-critical application, at block 820, the request may be held from reaching the operating system, and thus delaying the initiation of the procedures to set up a communication channel.
• the request may be aggregated with other intercepted requests.
• the other requests may be initiated by additional applications executing on the mobile device 105.
• a determination may be made as to whether a triggering event is detected, as described above. If it is determined that no triggering event is detected, the method 800 may return to continue to aggregate intercepted requests for network access. If, however, it is determined that a triggering event is detected, at block 835, the aggregated requests may be released to the socket layer 240 of the operating system 240. In other words, system calls from a number of applications may be held and bundled together and then released as a single system call to the socket layer 240.
• the method 800 may provide for intercepting, holding, and aggregating requests for network access from non-critical applications executing on the mobile device 105. By holding and aggregating requests, a number of system calls may be bundled together and released as a single system call. This may result in battery power savings for the mobile device 105 as well as a reduction in network signaling because the quantity of system calls to initiate procedures to set up communication channels may be reduced. It should be noted that the method 800 is just one implementation and that the operations of the method 800 may be rearranged or otherwise modified such that other implementations are possible.
• FIG. 9 is a flow chart illustrating one configuration of a method 900 for intercepting requests for network access from a number of applications executing on a mobile device.
• the method 900 is described below with reference to the device 105 shown in FIGS. 1, 2, 3, or 4.
• the processor 360 may execute one or more sets of codes to control the functional elements of the device 105 to perform the functions described below.
• a first request for network access is intercepted from a first application at a first time.
• a second request may be intercepted from a second application at a second time.
• the second time may be different than the first time.
• a third request may be intercepted from a third application at a third time.
• the third time may be different than the first time and the second time.
• the intercepted requests may be system calls to establish communication channels for network access.
• the applications may be executing on the mobile device 105.
• the first, second, and third requests may be aggregated or bundled together.
• a determination may be made at block 945 as to whether a triggering event has occurred. For example, a determination may be made as to whether the device has entered an active mode, a display on the device has been activated, the device has changed location, a user is near the device, and the like. If a triggering event is not detected, the method 900 may return to continue monitoring for the detection of a triggering event. If a triggering event is detected, a block 950, the aggregated requests may be released to the socket layer of the operating system. Upon receiving the requests, the socket layer may initiate procedures to establish a communication channel with an external network, such as the network 115.
• the method 900 may provide for intercepting, holding, and aggregating requests for network access from multiple applications executing on the mobile device 105. As a result, a number of system calls may be bundled together and released as a single system call. This may result in reduced battery consumption for the mobile device 105 as well as a reduction in network signaling because the quantity of system calls may be reduced. It should be noted that the method 900 is just one implementation and that the operations of the method 900 may be rearranged or otherwise modified such that other implementations are possible.
• FIG. 10 depicts one possible process 1000 implemented in certain
• embodiments for improving synchronization among application connection requests may implement the process 1000 on a mobile device.
• the method 1000 is described below with reference to the device 105 shown in FIGS. 1, 2, 3, or 4.
• the processor 360 or connectivity engine 225 of FIG. 2 or 3 may execute one or more sets of codes to control the functional elements of the device 105 to perform the functions described below.
• the method begins at a block 1005, by identifying that a first timer, such as one of soft-timer or hard-timer, may be expiring. This may be accomplished by a central system which polls the timers of various applications. Alternatively, each application may individually monitor its own timer and provide notification upon the timer's expiration.
• a first timer such as one of soft-timer or hard-timer
• data may be synchronized for applications associated with expired timers. For example, channel access may be provided to the applications whose timers have expired by forming a connection.
• connection may then remain open until each of the applications whose timers have expired completes their necessary communication activities. As communication requests are made when the timers expire, more efficient resource management will result as a consequence of the applications' shared usage of the communications system.
• the method 1000 may be performed indefinitely by again waiting for timers to expire at a block 1005 or the method may end.
• the timer or timers which have initially expired at block 1005 at their intended time may be referred to as "master timers", or interchangeably “trigger events”, in certain embodiments. That is, these timers dictate when other timers (“soft-timers”) may expire based upon their respective tolerances.
• master timers or interchangeably “trigger events”
• soft-timers may expire based upon their respective tolerances.
• a soft or hard-timer may serve as a master timer.
• only soft-timers may be affected by a master timer (as only soft-timers possess a tolerance).
• FIG. 11 illustrates one possible series of connection requests for each of three applications (Appl, App2, and App3). These applications may be run on a mobile device, such as the mobile device 105 of FIGS 1, 2, 3, or 4. Particularly, FIG. 11 represents techniques for forming connections based on communication requests from various applications. In this example, connection requests are not coordinated. Therefore, each application requests a connection at uncoordinated intervals from the other applications. This lack of coordination results in an inefficient use of the mobile device's resources as the applications ignore opportunities to share connections. Timer expirations are represented by vertical arrows at each point in time and the consequent request periods are indicated by rectangles.
• connection period is represented by a window in the request period rectangle with a width of 30 seconds (one will recognize this as a rather arbitrary duration and much smaller or longer durations may occur for each connection).
• This width is merely for purposes of illustration, and arbitrary widths may be present in an actual device.
• the numerical ranges of FIG. 11, as well as the following figures, have been selected merely for explanatory purposes. The figures should not necessarily be construed as representing the actual implementation of any system or embodiment.
• Appl may initiate a communication request every 5 minutes (connections at times 1, 6, 11, 16, etc.).
• App2 may initiate connection requests every 5 minutes, but offset from Appl by one minute. That is, App2's requests share the same period, but not the same phase, as Appl 's requests.
• App3 may perform connections every 10 minutes and is likewise offset from Appl by 4 minutes.
• the asynchronous connection requests of Appl, App2, and App3 result in an inefficient use of battery power and communication bandwidth as the connections are constantly brought up and down.
• fourteen separate connections (requiring reactivation of the mobile device's communication elements) with the communication system occur between time 6 and time 32.
• Certain of the present embodiments contemplate providing a system which may coordinate connection requests such that more efficient connection patterns arise. For example, if the mobile device 105 already has a connection with a network for one application, the mobile device 105 may use the same connection for another application without tearing down the connection and forming another. Thus, coordinating the timing between application connection requests so that applications share connections may reduce the number of connections that need to be formed. Certain of these embodiments may include a programming module which application developers may use when implementing applications for the platform operating on mobile device 105. In certain of these embodiments, the mobile device 105 may transmit information for scheduling to the network. In many embodiments, the applications running on the mobile device 105 may include "timers", i.e.
• the timers may be executed by the connectivity engine 225 of FIGS. 2 or 3.
• the timers may be implemented as part of the connectivity engine 225. These timers indicate a time or time interval within which the application may require a connection. Applications requiring periodic updates from a network (or which periodically transmit information to the network) may rely on these timers to determine when they should request a connection. Applications may also require data non-periodically and request data within a certain time defined by a timer. Some applications may be flexible in how often they require a connection. Certain of the present embodiments contemplate different types or configurations of timers to accommodate the flexibility, or lack thereof, associated with each application. Though the following description refers to an application as having a "timer" for ease of discussion, one skilled in the art will recognize that an application comprises many components which may themselves be individually associated with one or more timers.
• FIG. 12 represents a timing diagram for the applications from FIG. 11, but wherein the applications now employ either soft or hard-timers in conjunction with a process such as the method of FIG. 10.
• the applications may run on a mobile device, such as the mobile device 105 of FIGS. 1, 2, 3, or 4.
• the connectivity engine 225 of FIGS 2 or 3 may implement process 1000 to coordinate scheduling.
• each of applications (Appl, App2, and App3) include a soft-timer with a 2 minute tolerance. Timer expirations as they would have occurred in FIG 11, in the absence of a process such as process 1000, are indicated by dashed arrows. Solid arrows represent the timer expirations that do occur under the management of a process such as process 1000.
• the process 1000 may be performed at each time interval (i.e., at minutes 1, 2, 3, etc.)
• timers share equal periods, or if their periods are harmonics (i.e., multiples) of one another, they may, barring interference from the expiration of other "master" timers, remain in phase with one another perpetually (of course, the synchronization may also be disrupted if the periodicity of any of the applications' timers change).
• this example illustrates that 6 rather than 14 connection requests occur between minutes 6 and 33 as compared to the timing diagram FIG. 11 when the process is not applied.
• FIG. 13 depicts another situation wherein applications (Appl, App2, and App3) do not possess the same periods (8 minutes, 5 minutes, and 10 minutes respectively).
• the connection requests in FIG. 13 reflect the conventional, uncoordinated, technique employed by most applications. This lack of coordination results in an inefficient use of the mobile device's resources, resulting in the reactivation of the mobile device's communication resources 12 times between minutes 7 and 34.
• FIG. 13 differs from FIG 11 in that App 1 of FIG 13 is time sensitive.
• a developer or system designer wishing to employ the benefits of certain of the present embodiments, would likely generate a timer having little or no tolerance for Appl of FIG 13. Accordingly, a hard-timer may be used for Appl .
• App2 and App3 of FIG 13, in contrast are not as time sensitive and accordingly may be accommodated by soft-timers.
• App 2 and App3 are each given soft-timers with a tolerance of 2 minutes.
• FIG. 14 depicts the effects of applying a process such as process 1000, but this time to the applications of FIG. 13.
• App2 is synchronized with Appl at time 25 and App3 is synchronized with App2 at time 30.
• the applications may run on mobile device 105 of FIGS. 1, 2, 3, or 4. Further, the mobile device 105 may implement process 1000 to coordinate scheduling.
• This example illustrates how the previous synchronization of one clock (App2 at time 25 based on Appl) may affect the subsequent synchronization of another clock (App3 at time 30 based on App2). As the periods of applications clocks are not equal, or harmonics, the clocks may not be exactly synchronized in perpetuity. Still, this example illustrates that 8 rather than 12 connection requests occur between minutes 6 and 33 as compared to the timing diagram of FIG. 13 when a process, such as the process 1000, is not applied.
• Master clocks may be prioritized based upon the application with which they are associated. That is, an application which consumes a great deal of bandwidth or battery power may be less suitable for sharing resources than an application which consumes less bandwidth or battery power.
• the mobile device 105 may be adjusted so that process 1000 considers the behavior and/or corresponding priority of the "master" timers which have expired before prematurely expiring soft-timers having a tolerance in the appropriate range.
• the process may further consider the bandwidth requirements for each of applications whose timers expired at block 1005 (i.e. the master timers) in comparison with the bandwidth requirements of the applications whose tolerance permits the premature expiration of their timers.
• mobile device 105 may take appropriate action. For example, a connection request may be made at the applications with master timers allowed to perform their operations. The soft-timers may then be made to expire at an appropriate time (possible after their intended expiration time if permitted by their tolerance) so that these applications take advantage of the existing connection once the master timer applications no longer consume excessive bandwidth. Alternatively, the soft-timers' expiration may be delayed until a new connection request has been made that will employ less bandwidth or until the end of their tolerance.
• timer expiration is shown to occur at the leading edge of communication windows.
• Certain embodiments instead contemplate performing an analysis at the "trailing edge" of a data connection, i.e. when communication with a node is about to go dormant.
• mobile device 105 may execute a process similar to process 1000 before closing a connection to see if any applications are intending to open a connection and could instead make use of the existing connection, rather than initiate a new request once the present connection is closed.
• a mobile device may employ a software layer (for illustrative purposes, called a wrapper) which provides an application program interface (API) to capture system calls from applications and hold them from reaching the operating system.
• the captures calls may be aggregated so that frequent waking of the mobile device may be reduced and other communication resources conserved during periods where the user is not actively engaged with the mobile device.
• API application program interface
• DSP Digital Signal Processor
• ASIC Application Specific Integrated Circuit
• FPGA Field Programmable Gate Array
• a general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine.
• a processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a number of
• microprocessors one or more microprocessors in conjunction with a DSP core, or any other such configuration.
• RAM Random Access Memory
• ROM Read Only Memory
• EPROM Electrically Programmable ROM
• EEPROM Electrically erasable ROM
• registers hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.
• An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium.
• the storage medium may be integral to the processor.
• the processor and the storage medium may reside in an ASIC.
• the ASIC may reside in a user terminal.
• the processor and the storage medium may reside as discrete components in a user terminal.
• the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a non-transitory computer-readable medium.
• Computer- readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.
• a storage media may be any available media that can be accessed by a computer.
• such computer-readable media can comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer.
• any connection is properly termed a computer-readable medium.
• the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave
• the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium.
• Disk and disc includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Theoretical Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Mobile Radio Communication Systems (AREA)
• Telephone Function (AREA)
• Telephonic Communication Services (AREA)

Priority Applications (5)

Applications Claiming Priority (4)

Publications (1)

Family

ID=45048218

Family Applications (1)

Country Status (6)

Cited By (17)

Families Citing this family (2)

Citations (5)

Family Cites Families (8)

• 2011
  • 2011-11-04 EP EP11788656.4A patent/EP2687050A1/de not_active Withdrawn
  • 2011-11-04 BR BR112013023791A patent/BR112013023791A8/pt not_active IP Right Cessation
  • 2011-11-04 CN CN201180070644.2A patent/CN103535084B/zh not_active Expired - Fee Related
  • 2011-11-04 WO PCT/US2011/059439 patent/WO2012128792A1/en active Application Filing
  • 2011-11-04 KR KR1020137027548A patent/KR101557843B1/ko not_active IP Right Cessation
  • 2011-11-04 JP JP2014501056A patent/JP5784816B2/ja not_active Expired - Fee Related

Patent Citations (5)

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events