Patent Application
20150009874
Many portable computing devices, such as laptop computers, tablets, smartphones, or head-mounted displays and other wearable computing devices (e.g., eyeglasses, visors, gloves, watches, wristbands, etc.), include mobile broadband cards or chipsets that support third generation (3G) (e.g., Universal Mobile Telecommunications (UMTS), CDMA2000), 3G+(e.g., Long Term Evolution (LTE), Worldwide Interoperability for Microwave Access WiMAX or IEEE 802.16e), or fourth generation (4G) (e.g., LTE Advanced, Mobile WiMax Release 2 or IEEE 802.16m) wireless telecommunication standards. An important feature for many users with devices capable of supporting such standards is the ability to simultaneously operate the device to make a telephone call and access remote data. For example, two users may be collaborating via a web-based whiteboard or a cloud-based word processing document and thus require the ability to both talk to the other user and access the Internet at the same time. As another example, a user may be participating in a teleconference and desires to send an email during the teleconference. As yet another example, a user may be placed on hold by a customer service agent for a lengthy period of time and would like to pass the time by browsing the interne or playing a web-based video game. Although certain conventional devices and approaches enable users to “talk and surf” at the same time, these conventional systems and methods may provide a less than optimal experience for the user.
Various embodiments in accordance with the present disclosure will be described with reference to the drawings, in which:
FIG. SA-5B illustrate example approaches for transmitting data from a user device to a network in accordance with various embodiments;
In wireless data communication, the transceiver of the computing device uses significant amounts of power for radio frequency (RF) transceiving, analog-to-digital and digital-to-analog conversion, wideband signal processing, among other functions. As mobile networks are expected to support higher data rates and bandwidths, and consumers increasingly demand smaller, lighter computing devices (and concomitantly, smaller, lighter batteries), power saving is becoming more and more critical for such devices. A conventional power saving approach is discontinuous reception (DRX) and/or discontinuous transmission (DTX). DRX/DTX aims to reduce power usage by turning off the transceiver (or a transmitter and receiver in certain embodiments) used for wireless communication for as long as possible, and turning on the transceiver for short periods of time to receive and/or transmit data. The benefits of DRX/DTX may not be realized, however, when a device is used to send data of disparate profiles, such as voice data generally comprising of small packets requiring a persistent network connection and being intolerant to delay or web browsing traffic which may comprise of much larger packets but does not require a persistent network connection.
Systems and methods in accordance with various embodiments of the present disclosure may overcome one or more of the aforementioned and other deficiencies experienced in conventional approaches for concurrently transmitting data of distinct profiles, such as voice data and web traffic data or file transfer data. In various embodiments, a computing device can simultaneously transmit packets of a first type of data, such as voice data associated with a Voice over IP (VoIP) or Voice over LTE (VoLTE) telephone call and packets of a second type of data, such as web browsing traffic or file download, while optimizing the battery life of the computing device. In some embodiments, certain metrics can be determined for the computing device (by the computing device or the network to which the device is connected) to estimate how much of the second type of data (e.g., non-voice data) on top of the first type of data (e.g., voice data) is to be transmitted over the network. These metrics can include a type of data of the second type of data, a quality of service (QoS) corresponding to the second type of data, a data throttling rate, radio access conditions of the computing device, and other such factors. Based on these metrics, transmission of the second type of data can be aligned with transmission of the first type of data such that the RF modem, transceiver, transmitter, receiver, analog-to-digital (ADC) converter, digital-to-analog (DAC) converter, or other such components of the computing device can be turned off while the device is not transceiving data.
Various other functions and advantages are described and suggested below in accordance with the various embodiments.
On the EPC network 140 side of EPS, the core network includes components such as the Mobility Management Entity (MME) 144, the Serving Gateway (S-GW) 148, and the PDN Gateway (P-GW) 146. The MME 144 is a control element that processes the signaling between the UE 102 and the EPC network 140. The MME is responsible for bearer and connection management. The S-GW 148, through which all user IP packets are transferred, serves as the local mobility anchor for the data bearers when the UE 102 moves between eNodeBs 122. The S-GW 148 also stores information about the bearers when the UE 102 is in an idle state, and temporarily buffers downlink data while the MME 144 initiates paging of the UE 102 to reestablish the bearers. Further, the S-GW 148 performs certain administrative tasks in the network, such as collecting information for charging and lawful interception. The P-GW 146 is responsible for IP address allocation for the UE 102, as well as QoS enforcement for guaranteed bit rate (GBR) bearers. The P-GW also provides for filtering of downlink user IP packets into the different QoS-based bearers via Traffic flow Templates (TFTs). The TFTs use IP header information such as source and destination IP addresses and Transmission Control Protocol (TCP) port numbers to filter packets, such as VoIP from web-browsing traffic, such that data flows to their respective bearers with the appropriate QoS. An Uplink TFT (UL TFT) associated with each bearer in the UE filters IP packets to EPS bearers in the uplink direction, and a downlink TFT (DL TFT) in the P-GW uses a similar set of downlink packet filters. As part of the procedure of a UE attaching to the network, the UE is assigned an IP address by the P-GW and at least one bearer (referred to as the default bearer, a non-GBR bearer) is established throughout the lifetime of the PDN connection to provide the UE with always-on IP connectivity to that PDN. Additional bearers (referred to as dedicated bearers) can also be established at any time during or after completion of the attachment procedure, and can be either a GBR or a non-GBR bearer.
In some embodiments, the EPC network 140 can also include components such as the Home Subscriber Server (HSS) 142 and the Policy Control and Charging Rules Function (PCRF) 150. The HSS 142 stores users' SAE subscription data, such as the EPS-subscribed QoS profile and roaming access restrictions. The HSS can also store information about the PDNs to which the user can connect (e.g., access point names (APNs), PDN addresses). Further, the HSS can store dynamic information such as the identity of the MME to which a user is currently attached or registered. In some embodiments, the HSS may also integrate the authentication center (AUC), which generates authentication and security data. The PCRF 150 is responsible for policy control and controlling the flow-based charging functionalities in the Policy Control Enforcement Function (PCEF) (not shown), which resides in the P-GW 146. The PCRF provides QoS authorization that determines how a certain data flow will be treated in the PCEF and ensures that the flow comports with the user's subscription profile.
On the E-UTRAN 120 side of EPS 100, the access network comprises of base stations or evolved NodeBs (eNodeBs) 122, which are connected to UEs 102, such as personal computers, smart phones, tablets, and wearable computing devices, among others. The eNodeBs 122 are interconnected through the X2 interface. The eNodeBs connect to the EPC network 140 via the S1 interface. More specifically, the eNodeBs 122 connect to the MME 144 via the S1-MME interface, and to the S-GW 148 via the S1-U interface. The E-UTRAN 120 is responsible for radio access functions, including radio resource management (RRM), header compression, security, and connection to the EPC network 140. These functions are performed by the eNodeBs, each of which can be responsible for managing multiple cells. Under LTE, radio control is integrated into the eNodeB and can allow for closely integrated interaction between the different protocol layers of the radio access network. This can reduce latency and improve efficiency. Further, such distributed control can eliminate the need for a high-availability, processor-intensive controller for reduction in costs and single-point-failures
The radio access protocol architecture for LTE can be separated into a user plane protocol stack 200, as shown in
The LTE L1 or PHY layer operates according to asymmetrical modulation and data rates for uplink and downlink. On downlink, Orthogonal Frequency Division Multiple Access (OFDMA) is used, and on uplink, Single Carrier-Frequency Division Multiple Access (SC-FDMA) (also known as Discrete Fourier Transform (DFT) spread OFDMA) is used. OFDMA is a multicarrier approach that subdivides the available bandwidth in a plurality of mutual orthogonal narrowband subcarriers. In OFDMA, these subcarriers can be shared between multiple users. Radio access is optimized for performance on the downlink because the eNodeB is assumed to have no power limitations. On the uplink, radio access is optimized more for power consumption than efficiency because of the relatively short battery life of portable computing devices. The LTE PHY layer is full duplex in operation in paired spectrum, with simultaneous transmission and reception. In various embodiments, the PHY layer operates continuously for downlink with interspersed sync and provides multiple channels simultaneously with varying modulation. Data can be represented as a resource block, which comprises a block of 12 subcarriers in one slot. A transport block is a group of resource blocks with a common modulation/coding. The physical interface can use transport blocks that correspond to the data carried over a period of time for allocation to a particular UE. Each radio subframe is 1 ms long, and each frame is 10 ms in length. Multiple UEs can be serviced on the downlink at any particular time in one transport block, and the MAC controls what to send at a given time. The LTE standard specifies these physical channels: the Physical Broadcast Channel (PBCH), the Physical Control Format Indicator Channel (PCFICH), the Physical Downlink Control Channel (PDCCH), the Enhanced Physical Downlink Control Channel (EPDCCH), the Physical Hybrid ARQ Indicator Channel (PHICH), the Physical Downlink Shared Channel (PDSCH), the Physical Multicast Channel (PMCH), the Physical Uplink Control Channel (PUCCH), the Physical Uplink Shared Channel (PDSCH), and the Physical Random Access Channel (PRACH). The modulation schemes supported in the downlink and uplink are QPSK, 16QAM, and 64QAM. In PBCH, the coded BCH transport block is mapped to four subframes within a 40 ms interval. The 40 ms interval is blindly detected (i.e., there is no explicit signal indicating each interval). Each subframe is assumed to be self-decodable (i.e., the BCH can be decoded from a single reception). The PCFICH provides the UE with the number of OFDM symbols used for the PDCCH, and is transmitted in every subframe. The PDDCH signals the UE regarding the resource allocation of the PCH and DL-SCH, and HARQ data corresponding to the DL-SCH. The PDCCH also carries the uplink scheduling grant. The EPDCCH carries scheduling assignments. The PHICH carries HARQ ACK/NAKs in response to uplink transmissions. The PDSCH carries the DL-SCH and PCH. The PMCH carries the MCH. The PUCCH carries HARQ ACK/NAKs in response to downlink transmissions, scheduling requests (SRs), and Channel Quality Information (CQI) reports. The PUSCH carries the UL-SCH. The PRACH carries the random access preamble.
The MAC layer provides for scheduling and distribution of bandwidth to UEs, and scheduling of downlink and uplink data. The MAC layer also provides for random access procedure control to enable a UE that is not allocated with uplink radio resources to access and synchronize with the network. The MAC is also responsible for uplink timing alignment to ensure that UE transmissions do not overlap when received at the eNodeB. Discontinuous reception (DRX)/discontinuous transmission (DTX) is also implemented at the MAC layer to save battery life by limiting the time the UE receives downlink channels. The MAC layer also provides for Hybrid Automatic Repeat ReQuest (HARQ) and maps RLC data received through logical channels onto transport channels connecting the MAC layer with the L1 or PHY layer.
The RLC layer provides for reformatting (e.g., segmentation, concatenation) of packets output by the PDCP (also referred to as Protocol Data Units (PDUs)) to the fit size requirements of the MAC layer. Transport block sizes can depend on bandwidth requirements, distance, power requirements, modulation approaches, and type of application. The RLC also reorders packets received out of sequence during HARQ operation. The RLC communicates with the PDCP through a Service Access Point (SAP) and with the MAC through logical channels. There are three modes of data transmission by the RLC: Transparent Mode, Unacknowledged Mode, and Acknowledged Mode. Transparent Mode is a pass-through mode which maps packets received by the RLC (also referred to as Service Data Units (SDUs)) to RLC PDUs without any overhead or modification to packets. Transparent Mode is used for some control signaling such as broadcast system information and paging messages. Unacknowledged Mode can be used for delay sensitive traffic such as VoIP. Unacknowledged Mode can also be used for point to multipoint data flow such as Multimedia Broadcast/Multicast Service (MBMS). In Unacknowledged Mode, the RLC layer performs segmentation and concatenation of RLC SDUs, reordering and duplicate detection of RLC PDUs, and reassembly of RLC SDUs. Acknowledge Mode is used to support data tolerant to delay but sensitive to error (e.g., web browsing or file download). In this mode, data flow may be bidirectional such that the RLC can transmit and receive data. The RLC can also apply Automatic Repeat reQuest (ARQ) to correct erroneous packets through retransmission of data. In Acknowledge Mode, the RLC can perform the functions of Unacknowledged Mode as well as retransmission of RLC data plane PDUs, resegmentation of retransmitted RLC data PDUs, polling, and status reporting.
The PDCP layer provides for header compression and decompression for all user plane data packets. Compression and decompression is based on the Robust Header Compression (RoHC) protocol which stores static parts of the header and updates them when they change. The dynamic parts of the header are compressed by transmitting the difference from the reference. RoHC can achieve significant savings on bandwidth and processing resources for services such as VoIP where the IP/UDP/RTP header comprises a large percentage of the actual packet. For example, the IPv4 header is 40 bytes, which can be compressed to 4-6 bytes for a VoIP payload of 32 bytes. The PDCP layer also provides for handover management. The PDCP layer reorders and sequences packets output by an LTE radio protocol layer (also sometimes referred to as Protocol Data Unit (PDU)) during a handover from one cell coverage area to another. Handovers can be seamless or lossless. Seamless handovers correspond to data that is tolerant to loss but not delay, such as control plane data and RLC Unacknowledged Mode user plane data. A seamless handover is designed to minimize delay as no security data is exchanged between the source and target eNodeB during such a handover. A packet received at the PDCP (sometimes referred to as the PDCP Service Data Unit (SDU)) at the eNodeB that has not been transmitted is forwarded over the X2 interface for transmission by the target eNodeB. A PDCP SDU at the UE that has not been transmitted is buffered and transmitted after the handover is complete. A lossless handover corresponds to data tolerant to delay but not loss, such as for a file download where minimal packet loss is preferred to save bandwidth utilization and increase data rate. A lossless handover is applied to RLC Acknowledge Mode bearers. The PDCP layer also provides for security, such as encryption and decryption of user and control plane data to protect against eavesdropping and preventing packet insertion or replacement by a malicious user. In some embodiments, SNOW 3G or AES-128 encryption can be used to provide security for user and control plane data.
The control plane protocol also includes the Radio Resource Control (RRC) protocol, which involve transmission of Non-Access Stratum (NAS) information. The RRC protocol also provides for broadcasting of system information based on the mode of the UE. System information is defined in System Information Blocks (SIBs). In addition, the RRC provides a Master Information Block (MIB), which includes a limited number of the most frequently transmitted parameters necessary for a UE's initial access to the network. System information is mapped to different logical channels depending on the state of the UE and the type of information. The RRC also includes procedures for establishment, modification and release of RRC connections for paging, security activation, Signaling Radio Bearers (SRBs), Data Radio Bearers (DRBs), handover, and other functions such as configuration of lower protocol layers. To reduce E-UTRAN overhead and processing by a UE registered to the MME, UE-related information can be released after a long period of inactivity. During such periods, the MME stores the UE context and established bearer information. These states are known as EPS Connect Management (ECM) Idle and Connected Modes. The UE state at the MME is captured by the EPS Mobility Management (EMM) state and can be either Deregistered or Registered. An RRC connection is used for transitions between ECM Idle and Connected Mode. When setting DRBs, the RRC configures the lower layers (PDCP, RLC, MAC, and PHY). For example, the RRC may cause the PDCP to apply header compression for VoIP packets or the MAC to apply HARQ for delay-tolerant traffic. The RRC may also assign Prioritized Bit-Rates (PBRs) to control how the UE divides uplink resources between different radio bearers. The RRC also provides for mobility procedures, security activation, transfer of UE RRC context data, and measurement and configuration reporting for mobility support.
As mentioned, the MAC layer manages HARQ functions. The MAC layer also provides for transport of resource blocks as a logical mapping of different logical channels out of the transport block for the higher layers. The HARQ process, performed between the MAC and PHY layers, retransmits transport blocks for error recovery. The PHY performs retention and re-combination (incremental redundancy), and the MAC layer is responsible for management and signaling. The MAC layer provides a NACK when there is a transport block CRC failure, and the PHY typically provides a signal for the CRC failure. Retransmission is performed by the eNodeB or the sender on the downlink using a different type of coding. The coding is sent and maintained in buffers in the eNodeB. Eventually, such as between one to four attempts, there will be sufficient data to reconstruct the signal. In the HARQ process, the retransmission of the transport block does not have to be fully correct. It is sufficient for the transport block to be correct enough to be combined mathematically with the previous transport block in order to generate a correct transport block. Logical channels are at the top of the MAC layer. Logical channels represent data transfer services offered by the MAC, and are defined by the type of information the logical channel carries. Types of logical channels can include control channels for control plane data and traffic channels for user plane data. Transport channels are in the transport blocks at the bottom of MAC layer. Transport channels represent data transfer services offered by the PHY, and are defined by the information carried, physical layer modulation, and/or encoding.
Also illustrated in this example are transport channels 314, which include the Broadcast Channel (BCH), Paging Channel (PCH), Downlink Shared Channel (DL-SCH), and the Multicast Channel (MCH). Transport channels use different modulations and coding. The BCH, PCH, and MCH must be received everywhere in the coverage area of the eNodeB, so they must use robust modulation. The BCH uses a fixed, pre-defined transport format. The PCH supports discontinuous reception (DRX) to enable UE power saving. This transport channel maps to physical resources which can be used dynamically for traffic and other control channels. The DL-SCH provides support for HARQ, dynamic link adaptation by varying the modulation, coding, and transmit power, dynamic and semi-static resource allocation, and UE DRX, and MBMS transmission. In some embodiments, DL-SCH can support broadcast in an entire cell and beam forming. This transport channel can be optimized by the UE. Download physical channels 316 PBCH, PDSCH, PDCCH, and PMCH are also shown, and their functions are discussed elsewhere herein.
All MAC transmission on the UL-SCH must be scheduled by the Random Access Channel (RACH) procedure. When the UE is not connected to the network, no transmit slots are scheduled for that UE. The RACH provides a means for disconnected devices to transmit data. Transmitting on the UL-SCH requires a resource allocation from the eNodeB, and time alignment to be current, or the RACH procedure is required. The RACH procedure can be used during initial access from the disconnected state (RRC_IDLE) or radio access failure, handover requiring random access, DL or UL data arriving during RRC_CONNECTED after UL PHY is no longer in sync, or UL data arriving when no dedicated scheduling request channels are available. Timing is critical because the UE can move different distances from the base station, and LTE requires microsecond-level precision. There are two types of the RACH procedure, contention-based, which can apply to each of these situations, and non-contention-based, which applies to handover and arrival of DL data.
In LTE, the MAC layer in eNodeB allocates physical layer resources for the DL-SCH and UL-SCH. Different schedulers operate for the DL-SCH and UL-SCH. Resources are composed of Physical Resource Blocks (PRBs) and Modulation Coding Schemes (MCS). The MCS can establish the bit rate and capacity of PRBs. Allocations may be valid for one or more Transmission Time Intervals (TTIs) with each TTI comprising a 1 ms subframe. In various embodiments, semi-persistent scheduling (SPS) can be utilized to reduce control channel signaling for applications that require persistent radio resource allocations, such as VoIP. In LTE, both downlink and uplink are fully scheduled since the downlink and uplink traffic channels are dynamically shared channels. This means that the PDCCH must provide access grant information to indicate which users should decode the PDSCH in each subframe and which users are allowed to transmit on the PUSCH in each subframe. Without SPS, every downlink or uplink PRB allocation must be granted via an access grant message on the PDCCH. This may be sufficient for some best-effort types of applications having large packet sizes and requiring scheduling of only a few users for each subframe (e.g., web browsing or file download). However, for applications that require persistent PRB allocations of small packet sizes (e.g., VoIP or VoLTE), the access grant control channel overhead becomes untenable. SPS enables set up of an ongoing allocation of resources that persists until a signal is detected on the PDCCH to change such allocation. Semi-persistent schedules can be configured for both uplink and downlink.
As mentioned, LTE utilizes certain power saving protocols such as Discontinuous Reception (DRX)/Discontinuous Transmission (DTX). Both approaches reduce transceiver duty cycle (or receiver duty cycle and transmitter duty cycle in embodiments having separate hardware for the receiver and the transmitter) while a UE is in active operation, i.e., when the UE is in Connected Mode. DRX/DTX can also apply when the UE is in IDLE mode but with a longer cycle time than when in Connected Mode. The RRC sets a cycle wherein the UE transceiver (or receiver and transmitter) is operational for a specified period of time during which the UE can receive data from/transmit data to the network. After the specified period of time, the UE transceiver (or receiver and transmitter) can be turned off and/or the UE is not required to monitor the PDCCH until the UE is “awaken.”
When the UE has non-voice data to transmit to the network, however, conventional power saving approaches may be ineffective.
Systems and approaches in accordance with various embodiments can realize power savings during simultaneous transmission of data having distinct profiles, such as VoIP or VoLTE packets and non-voice data, by aligning the transmission of data of a first type, such as the non-voice data, with the SPS uplink timing for data of a second type, such as VoIP or VoLTE packets.
If it is determined that the BO amount is greater than or equal to the BO threshold 706, the computing device can deactivate DRX/DTX 716 such that the computing device's transceiver is active. Voice packets and the non-voice data packets can be transmitted during the active time of the transmitter 718. After the non-voice data has been transmitted, DRX/DTX can be reactivated and the remaining voice packets of the VoIP or VoLTE can be transmitted based on SPS until the call is complete 714. Although process 700 illustrates an example of data transmission from the computing device directed by the UE, it will be appreciated that in other embodiments, data transmission flow can be directed from the eNodeB or network in other embodiments. For example, when a particular UE has been granted a semi-persistent allocation of PRBs for VoIP or VoLTE and then sends a BSR or SR indicating non-voice data for transmission to the network, the eNodeB can send a control signal to the UE to delay transmission of non-voice data in accordance with the SPS allotments for the voice data. Further, instead of the UE determining the BO threshold and passing the information to the eNodeB, the eNodeB can obtain that information or derive similar information from the various measures the UE provides to the eNodeB, such as CQI reports, HARQ/ARQ retransmission information, and other such UE measurements.
In various embodiments, audio element 810 also includes a device for VoIP or VoLTE support. The VoIP device includes a vocoder, an analog-to-digital converter (ADC) to digitize the voice signal and a digital-to-analog converter (DAC) to convert the digital voice to an analog voice for the user. The vocoder can also include functionality for voice signal compression and decompression to effectively minimize the number of bits used to represent the voice such that voice data can be transmitted faster but at lower data rates. In some embodiments, the vocoder may be an Adaptive Multi-Rate (AMR) vocoder that has variable bit-rate capability from 1.8 kbits/s to 12.2 kbits/s. The AMR vocoder segments voice data according to AMR packets, which are then encapsulated into IP packets for transmission.
The computing device 800 includes at least one capacitive component or other proximity sensor, which can be part of, or separate from, the display assembly. In at least some embodiments the proximity sensor can take the form of a capacitive touch sensor capable of detecting the proximity of a finger or other such object as discussed herein. The computing device also includes various power components 814 known in the art for providing power to a computing device, which can include capacitive charging elements for use with a power pad or similar device. The computing device can include one or more communication elements or networking sub-systems 816, such as LTE or variations thereof, WiMax or variations thereof, Wi-Fi, Bluetooth®, RF, wired, or wireless communication system. The device in many embodiments can communicate with a network, such as the Internet, and may be able to communicate with other such devices. In some embodiments the device can include at least one additional input device 818 able to receive conventional input from a user. This conventional input can include, for example, a push button, touch pad, touchscreen, wheel, joystick, keyboard, mouse, keypad, or any other such device or element whereby a user can input a command to the device. In some embodiments, however, such a device might not include any buttons at all, and might be controlled only through a combination of visual and audio commands, such that a user can control the device without having to be in contact with the device.
The device 800 also can include one or more orientation and/or motion sensors 812. Such sensor(s) can include an accelerometer or gyroscope operable to detect an orientation and/or change in orientation, or an electronic or digital compass, which can indicate a direction in which the device is determined to be facing. The mechanism(s) also (or alternatively) can include or comprise a global positioning system (GPS) or similar positioning element operable to determine relative coordinates for a position of the computing device, as well as information about relatively large movements of the device. The device can include other elements as well, such as may enable location determinations through triangulation or another such approach. These mechanisms can communicate with the processor 802, whereby the device can perform any of a number of actions described or suggested herein.
The various embodiments can be further implemented in a wide variety of operating environments, which in some cases can include one or more user computers or computing devices which can be used to operate any of a number of applications. User or client devices can include any of a number of general purpose personal computers, such as desktop or laptop computers running a standard operating system, as well as cellular, wireless and handheld devices running mobile software and capable of supporting a number of networking and messaging protocols. Such a system can also include a number of workstations running any of a variety of commercially-available operating systems and other known applications for purposes such as development and database management. These devices can also include other electronic devices, such as dummy terminals, thin-clients, gaming systems and other devices capable of communicating via a network.
The operating environments can include a variety of data stores and other memory and storage media as discussed above. These can reside in a variety of locations, such as on a storage medium local to (and/or resident in) one or more of the computers or remote from any or all of the computers across the network. In a particular set of embodiments, the information may reside in a storage-area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the computers, servers or other network devices may be stored locally and/or remotely, as appropriate. Where a system includes computerized devices, each such device can include hardware elements that may be electrically coupled via a bus, the elements including, for example, at least one central processing unit (CPU), at least one input device (e.g., a mouse, keyboard, controller, touch-sensitive display element or keypad) and at least one output device (e.g., a display device, printer or speaker). Such a system may also include one or more storage devices, such as disk drives, optical storage devices and solid-state storage devices such as random access memory (RAM) or read-only memory (ROM), as well as removable media devices, memory cards, flash cards, etc.
Such devices can also include a computer-readable storage media reader, a communications device (e.g., a modem, a network card (wireless or wired), an infrared communication device) and working memory as described above. The computer-readable storage media reader can be connected with, or configured to receive, a computer-readable storage medium representing remote, local, fixed and/or removable storage devices as well as storage media for temporarily and/or more permanently containing, storing, transmitting and retrieving computer-readable information. The system and various devices also typically will include a number of software applications, modules, services or other elements located within at least one working memory device, including an operating system and application programs such as a client application or Web browser. It should be appreciated that alternate embodiments may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets) or both. Further, connection to other computing devices such as network input/output devices may be employed.
Storage media and computer readable media for containing code, or portions of code, can include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as computer readable instructions, data structures, program modules or other data, including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other medium which can be used to store the desired information and which can be accessed by a system device. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments.
The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the claims.
