Embodiments are generally directed to data sampling of client devices, and specifically to dynamic sample selection of client devices based on geospatial area and selection predicates.
Conventional distributed system environments include client devices that are sampled on periodic basis. The sampling monitors the status and data processing by the client devices as well as data traffic in a network. To monitor the client devices, the conventional distributed system environment sends an information request to all or a preconfigured number of client devices. The client devices receive and process the request and generate a response.
However, when multiple client devices respond to a request at or approximately the same time, the data traffic associated with the response may cause traffic congestion in the distributed system environment. Additionally, the preconfigured client devices may include client devices whose information is of no interest to the conventional distributed system environment. Further, a request for information of each device may incur additional traffic.
A system and method for determining a dynamic sample of client devices in a distributed system environment are provided. Coordinates for areas based on geospatial input are received. A predicate function that selects a dynamic sample of client devices in the one or more areas based on the received coordinates are determined. The client devices are selected based on the predicate function. The selection is done by broadcasting, multicasting or unicasting the predicate to the client devices and having each client device determine whether they are an active sample participant. In one embodiment, the determination is made by the client device evaluating the predicate function. In another embodiment the predicate is evaluated against criteria stored in a database. After the evaluation, each client device is notified their sample participation on/off status.
Further features and advantages of the embodiments, as well as the structure and operation of various embodiments, are described in detail below with reference to the accompanying drawings. It is noted that the embodiments are not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.
The accompanying drawings, which are incorporated herein and form part of the specification, illustrate the embodiments and, together with the description, further serve to explain the principles of the embodiments and to enable a person skilled in the pertinent art to make and use the embodiments. Various embodiments are described below with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout.
The embodiments will be described with reference to the accompanying drawings. Generally, the drawing in which an element first appears is typically indicated by the leftmost digit(s) in the corresponding reference number.
In the detailed description that follows, references to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
The term “embodiments” does not require that all embodiments include the discussed feature, advantage or mode of operation. Alternate embodiments may be devised without departing from the scope of the disclosure, and well-known elements of the disclosure may not be described in detail or may be omitted so as not to obscure the relevant details. In addition, the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. For example, as used herein, the singular forms “a,” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes” and/or “including,” when used herein, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
In an embodiment, the components of the distributed system environment 100 are located in different geographic locations. Because the components are located in different locations, distributed system environment 100 is adapted to conduct dynamic sample selection of client devices that operate within the system. As part of the dynamic sample selection, client devices that meet particular selection criteria, or a combination of selection criteria in a designated area can be selected. Once the client devices are selected, a subset of those devices may be included in the dynamic sample to meet configured density and sampling rate requirements.
The dynamic sample selection has numerous advantages. Example advantages include minimizing bandwidth required to transfer data, minimizing network congestions between computing devices in the network, intelligently controlling network elements, conducting data analysis and optimization that affects system performance and intelligently selecting computing devices that act as monitoring or polling elements.
In an embodiment, distributed system environment 100 includes a server 102. Server 102 is a computing device dedicated to run one or more services, applications, etc., that communicate with multiple client devices 104 over a network. Example server 102 may include a database server, a file server, a mail server, a print server, a web server, a network control server, a monitoring server, an application server, an application server, a gaming server, etc. Server 102 may also include applications that send and receive requests to/from applications executing on client devices 104.
In an embodiment, server 102 may be a head-end. A head-end is a computing device or a network of computing devices that control video streaming, data and application distribution to set-top box devices that control the display of the video content on, for example, television.
Server 102, client devices 104 and other components in distributed system environment 100 communicate over a network (not shown). Example network may be any network that carries data traffic and provides access to services and applications. A network may include, but is not limited to, a local area network (LAN), metropolitan area network, and/or wide area network (WAN), such as the Internet, a fiber or hybrid-fiber network or a wireless network to give a few examples.
Client devices 104 are electronic devices that communicate with server 102 and/or with each other. In an embodiment, client devices 104 may include Cloud devices, such as database systems that store data. In another embodiment, client devices 104 may also include two-way communication devices that send and receive data. In yet another embodiment, client devices 104 may be computing devices under a control of a user and may include, but are not limited to, set-top-box devices (STBs), game-consoles, tablets, smart-tv's, smart phones, laptops, desktops, car navigation systems, etc.
In one embodiment, client devices 104 may communicate directly with server 102. In another embodiment, client devices 104 may communicate with server 102 using one or more hubs 106 and/or one or more nodes 108. Hubs 106 control communication to/from server 102 to a subset of client devices 104 in distributed system environment 100. Nodes 108 further segregate client devices 104 into groups within each hub 106.
Monitoring devices 110 are computing devices that monitor state of distributed system environment 100. Example monitoring devices 110 may include tablets, smartphones, laptops, etc., that include components described in
Unlike conventional monitoring devices, monitoring devices 110 obtain information from a dynamically selected sample of client devices 104. In an embodiment, the dynamic sample of client devices 104 may be obtained using geospatial input. A geospatial input allows monitoring devices 110 to obtain information for client devices 104 in a particular geographic area. Geospatial input may be received by geospatial applications 112 that are stored in memory and execute on a processor of monitoring devices 110. Example memory and processor is described in detail in
Geospatial applications 112 receive gesture based input from a user of monitoring device 110, in an embodiment. Some monitoring devices 110 may include a gesture sensitive display screen. To enter the geospatial input, a user using monitoring device 110 may draw a gesture on a gesture sensitive display screen of monitoring device 110, where the display screen portrays a geographic area. A person skilled in the art may appreciate that geospatial applications 112 may also receive other types of input via communication devices that include a mouse, keyboard, voice-activated input, etc.
In an embodiment, a user may use geospatial applications 112 to select one or more geographic areas. For instance, a user may use a gesture sensitive display screen of monitoring device 110 to select New York State from a map showing a map of the United States. A user may then zoom in on one or more areas within New York State, such as Manhattan or Long Island, and select these areas.
In another embodiment, a user may use geospatial application 112 to pan around the display screen of monitoring device 110. Based on the panning, geospatial application 112 may select or deselect one or more geographic areas.
In an embodiment, geospatial input may be in a form of a closed polygon.
In an embodiment, in response to receiving the geospatial input from a user, geospatial application 112 converts the geospatial input into geodetic coordinates, XY coordinates, or any other coordinates known to a person of ordinary skill in the art that described a geographic area (collectively referred to as coordinates).
In an embodiment, geospatial applications 112 allow monitoring devices 110 to dynamically target client devices 104 in the area selected using geospatial input. For instance, the targeted client devices 104 may be dynamically activated and deactivated based on the geospatial input, as well as attributes that are specific to client devices 104.
There are various factors that determine which client devices 104 are included in the dynamic sample. In one instance, client devices 104 in the selected zoom area may be activated based on a sampling rate. The sampling rate causes the number of sampled client devices 104 to be maintained at a sampling rate constant. In another instance, client devices 104 in the selected zoom area may be targeted based on optimizing the sampling rate such that a variable number of sampled client devices 104 is inversely proportional to the size of the zoom area and selection attributes that satisfy a sample rate constant. Such targeted sampling of client devices 104 controls the amount of data that may be transmitted over a network from client devices 104 to server 102. The targeted sampling also eliminates a dilemma common to conventional distributed system environments where multiple client devices are activated to transmit information, and overload the network with data traffic.
In an embodiment, geospatial applications 112 transmit coordinates to a rule engine 114. Rule engine 114 may be a computing device or an application executing on the computing device, such as a device described in
In an embodiment, rule engine 114 receives coordinates from one or more monitoring devices 110. Based on the coordinates, rule engine 114 dynamically selects client devices 104 from which it retrieves information. In an embodiment, rule engine 114 uses a multi-dimensional geospatial sampling function, a selection criteria function or a combination of both to determine client devices 104 that are present in the zoom area defined by the coordinates, and dynamically activates all or a subset of client devices 104 in the zoom area.
In an embodiment, rule engine 114 uses a multi-dimensional geospatial sampling function to selected sampling rate. The sampling rate defines a set of one or more dynamic zoom areas that satisfy a sampling rate constraint. As discussed above, a zoom area refers to a geographic area within a closed polygon selected using geospatial application 112. In another embodiment, zooms areas generated using multiple geospatial applications 112 may be combined into a zoom area A. In this embodiment, zoom area A=A1+A2+ . . . An where n is a number of zoom areas and each zoom area A1, . . . An is a distinct closed area polygon generated using geospatial applications 112. In an embodiment, each zoom area A1 to An may be selected independently from other zoom areas. However, in an embodiment, zoom area A that is a sum of zoom areas A1 to An must satisfy a sampling rate constraint, where the sampling rate constraint may be defined by one or more geospatial applications 112 or predefined in distributed system environment 100.
In an embodiment, when zoom area A decreases in size, the sampling rate inside zoom area A (such as sampling rate R) increases in proportion to a decrease in zoom area A. An increase in the sampling rate R may be attributed to selecting additional client devices 104 into the dynamic sample as the zoom area decreases. Additionally, as zoom area A decreases in size, the sampling rate outside of zoom area A (such as sampling rate O) decrease inversely to the sampling rate R in order to maintain the total number of client devices 104 that communicate with monitoring devices 110 at a constant density d. In an embodiment, the sampling rate R for a zoom area A (such as R(A)) may be defined as R(A)=d/A and sampling rate O may be defined as O=1/R.
In an embodiment, the density d of client devices 104 may not be uniform in the zoom area A. A non-uniform density d may be defined as d(A). A density may be non-uniform when the sampling rate R increases as the zoom area A decreases. In an embodiment, when density is non-uniform the sampling rate R(A,d)=d(A)/A.
In an embodiment, the sampling rates R(A) and R(A,d) may be used to construct a predicate function. The predicate function determines to a set of elements P that are contained within zoom area A. In an embodiment, the set of elements P may be a set of client devices 104 that are located in zoom area A.
Referring back to
In an embodiment, a geospatial sampling function and a selection criteria function may be combined to form a predicate function ƒ. For instance, a geospatial sampling function and a selection criteria function may be logically combined using a concatenation operator to form the predicate function ƒ.
In an embodiment, a particular predicate function ƒ is associated with a particular zoom area A. For instance, a predicate function ƒ1 is associated with zoom area Ai, where
Hence the predicate function ƒ for zoom area A is the sum of predicate functions ƒ associated with zoom areas λi, where i is an integer that counts a number of zoom areas. This way, each predicate function ƒi has a one to one mapping with a zoom area Ai.
To determine whether client devices 104 should be activated in a zoom area, rule engine 114 evaluates the predicate function ƒ. In a non-limiting embodiment, rule engine 114 evaluates the predicate function ƒ to either “0” or “1”. As discussed above, where zoom area A is a sum of multiple zoom areas Ai, predicate function ƒi associated with each zoom area is evaluated. When the predicate function ƒi evaluates to “1”, some or all client devices 104 in that zoom area Ai are activated for data sampling. On the other hand, when the predicate function ƒ evaluates to “0”, client devices 104 are not activated and data sampling does not occur.
In an embodiment, rule engine 114 constructs data access profiles. Data access profiles enable a rule calculation that determines which data sets that include client devices 104 can be sampled. In an embodiment, data access profiles may be associated with attributes of client devices 104 and include selection criteria discussed above. In another embodiment, data access profiles may be preconfigured and reconfigured by the distributed system administrator.
In an embodiment, distributed system environment 100 includes a device profile database 116. Device profile database 116 may be a database implemented as memory storage described in detail in
Device profile database 116 stores data access profiles constructed using rule engine 114. In another embodiment, device profile database 116 also stores selection criteria associated with client devices 104.
In an embodiment, predicated function ƒ uses data access profiles to determine the dynamic sample of client devices 104. The predicate function ƒ that includes data access profiles may be defined as predicate function ƒ(p). For instance, the predicate function ƒ(p) may be defined as:
ƒ(p)=T1(p)∨T2(p)∨T3(p) . . . Tc(p)
where tests T1 to Tc are predicate tests. In an embodiment, each Tx(p) is a test expression which evaluates to “0” or “1” to determine whether client devices 104 that pass tests T1 to Tc are included in the dynamic sample. Each of the tests T1 to Tc may be evaluated separately to identify client device 104 that meet the criteria of a particular Ti.
The data access profile of each of test T1 to Tc may be evaluated against selection criteria that include information associated with client devices 104 and zoom areas. For example, data access profile of each of test T1 to Tc is evaluated against available geospatial parameters such as divided regions, sub-regions, client device serial numbers, network addresses, etc.
In an embodiment, predicate function ƒ(p) may combine a sampling rate R with the predicate tests. In this embodiment, the predicate tests include a geospatial sampling function that constrains the predicate function ƒ(p) to a particular zoom area and selection criteria function that constrains the predicate function ƒ(p) to client devices 104 that fit the predetermined selection criteria within the zoom area.
In an embodiment, the total number of client devices 104, that are included in the selected zoom area A may be defined as:
where n is a total number of client devices 104 in distributed system environment 100, s is a sample rate constraint for a given predicate function, P is the set of client devices 104 in distributed system environment 100 that meet the data access profile as specified by the predicate function ƒ(p), and D is a set of client devices 104 that are dynamically selected to transmit information. In an embodiment, sample rate constraints may be a constant that is defined by an application that requests a dynamic sample selection or by the distributed system environment 100.
An example below describes a predicate function ƒ(p) that test for client devices 104 having two attributes and in a particular zoom area. The attributes include a service group and a zip code and a zoom area A. When these predicates are satisfied, client devices 104 that are included in set D of dynamically selected devices, are requested to transmit information to server 102, rule engine 114 or monitoring devices 110. The tests may be defined as T1 and T2, where T1 tests a service group and a zip code, and T2 tests a zoom area A. For example:
ƒ(p)=T1∨T2 where
T1=service group AND zipcode
and
T2=area A
When tests T1 and T2 evaluate to “1”, client devices 104 that meet the data access profile of T1 and T2 form set P. A sampling rate constraint s is then applied to set P to generate a set D of client devices 104, where client devices 104 in set D are included in the dynamic sample.
As discussed above, device profile database 116 stores attributes associated with client devices 104. In an embodiment, to determine client devices 104 in set D, rule engine 114 queries device profile database 116 for client devices 104 whose attributes satisfy the predicate function ƒ(p). For instance, rule engine 114 may generate a predicate function ƒ(p) as a database query, and transmit the database query to device profile database 116. In response to receiving the database query, device profile database 116 may process the database query and return a list of client devices 104 (also referred to as set P) that satisfy the predicate function ƒ(p). When the sampling constant s is not equal to “1”, rule engine 114 may modify the number of client devices 104 in set P in accordance with the sampling rate constraint s to generate set D. For example, when the sampling rate constraint s is inversely proportional to area A, set P decreases in proportion with the sampling rate constraint s, such that distributed system environment 100 is not overloaded with data traffic in response to a request to client devices 104.
Once rule engine 114 determines set D, rule engine 114 issues a request or causes server 102 to issue a request to client devices 104 in set D. Client devices 104 then respond to the request with data or information. The responses from client devices 104 are than displayed on monitoring devices 110.
In another embodiment, rule engine 114 may transmit the predicate function ƒ(p) to client devices 104. Each client device 104 that receives the predicate function ƒ(p), evaluates the predicate function ƒ(p). When client device 104 evaluates predicate function ƒ(p) to “1”, client device 104 transmits information to rule engine 114 directly or by way of server 102. Additionally, when client device 104 that evaluated the predicate function ƒ(p) to “1” may also evaluate the sampling rate constraints to determine its inclusion in set D.
T1=(date access profile inside A1=true)
T2=(date access profile inside A2=true)
T3=(date access profile inside A3==true)
T4=(date access profile inside A4=true)
The overall predicate function ƒ(p) for zoom areas A1 to A4 that generates set P is defined as:
ƒ(p)=T1∨T2∨T3∨T4
To determine the number of client devices 104 that are included in the dynamic sample, rule engine 114 evaluates ƒ(p) above, and then compensates for the sampling rate constraints, as described below:
In an embodiment where s=1, ƒ(p), when evaluated, yields a set D that includes 17 sampled client devices 104 in zoom areas A1 to A4.
In distributed system environment 500, monitoring devices 110 select a dynamic sample of STBs 104A that are in zoom areas A1 and A2. Once selected, rule engine 114 determines a predicate function that identifies STBs 104A in selected zoom areas A1 and A2. Broadband network head-end 102A then transmits a request for information to the selected STBs 104A.
The response to the request for information from STBs 104A is demonstrated by the data traffic in distributed system environment 500. For instance, data traffic from STBs 104A in zoom areas A1 and A2 accounts for 60% of data traffic and 30% of data traffic, respectively, in distributed system environment 500. The remaining 10% of data traffic from the unselected zoom areas may be due to some STBs 104A being sampled from the unselected zoom areas based on the test in the predicate function that meet the selection criteria irrespective of the zoom area.
At operation 602, coordinates are received. For example, rule engine 114 receives coordinates associated with a zoom area from one or more monitoring devices 110. As described herein, coordinates are generated by geospatial applications 112 in response to receiving geospatial input identifying a geographic area from a user. Once generated, the coordinates are transmitted to rule engine 114.
At operation 604, the zoom area is determined. For instance, monitoring devices 110 transmit the coordinates to rule engine 114. Rule engine 114 determines the zoom area in response to the received coordinates. When monitoring devices 110 have previously transmitted coordinates, rule engine 114 may update the previously determined zoom area with the zoom area associated with the received coordinates.
At operation 606, a predicate function is determined. For instance, the predicate function is determined based on a multi-dimensional geospatial sampling function associated with one or more zoom areas determined in operation 604. In an embodiment, where multiple zoom areas are included, a predicate function includes a test for each zoom area. In another instance, the predicate function is determined based on the selection criteria function that is evaluated against attributes of client devices 104. In an embodiment, the predicate function may be a combination of the multi-dimensional geospatial sampling function and the selection criteria function.
At operation 608 client devices are selected based on the predicate function. In one instance, the predicate function is applied to the client device attributes stored in the device profile database 116. In this embodiment, rule engine 114 transmits the predicate function to device profile database 116. Device profile database 116 then selects client devices 104 whose attributes meet one or more tests in the predicate function, and generates a list that includes the selected client devices 104.
At operation 610, the selected list is transmitted to the rule engine. For instance, device profile database 116 transmits the list to rule engine 114.
At operation 612, a list of client devices is conformed to a sampling rate constraint. For instance, rule engine 114 applies a sampling rate constraint to the selected client devices 104 so that the number of selected client devices 104 is below a predefined threshold.
At operation 614, the client devices are queried. For instance, rule engine 114 transmits or causes server 102 to transmit a request to client devices 104.
At operation 616, client devices transmit a response to the request. For instance, client devices 104 evaluate the request, and transmit information responsive to the request to rule engine 114.
At operation 618, the information is displayed. For instance, rule engine 114 transmits the information from the dynamically sampled client devices 104 to monitoring devices 110.
At operation 708, the predicate function is transmitted to client devices. For instance, server 102 transmits the predicate function to client devices 104.
At operation 710, the predicate function is evaluated. When each client device 104 receives the predicate function, each client device 104 evaluates the predicate function to determine whether client device 104 is included in the dynamic sample. For instance, client device 104 may include additional information, such as hub or node identifiers that are included in the predicate selection criteria, and that is not known to rule engine 114. This predicate selection criterion may be retrieved from client device 104 during the evaluation. If client device 104 is included in the dynamic sample, the event diagram proceeds to operation 712.
At operation 712, the sampling rate constraint is applied. For instance, client devices 104 that are included in the dynamic sample, also evaluate the sampling rate constraint. If the sampling rate constraint evaluation indicates that client device 104 is included in the dynamic sample, client device 104 proceeds to operation 714.
At operation 714, a client device transmits information. For instance, when client device 104 is included in the dynamic sample in operation 712, client device 104 transmits information to rule engine 114.
At operation 716, the information is displayed. For instance, rule engine 114 transmits the information from the dynamically sampled client devices 104 to monitoring devices 110.
Referring again to
In an embodiment, device information database 118 is memory storage in a computing device described in detail in
In an embodiment, based on the coordinates, rule engine 114 may generate dynamic geospatial queries that query information in device information database 118. A geospatial query may be in a structured query language (SQL) or another language adapted to manage data in a relational database management system and is based on geospatial input. The dynamic geospatial queries may be combined with machine learning and data-mining techniques to form data mining and analytics applications that monitor, collect, extract, data-mine and analyze data traffic information, usage information, etc., generated by client devices 104. These data mining and analytics applications (not shown) may execute on server 102 or another computing device in the distributed system environment 100. In an embodiment, the analytics applications may perform a failure analysis of the failed client devices 104 located in a particular geographic region (such as a failure analysis during a power outage caused by a storm) or proactively determine client devices 104 that may or have an above the threshold percentage for failing. In another embodiment, analytics applications may enable a user using monitoring devices 110 to generate client device usage metrics that identify popular channel usage by regions, hours spend viewing, interactive advertisements “clicks” or other usage information attributed to STBs 104A.
When rule engine 114 receives coordinates, rule engine 114 generates a predicate function as described above. The predicate function may be based on the geospatial area and/or data access profiles of client devices 104, that are set up as individual tests. Rule engine 114 then queries profiles of client devices 104 based on the predicate function from device profile database 116. In response to the query, device profile database 116 generates a list of client devices 104 that may be included in a geospatial query. Rule engine 114 then uses the list of client devices 104 to generate a geospatial query that includes some or all client devices 104 in the list, based on the sampling rate constraint.
Once a geospatial query is generated, rule engine 114 queries or causes server 102 to query device information database 118 for usage or other information associated with client devices 104. The queried information may then be analyzed by analytics applications executing on rule engine 114, server 102 or monitoring devices 110.
At operation 814, a geospatial query is generated. For instance, rule engine 114 generates a geospatial query that requests information associated with client devices 104 included in the list determined in operation 812. Once rule engine 114 generates the geospatial query, the geospatial query is transmitted to device information database 118.
At operation 816, a geospatial query is processed. For instance, device information database 118 receives and processes the query. The processed query generates information records that are then transmitted to rule engine 114.
At operation 818, the information records are analyzed. For instance, rule engine 114 receives the information records from device information database 118 and forwards the information records to an analytics application that processes the information records.
Various embodiments may be implemented by software, firmware, hardware, or a combination thereof.
Computer system 900 includes one or more processors, such as processor 906. Processor 906 can be a special purpose or a general purpose processor. Processor 906 is connected to a communication infrastructure 906 (for example, a bus or network).
Computer system 900 also includes one or more graphics processing units, such as graphics processing unit (“GPU”) 907. GPU 907 is also connected to a communication infrastructure 904. GPU 907 is a specialized processor that executes instructions and programs, selected for complex graphics and mathematical operations, in parallel. For example, GPU 907 may be adept at displaying and processing streaming media content.
Computer system 900 also includes a main memory 908, such as random access memory (RAM), and may also include a secondary memory 910. Secondary memory 910 may include, for example, a hard disk drive 912 and/or a removable storage drive 914. Removable storage drive 914 may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. The removable storage drive 914 reads from and/or writes to a removable storage unit 916 in a well-known manner. Removable storage unit 916 may comprise a floppy disk, magnetic tape, optical disk, etc. which is read by and written to by removable storage drive 914. As will be appreciated by persons skilled in the relevant art(s), removable storage unit 916 includes a tangible computer readable storage medium 924A having stored therein control logic 928B such as computer software and/or data.
In alternative implementations, secondary memory 910 may include other similar means for allowing computer programs or other instructions to be loaded into computer system 900. Such means may include, for example, a removable storage unit 916 and an interface 918. Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units 916 and interfaces 918 which allow software and data to be transferred from the removable storage unit 916 to computer system 900. As will be appreciated by persons skilled in the relevant art(s), interface 918 also includes a tangible computer readable storage medium 924B having stored therein control logic 928C such as computer software and/or data.
Computer system 900 may also include a communications interface 920. Communications interface 920 allows software and data to be transferred between computer system 900 and external devices 922. Communications interface 920 may include a modem, a network interface (e.g., an Ethernet card), a communications port, a PCMCIA slot and card, or the like. Software and data transferred via communications interface 920 are in the form of signals which may be electronic, electromagnetic, optical, or other signals capable of being received by communication interface 920. Software and data transferred via communications interface 920 are provided to communications interface 920 via a communications path. Communications path may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, a radio frequency (RF) link or other communications channels.
The communication and network interface 920 allows the computer system 900 to communicate over communication networks or mediums such as LANs, WANs the Internet, etc. The communication and network interface 920 may interface with remote sites or networks via wired or wireless connections.
In this document, the terms “computer program medium” and “computer usable medium” and “computer readable medium” are used to generally refer to media such as removable storage unit 916 and a hard disk 912 installed in hard disk drive 912. Computer program medium, computer usable medium, or computer readable medium can also refer to memories, such as main memory 908 and secondary memory 910, which can be memory semiconductors (e.g. DRAMs, etc.). These computer program products are means for providing software to computer system 900.
Computer programs (also called computer control logic 928) are stored in main memory 908, such as control logic 928A and/or secondary memory 910, such as control logic 928B. Computer programs may also be received via interface 918, such as control logic 928C. Such computer programs, when executed, enable computer system 900 to implement embodiments as discussed herein, such as the system described above. In particular, the computer programs, when executed, enable processor 906 to implement the processes of embodiments. Accordingly, such computer programs represent controllers of the computer system 900. Where embodiments are implemented using software, the software may be stored in a computer program product and loaded into computer system 900 using removable storage drive 914, interface 918, hard drive 912 or communications interface 922.
Embodiments can be accomplished, for example, through the use of general-programming languages (such as C or C++), hardware-description languages (HDL) including Verilog HDL, VHDL, Altera HDL (AHDL) and so on, or other available programming and/or schematic-capture tools (such as circuit-capture tools). The program code can be disposed in any known computer-readable medium including semiconductor, magnetic disk, or optical disk (such as CD-ROM, DVD-ROM). As such, the code can be transmitted over communication networks including the Internet and internets. It is understood that the functions accomplished and/or structure provided by the systems and techniques described above can be represented in a core (such as a CPU core and/or a GPU core) that is embodied in program code and may be transformed to hardware as part of the production of integrated circuits.
It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections, is intended to be used to interpret the claims. The Summary and Abstract sections may set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit the embodiments and the appended claims in any way.
The embodiments have been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.
The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the disclosure. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.
The breadth and scope of the embodiments should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
Number | Name | Date | Kind |
---|---|---|---|
5977957 | Miller | Nov 1999 | A |
6665715 | Houri | Dec 2003 | B1 |
7616707 | Jin | Nov 2009 | B2 |
8017411 | Sonderman | Sep 2011 | B2 |
8099109 | Altman et al. | Jan 2012 | B2 |
8108144 | Forstall | Jan 2012 | B2 |
8229442 | Ji | Jul 2012 | B1 |
8229454 | Yoakum | Jul 2012 | B1 |
8341009 | Algranati | Dec 2012 | B1 |
8495046 | Buchanan | Jul 2013 | B1 |
8504945 | Jakobson et al. | Aug 2013 | B2 |
8543456 | McKay | Sep 2013 | B2 |
8682350 | Altman et al. | Mar 2014 | B2 |
8750231 | Oroskar | Jun 2014 | B1 |
8898173 | Badoiu | Nov 2014 | B1 |
9088972 | Oroskar | Jul 2015 | B1 |
9125169 | Nichols | Sep 2015 | B2 |
9392406 | Houri | Jul 2016 | B2 |
9420320 | Doe | Aug 2016 | B2 |
20020143462 | Warren | Oct 2002 | A1 |
20030163369 | Arr | Aug 2003 | A1 |
20050149398 | McKay | Jul 2005 | A1 |
20060030333 | Ward | Feb 2006 | A1 |
20070106455 | Fuchs | May 2007 | A1 |
20070135993 | Riise | Jun 2007 | A1 |
20070136753 | Bovenschulte | Jun 2007 | A1 |
20070178911 | Baumeister | Aug 2007 | A1 |
20070198738 | Angiolillo | Aug 2007 | A1 |
20080016540 | Savoor | Jan 2008 | A1 |
20080045234 | Reed | Feb 2008 | A1 |
20080126334 | Laine | May 2008 | A1 |
20080126420 | Wright | May 2008 | A1 |
20080146205 | Aaron | Jun 2008 | A1 |
20080225810 | Buchwald | Sep 2008 | A1 |
20080262820 | Nasle | Oct 2008 | A1 |
20090106089 | Parkes | Apr 2009 | A1 |
20090132469 | White et al. | May 2009 | A1 |
20090198767 | Jakobson et al. | Aug 2009 | A1 |
20100198917 | Petersen | Aug 2010 | A1 |
20100312881 | Davis | Dec 2010 | A1 |
20110055884 | Beattie, Jr. | Mar 2011 | A1 |
20110161996 | Hamano | Jun 2011 | A1 |
20110202514 | Singh | Aug 2011 | A1 |
20110239243 | Dierks | Sep 2011 | A1 |
20110313859 | Stillwell | Dec 2011 | A1 |
20120046017 | Jennings | Feb 2012 | A1 |
20120046049 | Curtis | Feb 2012 | A1 |
20120239599 | Matsumoto | Sep 2012 | A1 |
20130014161 | Stallard | Jan 2013 | A1 |
20130103914 | Mitsunobu | Apr 2013 | A1 |
20130132438 | Park et al. | May 2013 | A1 |
20130148895 | Miller | Jun 2013 | A1 |
20130166730 | Wilkinson | Jun 2013 | A1 |
20130308470 | Bevan | Nov 2013 | A1 |
20130328862 | Piemonte | Dec 2013 | A1 |
20140095497 | Howe | Apr 2014 | A1 |
20140149396 | Park et al. | May 2014 | A1 |
20140213280 | Sandel | Jul 2014 | A1 |
20140250471 | Guerra | Sep 2014 | A1 |
20140281713 | Hampapur | Sep 2014 | A1 |