Software applications may store object that include content, such as different documents, articles, tasks, etc. Such objects may be tagged with data strings to point out to specific characteristics of the objects. For example, an article discussing current trends in car manufacturing may be tagged with a keyword such as the string “car”, or “manufacturing”, or even “car manufacturing”. In such manger, the object may be distinguished from the other objects, which may discuss manufacturing related to other products, such as aircraft, household appliances, etc. There are different types of software application that may utilize tags for their content. A tag represents additional criterion for identifying a particular object, and several tags may be assigned to an object. Tags may be non-hierarchical keywords or terms that may be assigned to a piece of information, such as a bookmark, an image, a file, a folder, etc. This helps describe an item and helps with browsing and/or searching. Tags may be depicted and visualized into a tag cloud, which is a visual representation of text data.
The claims set forth the embodiments with particularity. The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for maintaining tags assigned to artifacts are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. One skilled in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one or more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
In one embodiment, the set_of_artifacts 115 share a common characteristic and may be tagged with a set of tags 103, including tag_A, tag_B, until tag_H. For example, the set_of_artifacts 115 may be a set of articles regarding fashion, and tag_A may be “fashion”, tag_B may be “hairstyling”, tag_H may be “make-up”. The set_of_artifacts 115 may include artifacts art_1 117, art_2 118, until art_k 119. The art_1 117 is tagged with the tag_A, and the tag_B, the art_2 118 is tagged with the tag_B. The art_K 119 is tagged with the tag_A, which is part of the set of tags 103, which is particularly defined for the set_of_artifacts 115. The art_K 119 is further tagged with tag_I 107, which is not included in the set of tags 103. Further, the tag_I 107 may be defined as a tag associated with the set_of_artifacts 120. The art_L 121 is tagged with the tag_I 107. If a new artifact is about to be included in the artifacts 110, for example, in the set_of_artifacts 115, a tag from the tags 103 connected with the set_of_artifacts 115, may be suggested for the new artifact. However, the new artifact may not be assignED with a tag from the suggested tags associated with the set 115, and another tag may be determined for assigning.
In one embodiment, a tag_P 112 may be included in the tags 105 and the tag_P 112 may be associated with a particular set of artifacts, for example, based on a semantic correspondence between the string representing the tag_P 112 and a common characteristic that the content of artifacts from the set of artifacts share.
The artifacts 110 and the tags 105 may be stored and maintained by a software application that may have a user interface (UI) 130 that displays a list of tags 135 that is generated on the basis of the maintained tags 105. The UI 130 may further present a list of artifacts 140 generated based on the artifacts 110. The presented list of tags 135 and the presented list of artifacts 140 may be defined on a criterion for selection for presentation, such as limiting to a particular number of objects, or based on priority or other ranking, date and time, alphabetical order, etc. The UI 130 may further provide an “operations” 145 section to select an operation to be performed in relation to the artifacts 110 and the tags 105. For example, “choose an artifact for tagging” operation 150 may be provided through the UI 130. With the operation 150, an artifact from the list of artifacts 140 may be selected, and a tag from the tags 105 may be suggested for tagging the selected artifact. In another embodiment, other operations may be provided in the “operations” 145 section—defining a new tag to be included in the tags 105, filtering the list of artifacts 140 through selecting a tag from the list of tags 135 to generate a filtered list of artifacts that are assigned with the selected tag, etc.
In one embodiment, the software application that maintains artifacts and tags may be an innovation management system that utilizes tags as a central structuring element. The innovation management system targets different stages of the lifecycle of innovation management. The lifecycle includes steps such as generation of ideas, their submission into campaigns, their discussion and collaborative work in communities, their evaluation by expert groups, the portfolio process of innovation projects, inclusion of ideas into products, up to successful market introduction of the products. The innovation management system may contain ideas, campaigns, users, and other artifacts. There can be a huge number of artifacts, which is difficult to be maintained and to be browsed. In order for a user working with the innovation management system to be able to select groups of ideas, ideas and/or other artifacts, the artifacts may be tagged. Such a tag can be used to find easily all information associated with the artifacts that have the respective descriptive tag assigned.
In the innovation management system 202 there may be a huge number of ideas and also many campaigns providing information in an unstructured manner. Having the information structured makes it more useful when working with the innovation management system 202. Structuring is also useful during searching for relevant information and respectively for relevant artifacts. Through utilizing tags and tag assignment options provided by the innovation management system 202, all information (ideas, campaigns, etc.) may be found easily through searching relevant tags and navigating between artifacts that are associated with the relevant tags. A tag may be a string that is assigned to an idea. The tag represents an additional criterion for distinguishing the artifact from rest of the artifacts in the innovation management system 202. A tag may be used to identify and group ideas and/or other artifacts. An idea or other artifact may have several tags. A single tag may be assigned to several artifacts. A tag may comprise one or more words. The words may be defined with normal characters as well as numbers and special characters. There may be some restrictions in syntaxes used for defining tags. For example, a tag may be restricted to comprising characters such as “,” or “;”. In addition, if a tag is defined with leading and training whitespace, they may be removed from the tags during the process of defining the tags in the innovation management system 202.
In one embodiment, the innovation management system 202 may have a set of users registered and authorized to work with the system 202. The innovation management system 202 may classify a user as a separate artifact. Tags may be assigned to existing artifacts or during artifacts' creation process in the innovation management system 202. The front-end user 205 may interact with the innovation management system 202, for example through a UI of a front-end office of the innovation management system 202. The front-end user 205 may be, for example, an idea submitter. The idea coach 210 may interact with the innovation management system 202, for example, through a UI of a back-end office of the innovation management system 202. Specialists working professionally with ideas and campaigns may use the back-end office. Examples of back-office users apart from the idea coach 210 may be a campaign manager or a campaign administrator, an innovation manager, etc. For example, the idea coach 210 may process the ideas of a given campaign, set up in the innovation management system 202. Idea coaches may be authorized to process and evaluate ideas in the back-end office of the innovation management system 202. The idea coaches may assign themselves or other idea coaches to ideas. In one embodiment, users that have been previously assigned as idea coaches to a campaign are the only users that may be assigned as an idea coach to an idea part of the campaign. Further, campaign managers may set up and monitor campaigns; innovation managers may administer users, configure phases and evaluation methods for campaigns, etc.
In one embodiment, at use case 215, the front-end user 205 or the idea coach 210 may assign a tag to an idea. The assignment of tags may be performed through either the front-end office UI of the innovation management system 202 or the back-end office UI of the innovation management system 202 that comprises artifacts, such as ideas, campaigns, user, etc. The assigning of tags as suggested at 215 may be limited to only a part of the front-end users that are authors or coauthors of the particular artifacts that is tagged, e.g. the idea. In one embodiment, the assigning of the tag at use case 215 may be performed at 235 through selecting the tag from a list of available tags in the innovation management system 202. The list of available tags may be such as the tags 105,
In another embodiment, when assigning the tag at 215, the tag may be selected at 245 from a list of proposed tags that are not currently stored in the innovation management system 202. For example, the list of new proposed tags may be generated based on encountered keywords in the selected idea for tagging at 215. Further, the list of proposed tags that is suggested at 245 may be generated based on a text analysis over the content of the idea, e.g. idea's title, idea's description, idea's attachments, etc. The list of proposed tags may further include tags that are defined through a similarity search performed over the idea selected for tagging and rest of the ideas handled by the innovation management system 202. A similarity search function may be provided by the innovation management system 202 to compute a similarity between the selected idea at 215 and the rest of the ideas in the innovation management system 202. Based on the computed similarity, a list of tags assigned to similar ideas may be provided. For example, the list of tags of similar ideas may be ranked and tags coming from more similar ideas may come first in the list. The similarity search function relies on the existing tags assigned to ideas in the innovation management system 202 to provide tag suggestions. The innovation management system 202 may provide and display a list of similar tags, together with information about their usage and a degree of similarity between the each couple of similar tags. The described examples herein are not limiting the way a list of proposed tags is generated and are only presented for illustration purposes. Further, tag assignment may be performed in a similar manner to other artifacts apart from ideas (campaigns, users, etc.) in the innovation management system 202.
At use case 220, the front-end user 205 or the idea coach 210 may create a new tag 220. The new tag 220 may be entered in the innovation management system 202, for example, in a storage or a database, where other maintained tags are stored. When creating the new tag at 220, a list of new proposed tags may be suggested at 250 for selection, for example, by the front-end user 205. The list of new proposed tags may be the one that is suggested when the tag is assigned to the idea at 215. The list of new proposed tags may be suggested when the list of proposed tags is suggested at 245. In one embodiment, at 220, the new tag is created and then it may be used for assigning to artifacts. In another embodiment, with the initiation for assigning a tag to an idea at 215, a new tag may be created and assigned simultaneously. The newly created tag at 220 may be assigned to an idea in a corresponding manner to the assignment of a tag to an idea as suggested in the use case 215, where the newly created idea at 220 may be part of the list of available tags suggested at 235.
In one embodiment, the idea coach 210 may assign tags simultaneously to a number of artifacts from the innovation management system 202 at use case 225, which means that mass assigning of tags to artifacts, such as ideas, is performed. The idea coach 210 at 230 may join existing tags based on similarity between the tags. Tags may be strings combining one or more words or abbreviations, so similarity may be interpreted as linguistic similarity or semantic similarity. One or more existing tags may be linked based on a criterion for joining tags, and thus to reconfigure existing tags by merging the linked tags. The innovation management system 202 may provide and display a list of similar tags, together with information about their usage and a degree of similarity between the each couple of similar tags. Based on existing similarities between tags, the idea coach 210 may further join similar tags. Joined similar tags may be unified. For example, a leading tag may be selected and used to replace and unify the joined similar tags.
In one embodiment, in order to support tag-based navigation, tag clouds may be offered and displayed on the UI 300. A tag cloud 350 is displayed on the UI 300. The tag clouds may render a limited number of tags in different sizes. With a tag cloud “more relevant” tags may be displayed bigger than “less relevant” tags. A relevancy of a tag may be associated with a frequency of usage of the tag and selectiveness of the tag. For example, depending on the task of a user during navigating in the innovation management system 305, the relevance of the tags may depend on different criteria. If the user wants to learn what is going on in a campaign, the tags that are more frequently used are more relevant to the user. If a user wants to search for specific ideas, the tags that are more selective are more relevant to the user. The tag cloud 350 may be defined based on relevancy of tags in the innovation management system 305, which is defined according to frequency of use of the tags and selectiveness of the tags, and a limited number of tags for the tag cloud 350. In the tag cloud 350, the limited number of tags defined is 5. The tags included in the tag cloud 350 are X, Z, Application, onDemand, UI. The tags are displayed with a different size that corresponds to the relevance of the tag, as computed in the innovation management system 305. For example, tags with bigger size are tags that are more relevant according to the innovation management system 305. When navigating through tags in the innovation management system 305, one or more tags may be selected, for example, from the displayed tag cloud 350. The selected tags may be presented in block 330, which includes all tags that are selected for filtering the ideas to be displayed in the pool_of_ideas 320. The ideas that are filtered through the selection of tags 330 are Idea_1 335, Idea_2 340, and Idea_3 345. Idea_2 340 is also assigned with a Tag A. The Tag A may be selected and included into the selected tags for filtering 330. In another embodiment, through a search function provided by the innovation management system 305, ideas may be filtered and displayed in the pool_of_ideas 320. The displayed ideas resulting from the search may be tagged with different tags. In one embodiment, through selecting a tag of an idea displayed in the pool_of_ideas 320, a filter may be created that adjusts the displayed ideas in the pool_of_ideas 320. The display of ideas is adjusted to those that are assigned with the selected tag for filtering. When tag clouds are used for navigation aids, the terms or strings corresponding to the tags are hyperlinked to objects associated with the tag.
At 405, a request is received for assigning a tag to an artifact. With the request, a targeted artifact is determined. At 410, based on the requested artifact for tagging, a list of suggested tags is provided. The list of suggested tags may be a list of all available tags that are existing and associated with other artifacts maintained by the application. In another embodiment, when the requested artifact is part of a predefined group of artifacts, the list of suggested tags may include only the tags that are associated with that predefined group. For example, if the artifact is an idea in an innovation management system, and the idea is part of a campaign, only the tags that are associated with the campaign may be suggested. At 415, a selection of one or more tags is received for assigning to the requested artifact. At 420, the assignment of the one or more tags to the requested artifacts is stored. The tag is added to the requested artifact. By adding the tag, if it does not exist so far in the application that maintains the artifact, the tag is created and stored. The relationship between the artifact and the tag has an explanatory character for the artifact.
In one embodiment, a completely free tag assignment may lead to a wide variety of tags, which mean the same or describe a common criterion for tagging. For example, “UI design”, “usability”, “UI improvements”, etc. may be a couple of tags inside an application that are related. With a growing number of tags, there may be a need for tag maintenance functions, provided by the application, for the purpose to maintain a clear set of tags. There may be a function that suggests related tags from the application that may be reviewed and maintained. For example, the suggested tags may be unified, if they comply with a criterion for unification. Further, the suggested tags may be renamed, as they may have some typo mistakes in their definition, or they may not comply with a desired syntax used for defining tags in the application. Therefore, functions such as a delete function, a rename function, a merge function, or a unification function, etc. may be provided to maintain tags assignments to artifacts in the application. Users in different roles may utilize these functions to cleanse the set of tags maintained by the system.
At 435, from the stored tags, determine a previously existing tag that is similar to the stored new defined tag at 430, and associated the new defined tag with the similar tag. The similarity between the two tags may be determined based on a similarity function available through the application, maintaining the artifacts and the tags. Similarity between tags may appear when for example two tags are alternative representations of a criterion for tagging artifacts. Another example, may suggest that similarity between tags appear and may be detected when there is a typographical error in a tag definition, which may lead to the existence of a couple of tags meaning the same but spelled differently. If the application is the innovation management system 202 from
At 440, a first request to delete a selected tag is received. At 445, if the selected tag is assigned to an artifact, a warning message is provided. For example, the warning message is displayed on the UI of the application maintaining the artifacts and the tags. The selected tag may be deleted and if the tag was assigned to an artifact, the association between the tag and the artifact is also deleted. An exemplary schema for deleting tags is described below in relation to
In one embodiment, unification may be performed over a list of tags that are determined as similar. Similarity may be detected for cases where typos, etc. lead to tags that are different but mean the same. For example, if an artifact is related fashion, then an exemplary tag may be “fashion”, and one may type “faschion” by mistake, therefore there may be two tags with a similar meaning—fashion and faschion. From the list of similar tags, a user may be able to select tags for unification. The unification may comprise deletion of one or more of the tags included in the list of similar tags and replacing them with one unifying tags. The list of similar tags may be defined through identifying a tag similarity between existing tags. The tag similarity may be determined by means of a trigram index and by means of damerau-levenshtein metric. Before tags are compared with regard to similarity, they may be normalized through converting to lower case and omitting a leading and a trailing space. Two tags are considered potentially similar if they share at least one common trigram after normalization. A trigram may be series of three characters, e.g. “abc”, “ab1”. If they are considered potentially similar, an edit distance between the two tags is computed through the damerau-levenshtein distance metric. The damerau-levenshtein distance is a distance between two strings, i.e., finite sequence of symbols, given by counting the minimum number of operations needed to transform one string into the other, where an operation is defined as an insertion, deletion, or substitution of a single character, or a transposition of two adjacent characters. A character insertion, deletion or substitution is weighted by +1 distance. Transpositions are weighted with +2 distance. For performance reasons the edit distance computation may be limited to edit distance of a certain number. For example, every comparison of two strings with an edit distance greater than 4 may be considered as not similar.
In one embodiment, the application maintaining the tags and artifacts may provide a function to compute a similarity index for all tags. The similarity index may include determination of a trigram for a particular tag and computation of an edit distance between the particular tag and a tag from rest of the tags. Then, if a trigram exists, edit distances may be computed. The function may be called every time a tag changes or a new tag is created. The similarity index function may be triggered for each change of any tag. When computing the similarity index, any index entries existing for a given tag may be removed and replaced by the newly computed similarity index. For example, if an action from a user to a tag is for renaming of the tag, then a redetermination of existence of a trigram of the normalized tag is triggered. Based on the determination, edit distance may be recomputed. The results may be stored in corresponding indices. The function may compute the index entries for all tags at once. For example, two tags—“test” and “west” are evaluated for similarity based on the function described above to compute a similarity index. The following steps may be performed: 1) tags are normalized, which in the current example does not change them, as there are no whitespaces; 2) a trigram is determined—“est”; 3) due to the fact that a trigram exists, an edit distance is computed, which is 1, as the only operation that is performed in order to transform “test” into “west”, is to substitute “t” with “w”, which is defined as distance of 1. If we take a second example, of computing a similarity index between “test” and “what”, then the steps may be as follows: 1) normalization of the tags—they are not changed as there are no whitespaces; 2) a trigram is determined—there is no trigram that is shared by both of the tags, therefore, it may be concluded that these tags are nor similar. However, for the sake of the example, if an edit distance between “test” and “what” is about to be computed, then the edit distance is determined to be 3, as “t” is about to be replaced with “w”, “e” is about to be replaced with “h”, and “s” is about to be replaced with “a”, which all adds up into distance of 3 (1+1+1=3).
Further, existing tags may be grouped into clusters, which define that they are with high correlation. For example, an artifact assigned with a tag A have very often tag B. Tags within a cluster may be subject to suggestion for unification. For example, the third requests at 460 may be a unification request sent for a set of tags that form a tag cluster.
At 465 an updated tag assignment is stored for the requested set of tags for unification at 460. During the unification, the assignments of the set of tags are adjusted according to the received third request. An exemplary schema for unification of a set of tags is described below in relation to
At 630, a first ranked list of tags is determined. The first ranked list of tags is determined by a first ordering of tags that exist in the application. The first ordering of the tags is based on the frequency of use of a tag from all of the tags that are being ordered. For example, the frequency of a tag is computed by counting the number of artifacts that are assigned with the tag. At 635, a second ranked list of tags is determined. The second ranked list of tags is defined by a second ordering of the tags that exist in the application. The second ordering of the tags is based on selectiveness of a tag from all of the tags in the application. The selectiveness may be defined by means of a binary entropy function H(p) (function (1)) for a given tag. Selectiveness is computed in the following manner according to function (1), function (2), and function (3):
Selectiveness may be defined as information content related to existence (or presence) of a tag assigned to a particular artifact. The binary entropy function is defined as entropy of a Bernoulli trial and is a function of success probability, where the Bernoulli trial is modeled as a random variable that can take on only two values: 0 and 1, which means that either an artifacts is assigned with a tag (success), or there is no tag. The H(p) function is a concave function with symmetry at 0.5. Tags may be sorted based on selectivity through computing the entropy function. If the entropy function is used for sorting, it may be sufficient to compute a substitute function to function H(p) presented with function (2). The substitute function may be a function that shares the same behavior as the entropy function H(p). The substitute function may have a corresponding function values for a set of values of the parameter p compared the entropy function H(p) values for the same set of values for the parameter p. In one embodiment, a substitute function to the entropy function H(p) may be defined through a linear interpolation. Linear interpolation may be applied at values 0, 0.5 and 1. The entropy function H(p), defined with function (2), when computed at value 0.5 is equal to 1 (H(0.5)=1), and the entropy function H(p), when computed at value 0 and value 1 is equal to 0. Therefore, a substitute function Y(p) for function H(p) may be determined through combining a function Y1, when interpolating at p=0.5 (H(0.5)=1) and with p=0 (H(0)=0), with consecutive equations (4), (5), and (6); and a function Y2 with equations (7), (8), and (9), when interpolating with p=0.5 (H(0.5)=1) and p=1 (H(1)=0):
Therefore, based on functions Y1 and Y2, the function Y may be defined as the substitute function to the entropy function H(p), when the entropy function is used for sorting tags based on selectiveness of tags, that is defined by the entropy function H(p). The function Y is defined as in function (10). Function Y is sufficient and precise enough to be used for the purpose of sorting selectiveness of tags.
Further, for the sake of sorting, the function H(p), as defined above at function (2), may be also substituted with function Z(p), which may look as follows:
Z:=1−4(p−0.5)2 (11)
Function Z(p) as defined at (11) may be used for a better proximity to the results that may be computed with the entropy function H(p). However, for the sorting purposes of determining relative selectiveness of tags in the application storing tags assigned to artifacts, function Y(p) is sufficient enough and requires less computing resources. Therefore, it is cheaper to compute Y(p), compared to computing H(p).
At 640, the tag cloud is generated by including repeatedly and iteratively a first tag from the first ranked list (generated at 630), and a second tag from the second ranked list (generated at 635). The inclusion of tags from both lists is performed until a number of tags included in the tag cloud reaches the limited number of tags as defined for the tag cloud at 625. When applying the approach for computing a tag cloud as described in
For example, if we have tags T1, T2, T3, T4, and T5 with rank lists: LF=[T1, T2, T3, T4, T5] and LS=[T2, T1, T5, T3, T4], where LF is the first ranked list as described in relation to 630,
The process of step 3 terminates and the result list comprises the desired number of tags. Once the result list is computed, the tag cloud may be rendered by a layout algorithm.
Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. A computer readable storage medium may be a non-transitory computer readable storage medium. Examples of a non-transitory computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however that the embodiments can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. These modifications can be made in light of the above detailed description. Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.