Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F11/00—Error detection; Error correction; Monitoring
  • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
  • G06F11/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
  • G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
• • H—ELECTRICITY
  • H03—ELECTRONIC CIRCUITRY
  • H03M—CODING; DECODING; CODE CONVERSION IN GENERAL
  • H03M13/00—Coding, decoding or code conversion, for error detection or error correction; Coding theory basic assumptions; Coding bounds; Error probability evaluation methods; Channel models; Simulation or testing of codes
  • H03M13/03—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words
  • H03M13/05—Error detection or forward error correction by redundancy in data representation, i.e. code words containing more digits than the source words using block codes, i.e. a predetermined number of check bits joined to a predetermined number of information bits
  • H03M13/09—Error detection only, e.g. using cyclic redundancy check [CRC] codes or single parity bit
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L1/00—Arrangements for detecting or preventing errors in the information received
  • H04L1/24—Testing correct operation
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L1/00—Arrangements for detecting or preventing errors in the information received
  • H04L1/004—Arrangements for detecting or preventing errors in the information received by using forward error control
  • H04L1/0056—Systems characterized by the type of code used
  • H04L1/0061—Error detection codes
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L1/00—Arrangements for detecting or preventing errors in the information received
  • H04L2001/0092—Error control systems characterised by the topology of the transmission link
  • H04L2001/0094—Bus

Definitions

• This invention relates generally to computer memory systems, and more particularly to detection of a failing bus lane using syndrome analysis.
• Contemporary high performance computing main memory systems are generally composed of one or more dynamic random access memory (DRAM) devices, which are connected to one or more processors via one or more memory control elements.
• DRAM dynamic random access memory
• Overall computer system performance is affected by each of the key elements of the computer structure, including the performance/structure of the processor(s), any memory cache(s), the input/output (I/O) subsystem(s), the efficiency of the memory control function(s), the main memory device(s), and the type and structure of the memory interconnect interface(s).
• ECC error correcting code
• An ECC can detect and correct a number of failing bits, but requires more redundant bits than an error detection code.
• an error detection code can detect an error but is not capable of fully resolving the physical nature of the error; for example, it may not be able to fully identify a failing lane for all possible error patterns in the failing lane. Therefore, an error detection code alone may not accurately isolate errors to specific failing lanes.
• Another approach to detecting a failing lane is lane shadowing, where a copy of data is sent on spare lanes. However, lane shadowing only operates on a subset of lanes at any point in time and can miss error events occurring outside of the analysis window for a given failing lane.
• An embodiment is a computer implemented method for detecting bus failures.
• the method includes receiving a plurality of syndromes of an error detection code, the error detection code associated with a plurality of frames that have been transmitted on a bus that includes a plurality of lanes and is protected by the error detection code.
• the method includes performing for each of the lanes in each of the syndromes: decoding the syndrome under an assumption that the lane is a failing lane, the decoding outputting a decode result;
• a failing lane is then identified in response to the voting, with the failing lane being characterized by having more votes than at least one other lane on the bus.
• Another embodiment is a system for detecting bus failures that includes a bus interface device configured to receive and trap syndromes for a plurality of frames that have been transmitted on the bus, each frame including multiple bit transfers per lane; and syndrome processing logic in communication with the bus interface device.
• the syndrome processing logic is configured to perform: receiving a plurality of syndromes of an error detection code, the error detection code associated with a plurality of frames that have been transmitted on a bus, the bus including a plurality of lanes and protected by the error detection code.
• the syndrome processing logic is also configured to perform for each lane for each syndrome: decoding the syndrome under an assumption that the lane is a failing lane, the decoding outputting a decode result; determining if the decode result is a valid decode; and voting for the lane in response to determining that the decode result is a valid decode.
• a failing lane is identified in response to the voting; and the failing lane characterized by having more votes than at least one other lane on the bus.
• a further embodiment is a computer program product for detecting bus failure.
• the computer program product includes a computer readable storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for implementing a method.
• the method includes receiving a plurality of syndromes of an error detection code, the error detection code associated with a plurality of frames that have been transmitted on a bus that includes a plurality of lanes and is protected by the error detection code.
• the method includes performing for each of the lanes in each of the syndromes: decoding the syndrome under an assumption that the lane is a failing lane, the decoding outputting a decode result; determining if the decode result is a valid decode; and voting for the lane in response to determining that the decode result is a valid decode.
• a failing lane is then identified in response to the voting, with the failing lane being characterized by having more votes than at least one other lane on the bus.
• FIG. 1 depicts a cascade interconnect memory system that may be implemented by an exemplary embodiment
• FIG. 2 depicts an exemplary downstream eight transfer frame
• FIG. 3 depicts an exemplary downstream twelve transfer frame
• FIG. 4 depicts an exemplary downstream sixteen transfer frame
• FIG. 5 depicts an exemplary upstream eight transfer frame
• FIG. 6 depicts an exemplary process for detection of a failing bus lane using syndrome analysis.
• An exemplary embodiment of the present invention locates a failing lane in a bus that is protected using an error detection code.
• Counters and analysis of multiple error detection code syndromes can be used to statistically identify the failing lane.
• the analysis results in a bit vector with a number of entries equal to the number of lanes in the bus. There is a counter for every lane, which is incremented with the result of the analysis. If the bit vector is equal to zero for a particular lane, the counter for that lane is left untouched; otherwise, it is incremented.
• the analysis may not fully resolve which failing lane is the one responsible for the error, and instead gives multiple possibilities for the failing lane. Thus more than one counter may be incremented when a single syndrome is analyzed. This process is repeated several times as new syndromes are received. Although for a single syndrome analysis it may not be possible to resolve the failing lane, as multiple syndromes are analyzed and the accumulated contents of the counters are obtained, the failing lane will have a higher count with high probability. The more syndromes that are analyzed, the better the quality of the result of the analysis. Monitoring for an error condition where one and only one bit failure occurs in a frame transferred on the bus can yield a high accuracy in isolating a failing lane.
• a linear error detection code is characterized by a parity check matrix H.
• the number of rows (r) in the parity check matrix H is equal to the number of check bits in the code.
• d be a column vector that denotes the k payload bits
• c be a column vector that denotes the r bits associated with these k payload bits.
• the position of the check bits c need not be on the top of the vector, and also the check bits need not be placed contiguously; this organization is assumed here purely to improve the readability of this description.
• H v denotes the
• e is a vector with n entries with zeros where there is no error and ones where there is an error.
• each lane carries n/L bits throughout the transmission of a frame on the bus.
• n is divisible by L.
• Hi can be partitioned in two sections, the first section Hi_A containing n/L rows, and the other section Hi_B containing the remaining rows. The partitioning is shown by:
• Hi_A is a square matrix with dimensions (n/L)x(n/L) and Hi_B is a matrix with dimensions (r - n L) x (n/L).
• s_A has n/L entries and s_B has r-n/L entries.
• Equation (1) is the basis for detection of a failing bus lane. If lane i is the lane with the problem, then the marker mi to the left of equation (1), which only depends on the designed code H and the syndromes s, must be equal to zero. Since it is not known which lane is failing, the left hand side of equation (1) is computed for all L lanes, in essence assuming in turn that each lane is a failing lane, letting index i vary from 1 to L while computing the left hand side of equation (1).
• the associated lane is declared as a failing lane candidate, and the ith bit of an analysis bitvector vote lane is set to one, that is, vote_lane[i] is set to 1 (this is referred to herein as "voting for lane i").
• vote_lane[i] is set to 0 (this is referred to herein as "not voting for lane I")
• the error magnitude e_i is computed using a subset of the syndromes s_A for each lane, while the crosschecking of the candidate error vector is performed using the remaining syndrome bits s_B. If the crosschecking is successful a valid decode signal is generated, otherwise an invalid decode signal.
• an exemplary embodiment provides a counter for each bit lane that counts votes for the associated lane being a faulty lane. These counters persist across multiple error detection (and hence syndrome analysis) events, and thus they are also referred to as running counters.
• the bitvector vote lane can be used to increment the counters for each bitlane, essentially by adding the value of the bitvector vote lane to the current value of the counters.
• the counter for the failing lane gets more increments than the counters for the other lanes. This can be taken advantage of by hardware, firmware or software that keeps track of the counters and determines whether a counter has reached a threshold. If this is so, the corresponding lane is a good candidate for lane sparing. If the error pattern is a single bit error, then without any ambiguity the failing lane can be correctly identified if the error detection code is suitably designed.
• the error detection code is suitably designed.
• the error detection code employed has the capability of detecting at least any two bits in error.
• the syndromes of any two single bit errors cannot be the same.
• FIG. 1 an example of a memory system 100 is depicted that includes fully buffered dual in-line memory modules (DIMMs) communicating via a high-speed channel and using the analysis of error detection code syndromes as described herein.
• the memory system 100 may be incorporated in a host processing system as main memory for processing system 102.
• the memory system 100 includes a number of DIMMs 103a, 103b, 103c and 103 d with hub devices 104 communicating via a channel 106 or a cascade-interconnected bus (made up of a differential unidirectional upstream bus 118 and a differential
• the DIMMs 103a- 103d can include multiple memory devices 109, which may be double data rate (DDR) dynamic random access memory (DRAM) devices, as well as other components known in the art, e.g., resistors, capacitors, etc.
• the memory devices 109 are also referred to as DRAM 109 or DDRx, as any version of DDR may be included on the DIMMs 103a-103d, e.g., DDR2, DDR3, DDR4, etc.
• a memory controller 110 interfaces with DIMM 103a, sending commands, address and data values via the channel 106 that may target any of the DIMMs 103a- 103d.
• the commands, address and data values may be formatted as frames and serialized for transmission at a high data rate.
• the hub devices 104 and the memory controller 110 may be referred to generically as bus interface devices.
• a DIMM when a DIMM receives a frame from an upstream DIMM or the memory controller 110, it redrives the frame to the next DIMM in the daisy chain (e.g., DIMM 103a redrives to DIMM 103b, DIMM 103b redrives to DIMM 103c, etc.). At the same time, the DIMM decodes the frame to determine the contents. Thus, the redrive and command decode at a DIMM can occur in parallel, or nearly in parallel. If the command is a read request, all DIMMs 103a- 103d and the memory controller 110 utilize contents of the command to keep track of read data traffic on the upstream bus 118.
• the hub devices 104 on the DIMMs 103a-103d receive commands via a bus interface (e.g., a port) to the channel 106.
• the bus interface on the hub device 104 includes, among other components, a receiver and a transmitter.
• each hub device 104 includes both an upstream bus interface for communicating with an upstream hub device 104 or memory controller 110 via the channel 106 and a downstream bus interface for communicating with a downstream hub device 104 via the channel 106.
• the hub devices 104 also include counters 112, registers 114, and error handling logic 120.
• the memory controller 110 can also include counters 112, registers 114, and error handling logic 120.
• the counters 112 may function as error counters used by the error handling logic 120 to calculate error rates and set fault conditions in registers 114.
• the counters 112 may be implemented in software, firmware, hardware, or some combination thereof. Detailed processing of syndromes to identify specific failing lanes can be offloaded to syndrome processing logic 122 of processing system 102.
• systems produced with these modules may include more than one discrete memory channel from the memory controller 110, with each of the memory channels operated singly (when a single channel is populated with modules) or in parallel (when two or more channels are populated with modules) to achieve the desired system functionality and/or performance.
• any number of lanes can be included in the channel 106.
• the downstream bus 116 can include 13 bit lanes, 2 spare lanes and a clock lane, while the upstream bus 118 may include 20 bit lanes, 2 spare lanes and a clock lane.
• An exemplary embodiment of the downstream CRC is selected selected/applied such that 8, 12 and 16 transfer frames are supported (in an exemplary embodiment, 13 bitlanes are included in each transfer).
• the downstream CRC detects any lane failure, any transfer failure, and up to 5 bit random errors.
• contents of the downstream frame are ignored and a failure information register (FIR) bit is set in registers 114.
• the FIR is an architected means of storing information about a failure that is detected within the hub device 104.
• the FIR can be interrogated by the memory controller 110 and/or other system elements to determine what action, if any, needs to be performed.
• an error recovery state can be entered if the system 100 is enabled to do so.
• a "conventional" location for check bits is at the beginning or the end of codeword.
• An exemplary embodiment of the downstream code is designed so that the check bit positions are in a "non-conventional" location. This non-conventional location is desirable because of issues related to how the protocol is designed.
• putting the checkbits in a conventional place and then moving them around can break important properties of the code (e.g., all lane fail detect, etc.).
• Furthermore not all locations are feasible to provide CRC detection.
• the non-conventional location of the check bit positions are exploited by an exemplary downstream frame format described herein.
• the upstream CRC is selected/applied such that up to 20 bitlanes are covered for up to 8 transfers, and so that it detects any lane failure, any transfer failure (with an escape rate of 2**(-16)), and up to 4 random errors.
• all upstream hubs devices 104 monitor upstream CRC data as it passes through the hub device 104 to detect upstream CRC errors, and any detected error results in that hub device 104 interrupting all read traffic, forwarding a poisoned CRC, setting a FIR bit, and entering error recovery state.
• the downstream CRC (error detection) code is utilized on a 13 lane x 16 beat (maximum) frame format.
• This CRC code can detect: any lane failure, any transfer failure, and up to 5 bit random errors.
• the random silent error rate is about two to the power of negative seventeen ( ⁇ 2**(-17)).
• This is a Bose Chaudhuri Hocquenghem (BCH) code that has five consecutive zeros (among other zeros).
• BCH Bose Chaudhuri Hocquenghem
• FIG. 2 depicts an exemplary downstream eight transfer frame that utilizes an embodiment of the channel CRC described herein.
• FIG. 3 depicts an exemplary downstream twelve transfer frame that utilizes an embodiment of the channel CRC described herein.
• FIG. 4 depicts an exemplary downstream sixteen transfer frame that utilizes an embodiment of the channel CRC described herein.
• the CRC bit positions are: 156, 157, 158, 159, 169, 170, 171, 172, 182, 183, 184, 185, 186, 195, 196, 197, 198, and 199.
• matrix Gaussian elimination was used to obtain a matrix suitable for calculating the CRC bits in the positions given above.
• the CRC is defined for the longest frame size, which is 208 bits for the 16 transfer frame. Any frame that does not use all 208 bits simply sets all unused bits to zero.
• An embodiment of the basic CRC algorithm encodes CRC checkbits and transmits them across the bus per the frame protocol.
• the checker on the other end of the bus e.g., in a hub device 104 of FIG. 1
• a new or regenerated set of CRC checkbits is computed.
• the received CRC checkbits and the regenerated CRC checkbits are then compared (XOR'd) to form the syndrome vector. If the syndrome is a bitwise 0 vector, then no error is assumed to have occurred in the transmission of the data. Any non-zero syndrome indicates an error has occurred.
• This implementation does not support direct error isolation by examination of the syndrome.
• the counters 112 of FIG. 1 include configurable counters for each receiver link to calculate a CRC error rate.
• the counters 112 of FIG. 1 may also include error counters for each signal lane recording the results of each CRC syndrome analyzed.
• Error rate logic in the error handling logic 120 of FIG. 1 increments a timer for each run time, memory channel frame and also counts any detected non-poison CRC errors in using counters 112.
• each failing CRC syndrome is analyzed by the syndrome processing logic 122 to determine possible failing lanes, communicated by the logic by voting on those lanes that may be failing.
• the CRC is powerful enough to uniquely identify the failing lane for all single bit errors in a frame and correctly identify the failing lane during a random lane failure for a statistically significant number of failures. Since CRC error correction is not powerful enough to guarantee unique error detection for completely random lane errors, multiple failure candidates may possibly be identified.
• the lane error counters in counters 112 increment each time their lane is identified as a failure candidate (because a vote was generated for it).
• the syndrome processing logic 122 can service the attention request by reading the lane error counters in the counters 112 and determining which lane, (if any) should be repaired. Even though multiple lane failure candidates may be identified on each CRC error, when the error counters have accumulated enough CRC syndrome analysis results to exceed the threshold, there will likely be a clear statistical indicator of the lane that is failing most often. If a spare lane is available to repair the identified failure, the processing system 102 can issue a command that deactivates the failing lane. This changes the intermittent failure into a hard failure that can be detected and repaired by the subsequent re-initialization and repair sequence automatically initiated by the memory controller 110 and/or hub devices 104.
• each receiver in the channel 106 also includes dedicated trap registers in registers 114 to record the results of one failing CRC syndrome.
• the trap registers can be configured to record the first CRC error detected or continuously update to the latest CRC error detected. A valid bit is set in the trap register when a new error is captured and it is automatically reset when the trap register is read by the processing system 102.
• the voting does not isolate one lane significantly above the other lanes, then one of the lanes is selected and repaired.
• the new error rate is then monitored. If the new error rate after the repair is not significantly (e.g., within a threshold) better than the previous error rate, then the first repair is backed-off (undone) and another lane is selected and repaired. This processing, of repairing and backing-off may continue until the new error rate is significantly better than the previous error rate.
• more than one lane repair is allowed, then more than one lane is selected for repair from the top contenders. In this manner, a plurality of repairs may be performed.
• FIG. 5 depicts an exemplary upstream 8 transfer frame that utilizes an embodiment of the channel CRC described herein.
• the upstream CRC is described as follows for an 8 transfer frame format along with its CRC and error checking bit numbers.
• This code is intended for use on a 20 lane x 8 beat frame format. It can detect any lane failure, any transfer failure (transfer failures escape from the code with a probability 2**(-16)), and up to 4 bit random errors.
• This is a BCH code that has four consecutive zeros (among other zeros). Therefore, it has a minimum distance 5.
• the polynomial for the code for the downstream format was obtained by multiplying the code for the upstream format by 1+x 2 .
• the CRC bit positions as depicted in FIG. 5 are 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, and 159.
• An exemplary CRC algorithm includes encoding the CRC checkbits and transmitting them across the bus per the frame protocol. After the data is received by the checker (e.g., in a hub device 104 of FIG. 1) on the other end of the bus, a new or regenerated set of CRC checkbits is computed. The received CRC checkbits and the regenerated CRC checkbits are then compared (XOR'd) to form the syndrome vector. If the syndrome is a bitwise 0 vector, then no error is assumed to have occurred in the transmission of the data. Any non-zero syndrome indicates an error has occurred. This implementation, as with most CRCs, does not support direct error isolation by examination of the syndrome.
• hub devices 104 may be connected to the memory controller 110 of FIG. 1 through a multi-drop or point-to-point bus structure (which may further include a cascade connection to one or more additional hub devices 104).
• Memory access requests are transmitted by the memory controller 110 through the bus structure (e.g., the memory bus) to the selected hub device(s) 104.
• the hub device 104 translates the memory access requests to control the memory devices 109 to store write data from the hub device 104 or to provide read data to the hub device 104.
• Read data is encoded into one or more communication frame(s) and transmitted through the memory bus(es) to the memory controller 110.
• the memory controller(s) 110 may be integrated together with one or more processor chips and supporting logic, packaged in a discrete chip (commonly called a "northbridge" chip), included in a multi-chip carrier with the one or more processors and/or supporting logic, or packaged in various alternative forms that best match the application/environment. Any of these solutions may or may not employ one or more narrow/high speed links to connect to one or more hub chips and/or memory devices.
• FIG. 6 depicts an exemplary process 600 for detection of a failing bus lane using syndrome analysis.
• the syndrome processing logic 122 of FIG. 1 receives syndromes for a plurality of frames that have been transmitted on a bus, such as upstream bus 118 of FIG. 1, where each frame includes multiple bit transfers per lane as depicted in FIGS. 2-5.
• the syndromes may be trapped values from a bus interface device, such as memory controller 110 or hub device 104.
• the syndromes can be trapped in registers 114 of FIG. 1 and a fault indication set when error detection logic 120 determines that counters 112 have exceeded a threshold to initiate more detailed syndrome analysis for isolation of error conditions.
• the syndrome processing logic 122 decodes the syndromes into error vectors under an assumption that each lane is a failing lane.
• the error vectors select specific syndrome bits in combinations that would contribute to an error condition. Since the same syndrome bits can be involved in multiple error vector calculations, it may not be possible to isolate the error to a single lane for all possible error combinations.
• the syndrome processing logic 122 identifies a bad lane in response to decoding one and only one lane with a single bit failure in the error vectors from one of the frames.
• the syndrome processing logic 122 may also determine whether verification bits for the syndromes agree about the error vectors decoded from the syndromes, where the verification bits provide a degree of redundancy in the error detection code.
• the verification bits can be used in combination with the error vectors to vote for the bad lane.
• the syndrome processing logic 122 may clear votes for all other lanes to ensure 100% error identification accuracy for the single bit failure.
• the syndrome processing logic 122 identifies the bad lane where the error vectors consistently indicate an error across the plurality of frames using an embodiment of the voting process described herein.
• the syndrome processing logic 122 compares the number of votes received to determine if an error is consistently indicated. The comparing can include calculating a ratio of lanes with a higher number of votes to lanes with a lower number of votes, and then comparing the calculated ratio relative to a ratio threshold value. For instance, a lane may be declared as the bad lane if it indicates a failure four or more times as often as other lanes.
• the comparing can be performed after a predetermined number of syndromes are analyzed to ensure a statistically significant sample set is used.
• the running counters are reset after identifying the bad lane and initiating a corrective action, such as resetting the bus interface device, using a spare lane, or retraining the bus lanes.
• the running counters are reset after a prescribed amount of time.
• the capabilities of the present invention can be implemented in software, firmware, hardware or some combination thereof.
• aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon. Any combination of one or more computer readable medium(s) may be utilized to store instructions for execution of the syndrome processing logic 122 of FIG. 1.
• the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
• a computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non- exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.
• a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.
• a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof.
• a computer readable signal medium may be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.
• Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.
• Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages.
• the program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server.
• the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
• LAN local area network
• WAN wide area network
• Internet Service Provider for example, AT&T, MCI, Sprint, EarthLink, MSN, GTE, etc.
• These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart and/or block diagram block or blocks.
• the computer program instructions may also be loaded onto a computer, other
• each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).
• the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
• each block of the block diagrams and/or fiowchart illustration, and combinations of blocks in the block diagrams and/or fiowchart illustration can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• Quality & Reliability (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Probability & Statistics with Applications (AREA)
• Detection And Correction Of Errors (AREA)
• Techniques For Improving Reliability Of Storages (AREA)
• Detection And Prevention Of Errors In Transmission (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (1)

Family

ID=44588269

Family Applications (1)

Country Status (5)

Families Citing this family (19)

Citations (3)

Family Cites Families (18)

• 2010
  • 2010-06-24 US US12/822,498 patent/US8566682B2/en active Active
• 2011
  • 2011-06-08 EP EP11725911.9A patent/EP2537095B1/en not_active Not-in-force
  • 2011-06-08 JP JP2013515811A patent/JP5623635B2/ja not_active Expired - Fee Related
  • 2011-06-08 WO PCT/EP2011/059533 patent/WO2011160956A1/en not_active Ceased
  • 2011-06-08 CN CN201180024673.5A patent/CN102893262B/zh not_active Expired - Fee Related

Patent Citations (3)

Also Published As

Similar Documents

Legal Events