Abstract:
A semantics engine is described that produces a semantically-impaired but equivalent version of the original source code that can be compiled and executed using conventional tools for commonly used programming languages. This semantically-impaired source code and the compiled assemblies it produces are incomprehensible to anyone who would attempt to read them. The semantics-impairing process is irreversible both at the source and the assembly levels and the machine code generated by the semantically-impaired source code is exactly the same as that produced by the original source code. The semantics engine achieves confidentiality without using encryption or compression. All protective modifications are made directly to copies of the original source code thereby introducing no intermediate forms of the code.

Description:
CROSS REFERENCE OF RELATED APPLICATIONS 
     (none) 
     STATEMENT REGARDING FED SPONSORED R &amp; D 
     (none) 
     REFERENCE TO MICROFICHE APPENDIX 
     (none) 
     FIELD OF THE INVENTION 
     The field of this invention is the protection of the intellectual property that exists in the form of computer source code. The problem is two-fold since unprotected source code can be stolen and it can also be regenerated from executable assemblies. 
     STATE OF THE PRIOR ART 
     It is always an objective of software programmers to write source code that is clear and understandable for the sake of maintainability by using meaningful mnemonic identifiers and abundant program level documentation. 
     The traditional achievement of using meaningful mnemonic identifiers and clearly documenting the details relating to the data and procedures of the computer software programs leaves businesses vulnerable to theft of guarded proprietary secrets. 
     Numerous techniques have been proposed that scramble the object code or intermediate assembly code generated by a language compiler to prevent its conversion back to the original source code. Such techniques do not address the more important problem of source code theft. Further, these object or assembly scramblers are vulnerable since the executable assemblies of the .Net languages, for example, can be reversed easily to their original source code. 
     The semantics awareness is limited at the object or assembly levels for protection methods that work there because the information necessary to deal with semantics effectively is only available at the pure source code level. 
     None of the methods that scramble code at the assembly or object levels can achieve the equivalent or similar execution as that of their original source code and still be irreversible due to the lack of information available to them. They have insufficient information to determine the global nature of mnemonic identifiers, thereby limiting what they can do. In general, these methods that scramble assembly code must reverse their own processes prior to the generation of machine code thereby adding additional vulnerability. 
     No methods that claim to protect confidentiality are known to be effective where the original source code is concerned. Yet, theft of source code by internal employees represents the greatest threat statistically for loss of confidentiality of proprietary information in computer programs. 
     Some methods employ encryption and compression techniques at the assembly level to make reversibility to source code more difficult. Sophisticated tools, however, are available today as freeware that can reverse these methods in a short time. In fact, the only valid justification to use encryption or compression to achieve confidentiality is that reversibility is somehow a requirement of the method in question. 
     In addition, encryption and compression often cause programs in execution to be flagged as malware and possibly intercepted by anti-virus components of an operating system. 
     Further, the use of encryption and compression are not allowed by application market places due to the difficulty it creates for detecting concealed malware. 
     It is a benefit for this invention that the assemblies generated from compilation of the semantically-impaired source code automatically inherit the irreversible semantically-impaired characteristics of the original source code that are produced by the semantics engine. 
     No other method exists today that achieves the results of this invention, namely (1) irreversible, semantically-impaired but equivalent source code; (2) machine code of the semantics-impaired source exactly matches the machine code of the original source code; (3) confidentiality without using encryption or compression; (4) standard compilation tools used in conjunction with this invention; (5) semantically-impaired and irreversible execution assemblies (6) no introduction of complicating intermediate code forms. 
     SUMMARY AND OBJECTS OF THE INVENTION 
     The present invention is a computer software based semantics engine comprising both language-specific and manual parsers, and a semantic processor further comprising procedures to construct a list of semantic mnemonic identifiers, and a program documentation eliminator. 
     The invention works for any of the commonly used programming languages and a language-specific parser can be added for any language, present or future. Parsing can also be done manually, both interactively and by the use of batch scripts. 
     It is an object of the invention that the semantics engine outputs semantically-impaired source code in such a way that the proprietary information in the source code is rendered incomprehensible to humans. 
     Another object of this invention is that the process of producing semantically-impaired source code is irreversible to assure confidentiality. 
     Another object of the invention is that semantically-impaired source code, when compiled, produces assemblies that are also incomprehensible and irreversible. 
     Another object of the invention is that semantically-impaired source code, when compiled, produces assemblies with different nonsense character strings for each compilation making it more difficult for penetration hackers and reverse-engineers. 
     Another object of the invention is that semantically-impaired source code files are usable by developers as functional source code components of projects where other source files are routinely modified and the entire project can be recompiled using customary tools. 
     Another object of this invention is that compiled semantically-impaired source code produces exactly the same execution results as the original pure source code. 
     Another object of this invention is that executable programs compiled from semantically-impaired source code can be successfully submitted to commercial online application stores by avoiding the use of forbidden techniques such as encryption and compression. 
     Another object of this invention is that the semantics engine operates as a stand-alone utility. 
     Another object of this invention is that the semantics engine is incorporated within an integrated software development environment such as the Visual Studio. 
     Another object of this invention is that the semantics engine is incorporated into application-specific meta-languages that generate source code. 
     Another object of this invention is that the semantics engine is incorporated into standard language compilers that generate semantically-impaired source code as a preprocessing step. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows the present invention used as a stand-alone utility that is independent of any particular development environment. The unprotected source code comprises one or more original unprotected source code files. The semantics engine comprises components that parse and replace the semantic mnemonic identifiers with nonsense character strings and replace all of the program level documentation with spaces. The output of the semantic engine is semantically-impaired source code that is suitable as input to a standard language compiler but has been rendered unintelligible to humans in order to protect the confidentiality of the intellectual property in the original pure source code. 
         FIG. 2  shows the present invention with the same components as in  FIG. 1 , except that they are incorporated as features of an integrated development environment shown as the Visual Studio. 
         FIG. 3  shows the present invention with the same components as in  FIG. 1 , except that they are incorporated as follow-on processing to an application-specific code generator shown as a meta-language used for development of applications where the meta-language produces the source code. 
         FIG. 4  shows the present invention with the same components as in  FIG. 1 , except that the semantics engine is incorporated as a preprocessing component of a standard language compiler that produces a semantics-impairing language compiler. 
         FIG. 5  shows the present invention with the same components as in  FIG. 1 , except that a language-specific parser is either replaced by or augmented by a manual process of a person interacting with the unprotected source code files to specify the semantic mnemonic identifiers to be replaced in the source code by the semantics engine. The manual process could also be accomplished by use of a prepared script to specify the semantic mnemonic identifiers and to describe rules for removing program documentation. 
         FIG. 6  shows that when the semantically-impaired source code is compiled with a standard language compiler, it is a benefit that the assemblies or executable programs generated are also semantically-impaired. 
     
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     A preferred embodiment of the present invention is shown as a stand-alone utility in  FIG. 1  that is independent of any particular development environment. The semantics engine  2  operates on unprotected source code  1  thereby producing semantically-impaired source code  8 . The semantics engine  2  works for any operating environment, present or future, including but not limited to the Windows operating systems, the Linux operating systems, the Unix operating systems, the MAC operating system, the IOS operating system and the Android operating system. 
     The list  11  of semantic mnemonic identifiers are determined for the unprotected source code  1  by parsing each source code file  12  of the unprotected source code  1  using a language-specific parser  3  to determine the mnemonic identifiers  22 . Each mnemonic identifier  22  is further determined to be a defining mnemonic identifier  23  or a referencing mnemonic identifier  24 . The defining mnemonic identifiers  23  and all matching referencing mnemonic identifiers  24  are placed in a list  11  of semantic mnemonic identifiers that is used to determine which mnemonic identifiers  22  are to be replaced by the semantics processor  7 . 
     A defining mnemonic identifier  23  is the symbolic name of a unique source procedure or data item or set of data items from the unprotected source code  1 . A referencing mnemonic identifier  24  is a mnemonic pointer or mnemonic reference to a defining mnemonic identifier  23 . For most languages, the symbols in the names of the referencing and the defining mnemonic identifiers  23  match exactly. 
     Language-specific parsers  3  can be added to the semantics engine  2  for any programming language, present or future, including but not limited to the C# language, the C++ language, the Visual Basic language, the SQL language, the JAVA language, the MYSQL language, the ORACLE languages, the web development languages, the scripting languages including JavaScript, application-specific languages, or assembly languages. 
     The list  11  of semantic mnemonic identifiers for the unprotected source code  1  can also be determined by a manual parsing process  4  that can augment or can be used in place of a language-specific parser as shown in  FIG. 5 . In this case, a person makes decisions interactively 4 using a manual process to determine the defining mnemonic identifiers  23  that are included in the list  11  of semantic mnemonic identifiers to be replaced. Referencing mnemonic identifiers  24  are located by the semantics processor  7  and placed in the list  11  of semantic mnemonic identifiers to be replaced. 
     A script  4  is generated by the interactive process  4  that can be used to determine the list  11  of semantic mnemonic identifiers without manual intervention in subsequent invocations of the semantics engine  2  for the same unprotected source code  1 . This script  4  also describes rules for removing program documentation. 
     The script  4  can also be created and updated manually using a text editor. 
     As previously mentioned, the semantics processor  7  creates a list  11  of semantic mnemonic identifiers to be replaced comprising data items, sets of data items and procedure names from the original unprotected source code  1 . The file-offsets of each identifier relative to the location within the original source file  12  are recorded in list  11  of semantic mnemonic identifiers to be replaced. The reference and definition-matched mnemonic identifiers  22  comprise the completed list  11  of semantic mnemonic identifiers to be replaced. Matched references and definitions are managed by the semantics processor  7  to assure that no undefined symbol errors occur during compilation as a result of the mnemonic identifier replacements  6 . 
     The semantics processor  7  replaces all comments and program level documentation characters with spaces or other characters that do not alter the compilation process  9  thereby leaving intact all of the file-offsets recorded in the list  11  of semantic mnemonic identifiers to be replaced for the mnemonic identifiers  22  that are located in each of the unprotected source code files  12 . 
     The mnemonic identifiers  22  from the original unprotected source code  1  that are in the list  11  of semantic mnemonic identifiers to be replaced are systematically replaced  6  with meaningless, but syntactically valid nonsense character strings  25  randomly created by the semantics processor  7  without regard to the makeup of the mnemonic identifier  22  from the original unprotected source code  1 . For example:
         Accounts payable could be replaced by vh2inHNKl16fTtbyuJ10101   Part-cost could be replaced by vh2inHNK1l6fTtbyuJ10101       

     The symbol vh2inHNKl16fTtbyuJ10101 is not a function of, nor in any way derived from the symbol Accounts payable and there is no basis for the replacement process  6  to be reversed since the list  11  of semantic mnemonic identifiers to be replaced, being the only key, is destroyed after symbol replacement  6  operations are complete. 
     Further, for every subsequent semantic engine  2  invocation, the randomly generated nonsense character strings  25  are different and unrelated to previous invocations, thereby making the scenario more difficult for a reverse-engineer or for a potential penetration threat by a hacker. 
     It may appear that the two nonsense strings used above are identical but they are not.
         vh2inHNKl16fTtbyuJ10101   vh2inHNK1l6fTtbyuJ10101       

     There is one instance of a transposition of the number  1  and the letter  1 . It is a feature of the semantics engine  2  that nonsense character strings  25  that are replacements for different semantic mnemonic identifiers are visually indistinguishable from each other. This inability to distinguish one identifier from another further impairs a person&#39;s visual ability to understand the semantically-impaired source code  8 . 
     The nonsense character strings  25  are syntactically valid identifiers for the specific language. The execution results are the same as when Accounts payable was used as the mnemonic identifier  22  since both kinds of identifiers ultimately resolve to the same computer machine code addresses for execution. 
     In fact, the machine code objects produced by standard compilation of the unprotected original source and the semantically-impaired source code are identical making them equivalent other than
         (1) the semantically-impaired source code  8  is humanly incomprehensible, and   (2) the nonsense character strings  25  are inherited by the semantically-impaired assemblies  21  and they are irreversible to the original source code identifiers.       

     Unprotected source code  1  is copied to a location secured by the owner of the source code in order to preserve the confidentiality of the original unprotected source code  1  and availability of the original unprotected source code  1  is controlled by techniques that enforce access according to a basis of need-to-know, job function or title, or purely discretionary permission determined by the owner of the information or by an administrator. 
     The set of unprotected source code  1  ranges from one source file to all source files for a given project. It is a requirement that all of the unprotected source files  12  with referencing mnemonic identifiers  24  are included to avoid undefined symbol errors. 
     The simplicity of said semantics engine  2  assures that the configuration management requirements of an organization are not hampered, namely:
         (1) all of the protection modifications are confined to copies of the original unprotected source code files  1 ,   (2) the original unprotected source code  1  and the corresponding semantically-impaired source code  8  are equivalent and interchangeable as components of a development project,   (3) the original unprotected source code files  1  are always backed-up in a secure location where access is controlled, and   (4) there are no intermediate forms of the original unprotected source code  1  to manage.       

     Another preferred embodiment of the invention is shown in  FIG. 2  where the semantics engine  2  is incorporated as a feature of an integrated development environment shown as the Visual Studio  14 . This produces an intuitive mode of operation for developers that is familiar and efficient. 
     Another preferred embodiment of the invention is shown in  FIG. 3  where the semantics engine  2  is incorporated into an application-specific code generator  16 . In this embodiment, the unprotected source code  1  is the output of a meta-language code generator and this unprotected source code  1  is used to produce semantically-impaired source code  8 . 
     Another preferred embodiment of the invention is shown in  FIG. 4  where the semantics engine  2  is incorporated as a preprocessor to a standard language compiler yielding a semantics-impairing language compiler  20 . 
     Semantically-impaired source code  8  only produces semantically-impaired assembly code or executable  21  as shown in  FIG. 6 . 
     In conclusion, the present invention is a computer software based semantics engine comprising both language-specific and manual parsers, and a semantic processor further comprising procedures to construct a list of semantic mnemonic identifiers, and a program documentation eliminator. 
     The invention claims that the semantics engine outputs semantically-impaired source code in such a way that the proprietary information in the source code is rendered incomprehensible to humans.