 A further distinction has to be made between dysfunctions and misfunctions for software-based computational systems (Floridi, Fresco and Primiero 2015). Software can only misfunction but cannot ever dysfunction. A software token can dysfunction in case its physical implementation fails to satisfy intentions or specifications. Dysfunctions only apply to single tokens since a token dysfunctions in that it does not behave as the other tokens of the same type do with respect to the implemented functions. For this reason, dysfunctions do not apply to the intention level and the specification level. On the contrary, both software types and tokens can misfunction, since misfunctions do not depend on comparisons with tokens of the same type being able to perform some implemented function or not. Misfunction of tokens usually depends on the dysfunction of some other component, while misfunction of types is often due to poor design. A software token cannot dysfunction, because all tokens of a given type implement functions specified uniformly at the intention and specification levels. Those functions are implemented at the algorithm implementation level before being performed at the execution level; in case of correct implementation, all tokens will behave correctly at the execution level (provided that no operational malfunction occurs). For the very same reason, software tokens cannot misfunction, since they are implementations of the same intentions and specifications. Only software types can misfunction in case of poor design; misfunctioning software types are able to correctly perform their functions but may also produce some undesired side-effect. For the application of the notion of malfunctioning to the problem of malware classification, see (Primiero et al. 2019).