쩝.. 특허내려고 했는데 실패했던.

1. 사유는 넘 어려버서.

2. 어? 우리는 이미 쓰고 있는데?

3. 개발자에게나 유용하지...

1번의 경우 어려우면 같이 해서 내면 되는데 퇴근은 빨리 해야 겠고.

결국 현재 위에서 열나 쪼아서 나가고 있는 삼성 대부분의 특허는 가볍고 시시한 것들.

2,3 번의 경우. 그럼 특허를 내면 안될까? 심사원 정도 되면(아무렇게나 뽑힌거지만) 이미 쓸 정도로 괜찮고 없는거면 어떻게든 특허를 내서(뭐 꼭 내께 아니라도) 회사의 권익을 보호 해야 하지 않을까?

사원이라고 너덜한 업무 잡무, 책임지기 싫은 어려운 기술적 업무...

결국 어디나 올라가면 편한거다. 대충 비슷한 무리끼리 공동체 형성해서

애들 나가게 하면 자기는 안 짜를 TO가 나겠지 ㅡㅡ;

걱정마라.

한국 기업은 이미 많은 사람들에 의해서 바뀌고 있다.

그리고 너무도 잘되고 있다.

내가 주장하고자 했던 전문은 이렇다. 사실 뭐 업무가 많아 귀찮아서 중간에 포기 한건데.  위에서 말한 1처럼 어렵다기 보다. 그냥 wrapper 함수를 쓰자는 거.

별의 별것들이 다 특허가 되는 세상이라 어렵게 보이도록 포장해 본 것인데. 

다만 아쉬운 것은 평을 이렇게 들었더라면 납득이 될 것이란 말이다. 뭐 사실 억지로 한거라 어차피 밀고 나가진 않았을거기 때문에 아쉽진 않지만.

" 상당히 수고한 부분은 알겠는데 wrapper를 쓴 라이브러리들을 특허를 낸다고 해도 대부분의 원 함수들은 특허가 걸려있고 오픈된 경우는 GPL이 걸려 있어서 원천 기술이 되기는 힘들다." 

 이 정도? 아... 그럼 이 사람이 GPL 기본 원칙도 알고 있고, 랩핑 했을 때 이점도 캣치는 하고 있구나 할 것이다.

 무조건 아니오 하는 리더 보다는 충분히 납득할 만한 이유를 설명해 줄 수 있는 리더가 되자.

-------

KR20030044319A 의 메모리 관리 방식의 경우 메모리 할당 함수 자체를 overwriting 하지 않고 라이브러리를 이용한다고 구체적으로 명시하고 있음. 여기서 말하는 라이브러리는 첫째 malloc 동작을 수행할 때 

malloc함수의 헤더 부분이 아닌 본체를 말할수도 있으며, 둘째 커널이나 크기가 작은 실시간 운영체제에서 하고 있는 실재적으로 메모리 조각을 모아서 영역을 확보해주고 메모리 단편화와 누수 현상들을 직접 

관리하는 메모리 함수 본체를 말한다고 볼 수도 있으며, 셋째 메모리 테이블만을 관리해주는 기능을 가진 함수나 함수집합(모듈)로 볼 수도 있다. 첫째의 경우는 이 발명과 유사하나 다른점이 있으며, 둘째 셋째

의 경우는 메모리 관리 라이브러리 단까지 가지 않고 호출받은 포인터(주소)만을 저장하여 관리한다는 점이 크게 다르다. 우선 둘째 셋째의 경우만 보면, 라이브러리를 사용할 경우, 그 라이브러리에 대한 정적

링크와 동적링크 모두 메모리를 크게 소비하는 경향이 있어 메모리 관리 기법으로 적절치 않다. 상기의 둘째,셋째 방법의 경우는 매우 빈번히 수행되는 function이고 라이브러리 정적 링크의 경우 컴파일러나 

구현방법에 따라 조금씩 상이하나 호출시마다 자원(메모리, CPU점유) 소비하는 경향이 있다. 또, 동적링크 라이브러리로 암묵적으로 생각한다고 해도 동작 방식에 치명적 단점이 있음. 1. 타이밍이 중요한 시스템의 경우 한줄의 디버깅 코드가 시스템을 망가뜨릴 수도 있는데 빈번한 모듈에의 구현을 말한다. 2. KR20030044319A에 명시된 방법의 경우 메모리 레코드가 full인 경우 마지막 엔트리에 기존 내용이 오버랩되어 지워져 버린다. malloc이 연속적으로 나오다가 메모리테이블이 다 차서 오버랩되고 그 다음 free가 나오는 경우 allocation table과 free table의 정보가 무결성을 잃는다. 3. 메모리디버깅에서 가장 중요한 것이 메모리 용량을 임의적으로 정량화해야 한다는 것이다. 정량화 하지 않고 디버깅 기법 함수를 넣으면 메모리 디버깅을 하고자 넣은 기능이 되려 메모리 릭의 원인이 될 수 있다. 그래서 꼭 정량적으로 정량화 한다는 구체적 구현, 혹은 추상적인 명시가 되어야 한다.

 다시 첫째로 돌아가 여기서 말한 라이브러리가 리눅스에 비유하여 커널에서 메모리 관리가 아닌 시스템콜 이전의 malloc 함수의 본체 라이브러리에 기능을 추가한다는 뜻으로 풀이해보면 본 발명과 유사하다. 그러나 그 단계에서는 메모리 어드레스에 대한 포인터, 메모리 크기, 호출한 테스크의 식별부호, 반환 어드레스 포인터, 다음 요소를 가리키는 인자를 저장할 필요가 없다. free 함수 사용시에 메모리를 할당받은 포인터만 알고 있으면 메모리 해제가 되기 때문에 불필요한 정보들을 테이블에 저장할 필요가 없는 것이다. 그리고 malloc과 free로 연결되는 메모리라고 명시한 것으로 봐서 첫째로 말한 라이브러리를 뜻했다고 말할 수도 없다. 유사특허라고 한 사항을 조사한 내용을 말한다고 malloc, free라고 예를 들어 말했으나 메모리 할당 함수는 본 특허를 구현하기 쉬운 유저와 가까운 운영체제의 모듈에서 malloc, free만 있는 것이 아니다. 이 특허는 메모리를 한정하고 커널의 시스템 영역 이전의 부분에서 메모리 할당/해제 함수를 overwriting하여 구현한다는 점에는 확연히 다르다. 각 운영체제 나름대로 최적화되어 구현된 메모리 할당/해제 함수의 low level를 건들지 않고 C 언어의 포인터를 명확히 이용한다는 점에서도 다르다. C언어라고 명시한 이유는 어떻게 구현되었던지 메모리 할당할수는 포인터를 이용하고 또 그 포인터 정보를 이용해서 각 OS에 맞게 효과적으로 메모리 해제를 하기 때문이다.

 추가로 하드웨어 업체에서 C의 중요성은 되려 커져가고 있습니다. 상위단은 고급 언어로 구현을 하지만 그 것을 받치고 있는 framework(혹은, 더 작은 시스템에서는 펌웨어)은 대부분 C나 어셈으로 짜여진 Virtual Machine으로 되어 있기 때문입니다. 임베디드 디바이스의 경우 malloc이나 free의 경우 커스터 마이징해서 쓰고 있다고 생각되어집니다. 메모리는 항상 문제가 되기 때문에 트레이스로도 잡기 힘들어서 이미 비슷한 방법을 구현하여 써본 경험이 있는 팀(malloc, calloc시에 해당 포인터를 파일에 저장하고 free시에 해당 포인터를 지우는 방식으로 구현)의 개발자의 입장에서 이 특허는 여러 방법으로 다양하게 구현될 수 있는 점에서, 또 방어를 할 수 있는 특허라는 점에서 자산 보호의 중요한 시작이라고 보입니다. 보완해야할 부분이 있다면 보완하겠습니다.