Patenting Introspection:
A software product may have many innovations. Patents protect innovations from infringement and provide some copyrights assertion for the inventor or software maker so that someone else cannot claim as having ownership of the novelty. Patents can also help protect the maker from losing its competitive edge to someone else copying the idea. Patents are therefore desirable and can be used to secure mechanisms, processes and any novelty that was introduced into the product.
Introspection is the way in which the software maker uses the features that were developed for the consumers of the product for themselves so that they can expand the capabilities to provide even more assistance and usability to the user. In some sense, this is automation of workflows combined with the specific use of the product as a pseudo end-user. This automation is also called ‘dogfooding’ because it relates specifically to utilizing the product for the maker itself. The idea of putting oneself in the customers shoes to improve automation is not new in itself. When the product has many layers internally, a component in one layer may reach a higher layer that is visible to another standalone component in the same layer so that the interaction may occur between otherwise isolated components. This is typical for layered communication. However, the term ‘dogfooding’ is generally applied to the use of features available from the boundary of the product shared with external customers.
Consider a storage product which the customers use to store their data. If the software maker for the storage product decided to use the same product for storing data in isolated containers that are reserved for internal use by the maker, then this becomes a good example of trying out the product just like the customers would. This dogfooding is specifically for the software maker to store internal operational data from the product which may come in useful for troubleshooting and production support later. Since the data is stored locally to the instance deployed by the customer and remains internal, it is convenient for the maker to gather history that holds meaning only with that deployment.
The introspection automation is certainly not restricted to the maker. A customer may choose to do so as well. However, an out-of-box automation for the said purpose, can be done once by the maker for the benefit of each and every customer. This removes some burden from the customer while allowing them to focus more on storing data that is more relevant to their business rather than the operations of the product. A competitor to the product or a third-party business may choose to redo the same introspection with similar automation in order to gain a slice of the revenue. If a patent had been issued for the introspection, it would certainly benefit the product maker in this case.
A patent can only be given when certain conditions are met. We will go over these conditions for their applicability to the purpose of introspection.
First, the patent invention must show an element of novelty which is not already available in the field. This body of existing knowledge is called “prior art”. If the product has not been released, introspection becomes part of v1 and prevents the gap where a competitor can grab a patent between the releases of the product by the maker.
Second, the invention must involve an “inventive step” or “non-obvious” step where a person having ordinary skill in the relevant technical field cannot do the same. This is sufficiently met by introspection because the way internal operational data is stored and read is best known to the maker since all the components of the product are visible to the maker and best known to their staff.
Third, the invention must be capable of industrial application such that it is not merely a theoretical phenomenon but one that is useful in practice. Fortunately, all product support personnel will vouch for the utility of records that can assist with troubleshooting and support of the product in mission critical deployments.
Finally, there is an ambiguous criterion that the innovation must be “patentable” under law for a specific country. In many countries, certain theories, creativity, models or discovery are generally not patentable. Fortunately, when it comes to software development, history and tradition serves well just like in any other industry.
Thus, all the conditions of the application for patent protection of innovation can be met. Further, when the invention is disclosed in a manner that is sufficiently clear and complete to enable it to be replicated by a person with an ordinary level of skill in the relevant technical field, it improves the acceptance and popularity of the product.
A software product may have many innovations. Patents protect innovations from infringement and provide some copyrights assertion for the inventor or software maker so that someone else cannot claim as having ownership of the novelty. Patents can also help protect the maker from losing its competitive edge to someone else copying the idea. Patents are therefore desirable and can be used to secure mechanisms, processes and any novelty that was introduced into the product.
Introspection is the way in which the software maker uses the features that were developed for the consumers of the product for themselves so that they can expand the capabilities to provide even more assistance and usability to the user. In some sense, this is automation of workflows combined with the specific use of the product as a pseudo end-user. This automation is also called ‘dogfooding’ because it relates specifically to utilizing the product for the maker itself. The idea of putting oneself in the customers shoes to improve automation is not new in itself. When the product has many layers internally, a component in one layer may reach a higher layer that is visible to another standalone component in the same layer so that the interaction may occur between otherwise isolated components. This is typical for layered communication. However, the term ‘dogfooding’ is generally applied to the use of features available from the boundary of the product shared with external customers.
Consider a storage product which the customers use to store their data. If the software maker for the storage product decided to use the same product for storing data in isolated containers that are reserved for internal use by the maker, then this becomes a good example of trying out the product just like the customers would. This dogfooding is specifically for the software maker to store internal operational data from the product which may come in useful for troubleshooting and production support later. Since the data is stored locally to the instance deployed by the customer and remains internal, it is convenient for the maker to gather history that holds meaning only with that deployment.
The introspection automation is certainly not restricted to the maker. A customer may choose to do so as well. However, an out-of-box automation for the said purpose, can be done once by the maker for the benefit of each and every customer. This removes some burden from the customer while allowing them to focus more on storing data that is more relevant to their business rather than the operations of the product. A competitor to the product or a third-party business may choose to redo the same introspection with similar automation in order to gain a slice of the revenue. If a patent had been issued for the introspection, it would certainly benefit the product maker in this case.
A patent can only be given when certain conditions are met. We will go over these conditions for their applicability to the purpose of introspection.
First, the patent invention must show an element of novelty which is not already available in the field. This body of existing knowledge is called “prior art”. If the product has not been released, introspection becomes part of v1 and prevents the gap where a competitor can grab a patent between the releases of the product by the maker.
Second, the invention must involve an “inventive step” or “non-obvious” step where a person having ordinary skill in the relevant technical field cannot do the same. This is sufficiently met by introspection because the way internal operational data is stored and read is best known to the maker since all the components of the product are visible to the maker and best known to their staff.
Third, the invention must be capable of industrial application such that it is not merely a theoretical phenomenon but one that is useful in practice. Fortunately, all product support personnel will vouch for the utility of records that can assist with troubleshooting and support of the product in mission critical deployments.
Finally, there is an ambiguous criterion that the innovation must be “patentable” under law for a specific country. In many countries, certain theories, creativity, models or discovery are generally not patentable. Fortunately, when it comes to software development, history and tradition serves well just like in any other industry.
Thus, all the conditions of the application for patent protection of innovation can be met. Further, when the invention is disclosed in a manner that is sufficiently clear and complete to enable it to be replicated by a person with an ordinary level of skill in the relevant technical field, it improves the acceptance and popularity of the product.
No comments:
Post a Comment