Patent Grant
10972536
Each of the following applications are hereby incorporated by reference: application Ser. No. 15/659,603, filed on Jul. 25, 2017; application Ser. No. 14/167,742, filed Jan. 29, 2014; application Ser. No. 11/696,679, filed on Apr. 4, 2007; application Ser. No. 11/306,557, filed Jan. 2, 2006; application Ser. No. 10/862,115, filed Jun. 4, 2004. The Applicant hereby rescinds any disclaimer of claim scope in the parent applications or the prosecution history thereof and advises the USPTO that the claims in this application may be broader than any claim in the parent applications.
The subject matter of the present disclosure relates to a system and method for synchronizing presentation of media at multiple recipients or devices on a network.
With the increasing capacity and capability of personal computers, as well as improved multimedia interfaces for these computers, it has become popular to use personal computers as a repository for multimedia content, such as songs, movies, etc. Particularly with music, the increased popularity of storing multimedia information on a personal computer has resulted in a variety of products and services to serve this industry. For example, a variety of stand-alone players of encoded multimedia information have been developed, including, for example, the iPod, produced by Apple Computer of Cupertino, Calif. Additionally, services have been developed around these devices, which allow consumers to purchase music and other multimedia information in digital form suitable for storage and playback using personal computers, including, for example, the iTunes music service, also run by Apple Computer.
These products and services have resulted in an environment where many consumers use their personal computer as a primary vehicle for obtaining, storing, and accessing multimedia information. One drawback to such a system is that although the quality of multimedia playback systems for computers. e.g., displays, speakers, etc. have improved dramatically in the last several years, these systems still lag behind typical entertainment devices, e.g., stereos, televisions, projection systems, etc. in terms of performance, fidelity, and usability for the typical consumer.
Thus, it would be beneficial to provide a mechanism whereby a consumer could easily obtain, store, and access multimedia content using a personal computer, while also being able to listen, view, or otherwise access this content using conventional entertainment devices, such as stereo equipment, televisions, home theatre systems, etc. Because of the increasing use of personal computers and related peripherals in the home, it would also be advantageous to integrate such a mechanism with a home networking to provide an integrated electronic environment for the consumer.
In addition to these needs, there is also increasing interest in the field of home networking, which involves allowing disparate devices in the home or workplace to recognize each other and exchange data, perhaps under the control of some central hub. To date a number of solutions in this area have involved closed systems that required the purchase of disparate components from the same vendor. For example, audio speaker systems that allow computer-controlled switching of music from one location to another may be purchased as a system from a single vendor, but they may be expensive and/or may limit the consumer's ability to mix and match components of a home network from different vendors according to her own preferences. Thus, it would be beneficial to provide a mechanism by which various home networking components from differing vendors can nonetheless interact in a home network environment.
The subject matter of the present disclosure is directed to overcoming, or at least reducing the effects of, one or more of the problems set forth above.
A system and method for delivering network media at multiple devices is disclosed. For example, the network media delivery system includes client devices and a host device. Each client device has a network interface for network communication, an engine for processing media data, and a media interface for delivering processed media. The host device, which can be a computer, establishes network communication links with the client devices, which can be networked media stations. The media data can be audio, video, or multimedia. In one embodiment, the network communication links are wireless links established between a wireless network interface on the host device and wireless network interfaces on the client devices.
The host device sends media data to the client devices via the network. The media data can be sent wirelessly as unicast streams of packets containing media data that are transmitted at intervals to each client device, in one embodiment, the host device controls processing of media data such that processed media is delivered in a synchronized manner at each of the client devices. In another embodiment, the host device controls processing of media data such that processed media is delivered in a synchronized manner at the host device and at least one client device.
The system uses Network Time Protocol (NTP) to initially synchronize local clocks at the client devices with a reference clock at the host device. The media data is preferably sent as Real-Time Transport Protocol (RTP) packets from the host device to the client device. The system includes mechanisms for periodic synchronization, stretching, and compressing of time at the local clocks to handle clock drift. In addition, the system includes mechanisms for retransmission of lost packets of media data. In one embodiment, the system can be used to deliver audio at multiple sets of speakers in an environment, such as a house, and can reduce effects of presenting the audio out of sync at the multiple sets of speakers to avoid user-perceivable echo.
The foregoing summary is not intended to summarize each potential embodiment or every aspect of the present disclosure.
The foregoing summary, preferred embodiments, and other aspects of subject matter of the present disclosure will be best understood with reference to a detailed description of specific embodiments, which follows, when read in conjunction with the accompanying drawings, in which:
While the subject matter of the present disclosure is susceptible to various modifications and alternative forms, specific embodiments thereof have been shown by way of example in the drawings and are herein described in detail. The figures and written description are not intended to limit the scope of the inventive concepts in any manner. Rather, the figures and written description are provided to illustrate the inventive concepts to a person skilled in the art by reference to particular embodiments, as required by 35 U.S.C. § 112.
A network media delivery system having a host device and multiple client devices is described herein. The following embodiments disclosed herein are described in terms of devices and applications compatible with computer systems manufactured by Apple Computer. Inc. of Cupertino, Calif. The following embodiments are illustrative only and should not be considered limiting in any respect.
Referring to
The host device 20 is a personal computer, such as an AirPort-equipped Mac or a Wi-Fi-compliant Windows-based PC. The client devices 50 are networked media stations, such as disclosed in incorporated U.S. patent application Ser. No. 10/862,115. The client devices 50 are plugged into wall sockets, which provide power to the client devices 50, and are coupled to entertainment devices, such as amplifiers 80, powered speakers, televisions, stereo systems, videocassette recorders, DVD players, home theatre systems, or other devices capable of delivering media known in the art.
An example of the client device 50 is discussed briefly with reference to
The network electronics portion 54 also includes a wireless networking interface 68. The wireless network interface 68 preferably takes the form of a “Wi-Fi” interface according to the IEEE 802.11b or 802.11g standards know in the art. However, other wireless network standards could also be used, either in alternative to the identified standards or in addition to the identified standards. These other network standards can include the IEEE 802.11a standard or the Bluetooth standard, for example.
Returning to
The client devices 50 act as wireless base stations for a wireless network and enable the host device 20 to deliver media (e.g., audio, video, and multimedia content) at multiple locations in an environment. For example, the client devices 50 are connected to stereo amplifiers 80 or other entertainment devices to playback media stored on the host device 20. In one embodiment, a line level audio or a digital fiber optic type of connector connects the client devices 50 to the stereo amplifiers 80. Either type of connector can plug into the multimedia port (66;
For the purposes of the present disclosure, the client devices 50 can also be connected to laptops 70 or personal computers that are capable of playing media (audio, video, etc.) so that the laptops and personal computers can also be considered entertainment devices. Moreover, the laptops 70 or personal computers can have the same functionality as both a client device 50 and an entertainment device so that the laptops 70 and personal computers can be considered both a client device and an entertainment device. Accordingly, the term “client device” as used herein is meant to encompass not only the networked media stations associated with reference numeral 50, but the term “client device” as used herein is also intended to encompass any device (e.g., laptop, personal computer, etc.) compatible with the network media delivery system 10 according to the present disclosure. In the present disclosure, however, reference is made to client devices 50 for ease in discussion. Furthermore, the term “entertainment device” as used herein is meant to encompass not only stereo amplifiers 80 as shown in
The client devices 50 receive media data from the host device 20 over network connections and output this media data to the entertainment devices. Although it is contemplated that audio, video, audio/video, and/or other forms of multimedia may be used, exemplary embodiments disclosed herein relate to sharing of audio with client devices 50 connected to entertainment devices, such as stereo amplifiers 80, or with laptops 70 or other computers having internal speakers or the like. The audio can stored on the host device 20 or can be obtained from the Internet 46. However, it will be appreciated that the teachings of the present disclosure can be applied to video, audio/video, and/or other forms of multimedia in addition to the audio in the exemplary embodiments disclosed herein. Furthermore, in the discussion that follows, various details of the network media delivery system are implemented using hardware and software developed by Apple Computer. Inc. Although certain details are somewhat specific to such an implementation, various principles described are also generally applicable to other forms of hardware and/or software.
During operation, the system 10 delivers the same audio in separate locations of an environment (e.g., multiple rooms of a home). The system 10 addresses several issues related to playing the same audio in multiple, separate locations. One issue involves playing the audio in the separate locations in a synchronized manner with each other. Because the host device 20 and the client devices 50 have their own processors, memory, and transmission interfaces, sending or streaming audio from the host device 20 to the client devices 50 through a wireless or wired communication link will not likely result in synchronized playing of the audio at the separate locations. In addition, the client device 50 may be connected to different types of entertainment devices, which may have different latency and playback characteristics. It is undesirable to play the same audio in the separate locations out of sync because the listener will hear echoes and other undesirable audio effects. The system 10 addresses this issue by substantially synchronizing the playing of the audio in each location so that echo and other effects can be avoided. It should be noted that the level of precision required to substantially synchronize the playing of media at each location depends on the type of media being played, the perceptions of the user, spatial factors, and other details specific to an implementation.
Another issue related to playing of the same audio involves how to handle lost audio data at the separate locations. To address this issue, the disclosed system 10 preferably uses a retransmission scheme to recover lost audio. These and other issues and additional details of the disclosed network media delivery system are discussed below.
Referring to
The network discovery is used to initiate the interface between the host device 20 and client devices 50 and other compatible devices over the network of the system 10. One example of such a network discovery uses Bonjour, which is a technology that enables automatic discovery of computers, devices, and services on IP networks. Bonjour uses standard IP protocols to allow devices to find each other automatically without the need for a user to enter IP addresses or configure DNS servers. Various aspects of Bonjour are generally known to those skilled in the art, and are disclosed in the technology brief entitled “MAC OS X: Bonjour,” dated April 2005, and published by Apple Computer, which is incorporated herein by reference in its entirety. To provide the media sharing functionality between the host device 20 and the client devices 50, the client devices 50 advertise over the network that they support audio streaming and particular audio capabilities (e.g., 44.1 kHz sample rate, 16-bit sample size, and 2-channel/stereo samples). The client devices 50 may also advertise security, encryption, compression, and other capabilities and/or parameters that are necessary for communicating with the client devices 50.
When complaint client devices 50 are discovered, the addresses and port numbers of the discovered devices 50 are stored for use by the system 10. Then, the media application 22 displays information about the found client devices 50 in a user interface operating on the host device 20 (Block 106). In one embodiment, for example, the media application 22 discovers the client devices by obtaining information of the user's step up of computers and networks for their house, office, or the like from another application containing such information. In another embodiment, for example, the media application 22 discovers the client devices 50 and recognizes these client devices 50 as potential destinations for audio data. Then, the media application 22 automatically provides these recognized devices 50 as part of a selectable destination for audio playback in a user interface.
Returning to
If the negotiation succeeds, the client device 50 can be used for playback (Block 120). If the negotiation fails, however, the associated client device 50 can perform a number of possible operations (Block 121). For example, the client device 50 can return an error to the host device 20 in response to the command, and the session on this device 50 can be terminated. In another possible operation, the associated client device 50 can retry to negotiate the timing information. Alternatively, the associated client device 50 can ignore the fact that negotiating timing information has failed. This may be suitable when the user is not interested in the audio playing in synchronized manner in the multiple locations associated with the client devices 50. For example, the client device may be located by the pool or out in the garage and does not necessarily need to deliver the audio in synch with the other devices.
During playback at Block 120, the host device 20 sends audio data to the client devices 50, which process the audio data and deliver processed audio to the connected entertainment devices. An example of the process of playing back audio is discussed below with reference to the flowchart of
As discussed above, the host device 20 is connected to a wireless network established by the access point 30, which can also provide for a shared connection to the Internet or other network 46. The client devices 50 are also connected to the wireless network and have their multimedia ports connected to stereo amplifiers 80 or other entertainment device having output speakers or other multimedia output capability. A digital media file (e.g., a song in ACC format) is stored on the host device 20. Once playback is started (Block 122), the host device 20 transcodes a portion of the media file from the format (e.g., AAC) in which it is stored to a format that is understood by client device 50 (Block 124). This transcoding step is not necessarily required if the file is stored on the host device 20 in a format that is understood by the client device 50. In any case, a block of audio data for transmission is created (Block 126). This audio data is preferably compressed and encrypted (Block 128). Encryption is not necessarily required, but it is advantageous for digital rights management purposes.
The host device 20 then transmits the audio data over the wireless network to the client devices 50 (Block 130). The client devices 50 decrypt and decompress the received audio data (Block 132), and the client devices 50 decode the audio data based on the encoding performed in Block 124 (Block 134). The decoding results in raw audio data, which may be, for example, in the form of PCM data. This data is converted to analog audio signals by digital-to-audio converters (DAC) (Block 136), and the audio signals are output to the stereo amplifiers 80 for playing with their loudspeakers (Block 138).
With the benefit of the description of the components of the disclosed network media delivery system and its process of operation provided in
To transfer audio data and other information, the network media delivery system 10 of the present disclosure preferably uses User Datagram Protocol (UDP) as its underlying transport for media data. UDP is beneficial for synchronized playback to the multiple client devices 50 because synchronized playback places time constraints on the network protocol. Because audio is extremely time sensitive and has a definite lifetime of usefulness, for example, a packet of media data, such as audio, can become useless if it is received after a point in time when it should have been presented. Accordingly. UDP is preferred because it provides more flexibility with respect to the time sensitive nature of audio data and other media data.
To use UDP or some similar protocol, the disclosed system is preferably configured to handle at least a small percentage of lost packets. The lost packets can be recovered using Forward Error Correction (FEC), can be hidden using loss concealment techniques (e.g. repetition, waveform substitution, etc.), or can be recovered via retransmission techniques, such as those disclosed herein. Although UDP is preferred for the reasons set forth herein, Transmission Control Protocol (TCP) can be used. Depending on the implementation, retransmission using TCP may need to address problems with blocking of transmissions. If a TCP segment is lost and a subsequent TCP segment arrives out of order, for example, it is possible that the subsequent segment is held off until the first segment is retransmitted and arrives at the receiver. This can result in a chain reaction and effective audio loss because data that has arrived successfully and in time for playback may not be delivered until it is too late. Due to some of the retransmission difficulties associated with TCP, the Partial Reliability extension of Stream Control Transmission Protocol (SCTP) can provide the retransmission functionality. Details related to the Partial Reliability of SCTP are disclosed in RFC 3758, which can be obtained from http://www.ietf.org/rfc/rfc3758.txt, which is incorporated herein by reference.
UDP is preferred for time critical portions of the protocol because it can avoid some of the problems associated with blockage of transmission. For example, UDP allows the host's media application 22 to control retransmission of lost data because the media application 22 can track time constraints associated with pieces of audio data to be delivered. Based on the known time constraints, the media application 22 can then decide whether retransmission of lost packets of audio data would be beneficial or futile. All the same, in other embodiments, time critical portions of the disclosed system, such as time syncing, can be implemented using UDP, and audio data delivery can use TCP with a buffering system that addresses blocking problems associated with TCP.
Before discussing how the client devices negotiate timing information in order to play audio in synchronization, the discussion first addresses how the disclosed system streams audio for playback. Referring to
Although not shown in
The host device 320 uses several commands to set up a connection with and to control operation of the client devices 350. These commands include ANNOUNCE (used for identification of active client devices), SETUP (used to setup connection and operation). RECORD (used to initiate playback at client devices). PAUSE (used to pause playback). FLUSH (used to flush memory at the client devices), TEARDOWN (used to stop playback), OPTIONS (used to configure options). GET_PARAMETER (used to get parameters from the client devices), and SET_PARAMETER (used to set parameters at the client devices).
Preferably, the client devices 350 are authenticated when initially establishing a connection to the media application 322 running on the host device 320. Upon successful authentication, the media application 322 opens network connections to the transmission interface 356 of the client devices 350. Preferably, network connections between the host device 320 and the client devices 350 are separated into an audio channel for sending audio data and a control channel, used to set up connection and operation between the devices 320 and 350. However, a single channel could be used for data and control information. Once the connections are established, the host device 320 begins sending data to the client devices 350. In turn, the client devices 350 receive the audio data, buffer some portion of the data, and begin playing back the audio data once the buffer has reached a predetermined capacity.
Communication between the host device 320 and the client devices 350 preferably uses the Real Time Streaming Protocol (RTSP) standard. The media application 322 at the host device 320 preferably uses Real-Time Transport Protocol (RTP) encapsulated in User Datagram Protocol (UDP) packets 330 to deliver audio data from the host device 320 to the client devices 350. RTSP, RTP, and UDP are standards known to those skilled in the art. Therefore, some implementation details are not discussed here. Details of RTSP can be found in “Real-Time Streaming Protocol.” RFC 2326, which is available from http://www.ietf.org/rfc/ifc2326.txt and which is hereby incorporated by reference in its entirety. Details of RTP can be found in “Real-Time Transport Protocol.” RFC 3550, which is available from http://www.ietf.org/rfc/rfc3550.txt and which is hereby incorporated by reference in its entirety.
The packets 330 have RTP headers and include both sequence numbers and timestamps. The data payload of the RTP packets 330 contains the audio data to be played back by the client devices 350. The media files, from which the packets 330 are derived, can be stored on host device 320 in one or more formats, including, for example, MP3 (Motion Picture Expert's Group Layer 3), AAC (Advanced Audio Coding a/k/a MPEG-4 audio), WMA (Windows Media Audio), etc. Preferably, the media application 322 running on the host device 320 decodes these various audio formats to construct the packets 330 so that the client devices 350 do not need decoders for multiple formats. This also reduces the hardware performance requirements of the client devices 350. Another advantage of performing decoding on the host device 320 is that various effects may be applied to the audio stream, for example, cross fading between tracks, volume control, equalization, and/or other audio effects. Many of these effects would be difficult or impossible to apply if the client device 350 were to apply them, for example, because of the computational resources required. Although not preferred in the present embodiment, other embodiments of the present disclosure can allow for decoding at the client devices 350 for audio and other forms of media.
The host device 320 preferably uses a separate unicast stream 310A-B of RIP packets 330 for each of the client devices 350A-B. In the present embodiment, the separate unicast streams 310A-B are intended to deliver the same media information (e.g., audio) to each of the client devices 350A-B so that the same media can be presented at the same time from multiple client devices 350A-B. In another embodiment, each of the separate unicast streams 310A-B can be used to deliver separate media information (e.g., audio) to each of the client devices 350A-B. The user may wish to unicast separate media information in some situations, for example, if a first destination of a first unicast stream of audio is a client device in a game room of a house and a second destination of a second unicast stream of different audio is a client device in the garage of the house. Therefore, it may be preferred in some situations to enable to the user to not only select sending the same media information by unicast steams to multiple client devices by to also allow the user to send different media information by separate unicast streams to multiple client devices. The user interface 200 of
Separate unicast streams 310 are preferred because multicasting over wireless networks can produce high loss rates and can be generally unreliable. All the same, the disclosed system 300 can use multicasting over the wireless network. In general, though, bandwidth limitations (i.e. fixed multicast rate), negative effects on unicast performance (low-rate multicast slows down other unicast traffic due to multicast packets taking longer), and loss characteristics associated with multicasting over wireless (multicast packets are not acknowledged at the wireless layer) make multicasting less desirable than using multiple, unicast streams 310A-B as preferred. Use of multiple, unicast streams 310A-B does correspond to an increase in bandwidth as additional client devices 350 are added to a group of designated locations for playback. If the average compression rate for audio data is about 75%, the increase in bandwidth associated with multiple, unicast streams 310A-B may correspond to about 1 Mbit/sec bandwidth required for each client device 350 so that the host device 320 can send compressed audio data to the access point (e.g., 30;
Once an RTSP session has been started and the RECORD command has been sent from the host device 320 to the client devices 350, the host device 320 begins sending normal RTP packets 330 containing the audio data for playback. These RTP packets 330 are sent at regular intervals, based on the number of samples per second, which can be about 44,100 Hz for audio. The RTP packets 330 are sent at the regular intervals in a throttled and evenly spaced manner in order to approximate the audio playback rate of the remote client devices 350 because the UDP-based connection does not automatically control the sending of data in relation to the rate at which that data is consumed on the remote client devices 350.
Because each of the multiple client devices 350 has their own audio buffers 361, 362, network conditions, etc., it may not be desirable to use a feedback scheme when sending the packets 330. Accordingly, the host device 320 sends audio data at a rate that preferably does not significantly under-run or over-run a playback engine 353 of any of the remote client devices 350. To accomplish this, the host device 320 estimates a fixed delay 340 to insert between packets 330 to maintain the desired audio playback rate. In one embodiment, the packets 330 of audio data are sent with a delay of about 7.982-ms between packets 330 (i.e., 352 samples per packet/44.100 Hz=−7.982-ms per packet), which corresponds to a rate of about 125 packets/sec. Because the delay 340 is fixed, each of the client devices 350 can also detect any skew between its clock and the clock of the sending host device 320. Then, based on the detected skew, each client device 350 can insert simulated audio samples or remove audio samples in the audio it plays back in order to compensate for that skew.
As alluded to above, the RTP packets 330 have timestamps and sequence numbers. When an RTP packet 330 is received by a client device 350, the client device 350 decrypts and decompresses the payload (see Encryption and Compression section below), then inserts the packet 320, sorted by its timestamp, into a packet queue. The two audio buffers 361 and 362 are alternatingly cycled as audio is played hack. Each audio buffer 361 and 362 can store a 250-ms interval of audio. The received RTP packets in the packet queue are processed when one of the two, cycling audio buffers 361 and 362 completes playback. In one embodiment, the audio is USB-based so this is a USB buffer completion process.
To process the queued packets, the engine 353 assembles the queued RTP packets in one of the audio buffers 361 or 362. During the assembly, the engine 353 calculates when each of queued RTP packets should be inserted into the audio stream. The RTP timestamp in the packets combined with time sync information (see the Time Synchronization section below) is used to determine when to insert the packets. The engine 353 performs this assembly process and runs through the queued packets to fill the inactive audio buffer 361 or 362 before the currently playing audio buffer 361 or 362 has completed. Because each of the audio buffers 361 and 362 can store 250-ms of audio, the client device 350 has a little less than 250-ms to assemble all the RTP packets, conceal any losses, and compensate for any clock skew. If there are any gaps in the audio (e.g., the device's audio clock is skewed from the host's audio clock, a packet was lost and not recovered, etc.), then those gaps can be concealed by inserting simulated audio samples or removing existing audio samples.
For digital rights management purposes, it is desirable to determine whether the client devices 350 are authorized to receive an audio data stream and/or whether the communications links between the host device 320 and the client devices 350 are secure (encrypted). This requires some form of authentication, which is preferably based on a public key/private key system. In one embodiment, each client station 350 is provided with a plurality of private keys embedded in read only memory (ROM). The media application at the host device 320 is then provided with a corresponding plurality of public keys. This allows identification data transmitted from the networked client devices 350 to the media application to be digitally signed by the client device 350 using its private key, by which it can be authenticated by the media application at the host device 320 using the appropriate public key. Similarly, data sent from the media application at the host device 320 to the networked client stations 350 is encrypted using a public key so that only a client device 350 using the corresponding private key can decrypt the data. The media software and networked media station can determine which of their respective pluralities of keys to use based on the exchange of a key index, telling them which of their respective keys to use without the necessity of transmitting entire keys.
In addition to encryption, the decoded audio data is preferably compressed by host device 320 before transmission to the client devices 350. This compression is most preferably accomplished using a lossless compression algorithm to provide maximum audio fidelity. One suitable compressor is the Apple Lossless Encoder, which is available in conjunction with Apple's iTunes software. The client devices 350 require a decoder for the compression codec used.
The RTP packets 330 are preferably compressed using the Apple Lossless algorithm and are preferably encrypted using the Advanced Encryption Standard (AES) with a 128-bit key size. Loss is still inevitable even though the system 300 uses a UDP-based protocol that attempts to recover from packet loss via retransmission and/or Forward Error Correction (FEC). For this reason, encryption and compression preferably operate on a per-packet basis. In this way, each packet 330 can be completely decoded entirely on its own, without the need for any surrounding packets 330. The Apple Lossless algorithm is used to compress each individual packet 330 rather than compressing a larger stream of audio and packetizing the compressed stream. Although compressing each individual packet 330 may reduce the effectiveness of the compression algorithm, the methodology simplifies operation for the client devices 350 and allows them to be more tolerant to packet loss. Although compression rates are highly dependent on the content, music audio can have an average compression rate of about 75% of the original size when used by the disclosed system 300.
The AES-128 algorithm is used in frame-based cipher block chaining (CBC) mode to encrypt payloads of the RTP packets 330 and the RTP payload portion of RTCP retransmission packets (380;
As noted above, the RTP packets 330 received from the host device 320 have RTP sequence numbers. Based on those RTP sequence numbers, the client device 350 can determine whether packets 330 that have been lost during transmission or for other reasons. The lost RTP packets 330 cannot be queued for playback in the audio buffers 361 and 362 of the client devices 350 so that gaps will result in the audio. To address this issue, the client devices 350 requests that the lost packet(s) be retransmitted. Referring to
To handle retransmissions, the system 300 preferably uses Real-Time Transport Control Protocol (RTCP) when packet loss is detected. As note above, the sequence numbers associated with the received RTP packets (330;
In response to the retransmission request 370, the host device 320 sends one or more retransmission responses 380 for lost packets. Due to limitations of the maximum transmission unit (MTU) on RTCP packet sizes, only one response can be sent per retransmission response packet 380. This means that a single retransmission request packet 370 from a device 350 may generate up to 128 retransmission response packets 380 from the host device 320 if all of the lost packets are found in the host's recently sent packets.
Because RTP does not currently define a standard packet to be used for retransmissions, an RTP extension for an RTCP Retransmission Request packet is preferably defined.
In
When multiple, contiguous packets have been lost, the initial retransmit request 370 includes all the missing packets. However, if a response 380 is not received in a timely manner, the missing packets are spread out among multiple requests 370 over time when reattempts are made. Spreading out among multiple requests can maintain a uniform delivery of request and response packets. This also prioritizes packets by time and defers delivery of packets whose presentation time is later.
When the host device 320 receives a retransmission request 370, the host device 320 searches a list of recently sent packets stored at the device 320. If the requested packet in the request 370 is found, the host device 320 sends a retransmission response 380 to the client device 350. An example of an RTP extension for an RTCP Retransmit Response Packet 380 is shown in
If the requested packet is not found by the host device 320, however, a negative response 390 is sent so the corresponding client device 350 knows that any further attempt to request that particular packet is futile. An example of an RTP extension for an RTCP Futile Retransmit Response Packet 390 is shown in
In
Scheduling retransmission is based on regular reception of RTP packets (330:
Because the disclosed system 330 plays music at multiple locations at the same time, it may be desirable to be able to adjust the volume at each location individually. The disclosed system 300 supports individual volume control by using a relative volume setting specified using a header field as part of an RTSP SET PARAMETER request. The volume is expressed as a floating-point decibel level (e.g. 0 dB for full volume). In addition to volume, the disclosed system 330 can set other parameters related to the delivery of media at multiple locations using similar techniques. For example, the disclosed system 300 can be used to set equalization levels at each location individually.
Referring to
The reference clock 324 is maintained within the media application 322 running on the host device 320. If the host device 320 is a Macintosh computer, then the reference clock 324 can use the PowerPC timebase registers. If the host device 320 is a Windows-based computer, the reference clock 324 can use the Pentium performance counter registers. The reference clock 324 of the host's media application 322 is separate from the normal wall-clock time of the host device 320, which is maintained by an NTP agent and synchronized to an external clock. The reference clock 324 of the host's media application 322 does not need to be synchronized to an external clock and in some cases this would actually be undesirable. For example, a time difference between the reference clock 324 and the local clock of a client device 350 can be explicitly skewed or adjusted to account for spatial effects or differences, such at the client device 350 being located farther away than another. In addition, there may be situations where a user may want to intentionally skew the clocks to produce effects. Accordingly, the user interface associated with the disclosed system 300, such as interface 200 of
To synchronize the timebase between the client devices 350 and the host device 320, the media application 322 uses time sync information based on the principals of the Network Time Protocol (NTP) encapsulated in Real-Time Transport Control Protocol (RTCP) packets. Preferably, NTP is not used directly to avoid collisions with existing NTP services (e. g., date/time synchronization with an external clock) and to avoid permission issues due to NTP's use of a privileged port number. Even though the time sync information of the media application 322 is encapsulated in RTCP packets, the time synchronization works substantially the same as NTP and will be referred to as NTP henceforth. NTP is known in the art and provides the basis for inter-media synchronization support in the Real-Time Transport Protocol (RTP). Details of NTP can be found in “Network Time Protocol,” RFC 1305, which is available from http://www.ietf.org/rfc/rfc1305.txt and is incorporated herein by reference in its entirety.
Techniques of NTP, however, are preferably not used to provide moment-to-moment time directly to each client device 350 due to issues related to network latency, bandwidth consumption, and CPU resources. Accordingly, techniques of NTP are used for periodic synchronization of time. In addition, each client device 350 is provided with a high-resolution clock 364 based on the local clock hardware of each client device 350 (see Local Clock Implementation section below), the high-resolution clocks 364 are synchronized with the reference clock 324 of the host device 320 using the NTP techniques.
Synchronizing the local clocks 364 of the client devices 350 with the reference clock 324 preferably does not jump to a new time with every correction (referred to as stepping) because stepping can introduce discontinuities in time and can cause time to appear to go backward, which can create havoc on processing code that relies on time. Instead, the time synchronization techniques of the present disclosure preferably correct time smoothly using clock slewing so that time advances in a linear and monotonically increasing manner. In the clock slewing techniques of the present disclosure, frequent micro-corrections, below a tolerance threshold, are performed to the running clocks 364 at the client devices 350 to bring their timebase gradually in sync with the timebase of the reference clock 324 of the host's media application 322. The clock slewing techniques also predict the relative clock skew between the local clocks 364 and the host's reference clock 324 by analyzing past history of clock offsets and disciplining the local clocks 364 to run at the same rate as the host's reference clock 324.
Because a centralized reference clock 324 is used for several client devices 350 on a local network, one way to disseminate time information is to send broadcast/multicast NTP packets periodically from the host device 320 to the client devices 350. Sending NTP packets by multicasting must account for losses and performance degradation that may result from the wireless 802.11b and 802.11g communication links between the host device 320 and the client devices 350. Due to issues of performance degradation, loss rates, and lack of propagation delay information associated with broadcasting or multicasting, unicast NTP transactions 400 are preferably used.
As part of the unicast NTP transactions 400, the client devices 350 periodically send unicast requests 410 to the host device 320 so that the client devices 350 can synchronize their clocks 364 with the reference clock 324. Then, the client devices 350 use responses 420 from the host device 320 corresponding to their requests 410 to continually track the clock offset and propagation delay between the client device 350 and host device 320 so the client devices 350 can update their local clocks 364. Thus, synchronization of the audio playback at the client devices 350 is achieved by maintaining local clocks 364 that are synchronized to the host device's clock 324. Since all client devices participating in a particular session are synchronized to the reference clock 324. When the clocks 324 and 364 are synchronized, the client devices 350 can play audio in-sync without ever communicating with each other.
With the timebase at the client devices 350 synchronized with the reference clock 324 at the host device 320, the client devices 350 can use the synchronized timebase to determine when to playback packets of audio data. As noted previously, audio data is delivered to the client devices 350 using RTP packets (330;
With respect to the unicast requests and responses 410 and 420 noted above, RTP does not define a standard packet format for synchronizing time. There is an RTCP sender report, which contains some timing information, but not everything that is needed to synchronize time (e.g., there is no originate time for receivers to determine the round trip time). There are also rules preventing sender reports from being sent before any RTP data has been sent, which is critical for playing the initial audio samples in sync.
Therefore, the host's media application 322 preferably defines an RTP extension for an RTCP TimeSync packet for the requests and responses 410 and 420. An embodiment of an RTCP TimeSync packet 430 is shown in
In
The host's media application 322 also defines an RTP extension for an RTCP TimeAnnounce packet 450. The RTCP TimeAnnounce packets 450 are sent periodically (e.g., once a second) by the host device 320 to update the client devices 350 with the current timing relationship between NTP and RTP. The RTCP TimeAnnounce packets 450 can be sent sooner if the host device 320 changes the NTP to RTP timing relationship. For example, when a new song starts, the host's media application 322 can send a new RTCP TimeAnnounce packet 450 with the marker bit (M) set to indicate that the NTP to RTP timing relationship has changed.
As shown in the embodiment of
Returning to
To maintain more accurate time, it may be preferable to allow time to be adjusted gradually. Accordingly, the nanoseconds counter is adjusted in very small increments during each clock interrupt to “slew” to the target time. These small increments are chosen based on a fraction of the amount of adjustment needed and based on the tick delta. This prevents time from appearing to go backward so that time always increases in a linear and monotonic manner.
Additionally, the client device 350 can predict what the next NTP clock offset will be in the future to further adjust the local clock 364. To make the prediction, the client device 350 uses a moving average of NTP clock offsets to estimate the slope of the clock skew between each of client device 350 and host device 320. This slope is then extrapolated to estimate the amount of adjustment necessary to keep the local clock 364 at the client device 350 in sync with the reference clock 324. The client device 350 then makes very small adjustments to the per-clock interrupt increment, in addition to the adjustments made for clock stewing, to simulate the faster or slower clock frequency of the host's reference clock 324. This allows the local clock 364 to remain synchronized between NTP update intervals and may even allow the reference clock 324 to remain synchronized in the absence of future NTP clock updates).
Referring to
To play audio in a synchronized manner on multiple client devices 350 (only one of which is shown in
To provide buffering without this high level of latency, the sending of packets 330 is preferably decoupled or separated from the timeline for presenting the audio data of those packets 330. To achieve this, the media application 322 maintains two simulated timelines 328 and 329. A first packet timeline 328 corresponds to when packets 330 should be sent, and a second playback timeline 329 corresponds to when the audio data in those packets 330 should be presented or delivered (i.e., played for the user). The separate timelines 328 and 329 allow the send rate of the packets 330 to vary as needed so that the system 300 can provide buffering without introducing latency. If more buffering is needed, for example, the packet send rate of the first packet timeline 328 can be temporarily increased to front-load the buffers in memory 354 on the client devices 350 and can be later reduced back to the real-time send rate of the packets 330. The separate timelines 328 and 329 also avoid problems associated with fluctuations in the presentation time of audio caused by scheduled latency of the operating systems on the devices.
The second playback timeline 329, which corresponds to when the audio data in the packets 330 should be presented or delivered, is constructed by the host device 320. Using the reference clock 324 and a desired playback rate of the audio, the host device 320 estimates the number of audio samples that would have played at a given point in time at the client device 350 to construct the playback timeline 329. This second playback timeline 329 is then published from the host device 320 to the client devices 350 as part of the time announcements 450 sent periodically from the host device 320 to the client devices 350. As discussed in greater detail previously, the client device 350 uses the periodic time announcements 450 to establish and maintain the relationship between the RTP timestamps in the audio packets 330 and the corresponding NTP presentation time for the audio packets 330 so that the client device 350 can deliver the audio in synch with other devices.
By having the send rate of the packets 330 (represented by the packet timeline 328) separate from the presentation time (represented by the playback timeline 329), the periodic time announcements 450 are not designed to take effect immediately when received by the client devices 350 since the announcements 450 may come in advance of when they are effective. As noted previously, however, the time announcement packets 450 contain an additional RTP timestamp that indicates when the announced time should take effect at the client device 350. Therefore, a time announcement packet 450 is saved at a client device 350 once it is received. When audio playback reaches the RTP timestamp of that saved time announcement packet 450, the client device 350 applies the time change contained in that saved time announcement package 450.
To play audio in a synchronized manner on multiple client devices 350 (only one of which is shown in
Determination of the latency characteristics of the client devices 350 preferably occurs at initial set up of the system 300. For example, the media application 322 at the host device 320 sends RTSP SETUP requests 312 to the client devices 350 at initial set up. In responses 314 to the RTSP SETUP requests 312, the client devices 350 use a header field to report the latency characteristics associated with the client devices 350. The values of the field are preferably given as the number of RTP timestamp units of latency. For example, a client device 350 having 250-ms of latency at a 44,100-Hz sample rate would report its audio-latency as 11025 RTP timestamp units. Based on the reported latency characteristics from the client devices 350, the host's media application 322 determines a maximum latency of all client devices 350 in the group being used for playback. This maximum latency is then added to the playback timeline 329.
In addition to synchronized playback at multiple client devices 350, the disclosed system 300 allows for synchronized local playback at the host device 320 running the media application 322. For example, the host device 320 can play the same audio to its local speakers (not shown) that is being played by the client devices 350, and the host device 350 can have that same audio play in sync with the all the other devices 350. To achieve this, the host device 320 uses many of the same principles as applied to the client devices 350. Rather than receiving packets of audio data over a wireless network, however, audio data is delivered directly to a local playback engine 323 of the media application 322. In addition, because local playback on the host device 320 is handled by the media application 322, there is no need for the host device 320 to synchronize time with its own reference clock 324.
The packets of audio data delivered to the synchronized local playback engine 323 within the media application 322 are generated before being compressed and encrypted. Since these packets do not leave media application 322, no compression or encryption is necessary. In one embodiment, the host device 320 uses CoreAudio to playback audio. CoreAudio can be used for both Mac-based or Windows-based computers because QuickTime 7 provides support for CoreAudio on Windows-based computers. During operation, an output AudioUnit is opened, and a callback is installed. The callback is called when CoreAudio needs audio data to play. When the callback is called, the media application 322 constructs the relevant audio data from the raw packets delivered to it along with the RTP→NTP timing information. Since CoreAudio has different latency characteristics than the latency characteristics associated with the client devices 350, information is also gathered about the presentation latency associated with the audio stream of CoreAudio. This information is used to delay the CoreAudio audio stream so that it plays in sync with the known latency of the audio streams associated with the client devices 350.
In addition to the techniques discussed previously for handling lost RTP packets of audio data and for synchronizing clocks between the host device 320 and the client devices 350, the disclosed system 300 preferably limits stuttering in the playback of media. Referring to
If the number of credits goes below a predefined threshold at Block 504, the client device is put on probation (Block 506). When on probation, audio is disabled and silenced, but the client device can still send retransmit requests to the host device as needed to recover lost packets of audio data. The audio is silenced during probation so that the client device will not produce an annoying stutter sound when a significant number of glitching periods are successively delivered in an interval of time. Even though the audio is silenced, retransmits remain enabled so that operation of the client device can improve to a point suitable to resume playback.
If the number of glitches is not greater than the limit at Block 504, then the client device is set as “glitch free” (Block 505). Each time a “glitch-free” period is detected, for example, a number of credits is added to the credit score for the client device. The number of credits is capped at a maximum value to prevent a long sequence of glitch-free periods from extending the number of glitches required before going into stutter avoidance mode because the intention is to be able to go into stutter avoidance mode quickly so that there is not any significant stutter produced.
For the client device on probation with audio silenced and retransmits enabled, the number of glitches occurring in a predetermined unit of time (e.g., X seconds) is determined (Block 508). The number of glitches is compared to a predetermined limit or threshold (Block 510). If the client device is on probation for the predetermined unit of time (X seconds) and the number of credits reaches an upper threshold at Block 510, the client devices is placed back into normal playback mode at Block 505.
If the client device remains on probation for the predetermined unit of time (X seconds) and the number of credits has not reached an upper threshold at Block 510, then the client device is put in jail (Block 512). When in jail, the audio remains disabled and silenced. However, retransmits are now disabled. In this situation, the client device has not recovered for a significant period of time, and any retransmits may actually be making the situation worse. By disabling retransmits, the recovery time may be improved by reducing congestion on the network. In addition, disabling retransmits may at least reduce the amount of traffic on the network and may allow other client devices to receive packets of audio data more reliably.
If the client device remains in jail for a predetermined unit of time (e.g., Y seconds) at Block 514, the client device goes on parole to see if its situation has improved (Block 516). When on parole, audio is still disabled and silenced. However, retransmits are re-enabled. The number of glitches occurring in a predetermined unit of time (e.g., Z seconds) is determined (Block 518) and compared to a predetermined limit (Block 520). If the client device is on parole for the predetermined unit of time and the number of credits reaches an upper threshold at Block 520, then client device returns to normal playback mode at Block 505 where audio and retransmits are both enabled. If the client device stays on parole for the predetermined unit of time and the number of credits does not reach the upper threshold at Block 520, however, the client device goes back to jail at Block 512.
With reference again to
In another solution, the client devices 350 periodically (e.g., once a minute) send unsolicited, unicast ARP request packets (not shown) to the host device 320. These unicast ARP request packets contain source addresses (Internet Protocol (IP) address and the hardware address of the client device 350) and target addresses (IP address and hardware address of the host device 320). The unicast ARP request packets are more reliable than broadcast packets because the unicast packets are acknowledged and retried at a wireless layer. To keep the ARP entries on the host device 320 for the client devices 350 from expiring, the host device 320 updates its ARP cache when it receives these unicast ARP request packets by refreshing the timeout for the corresponding ARP entries. This prevents the host device 320 from needing to issue a broadcast ARP request when the ARP entry for a client device 350 expires because the ARP entries effectively never expire as long as the client devices 350 unicast ARP request packets to the host device 320.
The foregoing description of preferred and other embodiments is not intended to limit or restrict the scope or applicability of the inventive concepts conceived of by the Applicants. In exchange for disclosing the inventive concepts contained herein, the Applicants desire all patent rights afforded by the appended claims. Therefore, it is intended that the appended claims include all modifications and alterations to the full extent that they come within the scope of the following claims or the equivalents thereof.
| Number | Name | Date | Kind |
|---|---|---|---|
| 4807224 | Naron et al. | Feb 1989 | A |
| 5534911 | Levitan | Jul 1996 | A |
| 5535381 | Kopper | Jul 1996 | A |
| 5553222 | Milne et al. | Sep 1996 | A |
| 5559945 | Beaudet et al. | Sep 1996 | A |
| 5583993 | Foster et al. | Dec 1996 | A |
| 5587404 | Kroener et al. | Dec 1996 | A |
| 5613863 | Klaus et al. | Mar 1997 | A |
| 5616876 | Cluts | Apr 1997 | A |
| 5640566 | Victor et al. | Jun 1997 | A |
| 5664044 | Ware | Sep 1997 | A |
| 5664226 | Czako et al. | Sep 1997 | A |
| 5666530 | Clark et al. | Sep 1997 | A |
| 5696948 | Cruz et al. | Dec 1997 | A |
| 5709521 | Glass et al. | Jan 1998 | A |
| 5710922 | Alley et al. | Jan 1998 | A |
| 5721949 | Smith et al. | Feb 1998 | A |
| 5722041 | Freadman | Feb 1998 | A |
| 5727202 | Kucala | Mar 1998 | A |
| 5739451 | Winksy et al. | Apr 1998 | A |
| 5745583 | Koizumi et al. | Apr 1998 | A |
| 5751997 | Kullick et al. | May 1998 | A |
| 5790521 | Lee et al. | Aug 1998 | A |
| 5815297 | Ciciora | Sep 1998 | A |
| 5835721 | Donahue et al. | Nov 1998 | A |
| 5835732 | Kikinis et al. | Nov 1998 | A |
| 5845282 | Alley et al. | Dec 1998 | A |
| 5864868 | Contois | Jan 1999 | A |
| 5867668 | Spirakis et al. | Feb 1999 | A |
| 5875354 | Charlton et al. | Feb 1999 | A |
| 5918213 | Bernard et al. | Jun 1999 | A |
| 5918303 | Yamaura et al. | Jun 1999 | A |
| 5923757 | Hocker et al. | Jul 1999 | A |
| 5925843 | Miller et al. | Jul 1999 | A |
| 5931906 | Fidelibus et al. | Aug 1999 | A |
| 5953350 | Higgins | Sep 1999 | A |
| 5963916 | Kaplan | Oct 1999 | A |
| 5969283 | Looney et al. | Oct 1999 | A |
| 6000000 | Hawkins et al. | Dec 1999 | A |
| 6006274 | Hawkins et al. | Dec 1999 | A |
| 6008777 | Yiu | Dec 1999 | A |
| 6038199 | Pawlowski et al. | Mar 2000 | A |
| 6041023 | Lakhansingh | Mar 2000 | A |
| 6061306 | Buchheim | May 2000 | A |
| 6085252 | Zhu et al. | Jul 2000 | A |
| 6092119 | Rossmere et al. | Jul 2000 | A |
| 6101591 | Foster et al. | Aug 2000 | A |
| 6125369 | Wu et al. | Sep 2000 | A |
| 6138245 | Son et al. | Oct 2000 | A |
| 6166314 | Weinstock et al. | Dec 2000 | A |
| 6172948 | Keller et al. | Jan 2001 | B1 |
| 6208044 | Viswanadham et al. | Mar 2001 | B1 |
| 6212359 | Knox | Apr 2001 | B1 |
| 6216131 | Liu et al. | Apr 2001 | B1 |
| 6240555 | Shoff et al. | May 2001 | B1 |
| 6243328 | Fenner et al. | Jun 2001 | B1 |
| 6243725 | Hempleman et al. | Jun 2001 | B1 |
| 6243772 | Ghori et al. | Jun 2001 | B1 |
| 6247135 | Feague | Jun 2001 | B1 |
| 6248946 | Dwek | Jun 2001 | B1 |
| 6263313 | Milsted et al. | Jul 2001 | B1 |
| 6263503 | Margulis | Jul 2001 | B1 |
| 6272545 | Flanagin et al. | Aug 2001 | B1 |
| 6282714 | Ghori et al. | Aug 2001 | B1 |
| 6283764 | Kajiyama et al. | Sep 2001 | B2 |
| 6295541 | Bodnar et al. | Sep 2001 | B1 |
| 6332175 | Birrell et al. | Dec 2001 | B1 |
| 6338044 | Cook et al. | Jan 2002 | B1 |
| 6341316 | Kloba et al. | Jan 2002 | B1 |
| 6345256 | Milsted et al. | Feb 2002 | B1 |
| 6356971 | Katz et al. | Mar 2002 | B1 |
| 6374177 | Lee et al. | Apr 2002 | B1 |
| 6380947 | Stead | Apr 2002 | B1 |
| 6389467 | Eyal | May 2002 | B1 |
| 6397388 | Allen | May 2002 | B1 |
| 6411943 | Crawford | Jun 2002 | B1 |
| 6429880 | Marcos et al. | Aug 2002 | B2 |
| 6453281 | Walters et al. | Sep 2002 | B1 |
| 6489986 | Allen | Dec 2002 | B1 |
| 6490432 | Wegener et al. | Dec 2002 | B1 |
| 6493758 | McLain | Dec 2002 | B1 |
| 6523124 | Lunsford et al. | Feb 2003 | B1 |
| 6529233 | Allen | Mar 2003 | B1 |
| 6529804 | Draggon et al. | Mar 2003 | B1 |
| 6546428 | Baber et al. | Apr 2003 | B2 |
| 6563769 | Van Der Meulen | May 2003 | B1 |
| 6587403 | Keller et al. | Jul 2003 | B1 |
| 6587404 | Keller et al. | Jul 2003 | B1 |
| 6587480 | Sanders | Jul 2003 | B1 |
| 6621768 | Keller et al. | Sep 2003 | B1 |
| 6630963 | Billmaier | Oct 2003 | B1 |
| 6636873 | Carini et al. | Oct 2003 | B1 |
| 6659861 | Faris et al. | Dec 2003 | B1 |
| 6664981 | Ashe et al. | Dec 2003 | B2 |
| 6665803 | Lunsford et al. | Dec 2003 | B2 |
| 6684060 | Curtin | Jan 2004 | B1 |
| 6694200 | Naim | Feb 2004 | B1 |
| 6718348 | Novak et al. | Apr 2004 | B1 |
| 6721489 | Benyamin et al. | Apr 2004 | B1 |
| 6728585 | Neoh | Apr 2004 | B2 |
| 6728729 | Jawa et al. | Apr 2004 | B1 |
| 6731312 | Robbin | May 2004 | B2 |
| 6744738 | Park et al. | Jun 2004 | B1 |
| 6757913 | Knox | Jun 2004 | B2 |
| 6760721 | Chasen et al. | Jul 2004 | B1 |
| 6763345 | Hempleman et al. | Jul 2004 | B1 |
| 6766376 | Price | Jul 2004 | B2 |
| 6779019 | Mousseau et al. | Aug 2004 | B1 |
| 6785542 | Blight et al. | Aug 2004 | B1 |
| 6794566 | Pachet | Sep 2004 | B2 |
| 6798838 | Ngo | Sep 2004 | B1 |
| 6801964 | Mahdavi | Oct 2004 | B1 |
| 6831881 | Patil et al. | Dec 2004 | B2 |
| 6845398 | Galensky et al. | Jan 2005 | B1 |
| 6874037 | Abram et al. | Mar 2005 | B1 |
| 6898159 | Kudo | May 2005 | B2 |
| 6920179 | Anand et al. | Jul 2005 | B1 |
| 6925595 | Whitledge et al. | Aug 2005 | B1 |
| 6928433 | Goodman et al. | Aug 2005 | B2 |
| 6929058 | Liu et al. | Aug 2005 | B2 |
| 6935627 | Jung | Aug 2005 | B2 |
| 6941324 | Plastina et al. | Sep 2005 | B2 |
| 6944880 | Allen | Sep 2005 | B1 |
| 6947598 | Yogeshwar et al. | Sep 2005 | B2 |
| 6956562 | O'Hara et al. | Oct 2005 | B1 |
| 6959288 | Medina et al. | Oct 2005 | B1 |
| 6959562 | Navedo et al. | Nov 2005 | B2 |
| 6978127 | Bulthuis et al. | Dec 2005 | B1 |
| 6981259 | Luman et al. | Dec 2005 | B2 |
| 6985966 | Gupta et al. | Jan 2006 | B1 |
| 6987221 | Platt | Jan 2006 | B2 |
| 6993532 | Platt et al. | Jan 2006 | B1 |
| 6993722 | Greer et al. | Jan 2006 | B1 |
| 6999826 | Zhou et al. | Feb 2006 | B1 |
| 7010758 | Bate | Mar 2006 | B2 |
| 7016443 | Splett | Mar 2006 | B1 |
| 7022905 | Hinman et al. | Apr 2006 | B1 |
| 7024214 | Loveland | Apr 2006 | B2 |
| 7024491 | Hanmann et al. | Apr 2006 | B1 |
| 7024575 | Lienhart et al. | Apr 2006 | B2 |
| 7034891 | Joung et al. | Apr 2006 | B2 |
| 7039656 | Tsai et al. | May 2006 | B1 |
| 7047308 | Deshpande | May 2006 | B2 |
| 7069058 | Kawashima | Jun 2006 | B2 |
| 7075000 | Gang et al. | Jul 2006 | B2 |
| 7076204 | Richenstein et al. | Jul 2006 | B2 |
| 7082310 | Hirayama et al. | Jul 2006 | B2 |
| 7082320 | Kattukaran et al. | Jul 2006 | B2 |
| 7084898 | Firestone et al. | Aug 2006 | B1 |
| 7096271 | Omoigui et al. | Aug 2006 | B1 |
| 7111009 | Gupta et al. | Sep 2006 | B1 |
| 7130892 | Mukai | Oct 2006 | B2 |
| 7136934 | Carter et al. | Nov 2006 | B2 |
| 7142934 | Janik | Nov 2006 | B2 |
| 7143939 | Henzerling | Dec 2006 | B2 |
| 7146322 | Cowgill | Dec 2006 | B2 |
| 7166791 | Robbin et al. | Jan 2007 | B2 |
| 7174560 | Crinon | Feb 2007 | B1 |
| 7184774 | Robinson et al. | Feb 2007 | B2 |
| 7185084 | Sirivara et al. | Feb 2007 | B2 |
| 7194692 | Marcos et al. | Mar 2007 | B2 |
| 7200357 | Janik et al. | Apr 2007 | B2 |
| 7228054 | Cowgill | Jun 2007 | B2 |
| 7260714 | Dawson et al. | Aug 2007 | B2 |
| 7266713 | Lienhart et al. | Sep 2007 | B2 |
| 7281141 | Elkayam et al. | Oct 2007 | B2 |
| 7283880 | Dick | Oct 2007 | B2 |
| 7289393 | Keller et al. | Oct 2007 | B2 |
| 7295809 | Moore | Nov 2007 | B2 |
| 7295983 | Fujiwara et al. | Nov 2007 | B2 |
| 7302239 | Jitsuhara | Nov 2007 | B2 |
| 7305691 | Cristofalo | Dec 2007 | B2 |
| 7312785 | Tsuk et al. | Dec 2007 | B2 |
| 7330868 | Kawasaki et al. | Feb 2008 | B2 |
| 7336675 | Naik et al. | Feb 2008 | B2 |
| 7343553 | Kaye | Mar 2008 | B1 |
| 7346698 | Hannaway | Mar 2008 | B2 |
| 7359671 | Richenstein et al. | Apr 2008 | B2 |
| 7367701 | Lee | May 2008 | B2 |
| 7369532 | Silvester | May 2008 | B2 |
| 7370129 | Green et al. | May 2008 | B2 |
| 7391791 | Balassanian et al. | Jun 2008 | B2 |
| 7406294 | Liu | Jul 2008 | B1 |
| 7418472 | Shoemaker et al. | Aug 2008 | B2 |
| 7418673 | Oh | Aug 2008 | B2 |
| 7424024 | Chen et al. | Sep 2008 | B2 |
| 7430753 | Gray et al. | Sep 2008 | B2 |
| 7437158 | Russell | Oct 2008 | B2 |
| 7444388 | Svendsen | Oct 2008 | B1 |
| 7447815 | Weaver et al. | Nov 2008 | B2 |
| 7469283 | Eyal et al. | Dec 2008 | B2 |
| 7471988 | Smith et al. | Dec 2008 | B2 |
| 7474677 | Trott | Jan 2009 | B2 |
| 7477653 | Smith et al. | Jan 2009 | B2 |
| 7480746 | Simon et al. | Jan 2009 | B2 |
| 7483538 | McCarty et al. | Jan 2009 | B2 |
| 7502604 | Knox | Mar 2009 | B2 |
| 7505483 | Jeon et al. | Mar 2009 | B2 |
| 7508815 | Lapeyre et al. | Mar 2009 | B2 |
| 7519681 | Edwards et al. | Apr 2009 | B2 |
| 7519686 | Hong et al. | Apr 2009 | B2 |
| 7532862 | Cheshire | May 2009 | B2 |
| 7539777 | Aitken | May 2009 | B1 |
| 7542784 | Passier et al. | Jun 2009 | B2 |
| 7543245 | Irimajiri | Jun 2009 | B2 |
| 7555291 | Waessingbo | Jun 2009 | B2 |
| 7561215 | Kim et al. | Jul 2009 | B2 |
| 7577261 | Liu et al. | Aug 2009 | B2 |
| 7606570 | Karaoguz et al. | Oct 2009 | B2 |
| 7617513 | McCafferty et al. | Nov 2009 | B2 |
| 7620011 | Kim et al. | Nov 2009 | B2 |
| 7627343 | Fadell et al. | Dec 2009 | B2 |
| 7634227 | De Jong | Dec 2009 | B2 |
| 7647346 | Silverman et al. | Jan 2010 | B2 |
| 7650470 | Poo | Jan 2010 | B2 |
| 7657706 | Iyer et al. | Feb 2010 | B2 |
| 7680849 | Heller et al. | Mar 2010 | B2 |
| 7689095 | Sugiyama et al. | Mar 2010 | B2 |
| 7698297 | Jawa et al. | Apr 2010 | B2 |
| 7698723 | Hicks et al. | Apr 2010 | B2 |
| 7706901 | Berreth | Apr 2010 | B2 |
| 7724780 | Baird et al. | May 2010 | B2 |
| 7725912 | Margulis | May 2010 | B2 |
| 7734688 | Langdon | Jun 2010 | B2 |
| 7765326 | Robbin et al. | Jul 2010 | B2 |
| 7769903 | Robbin et al. | Aug 2010 | B2 |
| 7797446 | Heller et al. | Sep 2010 | B2 |
| 7821574 | Black | Oct 2010 | B2 |
| 7827259 | Heller et al. | Nov 2010 | B2 |
| 7853341 | McCarty et al. | Dec 2010 | B2 |
| 7890661 | Spurgat et al. | Feb 2011 | B2 |
| 7899915 | Reisman | Mar 2011 | B2 |
| 7903690 | Wakid | Mar 2011 | B2 |
| 7950037 | Mensch | May 2011 | B2 |
| 7996505 | Krantz et al. | Aug 2011 | B2 |
| 8037220 | Moore et al. | Oct 2011 | B2 |
| 8041438 | Batson et al. | Oct 2011 | B2 |
| 8169938 | Duchscher et al. | May 2012 | B2 |
| 8171177 | Rostaing et al. | May 2012 | B2 |
| 8184657 | Dacosta | May 2012 | B2 |
| 8185674 | Moore et al. | May 2012 | B2 |
| 8214447 | Deslippe et al. | Jul 2012 | B2 |
| 8266657 | Margulis | Sep 2012 | B2 |
| 8284739 | Doyle et al. | Oct 2012 | B2 |
| 8285727 | Weber et al. | Oct 2012 | B2 |
| 8374087 | Dacosta | Feb 2013 | B2 |
| 8423893 | Ramsay et al. | Apr 2013 | B2 |
| 8443038 | Robbin et al. | May 2013 | B2 |
| 8539533 | Caspi et al. | Sep 2013 | B2 |
| 8689036 | Millington et al. | Apr 2014 | B2 |
| 8797926 | Kearney et al. | Aug 2014 | B2 |
| 8918541 | Morrison et al. | Dec 2014 | B2 |
| 8957972 | Gluskin et al. | Feb 2015 | B2 |
| 9182777 | Millington | Nov 2015 | B2 |
| 9189011 | Millington | Nov 2015 | B2 |
| 9195258 | Millington | Nov 2015 | B2 |
| 9207905 | Millington | Dec 2015 | B2 |
| 9389745 | Leatham | Jul 2016 | B1 |
| 9417689 | Ramaswamy | Aug 2016 | B1 |
| 9448683 | Robbin et al. | Sep 2016 | B2 |
| 9729630 | Bradley et al. | Aug 2017 | B2 |
| 9763018 | McPherson et al. | Sep 2017 | B1 |
| 9826012 | Hao et al. | Nov 2017 | B2 |
| 10209953 | Millington | Feb 2019 | B2 |
| 10362346 | Mayalil et al. | Jul 2019 | B2 |
| 10439896 | Millington et al. | Oct 2019 | B2 |
| 20010004310 | Kono | Jun 2001 | A1 |
| 20010008535 | Lanigan | Jul 2001 | A1 |
| 20010011308 | Clark et al. | Aug 2001 | A1 |
| 20010018858 | Dwek | Sep 2001 | A1 |
| 20010021053 | Colbourne et al. | Sep 2001 | A1 |
| 20010021305 | Sugiyama et al. | Sep 2001 | A1 |
| 20010021998 | Margulis | Sep 2001 | A1 |
| 20010041021 | Boyle et al. | Nov 2001 | A1 |
| 20010044835 | Schober et al. | Nov 2001 | A1 |
| 20010048642 | Berhan | Dec 2001 | A1 |
| 20010052123 | Kawai | Dec 2001 | A1 |
| 20020002413 | Tokue | Jan 2002 | A1 |
| 20020013784 | Swanson | Jan 2002 | A1 |
| 20020013852 | Janik | Jan 2002 | A1 |
| 20020013853 | Baber et al. | Jan 2002 | A1 |
| 20020019984 | Rakib | Feb 2002 | A1 |
| 20020022453 | Balog et al. | Feb 2002 | A1 |
| 20020045960 | Phillips et al. | Apr 2002 | A1 |
| 20020046315 | Miller et al. | Apr 2002 | A1 |
| 20020055934 | Lipscomb et al. | May 2002 | A1 |
| 20020073139 | Hawkins et al. | Jun 2002 | A1 |
| 20020074413 | Henzerling | Jun 2002 | A1 |
| 20020078075 | Colson et al. | Jun 2002 | A1 |
| 20020081098 | Scally | Jun 2002 | A1 |
| 20020095663 | Joory | Jul 2002 | A1 |
| 20020103554 | Coles et al. | Aug 2002 | A1 |
| 20020113824 | Myers | Aug 2002 | A1 |
| 20020116082 | Gudorf | Aug 2002 | A1 |
| 20020118848 | Karpenstein | Aug 2002 | A1 |
| 20020133515 | Kagle et al. | Sep 2002 | A1 |
| 20020133824 | Mensch | Sep 2002 | A1 |
| 20020138606 | Robison | Sep 2002 | A1 |
| 20020156921 | Dutta et al. | Oct 2002 | A1 |
| 20020161865 | Nguyen | Oct 2002 | A1 |
| 20020164973 | Janik et al. | Nov 2002 | A1 |
| 20020174243 | Spurgat et al. | Nov 2002 | A1 |
| 20020174269 | Spurgat et al. | Nov 2002 | A1 |
| 20020194309 | Carter et al. | Dec 2002 | A1 |
| 20020196912 | Norris | Dec 2002 | A1 |
| 20030013332 | Lin | Jan 2003 | A1 |
| 20030013492 | Bokhari et al. | Jan 2003 | A1 |
| 20030013493 | Irimajiri et al. | Jan 2003 | A1 |
| 20030030733 | Seaman et al. | Feb 2003 | A1 |
| 20030037254 | Fischer et al. | Feb 2003 | A1 |
| 20030045955 | Janik | Mar 2003 | A1 |
| 20030046434 | Flanagin et al. | Mar 2003 | A1 |
| 20030050058 | Walsh et al. | Mar 2003 | A1 |
| 20030065802 | Vitikainen et al. | Apr 2003 | A1 |
| 20030074457 | Kluth | Apr 2003 | A1 |
| 20030076301 | Tsuk et al. | Apr 2003 | A1 |
| 20030079038 | Robbin et al. | Apr 2003 | A1 |
| 20030083954 | Namba | May 2003 | A1 |
| 20030097379 | Ireton | May 2003 | A1 |
| 20030112279 | Irimajiri | Jun 2003 | A1 |
| 20030120742 | Ohgami et al. | Jun 2003 | A1 |
| 20030131360 | Joung et al. | Jul 2003 | A1 |
| 20030134589 | Oba | Jul 2003 | A1 |
| 20030158737 | Csicsatka | Aug 2003 | A1 |
| 20030167318 | Robbin et al. | Sep 2003 | A1 |
| 20030181203 | Cheshire | Sep 2003 | A1 |
| 20030182315 | Plastina et al. | Sep 2003 | A1 |
| 20030191756 | Oh | Oct 2003 | A1 |
| 20030197725 | Tuli | Oct 2003 | A1 |
| 20030210821 | Yogeshwar et al. | Nov 2003 | A1 |
| 20030221161 | Balassanian et al. | Nov 2003 | A1 |
| 20030221541 | Platt | Dec 2003 | A1 |
| 20030229900 | Reisman | Dec 2003 | A1 |
| 20040001395 | Keller et al. | Jan 2004 | A1 |
| 20040001396 | Keller et al. | Jan 2004 | A1 |
| 20040001494 | Barrack et al. | Jan 2004 | A1 |
| 20040003151 | Bateman et al. | Jan 2004 | A1 |
| 20040004338 | Jung | Jan 2004 | A1 |
| 20040017997 | Cowgill | Jan 2004 | A1 |
| 20040027930 | Kudo | Feb 2004 | A1 |
| 20040031058 | Reisman | Feb 2004 | A1 |
| 20040045030 | Reynolds et al. | Mar 2004 | A1 |
| 20040055446 | Robbin et al. | Mar 2004 | A1 |
| 20040057446 | Varsa et al. | Mar 2004 | A1 |
| 20040068536 | Demers et al. | Apr 2004 | A1 |
| 20040072584 | Kern | Apr 2004 | A1 |
| 20040076086 | Keller et al. | Apr 2004 | A1 |
| 20040078416 | Kawasaki et al. | Apr 2004 | A1 |
| 20040128198 | Register et al. | Jul 2004 | A1 |
| 20040128402 | Weaver et al. | Jul 2004 | A1 |
| 20040132510 | Yamashita | Jul 2004 | A1 |
| 20040133908 | Smith et al. | Jul 2004 | A1 |
| 20040139180 | White et al. | Jul 2004 | A1 |
| 20040139233 | Kellerman et al. | Jul 2004 | A1 |
| 20040139844 | Tsuboi | Jul 2004 | A1 |
| 20040143442 | Knight | Jul 2004 | A1 |
| 20040157548 | Eyer | Aug 2004 | A1 |
| 20040174896 | Caspi et al. | Sep 2004 | A1 |
| 20040177063 | Weber et al. | Sep 2004 | A1 |
| 20040177371 | Caspi et al. | Sep 2004 | A1 |
| 20040177377 | Lin et al. | Sep 2004 | A1 |
| 20040179540 | Lee et al. | Sep 2004 | A1 |
| 20040193900 | Nair | Sep 2004 | A1 |
| 20040215611 | Jawa et al. | Oct 2004 | A1 |
| 20040215810 | Tan et al. | Oct 2004 | A1 |
| 20040216108 | Robbin | Oct 2004 | A1 |
| 20040220926 | Lamkin | Nov 2004 | A1 |
| 20040221088 | Lisitsa et al. | Nov 2004 | A1 |
| 20040223622 | Lindemann et al. | Nov 2004 | A1 |
| 20040225762 | Poo | Nov 2004 | A1 |
| 20040234088 | McCarty et al. | Nov 2004 | A1 |
| 20040236568 | Guillen et al. | Nov 2004 | A1 |
| 20040242224 | Janik et al. | Dec 2004 | A1 |
| 20040250273 | Swix et al. | Dec 2004 | A1 |
| 20040252604 | Johnson et al. | Dec 2004 | A1 |
| 20040255326 | Hicks et al. | Dec 2004 | A1 |
| 20040261040 | Radcliffe et al. | Dec 2004 | A1 |
| 20040261112 | Hicks et al. | Dec 2004 | A1 |
| 20040267825 | Novak et al. | Dec 2004 | A1 |
| 20050010616 | Burks | Jan 2005 | A1 |
| 20050055444 | Venkatasubramanian | Mar 2005 | A1 |
| 20050071375 | Houghton et al. | Mar 2005 | A1 |
| 20050080915 | Shoemaker et al. | Apr 2005 | A1 |
| 20050089052 | Chen et al. | Apr 2005 | A1 |
| 20050147130 | Hurwitz et al. | Jul 2005 | A1 |
| 20050174488 | Chennakeshu | Aug 2005 | A1 |
| 20050201360 | Redstone | Sep 2005 | A1 |
| 20050201398 | Naik et al. | Sep 2005 | A1 |
| 20050207726 | Chen | Sep 2005 | A1 |
| 20050210101 | Janik | Sep 2005 | A1 |
| 20050226233 | Kryuchkov et al. | Oct 2005 | A1 |
| 20050235015 | Abanami et al. | Oct 2005 | A1 |
| 20050235048 | Costa-Requena et al. | Oct 2005 | A1 |
| 20050240494 | Cue et al. | Oct 2005 | A1 |
| 20050240661 | Heller et al. | Oct 2005 | A1 |
| 20050240745 | Iyer et al. | Oct 2005 | A1 |
| 20050254447 | Miller-Smith | Nov 2005 | A1 |
| 20050262528 | Herley et al. | Nov 2005 | A1 |
| 20050265316 | Liu et al. | Dec 2005 | A1 |
| 20050273790 | Kearney et al. | Dec 2005 | A1 |
| 20050289224 | Deslippe et al. | Dec 2005 | A1 |
| 20060007943 | Fellman | Jan 2006 | A1 |
| 20060015580 | Gabriel et al. | Jan 2006 | A1 |
| 20060027080 | Schultz | Feb 2006 | A1 |
| 20060030961 | Lin | Feb 2006 | A1 |
| 20060062242 | Dacosta | Mar 2006 | A1 |
| 20060062243 | Dacosta | Mar 2006 | A1 |
| 20060067463 | Hack et al. | Mar 2006 | A1 |
| 20060069724 | Langdon | Mar 2006 | A1 |
| 20060074637 | Berreth | Apr 2006 | A1 |
| 20060083194 | Dhrimaj et al. | Apr 2006 | A1 |
| 20060090202 | Liu et al. | Apr 2006 | A1 |
| 20060092844 | Jeon et al. | May 2006 | A1 |
| 20060100978 | Heller et al. | May 2006 | A1 |
| 20060106806 | Sperling et al. | May 2006 | A1 |
| 20060117371 | Margulis | Jun 2006 | A1 |
| 20060126667 | Smith et al. | Jun 2006 | A1 |
| 20060143455 | Gitzinger | Jun 2006 | A1 |
| 20060159109 | Lamkin et al. | Jul 2006 | A1 |
| 20060167982 | Jawa et al. | Jul 2006 | A1 |
| 20060168340 | Heller et al. | Jul 2006 | A1 |
| 20060168351 | Ng et al. | Jul 2006 | A1 |
| 20060224620 | Silverman et al. | Oct 2006 | A1 |
| 20060245451 | Wakid | Nov 2006 | A1 |
| 20060253279 | Sung | Nov 2006 | A1 |
| 20060274747 | Duchscher et al. | Dec 2006 | A1 |
| 20060277216 | Shukhman | Dec 2006 | A1 |
| 20060288057 | Collins et al. | Dec 2006 | A1 |
| 20070033052 | Cowgill | Feb 2007 | A1 |
| 20070038941 | Wysocki et al. | Feb 2007 | A1 |
| 20070067309 | Klein et al. | Mar 2007 | A1 |
| 20070067808 | Dacosta | Mar 2007 | A1 |
| 20070073723 | Ramer et al. | Mar 2007 | A1 |
| 20070073728 | Klein et al. | Mar 2007 | A1 |
| 20070074118 | Robbin et al. | Mar 2007 | A1 |
| 20070084333 | Robbin et al. | Apr 2007 | A1 |
| 20070088727 | Kindig | Apr 2007 | A1 |
| 20070088764 | Yoon et al. | Apr 2007 | A1 |
| 20070110074 | Bradley et al. | May 2007 | A1 |
| 20070124680 | Robbin et al. | May 2007 | A1 |
| 20070130541 | Louch et al. | Jun 2007 | A1 |
| 20070169115 | Ko et al. | Jul 2007 | A1 |
| 20070185919 | Kaplan et al. | Aug 2007 | A1 |
| 20070203954 | Vargas et al. | Aug 2007 | A1 |
| 20070220552 | Juster et al. | Sep 2007 | A1 |
| 20070250761 | Bradley et al. | Oct 2007 | A1 |
| 20070271312 | Heller et al. | Nov 2007 | A1 |
| 20070291323 | Roncal | Dec 2007 | A1 |
| 20080018927 | Martin et al. | Jan 2008 | A1 |
| 20080028008 | Brunet et al. | Jan 2008 | A1 |
| 20080040758 | Beetcher et al. | Feb 2008 | A1 |
| 20080065247 | Igoe | Mar 2008 | A1 |
| 20080086494 | Heller et al. | Apr 2008 | A1 |
| 20080164581 | Cho et al. | Jul 2008 | A1 |
| 20080168185 | Robbin et al. | Jul 2008 | A1 |
| 20080168245 | De et al. | Jul 2008 | A1 |
| 20080168391 | Robbin et al. | Jul 2008 | A1 |
| 20080168525 | Heller et al. | Jul 2008 | A1 |
| 20080168526 | Robbin et al. | Jul 2008 | A1 |
| 20080229335 | Robbin et al. | Sep 2008 | A1 |
| 20090006671 | Batson et al. | Jan 2009 | A1 |
| 20090172200 | Morrison et al. | Jul 2009 | A1 |
| 20090290725 | Huang | Nov 2009 | A1 |
| 20100309962 | Freundlich et al. | Dec 2010 | A1 |
| 20110210820 | Talty et al. | Sep 2011 | A1 |
| 20110264732 | Robbin et al. | Oct 2011 | A1 |
| 20120180093 | Ishihara et al. | Jul 2012 | A1 |
| 20130058593 | Kanalakis et al. | Mar 2013 | A1 |
| 20130174208 | Lee et al. | Jul 2013 | A1 |
| 20130311694 | Bhamidipati et al. | Nov 2013 | A1 |
| 20140006946 | Robbin et al. | Jan 2014 | A1 |
| 20140006947 | Garmark et al. | Jan 2014 | A1 |
| 20140037097 | Labosco | Feb 2014 | A1 |
| 20140096165 | Bei et al. | Apr 2014 | A1 |
| 20140178028 | Park et al. | Jun 2014 | A1 |
| 20140244863 | Bradley et al. | Aug 2014 | A1 |
| 20140250219 | Hwang | Sep 2014 | A1 |
| 20140307585 | Kearney et al. | Oct 2014 | A1 |
| 20140351876 | Kano | Nov 2014 | A1 |
| 20140380167 | Bloch et al. | Dec 2014 | A1 |
| 20150181286 | Gonzalez | Jun 2015 | A1 |
| 20150373401 | Kwon et al. | Dec 2015 | A1 |
| 20160044367 | Matsubara et al. | Feb 2016 | A1 |
| 20160066184 | Bhargav-Spantzel et al. | Mar 2016 | A1 |
| 20160073197 | Hammer et al. | Mar 2016 | A1 |
| 20160198198 | Iwami et al. | Jul 2016 | A1 |
| 20160219329 | Jee et al. | Jul 2016 | A1 |
| 20160255391 | Noble | Sep 2016 | A1 |
| 20160342378 | Coburn | Nov 2016 | A1 |
| 20170019443 | Conan et al. | Jan 2017 | A1 |
| 20170054774 | Robbin et al. | Feb 2017 | A1 |
| 20170242653 | Lang et al. | Aug 2017 | A1 |
| 20170242656 | Plagge et al. | Aug 2017 | A1 |
| 20170269900 | Triplett | Sep 2017 | A1 |
| 20180049146 | Daley et al. | Feb 2018 | A1 |
| 20180070122 | Baek et al. | Mar 2018 | A1 |
| 20180167373 | Anderson et al. | Jun 2018 | A1 |
| Number | Date | Country |
|---|---|---|
| 106465057 | Feb 2017 | CN |
| 0146334 | Jun 1985 | EP |
| 0830026 | Mar 1998 | EP |
| 0917077 | May 1999 | EP |
| 0982732 | Mar 2000 | EP |
| 1028425 | Aug 2000 | EP |
| 1112931 | Jul 2001 | EP |
| 1122931 | Aug 2001 | EP |
| 1143719 | Oct 2001 | EP |
| 1353269 | Oct 2003 | EP |
| 1408427 | Apr 2004 | EP |
| 1429569 | Jun 2004 | EP |
| 1463334 | Sep 2004 | EP |
| 1523171 | Apr 2005 | EP |
| 1548740 | Jun 2005 | EP |
| 1751949 | Feb 2007 | EP |
| 2360887 | Aug 2011 | EP |
| 2375678 | Oct 2011 | EP |
| 2000-339917 | Dec 2000 | JP |
| 2001-093226 | Apr 2001 | JP |
| 2001-117800 | Apr 2001 | JP |
| 2003-077214 | Mar 2003 | JP |
| 2003-303137 | Oct 2003 | JP |
| 2003-319485 | Nov 2003 | JP |
| 10-2001-0063284 | Jul 2001 | KR |
| 10-2001-0079176 | Aug 2001 | KR |
| 10-2002-0001127 | Jan 2002 | KR |
| 10-2002-0011027 | Feb 2002 | KR |
| 10-2006-0035634 | Apr 2006 | KR |
| 10-0599204 | Jul 2006 | KR |
| 9408337 | Apr 1994 | WO |
| 9516950 | Jun 1995 | WO |
| 0016533 | Mar 2000 | WO |
| 0043914 | Jul 2000 | WO |
| 0126374 | Apr 2001 | WO |
| 0133569 | May 2001 | WO |
| 0167753 | Sep 2001 | WO |
| 0225610 | Mar 2002 | WO |
| 0225935 | Mar 2002 | WO |
| 0265723 | Aug 2002 | WO |
| 0265732 | Aug 2002 | WO |
| 2003009601 | Jan 2003 | WO |
| 2003023786 | Mar 2003 | WO |
| 0338637 | May 2003 | WO |
| 2003036541 | May 2003 | WO |
| 2004004338 | Jan 2004 | WO |
| 2004034286 | Apr 2004 | WO |
| 2004057474 | Jul 2004 | WO |
| 2004084413 | Sep 2004 | WO |
| 2005060387 | Jul 2005 | WO |
| 2005114472 | Dec 2005 | WO |
| 2005122531 | Dec 2005 | WO |
| 2006007322 | Jan 2006 | WO |
| 2006047578 | May 2006 | WO |
| 2007079360 | Jul 2007 | WO |
| 2007079334 | Aug 2007 | WO |
| 2008033771 | Mar 2008 | WO |
| Entry |
|---|
| Compaq Computer Corp., “Personal Jukebox,” 2 pgs, Jan. 24, 2001 (downloaded from http://research.compaq.com/SRC/pjb/). |
| Clifton, David, pipe.c, A Kla2 Module, 2003, 10 pages. Retrieved on Oct. 17, 2011 from http://www.codelode.com/Kernel/k1a2pepec.html. |
| Clifton, “Pipe.c, A Kla2 Module,” 8 pgs, 2003 (retrieved Oct. 17, 2011 from http://www.codelode.com/Kernel/k1a2pepec.html, downloaded Apr. 18, 2012 from http://web.archive.org/2004010719482/http://www.codelode.com/Ke- rnel/kla2pipec . . . ). |
| Butler, “Portable MP3: The Nomad Jukebox,” Aug. 1, 2001 (http:lldb.tidbits.com/getbits.acgi? tbart=06261, downloaded Jul. 13, 2011 from http://www.tidbits.com/article/6261). |
| Butler, “Archos Jukebox 6000 Challenges Nomad Jukebox,” 6 pgs, Aug. 13, 2001 (from http://db.tidbits.com/getbits.acgi?tbart=06521 (downloaded Jul. 13, 2011 from http://www.tidbits.com/article/6521?printversion=1). |
| Bridgman, “Windows XP Expert Zone Community Columnist”, Using Windows Mobile-based Portable Media Centers and Windows Media Player 10, Aug. 25, 2004, 1-11. (U.S. Appl. No. 11/519,429). |
| Bott, “Special Edition Using Microsoft 1-18 Windows Millennium Passage”, Special Edition Using Microsoft Windows Millennium Edition, Nov. 3, 2000, pp. 1-24. (U.S. Appl. No. 11/519,429). |
| Awbrey, “Apple's iPod Available in Stores Tomorrow,” Press Release, Nov. 9, 2001 (downloaded Jul. 14, 2011 from http://www.apple.com/pr/library/2001/11/09Apple-s-iPod-Available). |
| Apple, “Mac OS X: Bonjour,” Technology Brief, Apr. 2005, 6-pgs. |
| Apple, “AirPort Express,” Technology Overview, Jul. 2004, 31-pgs. |
| Apple Introduces iTunes—World's Best and Easiest to Use Jukebox Software, Macworld Expo, San Francisco, Jan. 9, 2011 [.about.2 pages Downloaded on Jul. 14, 2011 at http://www.apple.com/pr/library/2001/01/09Apple-Introduces-iTunes-Worlds- Best and Ea . . . ] (U.S. Appl. No. 11/519,429). |
| Apple Inc., “iTunes, Playlist Related Help Screens,” iTunes v1.0, 8 pgs, Jan. 2001. |
| Apple Inc., “iTunes, Digital Music for your Mac,” 2 pgs (downloaded Oct. 22, 2001 from http://www.apple.com/itunes/). |
| Apple Inc., “iTunes 2, Digital Music for the Mac,” Specification Sheet, 2 pgs, Oct. 2001. |
| Apple Inc., “Apple-Downloads-Dashboard,” 1 pg (downloaded Apr. 2016 from http://www.apple.com/downloads/dashboard). |
| Apple Inc., “Apple-Downloads-Dashboard”, http://www.apple.com/downloads/dashboard, downloaded Dec. 16, 2008, pp. 102 (U.S. Appl. No. 11/519,429). |
| Apple Inc., “Apple Announces iTunes 2,” Press Release, 2 pgs, Oct. 23, 2001 (downloaded from http://www.apple.com/pr/library/2001/10/23Appl e-Announces-iTunes-2.html). |
| Apple Inc. “Apple Introduces iTunes—World's Best and Easiest to Use Jukebox Software,” MacWorld Expo, San Francisco, 2 pgs, Jan. 9, 2001 (https://www.apple.com/pr/library/2001/01/09Apple-Introduces-iTunes-Worlds-Best-and-Easiest- To-Use-Jukebox-S. |
| Andy Lindauer, “What's in you Pocket?,” Edgereview, downloaded Jan. 25, 2002, http://www.edgereview.com/print.cfm?Type+aag&ID=286 (U.S. Appl. No. 11/519,429). |
| Andrew Birrell, “Personal Jukebox (PJB),” Oct. 13, 2000 available from http://birrell.org/andrew/talks/pjb-overview.ppt. (U.S. Appl. No. 11/519,429). |
| Alicia Awbrey, press release entitled “Apple's iPod Available in Stores Tomorrow,” Nov. 9, 2001 [downloaded Jul. 14, 2011 at http://www.apple.com/pr/library/2001/11/09Apple-s-iPod-Available] (U.S. Appl. No. 11/519,429). |
| Adam C. Engst. “SoundJam Keeps on Jammin'.” Jun. 19, 2000, available from http://db.tidbits.com/getbits.acgi?tbart=05988. downloaded Jul. 25, 2011 at http?..db.tidbits.com/article/5988?print?version+1 (U.S. Appl. No. 11/519,429). |
| AccelerateYourMac.com, Apple posts Automated Scripts for iTunes 2.03, 9 pgs, 2001 (downloaded Apr. 11, 2012 from http://www.x1r8yourmac.com/archive/dec01/121801.html). |
| About MusicMatch Jukebox, MusicMatch Jukebox v4 Help. pp. 1-4, (1999) (U.S. Appl. No. 11/519,429). |
| Zheng et al., “MobiGATE: a mobile gateway proxy for the active deployment of transport entities,” Proceedings of the 2004 International Conference on Parallel Processing, Piscataway, NJ, Aug. 15, 2004 pp. 1-8 from IEEE on Jul. 2011 (U.S. Appl. No. 11/519,429). |
| Window's Media Player 6.4, Microsoft Corp., copyright 1999, software available at http://www.oldversion.com/program.php?n=wmp [.about.Downloaded Jul. 13, 2011 at: http://www.microsoft.com/download.en/confirmation.axps?displaylang-en&id=- 22758] (U.S. Appl. No. 11/519,429). |
| Wikipedia: “iTunes”, www.wikipedia.com, May 9, 2005, 6 pages. (U.S. Appl. No. 11/519,429). |
| Wikipedia, “IEEE 1394,” 13 pgs (Firewire and also known as Sony's iLink) (downloaded from https://en.wikipedia.org/wiki/IEEE.sub.-1394). |
| WebReviews.com, “Rio Portable Music Player,” 2 pgs, 1999 (downloaded Jan. 25, 2002 from download http://www.webreviews.com/9901/rio.html). |
| Vetro et al., “Media Conversions to Support Mobile Users,” IEEE Canadian Conference on Electrical and Computer Engineering, Piscataway, NJ, May 13, 2001, pp. 606-612 pp. 1-6 from IEEE on Jul. 2011 (U.S. Appl. No. 11/519,429). |
| TuneBase Pro Mk-II User's Guide, Escient, Inc., (1999) Downloaded Jul. 25, 2011 (U.S. Appl. No. 11/519,429). |
| TuneBase 100 User Guide, A CD Library Management System, Escient, Inc. copyright 1999. (101 Pages) (U.S. Appl. No. 11/519,429). |
| Travis Butler, “Portable MP3: The Nomad Jukebox,” Aug. 1, 2001, available from http://db.tidbits.com/getbits.acgi?tbart=06261. downloaded Jul. 13, 2011 at http://www.tidbits.com/article/6261 (U.S. Appl. No. 11/519,429). |
| Travis Butler, “Archos Jukebox 6000 Challenges Nomad Jukebox,” Aug. 13, 2001, available from http://db.tidbits.com/getbits.acgi?tbart=06521—Downloaded Jul. 13, 2011 @ http://www.tidbits.com/article/6521?printversion=1 (U.S. Appl. No. 11/519,429). |
| Top Stores of Dec. 18, 2001: Apple posts Automated Scripts for iTunes 2.03. downloaded 9 pages on Apr. 11, 2012 from the internet at: http://www.xlr8yourmac.com/archive/dec01/121801.html (U.S. Appl. No. 11/519,429). |
| Titmus, Richard, “Softsqueeze 2.0”, obtained from http://softsqueeze.sourceforge.net!, generated Jun. 8, 2006, copyright 2004, 2005, 3 pgs. |
| Stewart et al., “Request for Comments: 3758,” Network Working Group, May 2004, 22-pgs. |
| Steinberg, “Sonicblue Rio Car,” Product Review, Dec. 12, 2000, http://electronics.cnet.com/electronics/0-6342420-1304-4098389.html. (U.S. Appl. No. 11/519,429). |
| SoundJam MP Plus, Representative Screens, published by Cassady & Greene, Inc., Salinas, CA 2000. (U.S. Appl. No. 11/519,429). |
| SoundJam MP Plus Manual, version 2.0—MP3 Player and Encoder for Macintosh by Jeffrey Robbin, Bill Kincaid and Dave Heller, manual by Tom Negrino, published by Casady & Greene, Inc. 2000. 80 pages (U.S. Appl. No. 11/519,429). |
| snarfed.org, “libmsntp,” obtained from http://snarfed.org/space/libmsntp, generated Jun. 8, 2006, undated, 2-pgs. |
| snarfed.org, “History of Synchronizing mp3 playback,” http://snarfed.org/exec/history?name=synchronizing+mp3+playback, generated Jun. 8, 2006, 2 pgs. |
| Slim Devices. Inc. “Slim Devices: Support: FAQ.” obtained from http://www.slimdevices.com/su_faq.html. generated Jun. 21, 2006. copyright 2002-2006. 31-pgs. |
| Slim Devices. Inc. “Slim Devices: Squeezebox: Overview.” obtained from http://www.slimdevices.com/pi_overview.html. generated Jun. 21, 2006. copyright 2002-2006. 3-pgs. |
| Slim Devices. Inc. “Slim Devices: Squeezebox: Free Your Music.” obtained from http://www.slimdevices.com/index.html. generated Jun. 8, 2006. copyright 2002-2005. 2-pgs. |
| Slim Devices, Inc., “Squeezebox: Owner's Guide,” copyright 2006, 32-pgs. |
| Slim Devices, Inc., “Squeezebox 2: Owners Guide,” copyright 2005, 28-pgs. |
| Slim Devices, Inc., “Slim Devices: Squeezebox: Free Your Music.,” obtained from http://www.slimdevices.com/index.html, generated Jun. 8, 2006, copyright 2002-2004, 1-pg. |
| Slim Devices, Inc., “Slim Devices: Squeezebos: Overview,” http://www.slimdevices.com/pi_overview.html, generated Jun. 21, 2006, copyright 2002-2006, 3 pgs. |
| Slim Devices, Inc. “Slim Devices: Support: FAQ,” obtained from http://www.slimdevices.com/su.sub.-faq.html, generated Jun. 21, 2006, copyright 2002-2005, 31 pgs. |
| Slim Devices, Inc. “Slim Devices: Squeezebox: Overview” obtained from http:www.slimdevices.com/pi.sub.--overview.html, generated Jun. 21, 2006, copyright 2002-0226, 3 pgs. |
| Skarlatos et al., “Sprite Backup 5.0”, Internet Publication, Mar. 6, 2005 (downloaded www.pocketnow.com/index.php?a+portal print&t=review&id=788). |
| Sinitsyn, “A Synchronization Framework for Personal Mobil Servers,” Proceedings of the Second IEEE Annual Conference on Pervasive Computing and communications Workshops, Piscataway, NJ, Mar. 14, 2004, pp. 1-4 5 pages retrieved from IEEE on Jul. 2011 (U.S. Appl. No. 11/519,429). |
| Shulzrinne et al., “Request for Comments: 3550,” Network Working Group, Jul. 2003, 104-pgs. |
| Shulzrinne et al., “Request for Comments: 2326,” Network Working Group, Apr. 1998, 92-pgs. |
| Schulzrinne Comumbia U A RAO Netscape R Lanphier RealNetworks H: “Real Time Streaming Protocol (RTSP)” IETF Standard, Internet Engineering Task Force, IETF, CH, Apr. |
| Rosenberg, J. et al., “SIP: Session Initiation Protocol”, Jun. 1, 2002; 20020600, Jun. 1, 2001, Retrieved from ftp://frp-editor.org/in-notes/rfc3261.txt on Aug. 18, 2011, 232 pages. |
| Robbin et al., “SoundJam MP Plus Digital Audio System Version 2,” Representative Screens, published by Cassady & Greene, Inc., Salinas, CA, 6 pgs, 2000. |
| Rio Portable Music Player, Web Review, downloaded Jan. 25, 2002, http://www.webreviews.com/9901/rio.html. (U.S. Appl. No. 11/519,429). |
| Replay Gain, “Replay Gain—A proposed Standard,” Oct. 7, 2001 (downloaded from http://replaygain.hydrogenaudio.org/index.html and http://replaygain.hydrogenaudio.orgioutline.html). |
| Real Networks, Inc., “RealJukebox Plus Manual,” pp. 1-83, 1999 (downloaded Oct. 27, 2005 http://www.real.com/Jukebox/release notes.html#). |
| RCA, “Lyra User's Guide,” RD2201/2202/2204, www.lyrazone.com, pp. 1-37, 1999. |
| Pocket Tunes 5.0.0. copyright 2002-2009 Normsoft, Inc., (pp. 1-25, obtained from the Internet at: http://www.pocket-tunes.com/userguide/en.win)—[Downloaded 18 pages on Apr. 10, 2012 at http://www.pocket-tunes.com/userguide/en/) (U.S. Appl. No. 11/519,429). |
| Pocket PC Phone User Manual, High Tech Computer Corp., 2006; 208 pages, Downloaded Jul. 2011 www.htc.com (U.S. Appl. No. 11/519,429). |
| Personal Jukebox (PJB), “Systems Research Center and PAAD,” Compaq Computer Corp., Oct. 13, 2000, http://research.compaq.com/SRC/pjb/. (U.S. Appl. No. 11/519,429). |
| Perkins, C., “RTP Audio and Video for the Internet, Chapter 5, RTP Control Protocol”, 2003, Addison-Wesley, Boston, USA, pp. 95-111. |
| Perfect guide for digital/audio technique to enjoy music in PC, Nobuya Fukuda, published in “Nikkei Click”, Japan, Nikkei business Publications, Inc., Sep. 8, 1999, vol. 6/No. 10, p. 169. (U.S. Appl. No. 11/519,429). |
| Palm, Inc., “Handbook for PalmTM m500 Series Handhelds, User Manual,” 109 pgs. |
| Palacharla, S. et al., “Design and implementation of a Real-time Multimedia Presentation System using RTP”, Computer Software and Applications Conference, COMPSAC '97, Aug. 1997, pp. 376-381. |
| Palacharla, et al. “Design and Implementation of a Real-time Multimedia Presentation System using RTP;” Computer Software and Applications Conference; Aug. 13, 1997; pp. 376-381. |
| Nutzel et al., “Sharing System for Future HiFi Systems”, Proceedings of the Fourth International Conference on Web Delivering of Music, Sep. 13, 2004, 8 pgs. [9 pages downloaded] (U.S. Appl. No. 11/519,429). |
| Nullsoft, “winamp.com / Plug-ins,” obtained from http://winamp.com/plugins/details.php?id=15667, generated Jun. 8, 2006, copyright 2006, 2 pgs. |
| NormSoft, Inc., “Pocket Tunes 5.0.0,” 18 pgs, 2009 (http://www.pocket-tunes.com/userguide/en.win, downloaded 18 pages on Apr. 10, 2012 from http://www.pocket-tunes.com/userguide/enl). |
| Nomad Jukebox, User Guide, Creative Technology Ltd., Version 1, Aug. 2000. [38 pages downloaded Aug. 16, 2011] (U.S. Appl. No. 11/519,429). |
| Nilsson, “IDS tag versions 2.4.0.—Main Structure,” 12 pgs, Nov. 1, 2000 (downloaded from http://www.id3.org/id3v2.4.0-structure?-action=print). |
| Nilsson, “ID3 tag version 2.3.0,” 30 pgs, Feb. 3, 1999 (downloaded from http://www.id3.org/id3v2.3.0?action=print). |
| Myradus, LLC, “Myradus Media Player Puppeteer for iTunes,” obtained from http://www.myradus.com/Product.sub.--MediaPlayerPuppeteerFrom.aspx, generated Jun. 8, 2006, copyright 2004-2005, 1 pg. |
| MusicMatch, “Musicmatch and Xing Technology Introduce Musicmatch Jukebox,” May 18, 1998 (http://www.musicmatch.com/info/company/press/rel eases/?year +1998& release=2, downloaded Aug. 16, 2011 from http://www.thefreelibrary.com/MusicMatch+and+Xing+Technolo). |
| MusicMatch, “About MusicMatch Jukebox,” MusicMatch Jukebox v4 Help, 4 pgs, 1999. |
| Miniman, “Applian Software's Replay Radio and Player v1.02,” Product review, pocketnow.com, http://www.pocketnow.com/review/replay.htm, Jul. 31, 2001. Downloaded Aug. 25, 2011 http://web/archive.org/web/20010805081914/http://www.pocketnow.com/review- s/reply/reply.HTM (U.S. Appl. No. 11/519,429). |
| Mills, David L., “Request for Comments: 1305,” Network Working Group, Mar. 1992, 113-pgs. |
| Microsoft Corp., “Window's Media Player 6.4,” 2 pgs, 1999 (software downloadable at http://www.oldversion.com/program php?n=wmp, downloaded Jul. 13, 2011 from http://www.microsoft.com/download/en/confirmation.axps?displaylangen&id=2- 2758). |
| MediaGate, “Portable MPEG4 Player (MG-25),” 3 pgs, Jul. 29, 2004. |
| McGavren, “iTunes-perl,” 2004-2006 (http://code.googlecom, 5 pgs (downloaded Jan. 13, 2012 from http://code.google.com/p/itunes-perl/wiki/ Usage). |
| Maulik, “Synchronizing mp3 playback, version #2,” obtained from http://snarfed.org/exec/version?name=synchronizing+mp3+playback&version=2, generated Jun. 8, 2006, version #2 dated Dec. 28, 2004 in history, 2-pgs. |
| Maulik, “Synchronizing mp3 playback, version #1,” obtained from http://snarfed.org/exec/version?name=synchronizing+mp3+playback&version=1-, generated Jun. 8, 2006, version #1 dated Nov. 8, 2004 in history, 2-pgs. |
| Maulik and Ryan. “Synchronizing mp3 playback. version #1” obtained from http://snarfed.org/exec/version?name=synchronizing+mp3+playback&version=3. generated Jun. 8, 2006. version #3 dated Jan. 2, 2005 in history. 3-pgs. |
| Maulik and Ryan, “Synchronizing mp3 playback, version #9,” http://snarfed.org/exec/version?name=synchronizing+mp3+playback&version=9, generated Jun. 8, 2006, version #4 dated Mar. 3, 2005 in history, 3 pgs. |
| Maulik and Ryan, “Synchronizing mp3 playback, version #8,” http://snarfed.org/exec/version?name=synchronizing+mp3+playback&version=8, generated Jun. 8, 2006, version #8 dated Feb. 23, 2005 in history, 3 pgs. |
| Maulik and Ryan, “Synchronizing mp3 playback, version #7,” http://snarfed.org/exec/version?name=synchronizing+mp3+playback&version=7, generated Jun. 8, 2006, version #7 dated Feb. 21, 2005 in history, 3 pgs. |
| Maulik and Ryan, “Synchronizing mp3 playback, version #6,” obtained from http://snarfed.org/exec/version?name=synchronizing+mp3+playback&version=6, generated Jun. 8, 2006, version #6 dated Feb. 2, 2005 in history, 3-pgs. |
| Maulik and Ryan, “Synchronizing mp3 playback, version #5,” obtained from http://snarfed.org/exec/version?name=synchronizing+mp3+playback&version=5, generated Jun. 8, 2006, version #5 dated Jan. 19, 2005 in history, 3-pgs. |
| Maulik and Ryan, “Synchronizing mp3 playback, version #4,” http://snarfed.org/exec/version?name=synchronizing+mp3+playback&version=4, generated Jun. 8, 2006, version #4 dated Jan. 3, 2005 in history, 3 pgs. |
| Maulik and Ryan, “Synchronizing mp3 playback, version #17,” http://snarfed.org/exec/version?name=synchronizing+mp3+playback&version=17, generated Jun. 8, 2006, version #17 dated Feb. 5, 2006 in history, 4 pgs. |
| Maulik and Ryan “Synchronizing mp3 playback, version#7,” obtainedfromhttp://snarfed.org/exec/Nersion?name-synchronizing+rp3hpiaybackuerllon7generated6/8/2006version#? datedFeb. 21, 2005nhistoy3pgs. |
| Linksys “New Linksys Wireless Home Products Showcased at CEBIT 2004” Internet Article (Mar. 18, 2004) www.broadbandbuyer.co.uk/Shop/pageTextDetail.asp?Setl0=2&Textl0=473. |
| Lindauer, “What's in Your Pocket?,” Edgereview, 2 pgs (downloaded Jan. 25, 2002 from http://www.edgereview.com/print.cfm?Type+aag&ID=286). |
| K*Software, “kquery.com,” obtained from http://www.kquery.com/index.php?page=software.sub.-info&subpage=1&id=8, generated Jun. 8, 2006, copyright 2004, 4-pgs. |
| iTunes-perl, copyright 2004-2006 by Jay McGavren, obtained from the Internet at http://code.googlecom, pp. 7. (downloaded 5 pages on Jan. 13, 2012 from http://code.google.com/p/itunes-perl/wiki/Usage) (U.S. Appl. No. 11/519,429). |
| iTunes, Playlist Related Help Screens, iTunes v1.0, Apple Computer, Inc., Jan. 2001 (U.S. Appl. No. 11/519,429). |
| iTunes, Digital Music for your Mac, Apple Computer, Inc., downloaded Oct. 22, 2011, http://www.apple.com/itunes/ (U.S. Appl. No. 11/519,429). |
| iTunes 2, Playlist Related Help Screens, iTunes v2.0 Apple Computer, Inc., Oct. 23, 2001 (U.S. Appl. No. 11/519,429). |
| Iriver, “PMP140/120”, Sep. 13, 2004, 1-2 pgs. (U.S. Appl. No. 11/519,429). |
| iPod +iTunes, Markt+Technik Verlag, 2007. (U.S. Appl. No. 11/519,429). |
| Interview Summary dated Nov. 1, 2010 for U.S. Appl. No. 11/306,557; 3 pages. |
| Interview Summary dated May 20, 2010 for U.S. Appl. No. 11/306,557; 3 pages. |
| Hughes, M., “Turning Streams Inside Out, Part 2: Optimizing internal Java 1/0”, Sep. 3, 2002, 12 pages. Retrieved on Oct. 19, 2011 from http://50001.com/language/javaside/lec/javaibm/%BD%BA%%C6%AE%B8%B2%20% . . . . |
| Hewlett Packard, “Hewlett Packard Jornada 525 Color Pocket PC,” (downloaded Jan. 25, 2002, http://www.pc4d.com/electronics/ products/56/jornada 525 color pocket pc.shtml). |
| Hei et al., “iPod+iTunes,” iTunes7, Markt+Technik Verlag, 54 pgs, Dec. 22, 2006 (German). |
| Harmony Central, “Diamond Multimedia Announces Rio PMP300 Portable MP3 Music Player”, Press Release, 4 pgs, Sep. 14, 1998 (http://news.harmony-central.com/Newp/1988/Rio- Pump300.html, downloaded Aug. 16, 2011 from http://web.archive.org/web/20030705005208/http:/. |
| Handbook for Palm.TM. m500 Series Handhelds,User Manual.—(286 pages) (U.S. Appl. No. 11/519,429). |
| Glenn Fleishman, “Handheld iPod joins MP3 band a bit late, but is standout player,” Nov. 6, 2001, http://seattletimes,nwsource.com/html/businesstechnology/134361811.sub.- ptmacc040.html. [Downloaded Jul. 21, 2011 from http://web.archive.org/...001110233639/http://seattletimes.nwsource.com/h-tml/businesstechnology/134361811.sub.--ptmacc040.html] (U.S. Appl. No. 11/519,429). |
| Fukuda, “Perfect Guide for Digital/Auio Technique to Enjoy Music in PC,” Nikkei Click, Japan, Nikkei Business Publications, Inc., vol. 6, No. 10, 1 pg, Sep. 8, 1999 (not attached herewith; a copy will be submitted with next IDS filing). |
| Firewire, IEEE 1394 (also known as Sony's iLink), (http://www.wikipedia.org/wiki/Firewire (1995)). Download Jul. 13, 2011—http://en.wikipedia.org/wiki/IEEE.sub.--1393.sub.-interface (U.S. Appl. No. 11/519,429). |
| Etchison, “Accelerated discrete Adjustment of the Parameters of a Process”, IBM Technical Disclosure Bulletin, vol. 15, No. 5, Oct. 1, 1972, 2 pgs. (U.S. Appl. No. 11/519,429). |
| Escient, Inc., “TuneBase Pro Mk-II User's Guide,” 1999 (downloaded Jul. 25, 2011) (not attached herewith; A copy will be submitted with next IDS filing). |
| Erdmann et al., “iPod+iTunes,” O'Reilly, 157 pgs, 2006 (German). |
| Engst, “SoundJam Keeps on Jammin',” Jun. 19, 2000, (http://db.tidbits.com/getbits.acgi? tbart=05988, downloaded Jul. 25, 2011 from http?..db.tidbits.com/article/5988?print version+1). |
| Digital Still Cameras—Downloading Images to a Computer, Mimi Chakarova et al., Multi-Media Reporting and Convergence, 2 pgs. (U.S. Appl. No. 11/519,429). |
| Diamond Multimedia Announces Rio PMP300 Portable MP3 Music Player, Press Release, http://news.harmony-central.com/Newp/1988/Rio-Pump300.html, Sep. 14, 1998, 4 pgs. Downloaded on Aug. 16, 2011—http://www.archive.org/web/20030705005208/http://news.harmony-centr-al.com/Newp/1998/Rio-PMP300/html (U.S. Appl. No. 11/519,429). |
| De Herrera, Chris, “Microsoft ActiveSync 3.1” Version 1.02, (Oct. 13, 2000 Downloaded Aug. 16, 2011 From http://www.pocketpcfaq.com/wce/activesync3.1.htm (U.S. Appl. No. 11/519,429). |
| D-Link's New Wireless Media Device Plays Digital Music, Videos, and Photos on Home Television and Stereo; Retrieved from URL:http://presslink.dlink.com/pr/?prid=136, dated Jan. 20, 2004; 2-pgs. |
| Compaq Computer Corp., copyright 1991, Personal Jukebox User Manual, pp. 1-29. (U.S. Appl. No. 11/519,429). |
| Compaq Computer Corp., “Systems Research Center and PAAD,” Personal Jukebox (PJB), 25 pgs, Oct. 13, 2000 (downloaded from http://research.compaq.com/SRC/pjb/; redownloaded Apr. 2016 from http://birrell.org/andrew/talks/pjb-overview.pdf). |
| Stenton, Stuart P., Richard Hull, Patrick M. Goddi, Josephine E. Reid, Ben JC Clayton, Tom J. Melamed, and Susie Wee.“Mediascapes: Context-aware multimedia experiences.” IEEE Multi Media 14, No. 3 (2007): 98-105. (Year: 2007). |
| Number | Date | Country | |
|---|---|---|---|
| 20190334985 A1 | Oct 2019 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15659603 | Jul 2017 | US |
| Child | 16295267 | US | |
| Parent | 14167742 | Jan 2014 | US |
| Child | 15659603 | US | |
| Parent | 11696679 | Apr 2007 | US |
| Child | 14167742 | US | |
| Parent | 11306557 | Jan 2006 | US |
| Child | 11696679 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10862115 | Jun 2004 | US |
| Child | 11306557 | US |
