Đăng ký bản quyền ứng dụng tại Hà Nội bảo vệ sản phẩm công nghệ từ sớm

Đăng ký bản quyền ứng dụng tại Hà Nội là bước quan trọng đối với các sản phẩm app được đầu tư nhiều về công nghệ, giao diện và nội dung. Việc đăng ký giúp chủ sở hữu có thêm căn cứ chứng minh quyền khi ứng dụng bị sao chép hoặc phát sinh tranh chấp giữa các bên tham gia phát triển.

Một ứng dụng trên App Store có thể chứa nhiều tài sản trí tuệ trong cùng một biểu tượng

Một ứng dụng xuất hiện trên App Store hoặc Google Play thường được người dùng nhìn thấy dưới dạng một icon, một tên gọi và một giao diện thống nhất. Tuy nhiên, dưới góc độ sở hữu trí tuệ, phía sau biểu tượng đó có thể tồn tại đồng thời nhiều tài sản khác nhau: chương trình máy tính, giao diện đồ họa, hình ảnh, nội dung chữ viết, video, âm thanh, cơ sở dữ liệu, tên thương mại, nhãn hiệu và nhiều thành phần được cấp phép từ bên thứ ba.

Vì vậy, khi chuẩn bị đăng ký bản quyền ứng dụng tại Hà Nội, doanh nghiệp không nên bắt đầu bằng câu hỏi “đăng ký app cần giấy tờ gì?” mà nên bắt đầu bằng câu hỏi “trong app này, chúng tôi thực sự sở hữu những gì?”. Đây là bước giúp tránh tình trạng đăng ký một chương trình máy tính nhưng lại kỳ vọng giấy chứng nhận sẽ bao phủ toàn bộ logo, thương hiệu, dữ liệu và mọi tài nguyên xuất hiện bên trong ứng dụng.

Source code của ứng dụng được nhìn nhận thế nào dưới góc độ quyền tác giả?

Theo pháp luật sở hữu trí tuệ Việt Nam, chương trình máy tính thuộc nhóm tác phẩm được bảo hộ quyền tác giả. Chương trình máy tính được bảo hộ như tác phẩm văn học dù được thể hiện dưới dạng mã nguồn hay mã máy. Vì vậy, source code là một trong những lớp tài sản trung tâm khi doanh nghiệp xây dựng hồ sơ bảo hộ một ứng dụng.

Điều quan trọng là quyền tác giả bảo hộ hình thức thể hiện có tính sáng tạo chứ không đồng nghĩa một doanh nghiệp có thể độc quyền mọi ý tưởng kinh doanh hoặc mọi chức năng chung của ứng dụng. Hai ứng dụng cùng cho phép đặt lịch, giao đồ ăn hoặc quản lý khách hàng chưa đương nhiên xâm phạm nhau. Khi xảy ra tranh chấp, cần đi sâu hơn vào cách thể hiện, cấu trúc chương trình, mã nguồn và những yếu tố sáng tạo cụ thể.

Giao diện, icon, hình ảnh và nội dung trong app cần tách ra sao?

Giao diện ứng dụng có thể bao gồm bố cục màn hình, biểu tượng chức năng, hình minh họa, bộ icon, banner, hình nền, typography và nhiều thành phần đồ họa. Một số yếu tố có thể được xem xét dưới góc độ tác phẩm mỹ thuật ứng dụng hoặc những loại hình tác phẩm phù hợp khác nếu đáp ứng điều kiện bảo hộ. Nội dung bài viết, hình ảnh, video hay âm thanh trong app lại có thể tạo thành các tài sản quyền tác giả độc lập.

Doanh nghiệp nên lập một bảng tài sản riêng cho từng lớp thay vì ghi chung “toàn bộ app thuộc sở hữu công ty”. Ví dụ, source code do đội kỹ thuật nội bộ phát triển; bộ icon mua license từ một marketplace; 20 ảnh sản phẩm do công ty tự chụp; 10 hình minh họa do freelancer thiết kế; font chữ sử dụng theo giấy phép thương mại. Bảng phân loại này rất hữu ích khi đăng ký quyền, gọi vốn hoặc xử lý tranh chấp.

Tên ứng dụng có nên được bảo hộ bằng nhãn hiệu song song không?

Tên ứng dụng có chức năng nhận diện sản phẩm hoặc dịch vụ trên thị trường nên doanh nghiệp thường cần xem xét thêm cơ chế bảo hộ nhãn hiệu. Đăng ký quyền tác giả đối với chương trình máy tính không tự động tạo ra quyền độc quyền đối với tên app trên thị trường. Đây là hai cơ chế bảo hộ có đối tượng, điều kiện và phạm vi quyền khác nhau.

Với một startup tại Hà Nội chuẩn bị đưa ứng dụng ra thị trường, chiến lược thường hợp lý hơn là rà soát song song tên app, logo và chương trình máy tính. Nếu tên ứng dụng là tài sản thương hiệu trọng tâm, việc kiểm tra khả năng đăng ký nhãn hiệu nên thực hiện sớm, đặc biệt trước khi đầu tư lớn cho quảng cáo, domain, bảng hiệu hoặc mở rộng sang nhiều sản phẩm.

Trước khi đăng ký hãy dựng “bản đồ người tạo ra app”

Một trong những lỗi khó sửa nhất của hồ sơ ứng dụng không nằm ở source code mà nằm ở lịch sử hình thành quyền. Một app có thể được hình thành qua hai năm với founder viết phiên bản đầu tiên, developer nội bộ phát triển tiếp, freelancer làm module thanh toán và agency thiết kế lại giao diện. Khi đó, câu hỏi “ai sở hữu ứng dụng?” không thể trả lời chỉ bằng tên người đang giữ tài khoản App Store.

Doanh nghiệp nên dựng một timeline từ ngày dự án bắt đầu cho đến phiên bản đăng ký. Với từng giai đoạn, cần xác định ai tham gia sáng tạo, họ tham gia với tư cách nhân viên hay nhà thầu, phạm vi công việc là gì và tài liệu nào chứng minh quyền của doanh nghiệp đối với kết quả đó.

Founder tự code khác gì thuê đội kỹ thuật phát triển?

Founder trực tiếp viết chương trình có thể đồng thời là tác giả và, tùy quan hệ pháp lý cụ thể, là chủ sở hữu các quyền tương ứng. Nhưng nếu ứng dụng sau đó được đưa vào công ty, doanh nghiệp cần kiểm tra xem quyền đối với phần code ban đầu đã được chuyển cho pháp nhân hay chưa. Việc founder là cổ đông hoặc giám đốc không có nghĩa mọi tài sản họ tạo ra trước khi thành lập công ty tự động trở thành tài sản công ty.

Ngược lại, nếu doanh nghiệp thuê đội kỹ thuật xây dựng app, cần xem ai là người giao nhiệm vụ, ai ký hợp đồng và hợp đồng quy định quyền sở hữu kết quả công việc như thế nào. Pháp luật có quy định về chủ sở hữu trong trường hợp tổ chức giao nhiệm vụ sáng tạo cho người thuộc tổ chức hoặc giao kết hợp đồng với tác giả, nhưng doanh nghiệp vẫn nên thể hiện quan hệ quyền một cách rõ ràng bằng văn bản.

Developer nhận lương nhưng không có mô tả công việc gây rủi ro gì?

Việc developer có tên trong bảng lương chứng minh được một phần quan hệ lao động nhưng chưa phải lúc nào cũng đủ để trả lời toàn bộ câu hỏi về phạm vi nhiệm vụ sáng tạo. Nếu hợp đồng lao động chỉ ghi chung “nhân viên IT”, trong khi người đó viết toàn bộ backend của một sản phẩm mới, khi rà soát quyền sở hữu có thể phát sinh khoảng trống tài liệu về việc chương trình được tạo ra theo nhiệm vụ nào.

Doanh nghiệp công nghệ nên liên kết hợp đồng lao động với mô tả công việc, quyết định giao nhiệm vụ, kế hoạch dự án, biên bản nghiệm thu hoặc hệ thống quản trị công việc. Mục đích không phải tạo ra thật nhiều giấy tờ mà là xây được một chuỗi chứng cứ nhất quán: ai được giao việc, họ tạo ra phần nào, trong khoảng thời gian nào và kết quả đó thuộc dự án nào của doanh nghiệp.

Agency và freelancer cần bàn giao quyền sở hữu bằng tài liệu nào?

Hợp đồng với agency hoặc freelancer nên quy định rõ sản phẩm bàn giao, source code, file thiết kế gốc, repository, tài khoản quản trị, tài liệu kỹ thuật và phạm vi quyền được chuyển giao. Chỉ có hóa đơn thanh toán hoặc biên bản chuyển tiền chưa chắc giải quyết đầy đủ vấn đề quyền sở hữu trí tuệ.

Khi kết thúc dự án, doanh nghiệp nên có biên bản nghiệm thu và bàn giao tương ứng với hợp đồng. Nếu agency sử dụng nhân sự hoặc nhà thầu phụ của mình, doanh nghiệp cũng nên yêu cầu cam kết về quyền đối với các thành phần được bàn giao. Điều này đặc biệt quan trọng với app chuẩn bị gọi vốn, bởi nhà đầu tư thường không chỉ nhìn ứng dụng chạy được mà còn muốn biết công ty có thực sự sở hữu công nghệ đó hay không.

App Android, iOS và web app có cần đăng ký thành ba tác phẩm khác nhau?

Không nên mặc định rằng cứ có ba nền tảng thì phải có đúng ba hồ sơ, cũng không nên mặc định một giấy chứng nhận luôn bao phủ tất cả. Điểm cần đánh giá là mức độ độc lập của từng chương trình, cấu trúc code, phần dùng chung và phần được phát triển riêng.

Một ứng dụng sử dụng framework đa nền tảng có thể có phần lõi dùng chung rất lớn, trong khi một sản phẩm khác lại có hai đội viết Android và iOS bằng hai ngôn ngữ khác nhau. Vì vậy, phạm vi tác phẩm nên được xác định từ kiến trúc kỹ thuật thực tế.

Khi dùng chung backend nhưng khác frontend nên đánh giá thế nào?

Nếu Android, iOS và web cùng gọi vào một backend, backend có thể được xem là một thành phần quan trọng dùng chung của hệ thống. Trong khi đó, frontend của từng nền tảng có thể có những phần code và cách thể hiện khác nhau.

Doanh nghiệp nên lập sơ đồ hệ thống trước khi chọn phạm vi đăng ký. Sơ đồ có thể thể hiện backend, API, database, frontend iOS, frontend Android và web. Sau đó mới xác định phần nào là một chương trình tương đối hoàn chỉnh, phần nào chỉ là thành phần phụ thuộc và phần nào nên được lưu chứng cứ hoặc đăng ký riêng.

Hai hệ điều hành có codebase khác nhau ảnh hưởng phạm vi đăng ký ra sao?

Nếu iOS được viết bằng Swift và Android được viết bằng Kotlin với hai repository độc lập, mức độ khác biệt có thể lớn hơn nhiều so với trường hợp sử dụng một codebase chung. Khi đó, việc xem xét các chương trình như những tài sản riêng biệt có thể hợp lý hơn.

Ngoài code, doanh nghiệp cũng nên so sánh chức năng, ngày hoàn thành, nhóm developer và lịch sử version. Nếu hai chương trình do hai nhóm khác nhau xây dựng vào hai thời điểm khác nhau, việc tách hồ sơ đôi khi còn giúp chain of title rõ ràng hơn.

Phiên bản web và mobile liên kết nhưng không hoàn toàn giống nhau xử lý thế nào?

Web app có thể chia sẻ backend với mobile nhưng có frontend riêng, nhiều tính năng quản trị hoặc quy trình nghiệp vụ không xuất hiện trên ứng dụng di động. Trong trường hợp này, doanh nghiệp cần tránh mô tả cả hệ thống như một khối duy nhất nếu tài liệu kỹ thuật không phản ánh đúng thực tế.

Có thể xây dựng một ma trận chức năng để xác định phần chung và phần riêng giữa web, Android và iOS. Đây không chỉ là tài liệu hỗ trợ đăng ký mà còn giúp doanh nghiệp quản lý tài sản công nghệ lâu dài khi sản phẩm phát triển thành hệ sinh thái nhiều nền tảng.

Từ bản beta đến version 1.0 – chọn đúng “điểm chụp” của ứng dụng để đăng ký

Ứng dụng công nghệ không bao giờ thực sự đứng yên. Hôm nay đội kỹ thuật khóa version 1.0 nhưng vài tuần sau đã có version 1.1. Vì vậy, hồ sơ đăng ký nên được coi là một “ảnh chụp” của tác phẩm tại một thời điểm xác định.

Điều doanh nghiệp cần bảo đảm là tên phiên bản, tài liệu mô tả, source code được sử dụng và ngày hoàn thành có logic với nhau. Một bộ hồ sơ thiếu tính đồng nhất dễ khiến việc xác định chính xác đối tượng đăng ký trở nên khó khăn.

Có nên đăng ký khi app vẫn đang thử nghiệm không?

Một sản phẩm không nhất thiết phải chờ có hàng trăm nghìn người dùng mới nghĩ đến bảo hộ. Tuy nhiên, đăng ký khi code còn thay đổi từng ngày có thể khiến bộ tài liệu nhanh chóng lỗi thời.

Thời điểm phù hợp thường là khi doanh nghiệp đã có một phiên bản tương đối ổn định, xác định được tác giả, chủ sở hữu và cấu trúc chương trình. Với startup cần gọi vốn hoặc chuẩn bị công bố sản phẩm, việc khóa một phiên bản rõ ràng để làm mốc sở hữu trí tuệ có thể mang lại giá trị quản trị lớn.

Phiên bản nào nên được sử dụng trong tài liệu đăng ký?

Nên lựa chọn một version có thể xác định rõ ngày khóa mã nguồn và lưu lại repository tương ứng. Nếu chọn version 1.0, tài liệu mô tả, source code trích xuất, giao diện tham chiếu và các thông tin liên quan nên cùng phản ánh version đó.

Doanh nghiệp cũng nên lưu commit hoặc tag tương ứng trong hệ thống quản lý source code. Sau này, nếu phát sinh tranh chấp về thời điểm hình thành chương trình, lịch sử Git, tài liệu dự án và bộ hồ sơ đăng ký có thể hỗ trợ nhau thay vì tồn tại như các nguồn dữ liệu rời rạc.

Sau khi update nhiều tính năng có cần đăng ký thêm không?

Không phải mỗi lần sửa một nút hoặc vá một lỗi nhỏ đều mặc nhiên cần một hồ sơ quyền tác giả mới. Doanh nghiệp nên đánh giá mức độ sáng tạo và quy mô thay đổi của phiên bản mới.

Nếu app phát triển thêm một module quan trọng, thay đổi kiến trúc lớn hoặc hình thành một chương trình mới có giá trị kinh tế độc lập, nên cân nhắc xác lập thêm chứng cứ hoặc thực hiện đăng ký phù hợp. Cách quản trị tốt là ghi rõ trong release log đâu là sửa lỗi, đâu là cải tiến nhỏ và đâu là tài sản công nghệ mới.

Hồ sơ đăng ký bản quyền ứng dụng tại Hà Nội nên đi theo 5 câu hỏi

Thay vì bắt đầu bằng việc photo giấy tờ, doanh nghiệp có thể tổ chức hồ sơ xoay quanh năm câu hỏi: tác phẩm là gì, ai sáng tạo, ai sở hữu, quyền được hình thành từ đâu và phiên bản nào đang được đăng ký.

Luật Sở hữu trí tuệ quy định hồ sơ đăng ký gồm tờ khai và các thành phần liên quan; việc nộp hồ sơ có thể thực hiện trực tiếp, qua bưu chính hoặc qua cổng dịch vụ công theo quy định. Đăng ký không phải điều kiện bắt buộc để quyền tác giả phát sinh, nhưng giấy chứng nhận có giá trị đáng kể về chứng cứ khi xảy ra tranh chấp.

Ứng dụng tên gì và thuộc loại tác phẩm nào?

Tên tác phẩm trong hồ sơ nên thống nhất với cách doanh nghiệp xác định chương trình. Nếu app có tên thương mại là “ABC”, có thể cần ghi rõ tên chương trình và version để tránh nhầm với tên nhãn hiệu hoặc tên sản phẩm trên kho ứng dụng.

Đối với phần mềm, loại hình trọng tâm thường được xem xét là chương trình máy tính. Tuy nhiên, các tài sản khác bên trong ứng dụng có thể thuộc các loại hình khác nên không nên mặc định một hồ sơ chương trình máy tính đồng nghĩa với đăng ký toàn bộ tài sản sáng tạo trong app.

Ai trực tiếp sáng tạo và ai là chủ sở hữu?

Tác giả và chủ sở hữu là hai khái niệm không nên gộp thành một. Developer trực tiếp tham gia sáng tạo có thể là tác giả, trong khi doanh nghiệp có thể là chủ sở hữu các quyền tương ứng nếu quan hệ giao nhiệm vụ, hợp đồng hoặc chuyển giao đáp ứng quy định.

Đây là lý do chỉ ghi tên giám đốc vì “giám đốc đại diện công ty” có thể tạo ra sai lệch nếu người đó không trực tiếp sáng tạo. Hồ sơ tốt phải phản ánh được cả con người sáng tạo và căn cứ hình thành quyền của chủ sở hữu.

Quyền sở hữu được hình thành từ hợp đồng, giao nhiệm vụ hay chuyển giao?

Có ba tình huống thường gặp: nhân viên được doanh nghiệp giao nhiệm vụ phát triển chương trình; doanh nghiệp thuê cá nhân hoặc tổ chức phát triển; hoặc quyền được chuyển từ founder, công ty khác hay chủ sở hữu trước đó sang doanh nghiệp.

Mỗi tình huống cần chuỗi tài liệu khác nhau. Doanh nghiệp không nên cố sử dụng một mẫu “cam kết quyền sở hữu” để thay thế toàn bộ lịch sử hình thành quyền nếu thực tế dự án đã trải qua nhiều giao dịch.

API, SDK và mã nguồn mở – những phần doanh nghiệp dùng nhưng không sở hữu

Ứng dụng hiện đại gần như hiếm khi được viết hoàn toàn từ số 0. Một app có thể sử dụng framework, library mã nguồn mở, SDK thanh toán, API bản đồ, hệ thống đăng nhập và hàng chục package khác.

Việc sử dụng hợp pháp các thành phần đó không đồng nghĩa doanh nghiệp trở thành tác giả hoặc chủ sở hữu của chúng. Vì vậy, phạm vi tuyên bố quyền cần tách giữa code tự phát triển và thành phần được sử dụng theo giấy phép.

Open-source license ảnh hưởng đến ứng dụng thương mại như thế nào?

“Mã nguồn mở” không đồng nghĩa với “muốn dùng thế nào cũng được”. Mỗi dự án open-source có thể đi kèm một loại license với các điều kiện riêng về sao chép, phân phối, thông báo bản quyền hoặc cách thức cung cấp mã nguồn.

Trước khi đăng ký hoặc gọi vốn, đội kỹ thuật nên xuất danh sách dependency và rà license. Đây cũng là nội dung thường được kiểm tra trong quá trình technology due diligence, bởi một dependency sử dụng không đúng điều kiện có thể tạo ra rủi ro lớn hơn nhiều so với giá trị của chính package đó.

SDK của bên thứ ba có được đưa vào phạm vi khẳng định quyền hay không?

Doanh nghiệp có thể có quyền sử dụng SDK theo điều khoản của nhà cung cấp nhưng không vì thế trở thành chủ sở hữu SDK. Ví dụ, ứng dụng tích hợp SDK thanh toán hoặc phân tích dữ liệu chỉ đang sử dụng một thành phần công nghệ bên ngoài.

Trong tài liệu nội bộ, nên đánh dấu các thư mục hoặc module thuộc bên thứ ba và tránh diễn đạt theo hướng toàn bộ source code repository đều do công ty tự sáng tạo nếu điều đó không chính xác.

Doanh nghiệp nên lập danh mục thành phần bên thứ ba ra sao?

Danh mục có thể ghi tên thư viện, version, nguồn, loại license, chức năng sử dụng, ngày tích hợp và người phụ trách kiểm tra. Với API thương mại, có thể bổ sung hợp đồng hoặc điều khoản dịch vụ tương ứng.

Một bảng như vậy không chỉ phục vụ hồ sơ sở hữu trí tuệ. Nó còn hỗ trợ kiểm toán công nghệ, quản lý an ninh phần mềm, cập nhật dependency và xử lý khi một thư viện ngừng được duy trì.

Case study – app đặt lịch tại Hà Nội đổi 3 đội developer trước khi hoàn thiện

Giả sử một startup tại Hà Nội phát triển ứng dụng đặt lịch trong ba năm. Năm đầu founder thuê hai freelancer. Năm thứ hai công ty ký với một agency. Năm thứ ba thành lập đội kỹ thuật nội bộ và viết lại khoảng 60% hệ thống.

Khi chuẩn bị đăng ký quyền tác giả và gọi vốn, startup phát hiện source code tồn tại ở ba repository khác nhau, một số module không rõ ai viết và hợp đồng với freelancer đầu tiên chỉ còn file chuyển khoản.

Source code bị chia giữa ba repository tạo rủi ro thế nào?

Vấn đề không phải chỉ là ba repository mà là không xác định được lịch sử từng phần. Nếu module booking hiện tại được sao chép từ repository cũ rồi tiếp tục sửa, cần biết quyền đối với code gốc bắt đầu từ đâu.

Startup nên thực hiện source code mapping, xác định module, tác giả hoặc đội phát triển, thời gian tạo và repository nguồn. Sau đó mới ghép lại thành lịch sử phát triển của phiên bản hiện hành.

Quyền của từng đội phát triển cần được rà lại ra sao?

Đội freelancer cần kiểm tra hợp đồng, email giao việc, file bàn giao và chứng từ. Agency cần rà điều khoản IP và nghiệm thu. Nhân sự nội bộ cần kiểm tra hợp đồng lao động, giao nhiệm vụ và lịch sử commit.

Nếu phát hiện khoảng trống, nên xử lý bằng tài liệu bổ sung phù hợp với giao dịch thực tế thay vì tạo một văn bản hồi tố không phản ánh đúng lịch sử. Mục tiêu cuối cùng là một chain of title có thể giải thích cho luật sư, nhà đầu tư hoặc cơ quan giải quyết tranh chấp.

Cách xây lại “chain of title” trước khi đăng ký và gọi vốn

Chain of title có thể hiểu đơn giản là chuỗi giải thích quyền đã đi từ người sáng tạo đến chủ sở hữu hiện tại như thế nào. Với app trên, doanh nghiệp cần nối ba giai đoạn thành một dòng quyền liên tục.

Khi hoàn thành, công ty nên có sơ đồ thể hiện từng module và căn cứ sở hữu. Đây là tài liệu nội bộ rất có giá trị khi nhà đầu tư hỏi: “Có phần code quan trọng nào mà công ty đang dùng nhưng không thực sự sở hữu hay không?”.

Đăng ký bản quyền ứng dụng trước vòng gọi vốn có giá trị gì?

Giấy chứng nhận không thay thế toàn bộ quá trình thẩm định quyền sở hữu trí tuệ nhưng có thể là một thành phần quan trọng của data room. Theo Luật Sở hữu trí tuệ, người đã được cấp giấy chứng nhận nhìn chung không phải chứng minh quyền thuộc về mình khi có tranh chấp, trừ trường hợp có chứng cứ ngược lại.

Giá trị lớn hơn nằm ở quá trình chuẩn bị hồ sơ. Để đăng ký đúng, startup phải xác định tác giả, chủ sở hữu, version và căn cứ hình thành quyền. Chính quá trình đó giúp phát hiện nhiều lỗ hổng trước khi nhà đầu tư phát hiện.

Nhà đầu tư thường kiểm tra quyền đối với công nghệ ra sao?

Trong quá trình thẩm định, nhà đầu tư có thể quan tâm đến hợp đồng developer, freelancer, agency, license open-source, domain, nhãn hiệu, tài khoản kho ứng dụng và quyền đối với dữ liệu.

Nếu công nghệ là tài sản cốt lõi tạo ra định giá doanh nghiệp, một khoảng trống quyền sở hữu có thể trở thành vấn đề đáng kể trong quá trình đàm phán đầu tư.

IP đứng tên founder thay vì công ty có thể trở thành vấn đề thế nào?

Nếu founder sở hữu code, logo hoặc nhãn hiệu quan trọng trong khi công ty chỉ được sử dụng trên thực tế, nhà đầu tư có thể đặt câu hỏi: điều gì xảy ra nếu founder rời công ty?

Vấn đề không có nghĩa mọi tài sản đứng tên founder đều sai, nhưng cấu trúc quyền phải rõ. Nếu chiến lược kinh doanh xác định công ty là pháp nhân sở hữu công nghệ, quyền nên được sắp xếp phù hợp trước những giao dịch quan trọng.

Chuyển quyền về pháp nhân nên thực hiện vào giai đoạn nào?

Tốt nhất là quyền sở hữu được làm rõ từ thời điểm công ty tiếp nhận sản phẩm, thay vì chờ đến khi có tranh chấp hoặc nhà đầu tư yêu cầu.

Nếu app đã tồn tại trước khi công ty thành lập, doanh nghiệp nên rà soát tài sản sáng lập sớm và lập tài liệu chuyển giao phù hợp. Sau đó, các phiên bản mới được tạo trong công ty sẽ có chain of title dễ quản lý hơn.

12 lỗi thường gặp khi đăng ký bản quyền ứng dụng

Các lỗi của hồ sơ ứng dụng thường có tính dây chuyền. Một sai sót về tác giả có thể kéo theo sai căn cứ chủ sở hữu; một sai version có thể làm source code và bản mô tả không còn khớp nhau.

Ngoài ba nhóm lỗi lớn dưới đây, doanh nghiệp còn thường gặp tình trạng thiếu tài liệu chuyển quyền, nhầm quyền tác giả với nhãn hiệu, đưa code bên thứ ba vào phạm vi sở hữu, không lưu version đăng ký, không kiểm tra open-source, thiếu nghiệm thu, không quản lý tài khoản repository, không đồng nhất ngày hoàn thành và không lưu hồ sơ sau khi được cấp giấy.

Chỉ kê tên CEO dù đội kỹ thuật mới là người trực tiếp sáng tạo

CEO có thể là người đại diện pháp luật của chủ sở hữu nhưng không mặc nhiên là người trực tiếp sáng tạo chương trình. Việc xác định tác giả phải dựa vào hoạt động sáng tạo thực tế.

Đối với dự án nhiều developer, cần đánh giá ai thực sự tham gia tạo ra chương trình và quan hệ giữa họ. Ghi tên người thuận tiện thay vì người đúng có thể khiến giấy chứng nhận trở thành nguồn phát sinh tranh luận thay vì công cụ giảm tranh luận.

Tên ứng dụng trên hồ sơ khác tên phiên bản đang phát hành

Một app có thể đổi tên nhiều lần trước khi ra mắt. Nếu hồ sơ đăng ký dùng tên dự án nội bộ nhưng App Store dùng thương hiệu mới, cần lưu tài liệu giải thích mối liên hệ.

Tương tự, nếu hồ sơ ghi version 1.0 nhưng source code lại lấy từ branch đang phát triển version 1.3, doanh nghiệp sẽ khó xác định chính xác “ảnh chụp” nào đã được sử dụng đăng ký.

Không lưu hợp đồng với freelancer hoặc đơn vị phát triển outsource

Đây là lỗi đặc biệt phổ biến ở startup giai đoạn đầu. Founder thuê freelancer qua tin nhắn, thanh toán và nhận file nhưng không ký tài liệu về sở hữu trí tuệ.

Khi sản phẩm còn nhỏ, vấn đề tưởng như không đáng kể. Nhưng khi công ty được định giá hàng chục tỷ đồng, một module cốt lõi không rõ quyền sở hữu có thể trở thành vấn đề trong thẩm định đầu tư hoặc tranh chấp.

App có AI, chatbot hoặc nội dung tự động tạo ra cần nhìn quyền sở hữu cẩn trọng hơn

Việc tích hợp AI khiến bản đồ sở hữu trí tuệ phức tạp hơn vì hệ thống có thể đồng thời chứa code của doanh nghiệp, model hoặc API của bên thứ ba, dữ liệu người dùng, prompt, cơ sở dữ liệu và nội dung được tạo ra tự động.

Không nên vì doanh nghiệp vận hành toàn bộ hệ thống mà kết luận doanh nghiệp sở hữu tuyệt đối tất cả các lớp tài sản bên trong. Cục Bản quyền tác giả cũng xác định trí tuệ nhân tạo và chuyển đổi số là những thách thức mới đối với lĩnh vực quyền tác giả trong năm 2026.

Phần code do con người phát triển vẫn cần xác định tác giả thế nào?

Nếu đội developer trực tiếp viết hệ thống chatbot, workflow, backend hoặc lớp tích hợp model, phần sáng tạo của con người vẫn cần được quản trị như những dự án phần mềm khác.

Doanh nghiệp nên lưu commit, giao nhiệm vụ và tài liệu kỹ thuật. Không nên để nhãn “AI app” làm mờ đi câu hỏi cơ bản: ai đã trực tiếp tạo ra phần chương trình mà doanh nghiệp đang đăng ký?

Dữ liệu đầu vào và tài nguyên huấn luyện cần được quản trị ra sao?

Nếu doanh nghiệp tự xây tập dữ liệu hoặc huấn luyện hệ thống, cần xác định nguồn dữ liệu, căn cứ sử dụng, quyền đối với từng nguồn và cách thức dữ liệu được thu thập.

Một tập dữ liệu do doanh nghiệp tổng hợp không đồng nghĩa doanh nghiệp sở hữu quyền tác giả đối với từng tác phẩm chứa trong dữ liệu đó. Vì vậy, data governance và copyright clearance cần được xử lý thành một lớp riêng.

Không nên gom mọi thành phần của hệ thống thành một tuyên bố sở hữu duy nhất

Một hệ thống AI có thể bao gồm code do doanh nghiệp viết, model thuê qua API, thư viện open-source, dữ liệu có giấy phép và nội dung do người dùng cung cấp.

Cách an toàn hơn là tạo IP map: “own”, “licensed”, “open-source”, “user-provided” và “third-party”. Khi đó, doanh nghiệp biết rõ cái gì có thể khẳng định quyền sở hữu và cái gì chỉ có quyền sử dụng.

Khi app bị clone – phải chứng minh không chỉ “nhìn rất giống”

Hai ứng dụng có thể trông giống nhau vì cùng sử dụng pattern giao diện phổ biến. Vì vậy, khi phát hiện app nghi bị sao chép, doanh nghiệp cần tách từng nhóm chứng cứ thay vì chỉ chụp hai màn hình và kết luận “clone 100%”.

Tranh chấp phần mềm thường có giá trị hơn khi có thể chứng minh lịch sử hình thành tác phẩm, thời điểm công bố, source code, repository và mức độ tương đồng ở những thành phần có ý nghĩa.

So sánh code, giao diện và luồng chức năng nên tách biệt thế nào?

Code nên được so sánh với code; giao diện đồ họa so sánh với giao diện; nội dung, hình ảnh và dữ liệu cũng cần được xem xét riêng.

Luồng chức năng lại là câu chuyện phức tạp hơn bởi cùng một nhu cầu kinh doanh có thể dẫn đến các app có quy trình tương tự. Do đó, không nên đánh đồng việc hai ứng dụng cùng có “đăng ký – đặt lịch – thanh toán” với việc sao chép chương trình.

Chứng cứ trên kho ứng dụng nên được lưu tại thời điểm phát hiện ra sao?

Khi phát hiện ứng dụng nghi vi phạm, doanh nghiệp nên lưu thông tin về tên app, developer, phiên bản, ngày quan sát, nội dung listing, hình ảnh và các thông tin có thể thay đổi sau đó.

Song song, cần bảo toàn repository và version của chính mình. Chứng cứ về “tác phẩm gốc là gì và tồn tại từ bao giờ” thường quan trọng không kém chứng cứ về ứng dụng bị cho là sao chép.

Giấy chứng nhận quyền tác giả đóng vai trò gì trong quá trình xử lý?

Giấy chứng nhận giúp ghi nhận các thông tin về tác giả, tác phẩm và chủ sở hữu tại thời điểm đăng ký. Pháp luật cũng dành giá trị chứng cứ đáng kể cho giấy chứng nhận trong tranh chấp, dù giấy chứng nhận không có nghĩa mọi tranh chấp sẽ tự động được giải quyết có lợi cho người đứng tên.

Vì vậy, giấy chứng nhận nên được xem là một lớp trong bộ chứng cứ gồm source code, repository, hợp đồng, lịch sử phát triển, chứng cứ công bố và tài liệu về quyền sở hữu.

Timeline đăng ký ứng dụng tại Hà Nội nên bắt đầu từ ngày khóa phiên bản hồ sơ

Thay vì tính tiến độ từ ngày “đi nộp”, doanh nghiệp nên tính ngược từ ngày dự kiến khóa version. Khi version đã được khóa, đội pháp lý và đội kỹ thuật có thể cùng làm việc trên một bộ dữ liệu cố định.

Tính đến năm 2026, khung thực hiện đăng ký quyền tác giả tiếp tục dựa trên Luật Sở hữu trí tuệ cùng Nghị định 17/2023/NĐ-CP đã được sửa đổi bởi Nghị định 134/2026/NĐ-CP. Mẫu văn bản đăng ký hiện hành cũng đã được cập nhật theo Thông tư 08/2026/TT-BVHTTDL từ ngày 22/04/2026.

Một tuần đầu nên dành cho việc xác định quyền sở hữu thế nào?

Giai đoạn đầu nên tập trung vào danh sách developer, agency, freelancer, repository và hợp đồng. Nếu phát hiện khoảng trống về quyền, xử lý ngay trước khi chuẩn hóa bộ tài liệu kỹ thuật.

Việc này giúp tránh tình trạng đã in và chuẩn bị xong source code nhưng sau đó mới phát hiện một tác giả chưa được xác định hoặc quyền đối với một module chưa rõ.

Khâu chuẩn hóa tài liệu kỹ thuật thường vướng ở đâu?

Lỗi thường gặp là tên chương trình trong tài liệu không giống tờ khai; version ghi không thống nhất; source code lấy từ branch khác; phần giới thiệu mô tả tính năng đã xuất hiện ở version mới nhưng code lại thuộc version cũ.

Đội kỹ thuật nên cử một người chịu trách nhiệm “đóng băng” bộ dữ liệu pháp lý. Việc tiếp tục phát triển sản phẩm có thể diễn ra trên branch khác mà không làm thay đổi tài liệu đăng ký đã khóa.

Làm sao tránh cập nhật app khiến bộ tài liệu nộp trở nên không thống nhất?

Ngay khi quyết định đăng ký version 1.0, doanh nghiệp nên tạo tag hoặc snapshot riêng và lưu toàn bộ tài liệu tương ứng.

Từ thời điểm đó, version 1.1 có thể tiếp tục phát triển bình thường. Nguyên tắc là không quay lại sửa tài liệu của version 1.0 chỉ vì sản phẩm thương mại đã có thêm tính năng.

Chi phí bảo hộ một ứng dụng nên được chia theo “gói tài sản”

Không nên đặt câu hỏi duy nhất “đăng ký bản quyền app hết bao nhiêu?” nếu doanh nghiệp đang sở hữu nhiều tài sản khác nhau. Một chiến lược bảo hộ có thể gồm chương trình máy tính, logo, giao diện, nội dung và nhãn hiệu.

Cách lập ngân sách theo gói tài sản giúp startup ưu tiên tài sản quan trọng nhất trước. Phần mềm cốt lõi có thể được xử lý ngay, trong khi một số tài sản phụ được lên kế hoạch cho giai đoạn sau.

Gói phần mềm cốt lõi gồm những nội dung nào?

Gói cốt lõi nên xoay quanh chương trình máy tính, tác giả, chủ sở hữu, căn cứ hình thành quyền, version và tài liệu kỹ thuật.

Trước khi tính chi phí thủ tục, doanh nghiệp nên tính cả chi phí “làm sạch IP” nếu lịch sử dự án phức tạp. Một app có chain of title rõ ngay từ đầu thường dễ chuẩn bị hơn nhiều so với app đã đổi năm đội developer.

Icon và giao diện có thể cần thêm hồ sơ riêng trong trường hợp nào?

Nếu icon hoặc bộ giao diện là tài sản sáng tạo quan trọng, có giá trị độc lập và doanh nghiệp muốn xây phạm vi chứng cứ rõ hơn, có thể cân nhắc việc bảo hộ theo loại hình phù hợp.

Điều quan trọng là không nên mặc định giấy chứng nhận chương trình máy tính đã giải quyết toàn bộ vấn đề quyền đối với thiết kế đồ họa. Trước khi nộp, cần xác định chính xác từng đối tượng.

Tên app nên dự kiến thêm ngân sách đăng ký nhãn hiệu ra sao?

Nếu tên app sẽ trở thành thương hiệu chính, doanh nghiệp nên dành riêng ngân sách cho tra cứu, đánh giá và đăng ký nhãn hiệu theo nhóm sản phẩm, dịch vụ phù hợp.

Đối với startup có kế hoạch mở rộng, phạm vi nhãn hiệu còn nên được xem xét theo roadmap kinh doanh chứ không chỉ chức năng của ứng dụng ở thời điểm hiện tại.

Sau khi có giấy chứng nhận – ứng dụng vẫn tiếp tục phát triển từng sprint

Giấy chứng nhận không phải điểm kết thúc của quản trị tài sản trí tuệ. App tiếp tục có hàng chục sprint, hàng trăm commit và nhiều module mới sau ngày đăng ký.

Nếu không quản lý những thay đổi này, vài năm sau doanh nghiệp có thể không còn biết version đã đăng ký khác version hiện hành ở những điểm nào.

Nhật ký release giúp quản lý tài sản trí tuệ như thế nào?

Release log nên ghi version, ngày phát hành, module mới, thay đổi lớn và nhóm phụ trách. Khi cần rà lại quyền sở hữu, doanh nghiệp có thể nhanh chóng xác định tài sản mới được tạo vào giai đoạn nào.

Đây cũng là cách giúp pháp lý và kỹ thuật sử dụng cùng một ngôn ngữ. Thay vì hỏi “gần đây app thay đổi nhiều không?”, bộ phận pháp lý có thể nhìn trực tiếp vào lịch sử release.

Module quan trọng mới cần được đánh dấu và lưu chứng cứ ra sao?

Một module AI mới, engine định giá, thuật toán điều phối hoặc hệ thống quản trị có thể có giá trị lớn hơn hàng chục thay đổi giao diện nhỏ.

Khi module như vậy được hoàn thiện, doanh nghiệp nên lưu version, người tham gia, tài liệu giao nhiệm vụ và repository tương ứng. Sau đó mới đánh giá có cần xác lập thêm quyền hoặc thực hiện đăng ký tiếp theo hay không.

Khi thay đổi chủ sở hữu ứng dụng cần cập nhật hồ sơ nào?

Nếu quyền tác giả đã được đăng ký nhưng sau đó chủ sở hữu thay đổi, doanh nghiệp cần xem xét thủ tục cập nhật phù hợp. Theo thông tin của Cục Bản quyền tác giả, trường hợp đề nghị thay đổi chủ sở hữu hoặc thay đổi thông tin về tác phẩm, tác giả, chủ sở hữu thuộc nhóm trường hợp thực hiện cấp đổi giấy chứng nhận theo quy định.

Do đó, khi tái cấu trúc công ty, chuyển IP sang công ty mẹ hoặc thực hiện giao dịch M&A, danh sách giấy chứng nhận quyền tác giả nên được đưa vào checklist tài sản cần xử lý.

Checklist đăng ký bản quyền ứng dụng tại Hà Nội trước ngày phát hành chính thức

Trước khi bấm nút phát hành chính thức, startup nên dành một vòng kiểm tra cuối cho sở hữu trí tuệ. Đây là thời điểm chi phí sửa lỗi quyền sở hữu thường thấp hơn nhiều so với sau khi sản phẩm đã có nhà đầu tư, hàng trăm nghìn người dùng hoặc tranh chấp.

Checklist không nên chỉ hỏi “đã có hồ sơ đăng ký chưa?” mà phải kiểm tra ba lớp: con người và quyền sở hữu; version và tài liệu kỹ thuật; thương hiệu và thành phần bên thứ ba.

Checklist về developer, freelancer và quyền sở hữu source code

Doanh nghiệp cần xác định đầy đủ người trực tiếp tham gia sáng tạo chương trình, quan hệ của họ với công ty và căn cứ để công ty sở hữu các quyền tương ứng. Hợp đồng lao động, mô tả công việc, giao nhiệm vụ, hợp đồng outsource, nghiệm thu và chuyển giao nên tạo thành một chuỗi thống nhất.

Nếu có developer đã nghỉ việc hoặc freelancer ở nước ngoài, cần ưu tiên rà soát phần việc của họ trước ngày phát hành. Những khoảng trống tưởng nhỏ ở giai đoạn này có thể trở thành vấn đề lớn khi app tăng giá trị.

Checklist về version, tên app và tài liệu kỹ thuật

Tên chương trình, tên app, version, ngày hoàn thành và dữ liệu source code cần thống nhất. Repository dùng để lập hồ sơ nên được khóa hoặc đánh tag để có thể truy xuất sau này.

Doanh nghiệp cũng nên lưu một bản archive của tài liệu đã sử dụng. Không nên chỉ giữ file làm việc trên máy của một developer vì người đó có thể nghỉ việc hoặc repository có thể bị thay đổi.

Checklist về nhãn hiệu, icon, giao diện và tài sản bên thứ ba

Cuối cùng, hãy kiểm tra tên ứng dụng đã được rà nhãn hiệu hay chưa; logo và icon do ai thiết kế; giao diện thuộc quyền của ai; font, hình ảnh, SDK, API và thư viện đang sử dụng theo điều kiện nào.

Một ứng dụng được bảo hộ tốt không phải ứng dụng có “một giấy chứng nhận bao trọn mọi thứ”, mà là ứng dụng có bản đồ sở hữu trí tuệ rõ ràng: doanh nghiệp biết tài sản nào mình sáng tạo và sở hữu, tài sản nào được chuyển giao, tài sản nào được cấp phép và tài sản nào thuộc bên thứ ba. Khi bản đồ đó được xây dựng ngay từ giai đoạn đăng ký bản quyền ứng dụng tại Hà Nội, việc gọi vốn, thương mại hóa, chuyển nhượng công nghệ và xử lý hành vi sao chép sau này cũng trở nên chủ động hơn nhiều.

Đăng ký bản quyền ứng dụng tại Hà Nội nên được thực hiện ngay khi sản phẩm đã định hình rõ phiên bản và quyền sở hữu. Chuẩn bị đầy đủ tài liệu về tác giả, mã nguồn, đơn vị phát triển và quá trình chuyển giao sẽ giúp hồ sơ rõ ràng, hạn chế rủi ro pháp lý trong quá trình khai thác ứng dụng.