System and method for optimizing media playback quality for a wireless handheld computing device

A method for optimizing media playback quality for a wireless handheld computing device is disclosed. The system includes a client request manager that may be responsible for controlling or instructing a web browser on what file segments should be downloaded next to the wireless handheld mobile computing device to insure optimal video playback quality for the computing device. The request manager may be dynamic in that it may continually monitor elements of an application subsystem as well as the modem subsystem. The request manager may select one or more file segments for download that optimizes media playback on the wireless handheld computing device based on the data received from at least one of the application subsystem and modem subsystem.

DESCRIPTION OF THE RELATED ART

Today's computing environment is becoming more and more portable. People often surf the Internet with their wireless handheld computing devices with such ease similar to using mobile telephones for placing ordinary telephone calls. Typical conventional wireless handheld computing devices, include but are not limited to, devices like mobile phones, personal digital assistants (“PDAs”), “Smart” phones, pagers, navigation devices like portable GPS units, and a hand-held computer with a wireless connection or link. These wireless handheld computing devices usually fit within a person's hand or may be carried around with one hand by a person.

While these wireless handheld computing devices have made the computing environment more accessible while people are on the “go”, wireless handheld computing devices have created some unique problems with respect to performance of these devices within wireless networks. Some problems relating to performance include slow download of data when wireless network bandwidth is low, and slow communications due to reception errors. This performance is often a function of the hardware and software which can be contained within the tight, electronic packaging of these handheld sized units. The performance of these handheld sized units may also be a function of the wireless network in which the wireless handheld computing device establishes a communication link.

Communication links that provide videos are desired by many users of wireless handheld computing devices. Typically, videos may take some time to download onto the wireless handheld computing device because of their file size. Sometimes the videos may be interrupted during playback because of factors which relate to the wireless network. One factor that can negatively impact the performance of a wireless handheld computing device is when the handheld computing device establishes a communication link with a wireless communications network that may be experiencing a lower bandwidth.

Another factor relating to degraded performance of handheld computing devices in wireless communication networks is latency. Latency in packet-switched networks is measured either one-way (the time from the source sending a packet to the destination receiving it), or round-trip (the one-way latency from source to destination plus the one-way latency from the destination back to the source). Higher latency in wireless communication networks generally causes videos for wireless handheld computing device to take a longer time to load compared to those networks with low or minimal latencies. Generally, most wireless handheld computing devices do not compensate for the factors which negatively impact the performance of a wireless communications network.

What is needed is a system and method that can offset or compensate for factors which negatively impact the performance wireless handheld computing devices, such as during the playback of video, when the devices are coupled to a wireless communications network.

SUMMARY OF THE DISCLOSURE

According to a first exemplary aspect, a method for optimizing media playback quality for a wireless handheld computing device is disclosed. The method includes receiving a meta-object describing one or more file segments of media and reviewing options for the one or more file segments described in the meta-object. The method further includes evaluating data from an application subsystem and data from a modem subsystem. The method also includes selecting a file segment for download that optimizes media playback on the wireless handheld computing device based on the data received from at least one of the application subsystem and modem subsystem.

A computer system for optimizing media playback for a wireless handheld computing device is disclosed. The system includes a processor operable to receive a meta-object describing one or more file segments of media and review options for the one or more file segments described in the meta-object. The processor is operable for evaluating data from an application subsystem and data from a modem subsystem. The processor selects a file segment for download that optimizes media playback on the wireless handheld computing device based on the data received from at least one of the application subsystem and modem subsystem.

A computer system for managing one or more memory resources of a wireless handheld computing device includes means for receiving a meta-object describing one or more file segments of media and means for reviewing options for the one or more file segments described in the meta-object. The system also has means for evaluating data from an application subsystem and means for evaluating data from a modem subsystem. The system also includes means for selecting a file segment for download that optimizes media playback on the wireless handheld computing device based on the data received from at least one of the application subsystem and modem subsystem.

A computer program product comprising a computer usable medium having a computer readable program code embodied therein is disclosed. The computer readable program code is adapted to execute and implement a method for optimizing media playback for a wireless handheld computing device, wherein the executed method includes receiving a meta-object describing one or more file segments of media and reviewing options for the one or more file segments described in the meta-object. The computer readable program code is further adapted to execute steps for evaluating data from an application subsystem and evaluating data from a modem subsystem. The computer readable program code further executes a step for selecting a file segment for download that optimizes media playback on the wireless handheld computing device based on the data received from at least one of the application subsystem and modem subsystem.

DETAILED DESCRIPTION

In this description, the terms “communication device,” “wireless device,” “wireless telephone,” “wireless communication device,” and “wireless handset” are used interchangeably. With the advent of third generation (“3G”) wireless technology, greater bandwidth availability has enabled more electronic devices with a greater variety of wireless capabilities. Therefore, a wireless device could be a cellular telephone, a pager, a PDA, a smartphone, a navigation device, or a hand-held computer with a wireless connection or link.

FIG. 1Ais a diagram of a wireless handheld computing device200coupled to a wireless communications network206. Many of the system elements illustrated inFIG. 1Aare coupled via communications links103A-B to the communications network206. The links103illustrated inFIG. 1may comprise wireless links. Wireless links include, but are not limited to, radio-frequency (“RF”) links, infrared links, acoustic links, and other wireless mediums.

The communications network206may comprise a wide area network (“WAN”), a local area network (“LAN”), wireless LANs (“wLANs”), the Internet, a Public Switched Telephony Network (“PSTN”), a paging network, or a combination thereof. The communications network206may be established by broadcast RF transceiver towers208. However, one of ordinary skill in the art recognizes that other types of communication devices besides broadcast RF transceiver towers208are included within the scope of the invention for establishing the communications network206.

The server210may have meta-objects402and video file segments212that may be downloaded and stored in memory by the wireless handheld computing device200. The handheld computing device200is shown to have an antenna372so that a respective handheld device200may establish wireless communication links103with the communications network206.

The server210may communicate with the wireless handheld computing device200across the communications network206in order to share its meta-objects402and file segments212with the handheld computing device200. The meta-objects and file segments212are processed and managed by the application subsystem102and modem subsystem133of the handheld computing device200.

Each meta-object402may comprise a file, such as file having an extendible mark-up language (XML) format, which has detailed file information206about video files212that may be downloaded by the wireless handheld computing device200. While only video file segments212have been illustrated, one of ordinary skill in the art recognizes that any type of media file is within the scope of the invention. That is, a media file may include, but is not limited to, video files, audio files, large image files, and any combination thereof.

The detailed file information206of the meta-object402may describe various properties of video file segments212A-D which may be downloaded by the wireless handheld computing device200. Exemplary properties include, but are not limited to, the total length of a video that comprises a plurality of file segments212, the discrete length of each file segment212, different bit rates for similar segments212, and different video resolutions for similar segments212. Other properties for the video not mentioned here and describing various aspects/features of video are included within the scope of the invention as is understood to one of ordinary skill in the art. Further, the invention is not limited to video files and may be appropriate for other types of files such as image files, voice files, text files, and any other type of file comprising data which has a size that generally requires a file to be broken into different segments.

While only four file segments212A-D have been illustrated, a greater number or a fewer number of file segments212are within the scope of the invention as is understood to one of ordinary skill in the art. Further, fewer or greater duplicate file segments212having different bit rates but with similar resolutions, as well as fewer or greater duplicate file segments212having similar bit rates with similar resolutions, and fewer or greater duplicate file segments212having different bit rates and different resolutions are within the scope of the invention as understood to one of ordinary skill the art.

The first file segment to212A has a first bit rate at a first video resolution and is provided with a first universal resource locator (“URL”) that may be selected by the wireless handheld computing device200. The second file segment212B has a first bit rate similar to the first file segment212A but it has a second video resolution which is different from the first resolution of the first file segment212A. The second file segment to212B has a second URL which is different from the first URL of the first file segment212A.

The third file segment212C has a second bit rate which is different from the first bit rates of the first and second file segments212A-212B. The third file segment to212C has a first video resolution which is identical to the video resolution of the first and second file segments212A-212B. The third file segment212C has a third URL which is different from the first URL of the first file segment212A and second URL of the second file segment212B.

The fourth file segment212D has a second bit rate equal to the second bit rate of the third file segment212C but has a second video resolution which is the same as the second video resolution of the second file segment212B. The fourth file segment212C has a fourth URL which is different from the first URL of the first file segment212A, the second URL of the second file segment212B, and the third URL of the third file segment212C. One of ordinary skill in the art recognizes that fewer or a greater number of file segments212may be provided without departing from the scope of the invention. Further details about the meta-object402and the file segments212will be described below in connection withFIGS. 5A-5BandFIG. 8.

FIG. 1Bis a diagram of a first aspect of a software architecture for a system102that optimizes video playback for a wireless handheld computing device200. The application subsystem102may comprise a mobile web browser application105that is executed by a central processing unit324(seeFIG. 2) and which can run video supported by the hypertext transfer protocol (“HTTP”) streaming request manager109.

The mobile web browser application or module105may communicate with transfer communication protocol (“TCP”) modules127that reside over an Internet protocol (“IP”) layer129as understood to one of ordinary skill in the art and described below.

The IP layer129communicates with a network buffer layer131as understood by one of ordinary skill the art. The IP layer129communicates with the modem subsystem133, which is executed by a second central processing unit326(seeFIG. 2).

The mobile web browser module105includes a hypertext transfer protocol (“HTTP”) streaming request manager109, a HTTP stack111, and a domain name server module113. While illustrated as included within the web browser module105, in a further alternative exemplary embodiment (not illustrated), the HTTP streaming request manager109may reside as a separate module relative to web browser105.

HTTP streaming protocol is a mechanism for sending data from a server210to a web browser on a handheld computing device200in response to an event. HTTP streaming protocol may be achieved through several common mechanisms. In one such mechanism, the server210does not terminate the response to the computing device200, also referred to as the client, after data has been served. This differs from the typical HTTP cycle in which the response is closed immediately following data transmission. The server210leaves the response open such that if an event is received, it can immediately be sent to the client. Otherwise the data would have to be queued until the client's next request is made to the server210. Typical uses for HTTP streaming protocol include, but are not limited to, video playback, market data distribution (stock tickers), live chat/messaging systems, online betting and gaming, sport results, monitoring consoles and sensor network monitoring. The HTTP streaming protocol typically uses port80or port8080.

The mobile web browser module105may be coupled to a memory resource119. The memory resource119may include, but is not limited to, a cache, random access memory (“RAM”), flash memory, a Secure Digital (“SD”) memory card, and any combination thereof.

The request manager109may be responsible for controlling or instructing the web browser105on what file segments212should be downloaded next to the handheld mobile computing device200to insure optimal video playback quality for the computing device200. The request manager109may be dynamic in that it may continually monitor elements of the application subsystem102as well as the modem subsystem133. Further, the request manager109may also receive messages from elements within the application subsystem102and the modem subsystem133.

The DNS module113of the web browser105may be responsible for translating the text based domain names into the numeric Internet protocol (IP) address as understood by one of ordinary skill the art. The DNS module113may communicate the IP address back to the HTTP stack111which in turn relays it to the TCP connection module127.

When the HTTP stack111returns a meta-object402from the TCP connection module127, the HTTP stack module111relays this meta-object402to the streaming client request manager109. The http stack module111may also provide the client request manager109with certain status information. The status information may include, but is not limited to: high speed-schedule control channel (“HS-SCCH”) Valid status; high speed transport block size (“HS-TBS”); layer one block error rates (“L1 BLER”); radio link control protocol data unit (“RLC PDU”) size; radio link control down link service data unit (“RLC DL SDU”) Byte received (“Rx”); high speed downlink packet access (“HSDPA”) user equipment (“UE”) Category; media access control uplink buffer status report (“MAC UL BSR”); enhanced uplink transmission time interval (“EUL TTI”); enhanced transport format combination index (“ETFCI”) table index; ETCFI; the number of new transmissions (“Tx”); radio link control uplink service data unit (“RLC UL SDU”) Byte transmission (“Tx”); diversity transmission/diversity reception (“DTX/DRX”) mode; enhanced uplink user equipment (“EUL UE”) category; media access control transmission layer transport block size (“MAC TL TBS”); packet data convergence protocol downlink service data unit (“PDCP DL SDU”) Byte reception (“Rx”); media access control uplink transport block size (“MAC UL TBS”); packet data convergence protocol uplink service data unit (“PDCP UL SDU”) Byte transmission (“Tx”); and user equipment category (“UE Category”).

The request manager109is responsible for parsing and/or reviewing the meta-object402and deciding which video segments212are appropriate for the next download after assessing the current wireless network conditions and the operating environment of the handheld computing device200.

The Transport Control Protocol (“TCP”) connection module127operates in the Transport Layer of the Open Systems Interconnection (“OSI”) model of general networking as understood by one of ordinary skill in the art. The TCP connection module127is responsible for encapsulating application data blocks into data units (datagrams, segments) suitable for transfer to the network infrastructure for transmission to the destination host, or managing the reverse transaction by abstracting network datagrams and delivering their payload to the mobile web browser105.

The TCP connection modules127may provide information that includes, but is not limited to, re-transmission time out (“RTO”); advertised receiver window (“Rx Window”); transmission-receiver throughput (“Tx/Rx Throughput”); packet statistics; a total number of TCP connections; estimated round-trip time (“RTT”); number of bytes received; the number of in sequence packets; and the TCP transmitting window size.

The Internet Protocol (“IP”) module129communicates with the TCP connection module127and the network buffer layer131. The IP module129has the task of delivering distinguished protocol datagrams (packets) from the mobile web browser to the server210based on their addresses. The IP module129defines addressing methods and structures for datagram encapsulation. The IP module129may utilize Internet Protocol Version 4 (“IPv4”) as well as Internet Protocol Version 6 (“IPv6”), which is being deployed actively as of this writing. However, other versions of the Internet protocol, including future ones not yet developed, are included within the scope of the invention.

The network buffer layer131communicates with the IP module129and the modem subsystem133. The network buffer layer131may contain all hardware specific interface methods, such as Ethernet and other IEEE 802 encapsulation schemes. The network buffer layer131may probe the topology of a local network, such as the communications network206. It may discover routers and neighboring hosts, and it may be responsible for discovery of other nodes on the link. The network buffer layer131may determine the link layer addresses of other nodes, find available routers, and maintaining reachability information about the paths to other active neighbor nodes.

The streaming client request manager109may communicate with the http stack111as well as the TCP modules127. The streaming request manager109also communicates with one or more sensors125. The sensors125may include, but are not limited to, pedometer125A, an accelerometer125B, a proximity sensor125C, a compass125D, and an ambient light sensor125E. The pedometer125A may provide signals that indicate that the handheld computing device200is being used by a person who is walking.

The accelerometer125B may provide signals that indicate that the handheld computing device200is located in a motorized vehicle, such as an automobile. The proximity sensor125C may indicate if the handheld computing device200is positioned next to a person's face for conducting a telephone call. The compass125D may provide signals that indicate a specific direction in which the handheld computing device200is traveling. And the ambient light sensor125E may provide signals to indicate if the handheld computing device200is being used in a light or dark environment, which impacts how videos may need to be displayed on the computing device200.

The modem subsystem133may comprise a radio link control (“RLC”) layer135, a media access control (“MAC”) layer139, a physical (“PHY”) layer141, a radio-relay control (“RRC”) module137, and a global positioning system (“GPS”)143. These elements of the modem subsystem133may be responsible for communicating with communications hardware such as the RF transceiver368as illustrated inFIG. 2.

Each of the elements of the modem subsystem133may send messages or receive queries from the http streaming client request manager109. For example, the RRC module137may communicate information such as, but not limited to, high speed downlink packet access (“HSDPA”) category information, enhanced uplink layer (“EUL”) category information, and discontinuous reception/transmission (“DRX/DTX”) configuration (“Config”) information.

The RLC module135may communicate throughput as well as radio link control (“RCL”) protocol data unit (“PDU”) size. The MAC layer139may communicate uplink (“UL”) information, such as, but not limited to, buffer status report (“BSR”) information and enhanced dedicated channel (“EDCH”) transport format (“TF”) information. The physical layer141may communicate the downlink (“DL”) information, such as, but not limited to, high speed transport block size (“HS-TBS”), modulation, channel quality indication (“CQI”), block error rate (“BLER”) measurement, multi-input/multi-output (“MIMO”), receiver (“Rx”) automatic gain control (“AGC”), as well as equalizer integrated circuit (“EQ/IC”) receiver (“Rx”) diversity (“D”). The physical layer141may also communicate uplink (“UL”) information, such as, but not limited to, BLER, modulation, and transmitter (“Tx”) automatic gain control (“AGC”).

The RRC module137, RLC module135, MAC module139, and PHY module141, may form an evolved high-speed packet access system (“HSPA”) as is understood to one of ordinary skill the art. Meanwhile, the GPS module143may provide information, such as, but not limited to, location, and speed or velocity of the handheld mobile computing device200to the streaming request manager109.

By monitoring elements of the application subsystem102and the modem subsystem133, the streaming client request manager109may allow the wireless handheld computing device200to intelligently vary a video quality being displayed on the device200by monitoring wireless network conditions as well as conditions of the handheld computing device200itself. Video quality may be varied by the streaming client request manager109by using the monitored conditions to determine what is the appropriate bit rate for a video segment file212to be downloaded from the server210.

Some of the monitored conditions based upon the data provided by the application subsystem102and the modem subsystem133include, but are not limited to: media player buffer conditions, including the size of the current buffer and the rate at which the buffer's growing are being consumed by the computing device200; current and historical WWAN bandwidth; current and historical WWAN signal strength; number of IP socket data connections available; estimation of an overall video clip length and then estimating each uniform resource locator (“URL”) download time for each file segment212based on signal-noise-ratio history/histogram and location based service (“LBS”); rate of speed of the handheld computing device200which is calculated by either cell tower identification triangulation or precise latitude longitude through the use of location-based technologies such as the GPS module143; and the direction of travel of the handheld computing device200using an accelerometer and/or the LBS.

The streaming client request manager109may calculate a predetermined time period in which the client request manager109must maintain or use a lower bit rate until the signal-to-noise ratio stays high and/or the BLER stays low continuously. The streaming client request manager109may also turn “on” or turn “off” any type of receive diversity function(s) in the modem subsystem133in order to minimize power during ideal network situations, such as when the handheld computing device200is stationary, or when the handheld computing device200is operating under relatively low-speed conditions, such as when a user is walking with the computing device200.

Referring toFIG. 2, this figure is a diagram of an exemplary, non-limiting aspect of a wireless handheld computing device200comprising a wireless telephone which corresponds with the wireless handheld computing device ofFIG. 1. As shown, the wireless handheld computing device102includes an on-chip system322that includes a digital signal processor and/or a first central processing unit324AND an analog signal processor and/or second central processing unit326that are coupled together. Further, the first processor324and the memory resources119may serve as a means for executing one or more of the method steps described in this disclosure in connection withFIGS. 5-8. Meanwhile, the second digital signal processor/central processing unit326may also execute one or more instructions relating to the modem subsystem133, which are also described in connection withFIGS. 5-8.

While a wireless handheld computing device200is illustrated, one of ordinary skill in the art recognizes that the invention may be practiced with any type of wireless computing device irrespective of the size of the computing device. That is, other wireless computing devices beyond handheld units, such as notebook computers, laptop computers, and desktop computers, are included within the scope of the invention.

As illustrated inFIG. 2, a display controller328and a touchscreen controller330are coupled to the digital signal processor324. A touchscreen display332external to the on-chip system322is coupled to the display controller328and the touchscreen controller330.

FIG. 2further indicates that a video encoder334, e.g., a phase-alternating line (“PAL”) encoder, a sequential couleur avec memoire (“SECAM”) encoder, a national television system(s) committee (“NTSC”) encoder or any other video encoder, is coupled to the digital signal processor324. As noted previously, the first digital signal processor324and/or second digital signal processor326may be substituted with a Central Processor Unit (“CPU”) as understood to one of ordinary skill in the art. Either hardware unit may execute the subsystem of software elements/instructions ofFIGS. 5A-8.

A video amplifier336is coupled to the video encoder334and the touchscreen display332. A video port338is coupled to the video amplifier336. As depicted inFIG. 2, a universal serial bus (“USB”) controller340is coupled to the digital signal processor324. Also, a USB port342is coupled to the USB controller340. The memory resources119and a subscriber identity module (“SIM”) card346may also be coupled to the digital signal processor324. Further, as shown inFIG. 2, a digital camera348may be coupled to the digital signal processor324. In an exemplary aspect, the digital camera348is a charge-coupled device (“CCD”) camera or a complementary metal-oxide semiconductor (“CMOS”) camera.

As further illustrated inFIG. 2, a stereo audio CODEC350may be coupled to the analog signal processor326. Moreover, an audio amplifier352may be coupled to the stereo audio CODEC350. In an exemplary aspect, a first stereo speaker354and a second stereo speaker356are coupled to the audio amplifier352.FIG. 2shows that a microphone amplifier358may be also coupled to the stereo audio CODEC350. Additionally, a microphone360may be coupled to the microphone amplifier358. In a particular aspect, a frequency modulation (“FM”) radio tuner362may be coupled to the stereo audio CODEC350. Also, an FM antenna364is coupled to the FM radio tuner362. Further, stereo headphones366may be coupled to the stereo audio CODEC350.

FIG. 2further indicates that a radio frequency (“RF”) transceiver368may be coupled to the analog signal processor326. An RF switch370may be coupled to the RF transceiver368and an RF antenna372. The RF transceiver368may communicate with conventional communications networks as well as with global positioning system (“GPS”) satellites in order to obtain GPS signals for geographical coordinates. The RF transceiver may be controlled and monitored by the GPS module143ofFIG. 1B.

As shown inFIG. 2, a keypad374may be coupled to the analog signal processor326. Also, a mono headset with a microphone376may be coupled to the analog signal processor326. Further, a vibrator device378may be coupled to the analog signal processor326.FIG. 2also shows that a power supply380may be coupled to the on-chip system322. In a particular aspect, the power supply380is a direct current (“DC”) power supply that provides power to the various components of the wireless handheld computing device102that require power. Further, in a particular aspect, the power supply is a rechargeable DC battery or a DC power supply that is derived from an alternating current (“AC”) to DC transformer that is connected to an AC power source.

As depicted inFIG. 2, the touchscreen display332, the video port338, the USB port342, the camera348, the first stereo speaker354, the second stereo speaker356, the microphone360, the FM antenna364, the stereo headphones366, the RF switch370, the RF antenna372, the keypad374, the mono headset376, the vibrator378, and the power supply380are external to the on-chip system322.

FIG. 3is a diagram of a touch screen display332for a wireless handheld computing device200. As shown, the wireless handheld computing device200may include a menu or listing510of program icons505, represented as square boxes in this exemplary embodiment. The wireless handheld computing device200also includes a headset or speaker376that may be positioned next to a user's ear for listening to a mobile phone conversation.

FIG. 4is a diagram of a screen332presenting the content of video400downloaded by a wireless handheld computing device200. The video400may comprise moving images. In the exemplary embodiment illustrated inFIG. 4, two automobiles are illustrated as moving towards each other in directions corresponding with two arrows. One of ordinary skill in the art recognizes that invention is not limited to the exemplary automobile images illustrated inFIG. 4and that other types of moving images for different videos are within the scope of the invention.

Referring toFIG. 5A, this figure is a flowchart illustrating a method500A for optimizing video playback for a wireless handheld computing device200. Block505is the first step in the process500in which the meta-object402describing the available video file segments212on the server210is received by the wireless handheld computing device200. As noted previously, the meta-object402may comprise a file, such as file having an extendible mark-up language (XML) format, which has detailed file information206about video files212that may be downloaded by the wireless handheld computing device200.

This detailed file information206in meta-object402may describe various properties of video file segments212A-D which may be downloaded by the wireless handheld computing device200. Exemplary properties include, but are not limited to, the total length of a video that comprises a plurality of file segments212, the discrete length of each file segment212, different bit rates for similar segments212, and different video resolutions for similar segments212. Other properties for the video not mentioned here and describing various aspects/features of video are included within the scope of the invention as is understood to one of ordinary skill in the art. Further, the invention is not limited to video files and may be appropriate for other types of files such as image files, voice files, text files, and any other type of file comprising data which has a size that generally requires a file to be broken into different segments.

In the exemplary embodiment illustrated inFIG. 1A, the meta-object402describes a video having a length of X minutes which is broken into file segments212having a length of Y seconds. The meta-object402describes that three bit rates have been provided for each file segment212. The meta-object402also describes that two resolutions are available for each file segment212. One resolution is denoted as being “High” resolution while the other file segment212is denoted as being “Low” resolution.

Next, in block510, the http streaming client request manager109may review the options for the file segments212that are listed in the meta-object402. The client request manager109may store these options in one or more memory resources119.

In routine block515, the client request manager109may evaluate the data it receives from the sensors125as illustrated inFIG. 1B. As noted previously, the client request manager109may actively request or “ping” the sensors125for data or the sensors125may provide status updates to the client request manager109when conditions change. Further details of routine block515will be described in connection withFIG. 6described in further detail below.

Next, in block520, the client request manager109may store the data from the sensors125in one or more memory resources119. In block525, the client request manager109may evaluate data from the application subsystem102.

Specifically, in block525, the client request manager109may evaluate the data provided by the TCP connection modules127and the HTTP stack111. As noted previously, the TCP connection modules127may provide information that includes, but is not limited to, re-transmission time out (“RTO”); advertised receiver window (“Rx Window”) that allows for the client request manager109to estimate and achievable maximum throughput as understood by one of ordinary skill in the art; transmission-receiver throughput (“Tx/Rx Throughput”); packet statistics; a total number of TCP connections; estimated round-trip time (“RTT”) so that the RTT for different host names may be estimated as understood by one of ordinary skill in the art; number of bytes received so that the client request manager109can compute the average serving throughput as understood by one of ordinary skill in the art; the number of in sequence packets so that the client request manager109can estimate the TCP transmitting window size as understood by one of ordinary skill in the art; and the TCP transmitting window size so that the client request manager109the estimate the achievable maximum throughput as understood by one of ordinary skill in the art.

The HTTP stack module111may provide the client request manager109with status information that may include, but is not limited to: high speed-schedule control channel (“HS-SCCH”) Valid status which allows the client request manager109to estimate how often the handheld computing device200is scheduled by the network for transmission and it is a value that allows the client request manager109to estimate the maximum achievable throughput as understood by one of ordinary skill in the art; high speed transport block size (“HS-TBS”) and layer one block error rates (“L1 BLER”) which allow the client request manager109to estimate the average and maximum achievable throughput as understood by one of ordinary skill in the art; radio link control protocol data unit (“RLC PDU”) size which allows the client request manager109to estimate the achievable maximum throughput as understood by one of ordinary skill in the art; radio link control down link service data unit (“RLC DL SDU”) Byte received (“Rx”) which allows the client request manager109to compute the average throughput to the Internet protocol (“IP”) layer as understood by one of ordinary skill in the art.

The HTTP stack module111may further provide the client request manager109with other status information, such as, but not limited to: high speed downlink packet access (“HSDPA”) user equipment (“UE”) Category which allows the client request manager109to calculate the theoretical maximum downlink throughput as understood by one of ordinary skill in the art; media access control uplink buffer status report (“MAC UL BSR”) which indicates how much data is buffered to the protocol stack waiting for uplink transmission scheduling as understood by one of ordinary skill in the art; enhanced uplink transmission time interval (“EUL TTI”); enhanced transport format combination index (“ETFCI”) table index; ETCFI; the number of new transmissions (“Tx”); radio link control uplink service data unit (“RLC UL SDU”) Byte transmission (“Tx”) which allows the client request manager109to compute the average throughput seen by the IP layer as understood by one of ordinary skill in the art; diversity transmission/diversity reception (“DTX/DRX”) mode which allows the client request manager109to configure this mode so that HTTP requests may be bundled that may decrease latency as understood by one of ordinary skill in the art; enhanced uplink user equipment (“EUL UE”) category which allows the client request manager109to calculate a theoretical maximum uplink throughput as understood by one of ordinary skill in the art; media access control transmission layer transport block size (“MAC TL TBS”) which allows the client request manager109to calculate the average throughput as understood by one of ordinary skill in the art; packet data convergence protocol downlink service data unit (“PDCP DL SDU”) Byte reception (“Rx”) which allows the client request manager109to compute the average throughput to the IP layer as understood by one of ordinary skill in the art; media access control uplink transport block size (“MAC UL TBS”) which allows the client request manager109to compute the average throughput as understood by one of ordinary skill in the art; packet data convergence protocol uplink service data unit (“PDCP UL SDU”) Byte transmission (“Tx”) which allows the client request manager109to compute the average throughput as seen by the IP layer as understood by one of ordinary skill in the art; and user equipment (“UE Category”) which allows the client request manager109to compute the theoretical maximum throughput as understood by one of ordinary skill in the art.

With the EUL TTI, ETFCI table index, ETCFI, and the number of new Tx parameters provided by the HTTP stack111, the client request manager109may estimate the average and maximum achievable throughput as understood by one of ordinary skill the art. In block530, the client request manager109may store the data from the application subsystem102in one or more of the memory resources119. In routine block535, the client request manager109may evaluate data from the modem subsystem133. Details of routine block535will be described in further detail below in connection withFIG. 7.

In routine block545, the http streaming client request manager109may estimate future conditions of the wireless network206based on a comparison of historical data to the new data that has been retrieved from the application subsystem102and the modem subsystem133. For example, based on the data that the client request manager109receives from the sensors125, the client request manager109may determine if the handheld computing device200is moving and how fast it may be moving. This allows the streaming client request manager109to estimate what type of radio conditions may be expected in the near future for the handheld computing device200.

The client request manager109may make certain adjustments to the operation of the handheld computing device200when it has determined that the handheld computing device200is in a motor vehicle, such as an automobile, which will likely pass through many different wireless networks206while it is moving. This may allow the client request manager109to determine how long the handheld computing device200may be within the reception range of a particular wireless network206and specifically a cellular base station transceiver tower208.

As another example, in block545, the http streaming client request manager109may determine that the handheld computing device200is being carried by a human who is walking. If this condition is detected, then the client request manager109will determine that the handheld computing device200will be within a particular wireless network206, and specifically within range of a cellular base station transceiver tower208, for a certain period of time which is typically greater than the period of time compared to when the handheld computing device200would have been if the handheld computing device200was in a motorized vehicle, such as an automobile.

The calculation of time by the client request manager109in block545of how long the handheld computing device200will be within range of a particular wireless network206allows the client manager109to anticipate when a handoff will likely occur from one cellular base station transceiver tower208to another transceiver tower to208. Alternatively, or in addition to this time calculation, the streaming client request manager109may query hardware or software elements within the modem subsystem133that may track data indicating when a cell site handoff is about to occur.

It is not critical that the client request manager109calculate exactly when a handoff is about to occur but rather it is helpful for the client request manager109to determine when the handheld computing device109will be experiencing rapid changes with respect to the wireless networks206in which the handheld computing device200is able to establish to communications.

Next, in routine block550, the client request manager109may select a file segment type to download from the server210based on current network conditions and current conditions of the handheld computing device109and/or based on the estimate of network conditions calculated in routine block545. In this routine block550, the client request manager109may specify which file segment212that it wishes to download from the server210in order to optimize playback of the video400that is being displayed on the handheld computing device200. The streaming client request manager109in some situations may constantly request a low-quality video streaming signal, such as the fourth file segment to212D, which has a lower bit rate and lower resolution compared to the third file segment212C.

The streaming client request manager109may typically request low-quality video streaming signals if the manager109has determined that it is likely that the handheld device109will experience rapid changes with respect to the wireless networks206and possibly lose communications with the wireless networks206. If the client request manager109determines that the handheld computing device200will likely be stationary, then the client request manager109may ask for high-quality signals or a combination of low quality and high quality depending upon the conditions detected by the client request manager109. For example, if the client request manager109detects that the handheld computing device200will be stationary, then the client request manager109may request a high-quality signal that comprises the first file segment212A ofFIG. 1Ahaving the first and highest bit rate and highest video resolution. The client request manager109may build a buffer of data, such as for streaming video, so that the handheld computing device200may keep advanced segments212of a video stream that is not being viewed by a user in memory resources119.

As another example of steps that may be performed by the client request manager109in routine block550, the client request manager109may shut down the display screen332when the proximity sensor125C determines that the handheld computing device200is being positioned proximate to an ear of a user so that a telephone conversation may be established. In such a scenario, the display screen232of the handheld computing device may be activated or powered off since it is unlikely that a user is using the video aspects of the handheld computing device200when the handheld computing device200is positioned adjacent to a user's ear. Alternatively, the client request manager109may also request low-quality video in such a scenario since it is unlikely that the video is being monitored or viewed closely by the user.

A further example of the steps that may be performed by the client request manager109in routine block550include the client request manager109selecting a file segment212based on data that it has received from the ambient light sensor125E. If the ambient light sensor125E indicates that the handheld computing device200is being exposed to a significant amount of light that may deteriorate the ability to view a video, then the client request manager109may request low-quality video in this scenario. If the ambient light sensor125E indicates that the handheld computing device200is being exposed to an environment in which light is not present, then the client request manager109may request higher quality video in this scenario since the video quality will be easily perceived by a user.

Next, in optional block555which has been illustrated with broken lines, the client request manager109may set a predetermined period of time and/or a condition to prevent a switch to a different level of video quality. In optional block555, the client request manager109calculates an amount of time that it believes the current network conditions will remain the same, usually in situations in which the network conditions are poor for establishing communications between the handheld computing device200and a broadcast transceiver tower208. This calculation of time is based upon the estimate of network conditions that the client request manager109calculated in block545.

Optional block555is usually practiced or executed by the streaming client request manager109after the client request manager109has determined in block545that the signal-to-noise ratio (“SNR”) tracked by the PHY layer module141has reached a predetermined level. In optional block555, the streaming client request manager109may prevent a change to a higher video quality segment212unless the SNR stays at a predetermined level for a predetermined period of time while the block error rate (“BLER”) stays at a predetermined level continuously for a predetermined period of time.

In optional block560, the client request manager109may store the predetermined period of time calculated in optional block555and/or the condition calculated in optional block555in one or more memory resources119that are associated with the current conditions for historical tracking purposes. Next, in optional block565, the client request manager109may determine if enhanced features of the modem subsystem133should be disabled or activated.

In this optional block565, the client request manager109may determine if advanced receiver functions, such as the receiver diversity (“RxDiv”) function, based on the GPS data from the GPS module143and power level conditions monitored by the client request manager109. If the client request manager109determines that the handheld computing device200is experiencing a low power condition and is moving rapidly between wireless networks206based on GPS data, then the client request manager109may decide to disable one or more advanced receiver functions in order to conserve power and to maintain communications with the wireless network206. If the client request manager109determines that the handheld computing device200is experiencing a normal power condition meaning that the handheld computing device200is fully charged and if the handheld computing device200is stationary, then the client request manager109may decide to enable or activate one or more of the advanced receiver functions from their disabled state.

In optional block570, the client request manager109enables or disables the advanced receiver functions based on its decisions determined in optional block565. Other advanced receiver functions which may be disabled or enabled by the client request manager include, but are not limited to: equalizer enable (“EQ Enable”); and interference cancellation enable (“IC Enable”). The process then continues to decision block575ofFIG. 5B.

FIG. 5Bis a continuation flowchart of the flowchart ofFIG. 5Aillustrating the method500for optimizing video playback for a wireless handheld computing device200. Decision block575is the first block of this flowchart in which the client request manager109may determine if one or more applications have taken over a primary use and/or control of the handheld computing device200. In this decision block575, the client request manager109may determine if another application, such as a telephone call, has been supported or executed by another application program module on the handheld computing device200. Alternatively, the client request manager109may detect another application program module that has dominant use or utilizes a large section of the display screen332relative to a section which supports the video400being displayed.

If the client request manager109detects that an application has taken over a primary use and/or control of the handheld computing device200in decision block575, such as in a situation of a telephone call been received by the handheld computing device200, then the process proceeds to decision block580. If the client request manager109does not detect any application taking over primary use and/or control of the handheld computing device200and decision block575, then the process returns to block515ofFIG. 5A.

In decision block580, the client request manager109determines if the requested file segments212are at a lowest quality. If the client request manager109determines that the current file segments212in memory resources119have a high-quality relative to what was described in the meta-object402, then the process proceeds to block585in which the client request manager determines if lower quality file segments212are available and if they are available, the client request manager109selects the lower quality file segments212while the other application module is dominating the use and/or control of the handheld computing device200.

Once the other application module as relinquished dominate use and/or control the mobile computing device200, then the client request manager109may permit the request for higher quality video file segments212depending upon the network conditions and conditions of the wireless handheld computing device200. If in decision block580the client request manager109determines that the current video file segments212are already at a lowest quality, then the process proceeds back to block515ofFIG. 5A.

FIG. 6is a flowchart illustrating a sub-method or a routine515ofFIG. 5Afor evaluating data from sensors125in a wireless handheld computing device200. Block605is the first block of routine515in which the client request manager109evaluates data from the pedometer sensor125A. As discussed previously, data from the pedometer sensor125A may indicate that the handheld computing device200is being carried by a person who is walking so that the client request manager109may calculate an estimate of time that the handheld computing device200may be present within a certain wireless network206.

Next, in block610, the client request manager109may evaluate data that it receives from the accelerometer125B. The data from the accelerometer125B may indicate to the client request manager109whether the handheld computing device200is within a moving vehicle or not. In block620, the client request manager109may evaluate data from the proximity sensor125C. The data from the proximity sensor125C may indicate to the client request manager109that the handheld computing device200is being positioned next to a user's face in order to conduct a telephone call (typically).

Next, in block625, the client request manager109may evaluate data that it receives from the compass125D. The data from the compass125D may indicate if the handheld computing device200is located within a motor vehicle or not.

In block630, the client request manager109may evaluate data from an ambient light sensor125E. The data from the ambient light sensor125E may indicate to the client request manager109lighting conditions for the handheld computing device200. The ambient light sensor125E may detect low-level and high-level lighting conditions such as direct sunlight and operation of the handheld computing device200at night in the absence of sunlight. After block630, the process returns to block520ofFIG. 5A.

FIG. 7is a flow chart illustrating a sub-method or a routine535ofFIG. 5Afor evaluating data from a modem subsystem133in a wireless handheld computing device200. Block705is the first block of routine535in which the client request manager109may evaluate data received from the GPS module143. The GPS module143may provide information, such as, but not limited to, location, and speed or velocity of the handheld mobile computing device200to the streaming request manager109. Specifically, the GPS module143may provide the latitude, longitude, altitude with regard to ellipsoid, altitude with regard to mean sea level, horizontal speed, vertical speed, and heading information.

In block710, the client request manager109may evaluate data from the radio relay control (“RRC”) module137. The RRC module137may communicate information such as, but not limited to, high speed downlink packet access (“HSDPA”) category information, enhanced uplink layer (“EUL”) category information, and discontinuous reception/transmission (“DRX/DTX”) configuration (“Config”) information.

In block720, the client request manager109may evaluate data from the radio link control (“RLC”) module135. The RLC module135may communicate throughput as well as radio link control (“RLC”) protocol data unit (“PDU”) size.

In block720, the client request manager may evaluate data from the media access control (“MAC”) module139. The MAC layer module139may communicate uplink (“UL”) information, such as, but not limited to, buffer status report (“BSR”) information and enhanced dedicated channel (“EDCH”) transport format (“TF”) information.

In block730, the client request manager109may evaluate data from the physical layer (“PHY”) module147. The physical layer141may communicate the downlink (“DL”) information, such as, but not limited to, high speed transport block size (“HS-TBS”), modulation, channel quality indication (“CQI”), block error rate (“BLER”) measurement, multi-input/multi-output (“MIMO”), receiver (“Rx”) automatic gain control (“AGC”), as well as equalizer integrated circuit (“EQ/IC”) receiver (“Rx”) diversity (“D”). The physical layer141may also communicate uplink (“UL”) information, such as, but not limited to, BLER, modulation, and transmitter (“Tx”) automatic gain control (“AGC”).

Other parameters monitored by the PHY module141include, but are not limited to, the following: the number of RAKE finger path which may allow the client request manager109to estimate the wireless channel profile, single or multiple path profile as understood by one of ordinary skill in the art; the common pilot channel (“CPICH”) signal-to-noise ratio (“SNR”) so that the client request manager109may predict fading channel conditions as understood by one of ordinary skill in the art; the channel quality indicator (“CQI”) so that the client request manager109may predict fading channel conditions as understood by one of ordinary skill in the art; the reference signal received quality (“RSRQ”) per antenna372so that the client request manager109may calculate the signal quality over the measurement bandwidth as well as to predict fading channel conditions as understood by one of ordinary skill in the art; and the rank indicator (“RI”) so that the client request manager109may calculate the number of transmission layers in spatial multiplexing multiple in multiple out (“SU-MIMO”) conditions as understood by one of ordinary skill in the art.

Next, in block735, the data from the modem subsystem elements may be stored by the client request manager109in one or more of the memory resources119. The process then returns to routine block540ofFIG. 5A.

FIG. 8is a state diagram illustrating communications between the streaming manager109of a wireless handheld computing device200and a server210which has various video files212for download by the wireless handheld computing device200. The first communication133A of the state diagram is sent from the modem subsystem133to the streaming client manager109. The first communication133A may comprise a status for the average transmission protocol (“TP”). The current status of the TP may indicate a rate of 1.8 megabits per second (“Mbps”) that may be supported by the handheld computing device109. The first communication133A may also provide a status for the block error rate (“BLER”). The BLER for this communication133A may comprise a magnitude of two percent.

The first communication133A may also provide a status for the round-trip time (“RTT”) between the handheld computing device200and the server210. The RTT may comprise a magnitude of 100 milliseconds (ms). The first communication133A may also provide status from the GPS module143. The status from the GPS module143may indicate that the handheld computing device109is moving at a speed at approximately one mile an hour.

The second communication111A may be sent from the http client111to request the meta-object402from the streaming server210. The third communication133B may indicate that the speed for the transmission protocol as decreased to 1.5 Mbps relative to the first communication133A. The third communication133B may also indicate that the BLER has increased to three percent, while the RTT remains the same at 100 ms. The GPS module143may indicate that the speed of the handheld computing device109has increased to two mph relative to the first communication133A.

The fourth communication to210A is sent from the server210to the http client111of the handheld computing device109. The fourth communication210A may comprise the meta-object file402. The meta-object file402may indicate that the file segments212comprise lengths of approximately five seconds, while the options for bit rates for each of the segments include those at 1.5 Mbps, 1 Mbps, 768 Mbps, 384 Mbps, and 64 kbps. The meta-object file402may also indicate that the file segments212may have two different video resolutions: one at 800×400 and another at 400×200.

In the fifth communication111B, the meta-object file402is passed to the client request manager109for review. In the six communication109A, the client request manager109has already determined a speed for the first file segment212and its resolution: 1 Mbps and a resolution of 800×400. Prior to the six communication109A and after the fifth communication111B the comprising the meta-object file402, the client request manager109may have executed blocks510-550ofFIG. 5A.

In the seventh communication111B, the http client111issues a request to the server210for the file segment212having a bit rate of 1 Mbps and a video resolution of 800×400. In the eighth communication133C, the modem subsystem133indicates that the average transmission protocol speed has dropped to 500 kbps while the BLER has increased to ten percent. Meanwhile, the RTT remains the same at 100 ms while the GPS module143indicates that the handheld computing device109has increased to a speed of 10 mph relative to the third communication133B.

Based on the conditions provided in the eighth communication133C, the client request manager109determines just prior to the ninth communication109B that the next file segment212that should be downloaded should have a bit rate of 1 Mbps and a lower video resolution of 400×200 compared to the six communication109A that was previously issued by the client request manager109. The client request manager109transmits this ninth communication to the http client111.

However, because the streaming server210has not responded to the http client's last request, the http client111is unable to transmit the contents of the ninth communication109B over to the streaming server210. Only after the http client111receives the next communication from the streaming server to 10 may the http client111transmit its next request to the streaming server210. This is the nature of the HTTP streaming protocol as is understood by one of ordinary skill in the art.

In the tenth communication210B, the streaming server210provides its response to the last request from the http client111which was the seventh communication111B. The tenth communication210B may comprise the contents of the last request111B which was a file segment having a bit rate of one Mbps and a video resolution of 800×400.

Next, in the eleventh communication133D from the modem subsystem133to the client request manager109, the conditions may indicate that the average transmission protocol has stayed the same at a bit rate of 500 kps while the BLER has also remained the same at ten percent. The eleventh communication133D may indicate that the RTT has increased from 100 ms to 120 ms and the speed of the client computing device109has remained the same at ten MPH.

In the twelfth communication109C, the client request manager109may have determined that the bit rate and a video resolution may remain the same relative to the last client request manager communication109B that provided a bit rate of 384 kbps and a video resolution of 400×200. This twelfth communication109C is transmitted from the client request manager109to the http client111.

In the thirteenth communication111C, the http client111may communicate with the streaming server210with a request for the next file segment212to have a bit rate of 384 kbps and a video resolution of 400×200. In the fourteenth communication210C, the streaming server210may provide the requested file segment212having the bit rate of 384 kbps and a video resolution of 400×200.

Next, in the fifteenth communication133E, the modem subsystem133may indicate that the average TP speed and the BLER have remained the same at 500 kbps and ten percent respectively. Modem subsystem133may also indicate that the RTT has increased from 120 ms to 150 ms and the speed has remained the same at 10 MPH.

Based on these conditions provided by the modem subsystem133in the fifteenth communication133D, the client request manager109may decide to request segments212with bit rates and video resolutions equal to the last, twelfth request109C in which the requested bit rate is at 384 kpbs and a video resolution of 400×200. The client request manager109transmits this data in the sixteenth communication109D.

In the seventeenth communication133F, the modem subsystem133may indicate that the bit rate for the transmission protocol has increased from 500 kbps to 3 Mbps and that the BLER has decreased from ten percent to 0.5 percent. The seventeenth communication133F may also indicate that the RTT has decreased from 150 ms to 100 ms and that speed of the handheld computing device109has decreased from 10 MPH to 1 MPH.

In view of the conditions provided in the seventeenth communication133F and after the client request manager has executed at least blocks510-550ofFIG. 5A, the client request manager109may request file segments212having a bit rate of 1.5 Mbps and a relatively high-resolution of 800×400. Subsequently, the http client111transmits the request of file segments212having a bit rate of 1.5 Mbps and a high-resolution of 800×400 to the streaming server210in the nineteenth communication111D.

While specific values have been discussed with reference to the state diagram inFIG. 8, one of ordinary skill in the art recognizes that other magnitudes for the TP, BLER, RTT, and GPS are possible and within the scope of the invention. Further, one of ordinary skill in the art recognizes that other factors monitored by both the modem subsystem133and the application subsystem102are within the scope of the invention.

One of ordinary skill in the art recognizes that a home personal computer using the client request manager109to access content over the Internet is within the scope of the invention. The client request manager109would be implemented and run on an operating system (“OS”), such as Windows™, and would typically monitor bandwidth (bit rate of the chosen streaming video) and the multimedia buffer status (bit consumption rate of the video stream) and make decisions on which higher or lower resolution content to that in the next file segment212.

A mobile handset using the client request manager109may be implemented either on an OS comprising Windows™ and connected to WWAN (such as Gobi), or the client request manager109may be provided within the mobile phone on an OS such as ANDROID™, SYMBIAN™, or mobile WINDOWS™ brand mobile operating systems. The client request manager109may also monitor bandwidth and multimedia buffer status similar to what was discussed above. However, in this mobile phone environment, the client request manager109may also take into account via the GPS module143and the accelerometer125B that a user is moving and accelerating. The client request manager109may notice that statistically when the user has accelerated similarly in the past, that the bandwidth has decreased. Therefore, if the client request manager109assumes that the bandwidth will can decrease in the future, then the request manager109may make an intelligent decision to request a lower video resolution than what may be support under current detected network conditions.

One of ordinary skill in the art recognizes that a more advanced client request manager109may take into account the signal-to-noise (“SNR”). For example, if the handheld computing device109stopped moving and a higher bit rate may be available, even though the client request manager109but typically request a higher bit rate, the client request manager109may notice that the SNR is low, and thus does not request a higher bit rate stream for the next set of file segments212.

Certain steps in the processes or process flows described in this specification naturally precede others for the invention to function as described. However, the invention is not limited to the order of the steps described if such order or sequence does not alter the functionality of the invention. That is, it is recognized that some steps may performed before, after, or parallel (substantially simultaneously with) other steps without departing from the scope and spirit of the invention. In some instances, certain steps may be omitted or not performed without departing from the invention. Further, words such as “thereafter”, “then”, “next”, etc. are not intended to limit the order of the steps. These words are simply used to guide the reader through the description of the exemplary method.

Additionally, one of ordinary skill in programming is able to write computer code or identify appropriate hardware and/or circuits to implement the disclosed invention without difficulty based on the flow charts and associated description in this specification, for example.

Therefore, disclosure of a particular set of program code instructions or detailed hardware devices is not considered necessary for an adequate understanding of how to make and use the invention. The inventive functionality of the claimed computer implemented processes is explained in more detail in the above description and in conjunction with the Figures which may illustrate various process flows.

Also, any connection is properly termed a computer-readable medium. For example, if 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, then 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, as used herein, 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. Combinations of the above should also be included within the scope of computer-readable media.