[The 9-HI™ Basics] Privacy, Intellectual Property and Community Meta Vectors
Collection and Use of Information Based on Designation of Project. Licensee shall designate each Group and Project as either Private or Public. Licensee agrees that such designation shall control the use of information generated by any Group, with respect to a Project and associated Topics and that the Platform will automatically collect Keywords, Risks, Success Factors and Success Evidence types (collectively, the “Community Meta Vectors”) as set forth in in the Protocols contained in the 9-HI Platform “Help and Knowledge Center”.
Privacy Policy. Data collected from the Licensee by AIS as a result of the access to and use of the 9-HI Platform will be treated in accordance with AIS’s Privacy Policy, which can be viewed here.
AI Strategy (AIS) Intellectual Property rights: The AIS Software, Codes, or any other component of the 9-HI Platform, and any confidential and proprietary information, provided by AIS or learned by Licensee as a result of its access to and use of the 9-HI Platform, and all copies thereof, are the sole property of AIS and nothing herein shall convey or be deemed to convey any title or any rights thereto to Licensee. All applicable rights in all copyrights, trademarks, trade secrets, trade names, patents and other intellectual property rights in or associated with the 9-HI Platform are and will remain in AIS and Licensee shall have no such intellectual property rights therein or thereto.
Licensee intellectual property rights: Any Licensee intellectual property which is uploaded/introduced during use of the 9-HI Platform shall remain the property of Licensee; provided that any such intellectual property which is designated as Public in accordance with the Protocols and included in the Platform Data Base maybe accessed by other 9-HI Members. Projects must be designated as either PRIVATE or PUBLIC before the unique 9-HI™ Project ID is assigned the Project. Such choice will determine how the Information/ Data will be treated. “Public” indicates this will be available to members of 9-HI (who may re-distribute to others, subject to any copyright restrictions) as set forth below:
(i) Words/concepts of great relevance and significance. These will be critical for both the development and growth of the 9-HI™ platform. Keywords will be organized and structured via the 3 Tier 1 Lanes so they can be used by AI Agents/SMEs for assistance with profile completion, project assignments, collaboration, SF guidance, etc.
(ii) An exposure to danger, or an unknown, that can be categorized as either a gap, barrier or vulnerability. Risks are those things that can prevent or derail a successful selection or development of a technology. In 9-HI™, Risks are assessed at the Tier 1 Level. Risks must be continuously reduced throughout a Development Program in order for the Program to be successful. During selection Projects, it is essential for the proposed effort to address significant Risks identified by the Host, this is normally presented as part of the Development Plan.
(iii) Second Tier measurements that roll up to calculate the FPMs. These are customized for specific technologies, teams and applications. Accurate selection of these is critical for deriving FPM scores, AI will be deployed to recommend FPMs of similar previously successful development efforts. Success factors can be long term or short term. Long term success factors are used for the entire project duration and are tied to the overall project goals and objectives to drive down the overall project risks. These long-term success factors should never change once they are established for the project, unless the scope of the project itself has changed. Short term success factors only apply to specific TRL(s) or other short-term period. They are not Success Factors that apply for the overall Development Program. These only occur in Development Projects in order to address specific development activities that provide new evidence to advance development to the next development activity.
(iv) Evidence used to drive down risks and improve SF Scores. Evidence must be able to survive an audit and/or stringent peer review. Examples of evidence might include, testing, prototyping, analysis, calculations, pilot reviews, focus group feedback, confirmed supporting data, etc. A Development Plan used to propose R&D work is a plan that describes what evidence is expected to be generated to drive down risks, drive up SF Scores and advance TRLs.