Determining severity of application crashes

In one example of the disclosure, incident data indicative of a crash of an application is obtained, the crash occurring during an access of the application by a user at a computing device. A session depth at which the crash occurred is determined based upon the incident data. Time period data is obtained, the time period data indicative of a time period, following the crash, until the user next accesses the application at the computing device. A severity score for the crash is determined based upon the session depth and the time period.

BACKGROUND

Many services are delivered to consumers via applications. In examples, these applications may be composite in that several components work in combination to fulfill the service. The components themselves may be distributed across various physical and virtual devices. For instance, a smartphone, tablet, notebook or other user computing device may serve as a client side user interface component. Through that user interface component, a user may initiate a series of actions carried to be carried out by the user computing device and by server side components to fulfill the service.

DETAILED DESCRIPTION

INTRODUCTION: For a provider of an application, understanding the user experience and users' satisfaction with the application are key factors to successful implementation. With such an understanding of user experience and satisfaction, the provider of the application can better evaluate the success or likely success of the application and how to invest resources for future development. Some tools may monitor usage of an application to identify crashes that users experience while using the application. Some of such tools may prioritize the reported crashes according a number of crash occurrences or a number of users impacted. However, these tools may not comprehensively consider differences in the impact each type of crash may have on a user's experience, and the user's perception of the severity of the crash.

To address these issues, various examples described in more detail below provide a system and a method for determination of application crash severity that can determine a score reflecting the impact of each crash by analyzing a session depth at which the crash occurs along with user activity after the crash. In examples, incident data indicative of a crash of an application may be obtained, the crash occurring during an access of the application by a user at a computing device. A session depth at which the crash occurred may be determined based upon the incident data. Time period data may be obtained, the time period data being indicative of a time period, following the crash, until the user next accesses the application at the computing device. A severity score for the crash may be determined based upon the session depth and the time period. In certain examples, the severity score may be determined in consideration of application usage by a subject user that experienced the crash compared to an average usage of the application by a set of other users. In certain examples, the application usage may be measured in terms of time of usage of the application, or in terms of frequency of use of the application. In examples, crash severity scores for a set of application crashes are compared, and the crashes are prioritized relative to each other based upon the comparisons. In examples, a user experience score for the application may be determined based upon a crash severity score and a plurality of other indicators of quality of the user's experience with the application, such as speed of application launch, a speed of a user-facing application event other than launch, or a count of non-crash application errors. In examples, a crash severity score for a subject crash, prioritization information for the subject crash, and/or a user experience score determined in consideration of the subject crash may be provided to a computing device for display.

In this manner, the disclosed examples may provide an effective and efficient system and method and system for determining and providing information with respect to severity of an application crash, for prioritizing the application crash relative to a set of crashes, and for assessing user experience with respect to the crashed application. Application providers' and developers' satisfaction with products and services that evaluate user satisfaction and performance of subject applications utilizing the disclosed examples may increase. Likewise, end user satisfaction with the subject applications that are evaluated utilizing the disclosed examples, and with the physical and virtual devices that host or otherwise facilitate the subject applications, may increase.

The following description is broken into sections. The first, labeled “Environment,” describes an environment in which various examples may be implemented. The second section, labeled “Components,” describes examples of various physical and logical components for implementing various examples. The third section, labeled “Illustrative Example,” presents an example of determination of application crash severity. The fourth section, labeled “Operation,” describes implementation of various examples.

ENVIRONMENT:FIG. 1depicts an example environment100in which examples may be implemented as a system102for determination of application crash severity. Environment100is shown to include computing device104, client devices106,108, and110, server device112, and server devices114. Components104-114are interconnected via link116.

Link116represents generally any infrastructure or combination of infrastructures to enable an electronic connection, wireless connection, other connection, or combination thereof, to enable data communication between components104-114. Such infrastructure or infrastructures may include, but are not limited to, a cable, wireless, fiber optic, or remote connections via telecommunication link, an infrared link, or a radio frequency link. For example, link116may represent the internet, intranets, and any intermediate routers, switches, and other interfaces. As used herein an “electronic connection” refers generally to a transfer of data between components, e.g., between two computing devices, that are connected by an electrical conductor. A “wireless connection” refers generally to a transfer of data between two components, e.g., between two computing devices, that are not directly connected by an electrical conductor. A wireless connection may be via a wireless communication protocol or wireless standard for exchanging data.

Client devices106,108, and110represent generally any computing device with which a user may interact to communicate with other client devices, server device112, and/or server devices114via link116. Server device112represents generally any computing device to serve an application and corresponding data for consumption by components104-110and114. Server devices114represent generally a group of computing devices collectively to serve an application and corresponding data for consumption by components104-110and112.

Computing device104represents generally any computing device with which a user may interact to communicate with client devices106-110, server device112, and/or server devices114via link116. Computing device104is shown to include core device components118. Core device components118represent generally the hardware and programming for providing the computing functions for which device104is designed. Such hardware can include a processor and memory, a display apparatus120, and a user interface122. The programming can include an operating system and applications. Display apparatus120represents generally any combination of hardware and programming to exhibit or present a message, image, view, or other presentation for perception by a user, and can include, but is not limited to, a visual, tactile or auditory display. In examples, the display apparatus120may be or include a monitor, a touchscreen, a projection device, a touch/sensory display device, or a speaker. User interface122represents generally any combination of hardware and programming to enable interaction between a user and device104such that the user may effect operation or control of device104. In examples, user interface122may be, or include, a keyboard, keypad, or a mouse. In some examples, the functionality of display apparatus120and user interface122may be combined, as in the case of a touchscreen apparatus that may enable presentation of images at device104, and that also may enable a user to operate or control functionality of device104.

System102, discussed in more detail below, represents generally a combination of hardware and programming to enable determination of severity of application crashes. In some examples, system102may be wholly integrated within core device components118. In other examples, system102may be implemented as a component of any of computing device104, client devices106-110, server device112, or server devices114where it may take action based in part on data received from core device components118via link116. In other examples, system102may be distributed across computing device104, and any of client devices106-110, server device112, or server devices114. For example, components that implement the incident data engine202(FIG. 2) functionality of obtaining incident data indicative of a crash of an application, the session depth engine204functionality of determining a session depth at which the crash occurred based upon the incident data, and the time period data engine206functionality of obtaining time period data indicative of a time period, following the crash, until the user next accesses the application at the computing device may be included within computing device104. Continuing with this example, components that implement the scoring engine208functionality of determining and providing a severity score for the crash based upon the session depth and the time period may be components included within a server device112. Other distributions of system102across computing device104, client devices106-110, server device112, and server devices114are possible and contemplated by this disclosure. It is noted that all or portions of system102to enable determination of severity of application crashes may also be included on client devices106,108or110.

COMPONENTS:FIGS. 2 and 3depict examples of physical and logical components for implementing various examples. InFIG. 2various components are identified as engines202,204,206,208,210, and212. In describing engines202-212focus is on each engine's designated function. However, the term engine, as used herein, refers generally to a combination of hardware and programming to perform a designated function. As is illustrated later with respect toFIG. 3, the hardware of each engine, for example, may include one or both of a processor and a memory, while the programming may be code stored on that memory and executable by the processor to perform the designated function.

FIG. 2is a block diagram depicting components of a system102to enable determination of severity of application crashes. In this example, system102includes incident data engine202, session depth engine204, time period data engine206, scoring engine208, prioritization engine210, and experience engine212. In performing their respective functions, engines202-212may access a data repository, e.g., any memory accessible to system102that can be used to store and retrieve data.

In an example, incident data engine202represents generally a combination of hardware and programming to obtain incident data indicative of a crash of an application, wherein the crash is occurring during an access of the application by a user at a computing device. As used herein, “application” refers generally to a software application executing at a client computing device. In an example, the application may be a rich client application. As used herein, a “rich client application” refers generally to an application executing in a computing device that that retrieves data via the Internet. In an example, a rich client application may be written in a programming language such as C/C++ or Java, which has access to some or all of the functions in the computer, and which executes stand-alone without the need of a web browser. In another example, the application could be a web application. As used herein, a “web application” refers generally to an application that is coded in a browser-supported language (such as XML, HTML, or HTML with JavaScript) and is reliant on a web browser application to render the application executable or presentable. Examples of web pages that may include or facilitate web applications are webmail pages, online search engine pages, online sale pages, auction sites pages, and wiki pages. As used herein, a “crash” of an application refers generally to the application experiencing an error that causes a user experience of the application exiting, closing, or freezing without a user instruction to close, exit, or pause the application. As used herein, a “computing device” may be a server, computer networking device, chip set, desktop computer, workstation, mobile computing device, or any other processing device or equipment. The terms “mobile device” and “mobile computing device” are used synonymously, and refer generally to any portable computing device, including, but not limited to, a notebook computer, tablet computer, or smartphone.

Session depth engine204represents generally a combination of hardware and programming to determine a session depth at which the crash occurred based upon the obtained incident data. As used herein, a “session” refers generally to a period during which a user interacts with a particular application. The session may be measured in various ways, including but not limited to a passage of a time period, a task (e.g., an editing task) being performed, or a type of content being accessed and/or edited via the application. As used herein, a “session depth” refers generally to a count of stages of a session at a point a crash occurs or occurred.

Continuing with the example ofFIG. 2, time period data engine206represents generally a combination of hardware and programming to obtain time period data indicative of a time period, following the crash, until the user next accesses the application at the computing device. In examples, the time period data may be obtained from a mobile computing device or other computing device at which the user accesses the application. In other examples, the time period data may be obtained from a server or other computing device that hosts the application that is accessed by the user.

Scoring engine208represents generally a combination of hardware and programming to determine and provide a severity score for the crash based upon the session depth and the time period. As used herein, a “severity score” refers generally to a rating or a grade, including but not limited to a numerical or alphabetical score, for the severity of a crash. For instance, a score of “10” on a scale of “1 to 10” may indicate a highest crash severity, or a score of “A” on a scale of “A-J” may indicate a highest crash severity.

Other severity score possibilities are possible and are contemplated by this disclosure. In examples, scoring engine208may determine the severity score utilizing a formula with a construct such that, with other factors being equal, an increase in the determined session depth results in an increase in the determined severity score. In this manner, the formula is reflective of an assumption that the farther a user is in the flow of an application at the time of a crash, the more severe is the impact of the crash upon the user.

In examples, scoring engine208may determine the severity score utilizing a formula with a construct such that, with other factors being equal, an increase in the time period until the user next accesses the application results in an increase in the determined severity score. In this manner, the formula is reflective of an assumption that a reduction in the user's accessing of the application correlates with the user's abandonment of the application.

In a particular example, the crash analyzed by scoring engine208is a crash experienced by a subject user, and the incident data obtained by incident engine202includes data indicative of a first measurement of application usage by the subject user compared with a second measurement that is an average usage of the application by other users. In examples the first measurement and second measurement may be measurements of usage occurring after the crash of the application. In other examples, the first measurement and second measurement may be measurements of a time of usage of the application, or may be measurements of a frequency of usage of the application.

In examples, scoring engine208provides the determined crash severity score to a computing device for display, wherein the receiving computing device is a device distinct from the computing device at which the application crash occurred. For instance, scoring engine208may execute at a server computing device such as server device112(FIG. 1) or a group of servers such as server devices114(FIG. 1), and send, via link116, the determined crash severity score to-a distinct computing device, such as a client notebook computing device106, for display to a user via a display component included in or connected to the distinct computing device. As used herein, “display” refers generally to exhibition or presentation caused by a computer for the purpose of perception by a user. In examples, a display may be a display to be presented at a computer monitor, touchscreen, projection device, or other electronic display component. As used herein, a “display component” refers generally to any combination of hardware and programming to exhibit or present content, a message, or other information for perception by a user, and can include, but is not limited to, a visual, tactile or auditory display. In particular examples, the display may be in a form to be presented at a monitor, display screen, or touchscreen component of a computing device. In examples, the display may include a graphic user interface to enable user interaction with the display. As used herein, “graphic user interface” and “GUI” are used synonymously, and refer generally to any type of display caused by an application that can enable a user to interact with the application via visual properties of the display.

System102may include a prioritization engine210. In these examples, prioritization engine210represents generally a combination of hardware and programming to compare a set of subject severity scores, and to prioritize the crashes relative to each other based upon the comparisons.

In examples, prioritization engine210is to provide the information regarding prioritization of the crashes to a computing device for display, wherein that computing device is a device distinct from the computing devices at which the application crashes occurred. For instance, prioritization engine210may execute at a server computing device such as server device112(FIG. 1) or a group of servers such as server devices114(FIG. 1), and send, via link116, the crash prioritization information to a separate client notebook computing device106, for display to a user.

System102may include an experience engine212. In these examples, experience engine212represents generally a combination of hardware and programming to determine and providing a user experience score for the application based upon a determined crash severity score and based upon a set of indicators of quality of the user's experience with the application other than indicators relating to application crashes. In examples, the set of other, non-crash, quality indicators may include a measured speed of launch of the application. In other examples, the set of other, non-crash, quality indicators may include a measured speed of a user-facing application event other than launch (e.g., a search result or other response time, a screen refresh time, a time to complete a cart checkout event, etc.). In other examples, the set of other, non-crash, quality indicators may include a count of application errors for events other than application crashes (e.g., returns of incorrect results, slow performance or lags, display errors, etc.).

In examples, experience engine212is to provide the user experience score to a computing device for display, wherein that computing device is a device distinct from the computing devices at which the application crashes occurred. For instance, experience engine212may execute at a server computing device such as server device112(FIG. 1) or a group of servers such as server devices114(FIG. 1), and send, via link116, the user experience information to a separate client notebook computing device106, for display to a user.

In examples, incident data engine202may obtain incident data and/or time period data engine204may obtain the time period data over a link116via a networking protocol. In examples, scoring engine208may provide a severity score for a crash, prioritization engine210may provide a prioritization of crashes, and/or experience engine212may provide a user experience score over a link116via a networking protocol. In examples the networking protocols may include, but are not limited to, Transmission Control Protocol/Internet Protocol (“TCP/IP”), HyperText Transfer Protocol (“HTTP”), and/or Session Initiation Protocol (“SIP”).

In the foregoing discussion ofFIG. 2, engines202-212were described as combinations of hardware and programming. Engines202-212may be implemented in a number of fashions. Looking atFIG. 3the programming may be processor executable instructions stored on a tangible memory resource322and the hardware may include a processing resource324for executing those instructions. Thus memory resource322can be said to store program instructions that when executed by processing resource324implement system102ofFIG. 2.

Memory resource322represents generally any number of memory components capable of storing instructions that can be executed by processing resource324. Memory resource322is non-transitory in the sense that it does not encompass a transitory signal but instead is made up of more or more memory components to store the relevant instructions. Memory resource322may be implemented in a single device or distributed across devices. Likewise, processing resource324represents any number of processors capable of executing instructions stored by memory resource322. Processing resource324may be integrated in a single device or distributed across devices. Further, memory resource322may be fully or partially integrated in the same device as processing resource324, or it may be separate but accessible to that device and processing resource324.

In one example, the program instructions can be part of an installation package that when installed can be executed by processing resource324to implement system102. In this case, memory resource322may be a portable medium such as a CD, DVD, or flash drive or a memory maintained by a server from which the installation package can be downloaded and installed. In another example, the program instructions may be part of an application or applications already installed. Here, memory resource322can include integrated memory such as a hard drive, solid state drive, or the like.

InFIG. 3, the executable program instructions stored in memory resource322are depicted as incident data module302, session depth module304, time period data module306, scoring module308, prioritization module310, and experience module312. Incident data module302represents program instructions that when executed by processing resource324may perform any of the functionalities described above in relation to incident data engine202ofFIG. 2. Session depth module304represents program instructions that when executed by processing resource324may perform any of the functionalities described above in relation to session depth engine204ofFIG. 2. Time period data module306represents program instructions that when executed by processing resource324may perform any of the functionalities described above in relation to time period data engine206ofFIG. 2. Scoring module308represents program instructions that when executed by processing resource324may perform any of the functionalities described above in relation to scoring engine208ofFIG. 2. Prioritization module310represents program instructions that when executed by processing resource324may perform any of the functionalities described above in relation to prioritization engine210ofFIG. 2. Experience module312represents program instructions that when executed by processing resource324may perform any of the functionalities described above in relation to experience engine212ofFIG. 2.

ILLUSTRATIVE EXAMPLE

FIGS. 4 and 5, in view ofFIGS. 1 and 2, illustrate an example of a system102for determining severity of application crashes. In examples, system102may be hosted at a computer system such as server device112(FIG. 1) or distributed over a set of computer systems such as server system114(FIG. 1). Beginning atFIG. 4, in this example, system102, for each of a plurality of crashes occurring during access of the application by a user at a mobile computing device of a set of mobile computing devices408, receives, retrieves or otherwise obtains via a network116incident data402indicative of the crash. In this example, we assume that users404interact with an application406at mobile computing devices408, and the incident data402includes data over a thirty day period indicative of the following Crashes A-C experienced by the users404at the mobile computing device:Crash A: User1111at Day 1: launched app→crashed. Launched again same Day 1.Crash B, User1243at Day 5: launched app→sign-in→banking→select→check deposit→scan→crashed. Launched again 2 days later at Day 7.Crash C, User1359at Day 1: launched app→sign-in→products→select→checkout→pay→crashed. User never returned to application during test period.

System102determines a session depth410at which each of Crash A, Crash B, and Crash C occurred. In this example, the session depth for Crash A is determined to be at depth “0”, the session depth for Crash B is determined to be at depth “5”, and the session depth for Crash C is determined to be at depth “5.”

Continuing atFIG. 4, system102, for each of Crash, A, Crash B, and Crash C, obtains time period data indicative of a time period, following the crash, until the user next accesses the application at the first computing device. In this example, the time period for the next access of the application by the user is determined to be zero days (Day 1 to Day 1) for Crash A. The time period for the next access of the application by the user404is determined to be two days (Day 5 to Day 7) for Crash B. The time period for the next access of the application by the user404is determined to be 31 days (Day 1 to “user never returned”) for Crash C. In this example, “31 days” is the default value when it is determined that the user did not return to the subject application during the 30 day measured timeframe.

System102determines, and provides to client computing device414via network116, a severity score416for each of Crash A, Crash B, and Crash C based upon the determined session depths410and the determined time period412. In this example, we assume system102calculates a severity score416according to the following formula:
Severity Score=Weight 50% (Session Depth)+Weight 50% (Re-use Time Period)

It should be noted that other weightings and other formulas are possible and are contemplated by this disclosure. For instance, in other examples incident data402may include usage gap data indicative of application usage by a first user of the subject application406compared to average usage of the subject application by a set of other users, and in such examples system102may determine crash severity scores according to a formula that takes into account such usage gap data.

Continuing atFIG. 4, system102compares the severity scores416to prioritize Crash A, Crash B, and Crash C relative to each other based upon the comparisons. In this example, system102prioritizes the set of crashes according to the crash severity scores416, such that Crash C has the highest priority, Crash B has secondary priority, and Crash A has the lowest priority of the set of three crashes. System102provides the prioritizations to client computing device414via network116.

Continuing atFIG. 4, in certain examples, system102may determine and provide to client computing device414via network116a user experience score420for the subject application406based upon the crash severity scores416and a set of other indicators422of quality of the user's experience with the subject application406. In examples, the set of other indicators of quality of the experience of a user404with the subject application may include, but are not limited to, speed of launch of the subject application, speed of a user-facing application event other than launch (e.g. an application calculation period, or an indicator of accuracy of results returned by the subject application), and a count of subject application errors that are not crash errors.

FIG. 5, in view ofFIG. 4, is an example of a display502to be presented at client computing device414(FIG. 4), e.g., a display for the benefit of an application provider or application developer user424(FIG. 4). The display502includes an aggregation of six hundred occurrences504of the “Launch”506, “Check Deposit Scan”508, and “Crash Severity Score”510crashes represented by Crash A, Crash B, and Crash C, respectively, the aggregation compiled by system102tracking crashes of the subject application406experienced by two hundred fifty users404of the subject application. In this manner, the severity of each of the crashes was determined in consideration of how deep the user was in the user's flow at the time of the crash, and the length of time before the use returned to reuse the application after experiencing the crash. In this example, the display502additionally includes a user experience score420for the subject application406determined based upon the crash severity scores416(FIG. 4) and a set of other indicators422(FIG. 4) of quality of the user's experience with the subject application.

OPERATION:FIG. 6is a flow diagram of implementation of a method to determine application crash severity. In discussingFIG. 6, reference may be made to the components depicted inFIGS. 2 and 3. Such reference is made to provide contextual examples and not to limit the manner in which the method depicted byFIG. 6may be implemented. Incident data indicative of a crash of an application is obtained. The crash is a crash occurring during an access of the application by a user at a computing device (block602). Referring back toFIGS. 2 and 3, incident data engine202(FIG. 2) or incident data module302(FIG. 3), when executed by processing resource324, may be responsible for implementing block602.

A session depth at which the crash occurred is determined based upon the incident data (block604). Referring back toFIGS. 2 and 3, session depth engine204(FIG. 2) or session depth module304(FIG. 3), when executed by processing resource324, may be responsible for implementing block604.

Time period data is obtained. The time period data is indicative of a time period, following the crash, until the user next accesses the application at the computing device (block606). Referring back toFIGS. 2 and 3, time period data engine206(FIG. 2) or time period data module306(FIG. 3), when executed by processing resource324, may be responsible for implementing block606.

A severity score for the crash is determined and provided based upon the session depth and the time period (block608). Referring back toFIGS. 2 and 3, scoring engine208(FIG. 2) or scoring module308(FIG. 3), when executed by processing resource324, may be responsible for implementing block608.

FIG. 7is a flow diagram of implementation of a method to determine application crash severity that includes prioritization based upon crash severity scores. In discussingFIG. 7, reference may be made to the components depicted inFIGS. 2 and 3. Such reference is made to provide contextual examples and not to limit the manner in which the method depicted byFIG. 7may be implemented. For each of a plurality of crashes occurring during access of the application by a user ata first computing device, incident data indicative of the crash is obtained (702). Referring back toFIGS. 2 and 3, incident data engine202(FIG. 2) or incident data module302(FIG. 3), when executed by processing resource324, may be responsible for implementing block702.

A session depth at which the crash occurred is determined for each of the crashes based upon the incident data (block704). Referring back toFIGS. 2 and 3, session depth engine204(FIG. 2) or session depth module304(FIG. 3), when executed by processing resource324, may be responsible for implementing block704.

Time period data is obtained for each of the crashes, the time period data indicative of a time period, following the crash, until the user next accesses the application at the first computing device (block706). Referring back toFIGS. 2 and 3, time period data engine206(FIG. 2) or time period data module306(FIG. 3), when executed by processing resource324, may be responsible for implementing block706.

A severity score for each of the crashes is determined based upon the session depth and the time period and is provided (block708). Referring back toFIGS. 2 and 3, scoring engine208(FIG. 2) or scoring module308(FIG. 3), when executed by processing resource324, may be responsible for implementing block708.

The subject severity scores are compared to prioritize the crashes relative to each other based upon the comparisons, and the prioritization of the crashes is provided to a second computing device for display (block710). Referring back toFIGS. 2 and 3, prioritization engine210(FIG. 2) or prioritization module310(FIG. 3), when executed by processing resource324, may be responsible for implementing block710.

FIG. 8is a flow diagram of implementation of a method for determining severity of application crashes that includes determining of user experience scores. In discussingFIG. 8, reference may be made to the components depicted inFIGS. 2 and 3. Such reference is made to provide contextual examples and not to limit the manner in which the method depicted byFIG. 8may be implemented. Incident data indicative of a crash of an application is obtained. The crash is a crash occurring during an access of the application by a user at a computing device (block802). Referring back toFIGS. 2 and 3, incident data engine202(FIG. 2) or incident data module302(FIG. 3), when executed by processing resource324, may be responsible for implementing block802.

A session depth at which the crash occurred is determined based upon the incident data. Referring back toFIGS. 2 and 3, session depth engine204(FIG. 2) or session depth module304(FIG. 3), when executed by processing resource324, may be responsible for implementing block804.

Time period data is obtained. The time period data is indicative of a time period, following the crash, until the user next accesses the application at the computing device (block806). Referring back toFIGS. 2 and 3, time period data engine206(FIG. 2) or time period data module306(FIG. 3), when executed by processing resource324, may be responsible for implementing block806.

A severity score is determined for the crash based upon the session depth and the time period (block808). Referring back toFIGS. 2 and 3, scoring engine208(FIG. 2) or scoring module308(FIG. 3), when executed by processing resource324, may be responsible for implementing block808.

A user experience score for the application is determined, based upon the crash severity score and a plurality of other indicators of quality of the uses experience with the application, and provided (block810). Referring back toFIGS. 2 and 3, experience engine212(FIG. 2) or experience module312(FIG. 3), when executed by processing resource324, may be responsible for implementing block810.

CONCLUSION:FIGS. 1-8aid in depicting the architecture, functionality, and operation of various examples. In particular,FIGS. 1, 2and,3depict various physical and logical components. Various components are defined at least in part as programs or programming. Each such component, portion thereof, or various combinations thereof may represent in whole or in part a module, segment, or portion of code that comprises executable instructions to implement any specified logical function(s). Each component or various combinations thereof may represent a circuit or a number of interconnected circuits to implement the specified logical function(s). Examples can be realized in any memory resource for use by or in connection with processing resource. A “processing resource” is an instruction execution system such as a computer/processor based system or an ASIC (Application Specific Integrated Circuit) or other system that can fetch or obtain instructions and data from computer-readable media and execute the instructions contained therein. A “memory resource” is any non-transitory storage media that can contain, store, or maintain programs and data for use by or in connection with the instruction execution system. The term “non-transitory” is used to clarify that the term media, as used herein, does not encompass a signal. Thus, the memory resource can comprise any one of many physical media such as, for example, electronic, magnetic, optical, electromagnetic, or semiconductor media. More specific examples of suitable computer-readable media include, but are not limited to, hard drives, solid state drives, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory, flash drives, and portable compact discs.

Although the flow diagrams ofFIGS. 6, 7 and 8show specific orders of execution, the order of execution may differ from that which is depicted. For example, the order of execution of two or more blocks or arrows may be scrambled relative to the order shown. Also, two or more blocks shown in succession may be executed concurrently or with partial concurrence. Such variations are within the scope of the present disclosure.

The present disclosure has been shown and described with reference to the foregoing examples. It is to be understood, however, that other forms, details and examples may be made without departing from the spirit and scope of this application that is protected by the following claims. The features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or the blocks or stages of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features, blocks and/or stages are mutually exclusive.