Patent Application
20150379439
Software products are not only collection of machine readable and executable content, but may also be compilations of knowledge, ideas and other intellectual assets or capital. These intellectual assets are subject to intellectual property laws or other regulations of that kind. Determining intellectual property content within software products is valuable knowledge for patent lawsuits, valuation of software enterprises, licensing and cross-licensing opportunities, mergers and acquisitions, etc. The currently employed techniques entail tracking patents, licenses, and other IP assets within a database. Such databases may contain relevant IP assets for various software products but may also be employed for other industries such as pharmaceuticals, mechanics, etc.
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 hybrid applications operating between on-premise and cloud platforms 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.
The process of determining and identifying IP content within software products requires expertise and manual effort. Determining the IP content may be difficult as intangible intellectual assets may not be easily associated with or mapped to software products and executable entities contained thereof. For example, an idea may be implementation of concise and identifiable algorithm or a specific interface. Another example may be a set of table entries that represents a workflow for an optimized process. Yet another example of idea may be an implementation of non-functional requirement in a distributed and orchestrated way, where the implementation may be scattered within a large number of lines of codes in different parts of the software product. Mapping expressions or implementation of ideas to patents or other IP assets is non-trivial in the software industry.
A known approach for identification of patents, trade secrets, trademarks, copyrights, licenses, and other IP assets is by tracking the IP assets in a database, for example, in an IP management docketing system. Those databases or docketing systems store and organize the IP assets but the IP assets are not linked with an actual implementation or expression of the subject matter covered by the relevant IP assets. For example, software products and, in particular source code portions thereof, are not technically linked to or associated with the IP assets. Systems managing versioning of software products or other transport and lifecycle management tools do not have connection with respective docketing systems and the tracked IP assets within.
In one embodiment, a link or a hook is established between an IP asset and a software product or system. In particular, a link may be established between an IP asset and an executable entity within the software product such as a package including application binaries. In one embodiment, the link or the hook may be a transportable object of type IP. Technically, transportable objects of various types may be associated with software products or systems. Examples of transportable objects include, but are not limited to, Packages, Executable code. Source Code, Documentation, Classes, Domain definitions, Data element Definitions, Screens, Functions Groups, Groups, Tables, Authorization Objects, Interfaces, Text Elements, Roles, Views, Business Configuration, Configuration Schemas, Calendar entries, Predefined Queries, Matchcodes, Annotations, Parameters, Test Cases, Test Data.
The transportable object of type IP represents a technical representation of IP assets or other types of intellectual capital, where that representation is integrated into the relevant software systems or products representing actual implementation of the respective IP assets or intellectual capital. A transportable object including transportable objects of type IP may be any entity that can be described by metadata of transport and lifecycle management tools, etc. In one embodiment, transportable objects of type IP may be used to track IP throughout lifecycle of software products, which represent implementation or expression of the subject matter covered by the respective IP.
Transport and lifecycle management tools (e.g., transport and lifecycle management (TLM) tool 180) automate, among others, software systems and products transportation from one system environment to another, software provisioning, installation, patching, upgrade, configuration, etc. In one embodiment, TLM tools keep metadata describing transportable objects. For example, TLM tool 180 may use metadata of transportable objects 185 to keep track of types of transportable objects that may be transported by TLM tool 180. Table 1 below represents an exemplary metadata describing a transportable object of type IP. Table 1 includes a number of attributes that a transportable object of type IP may have and respective description of the attributes.
A number of instances of the transportable object of type IP may be created and associated with packages 150 or other executable entities of software product 130. Further, TLM tool 180 may store associations of one or more packages from packages 150 to corresponding one or more transportable objects from transportable objects 160 or 162. An association of a package of a deployable unit with respective transportable object may be kept as a table entry in catalog of transportable objects 190.
Software product 130 may be deployed to and installed on development system environment 110. At one point in time, software product 130 may be shipped to customers and moved from development system environment 110 to another system environment, for example, dedicated to software at productive stage of their lifecycle. In one embodiment, a request to transport software product 130 from development system environment 110 to production system environment 120 may be received at TLM tool 180. Software product 135 represents software product 135 transported and deployed to production system environment 120. Similarly, packages 155 represent packages 150; packages 175 represents packages 170; instances of transportable objects 165 represent instances of transportable objects 160; and instances of transportable objects of type IP 167 represent instances of transportable objects of type IP 162 transported from development system environment 110 to production system environment 120.
In one embodiment, TLM tool 180 transports instances of transportable objects of type IP 162 along with transportation or deployment of deployable units 140. Upon transportation of deployment units 140 together with the instances of the transportable objects of type IP 162, associations between the deployable units 145 and corresponding instances of transportable objects of type IP 167 may be stored in catalog of transportable objects 190. Thus, instances of transportable objects are tracked upon upgrade, update, transportation, etc., of software products to keep track of IP throughout the lifecycle of the software products.
Once created, at 220, the instance of the transportable object of type IP is assigned to a deployable unit from one or more deployable units included in a software product. In particular, the instance of the transportable object may be assigned to a package included in the deployable unit. For example, an instance of transportable object of type IP that may represent an invention disclosure may be assigned to respective packages or executable entities, which cover the subject matter described in the invention disclosure. At 230, an association of the deployable unit and the instance of the transportable object of type IP may be stored in a repository. For example, a new entry in the catalog of transportable objects 190 in
In various embodiments, the software product may undergo various changes from one state of the lifecycle process to another. For example, changing the state of the software product from one state of the lifecycle process to another may include transporting the software product from one system environment to another, updating, upgrading, shipping, patching, or other transformation of the software product. Upon changing the software product from a first state to a second state of the lifecycle process, the instance of the transportable object of type IP is changed accordingly. Further, the change is tracked by storing an association between the instance of the transportable object of type IP and the corresponding changed deployable unit to which the instance of the transportable object of type IP is assigned. For example, a value of the package assignment attribute may be changed. Thus, when the software product is updated, upgraded, shipped, patched or undergoes other change in the lifecycle process, the instance of the transportable object of type IP being technically linked to the software product undergoes the respective change along with the software product. Thus, IP content or assets may be represented in and be tracked throughout various software lifecycle process chains.
In various embodiments, not only transportable objects but also other types of objects, technical representations or formats may be used to represent IP entities that can be linked to executable entities of software systems and products. Those objects, technical representations, files or formats representing IP may be referenced and used by software versioning control systems, software delivery systems, deployment systems, etc. Thus, in one aspect, IP may be represented and may be an object included in the bill of materials of a software product.
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 Data Base 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 and examples are described herein for illustrative purposes, various equivalent modifications are possible, 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.
