Kỹ năng đọc bằng sáng chế mà nhiều kỹ sư thường bỏ qua

Càng tìm hiểu sâu vào cơ sở dữ liệu của Văn phòng Sáng chế và Nhãn hiệu Hoa Kỳ (USPTO), mình càng nhận thấy một điều khá thú vị: hầu hết các kỹ sư mình biết đều đọc RFC, các bài báo khoa học, thảo luận trên GitHub hay Stack Overflow suốt cả ngày, nhưng họ chưa bao giờ thực sự mở một bản bằng sáng chế (patent) ra xem. Không phải vì bằng sáng chế không hữu ích, mà là vì chúng trông giống như một văn bản pháp lý khô khan. Font chữ thì nhỏ, ngôn ngữ thì cứng nhắc, và bạn phải lướt qua khoảng 40 đoạn văn bản dài dằng dặc trước khi tìm thấy thứ gì đó thực sự đáng quan tâm.

Thế nhưng, đằng sau lớp vỏ bọc đó, một bản bằng sáng chế thực chất là một tài liệu đặc tả kỹ thuật (technical spec) có gắn kèm các ràng buộc pháp lý. Phần đặc tả được viết bởi chính những người phát minh và được xem xét bởi các thẩm định viên — những người dành cả ngày chỉ để làm việc này. Chúng chứa đựng những mô tả chi tiết về cách thức hoạt động của các hệ thống, đi kèm với các sơ đồ minh họa. Có khoảng 10 triệu bản như vậy, hoàn toàn miễn phí và có thể tìm kiếm được. Vậy mà hầu như chẳng có ai trong một đội ngũ làm sản phẩm chịu đọc chúng.

Cơ sở dữ liệu của USPTO là nguồn thông tin tình báo đối thủ (competitive intelligence) bị bỏ phí nhất đối với một kỹ sư phần mềm — một khi bạn ngừng đọc bằng sáng chế như một văn bản thông thường và bắt đầu truy vấn chúng như một hệ thống.

Trong Bài viết thứ 2 của series này, mình đã lập luận rằng việc nộp bằng sáng chế hiếm khi là bước đi mà những người làm phần mềm nên ưu tiên ngay từ đầu. Bài viết này sẽ khai thác khía cạnh ngược lại: ngay cả khi bạn không bao giờ nộp một cái bằng sáng chế nào, thì chỉ cần dành một buổi chiều để tìm kiếm, bạn sẽ biết được những gì đã được bảo hộ trong lĩnh vực của mình, đối thủ cạnh tranh đang âm thầm xây dựng thứ gì, và những tính năng nào đã bị các thẩm định viên coi là hiển nhiên. Đó là ba thông tin tình báo đối thủ cực kỳ giá trị — hoàn toàn miễn phí, chỉ tốn vài giờ đồng hồ, ngay cả trước khi bạn bắt đầu viết dòng code đầu tiên.

Cấu trúc của một bản đặc tả bằng sáng chế

Hầu hết các bản bằng sáng chế đều được tổ chức theo cùng một cách. Một khi bạn đã nắm rõ cấu trúc này, bạn sẽ không còn đọc từ trên xuống dưới nữa mà sẽ nhảy thẳng vào những phần thực sự quan trọng.

Phần specification (đặc tả) là phần mô tả kỹ thuật — phát minh đó làm gì, hoạt động ra sao, nó giải quyết vấn đề gì. Đây là nơi bạn sẽ tìm thấy các thuật toán, kiến trúc hệ thống hay các sơ đồ phần cứng. Nó được viết cho những người có chuyên môn trong lĩnh vực liên quan, nghĩa là nó sẽ dày đặc hơn một bài blog nhưng vẫn dễ đọc hơn một bài báo học thuật.

Phần claims (các yêu cầu bảo hộ) mới là phần quan trọng về mặt pháp lý. Mỗi claim được đánh số sẽ định nghĩa một ranh giới chính xác. Claim 1 hầu như luôn là claim rộng nhất. Các claim 2, 3, 4 trở đi thường là các biến thể hẹp hơn dựa trên claim 1. Nếu bạn muốn biết chính xác bằng sáng chế đó ngăn cản người khác làm điều gì, hãy đọc các claim. Mọi thứ khác chỉ là thông tin bổ trợ.

Phần drawings (hình vẽ) là các sơ đồ được tham chiếu từ phần đặc tả — có thể là lưu đồ (flowchart), sơ đồ phần cứng hay bản vẽ giao diện (UI mockup). Đây là cách nhanh nhất để hiểu một bản bằng sáng chế lạ lẫm đang nói về điều gì. Mình hầu như luôn xem phần này đầu tiên.

Cái mẹo mà mình muốn nhấn mạnh là bạn không cần phải đọc từng chữ trong phần đặc tả. Bạn chỉ cần đọc tiêu đề, lướt qua bản tóm tắt (abstract), xem hình vẽ, rồi đọc claim 1. Chỉ mất khoảng 5 phút. Nếu thấy thứ gì đó liên quan, lúc đó mới cần đi sâu hơn.

Hai công cụ tìm kiếm, cùng một nguồn dữ liệu

USPTO cung cấp công cụ Patent Public Search tại địa chỉ patents.uspto.gov. Còn Google thì có Google Patents tại patents.google.com. Cả hai đều dùng chung một nguồn dữ liệu gốc, nhưng trải nghiệm sử dụng thì rất khác nhau.

Mình thường mặc định dùng Google Patents cho hầu hết các bước tìm kiếm đầu tiên. Giao diện của nó nhanh hơn, các gợi ý về bằng sáng chế liên quan rất xuất sắc, và chuỗi trích dẫn cũng dễ theo dõi hơn. Khi cần sự chính xác tuyệt đối — như truy vấn theo từng trường thông tin cụ thể, xem lịch sử thẩm định (prosecution history) hay các thủ tục sau khi cấp bằng — mình mới chuyển sang USPTO Patent Public Search.

Nếu bạn chưa bao giờ dùng cả hai, hãy bắt đầu với Google Patents. Việc bỏ công học cú pháp của USPTO chỉ thực sự xứng đáng khi bạn cần độ chính xác cực cao cho một mục tiêu cụ thể.

Truy vấn hệ thống, thay vì chỉ "duyệt" nó

Cải tiến lớn nhất mà một kỹ sư có thể áp dụng khi tìm kiếm bằng sáng chế là ngừng gõ các cụm từ tiếng Anh thông thường và bắt đầu sử dụng truy vấn Boolean với các mã trường (field codes). Ngôn ngữ truy vấn của USPTO mang lại cho bạn sức mạnh tương tự như khi bạn dùng grep trong codebase vậy.

Các toán tử rất đơn giản nhưng khi kết hợp lại thì cực kỳ mạnh mẽ.

Các mã trường giúp bạn giới hạn truy vấn vào một phần cụ thể của bằng sáng chế — như tiêu đề, tóm tắt, các claim, tên người phát minh hay công ty sở hữu (assignee ).

Một mẹo hữu ích: hãy tìm kiếm theo trường assignee để soi một đối thủ cụ thể. Nếu bạn muốn biết Stripe đang đăng ký bằng sáng chế cho thứ gì, hãy chạy lệnh .as.(Stripe). Bạn sẽ thấy mọi bằng sáng chế thuộc về họ, được xếp theo ngày tháng. Kết quả này thực chất là một lộ trình R&D công khai — dù có độ trễ một chút (bằng sáng chế thường được công bố sau 18 tháng kể từ khi nộp), nhưng nó vẫn rất đầy đủ.

Điều đã thay đổi hoàn toàn cách mình nhìn nhận về nghiên cứu đối thủ: các công ty chỉ công bố một phần nhỏ những gì họ thực sự đang làm. Họ nộp bằng sáng chế cho nhiều thứ hơn thế — và bằng sáng chế sẽ được công bố sau 18 tháng kể từ ngày nộp, bất kể sản phẩm có được tung ra thị trường hay không. Đọc danh sách bằng sáng chế của một đối thủ sẽ cho bạn thấy lộ trình nội bộ của họ từ 18 tháng trước, chính xác hơn nhiều so với việc đọc các thông cáo báo chí ngày hôm nay.

Mã CPC: "Siêu năng lực" thực thụ

Tìm kiếm bằng từ khóa thì cũng tạm ổn. Nhưng tìm kiếm theo phân loại (classification search) thì tốt hơn nhiều. Hệ thống Phân loại Sáng chế Hợp tác (CPC) là một hệ thống danh mục phân cấp được USPTO, Cơ quan Sáng chế Châu Âu và hầu hết thế giới sử dụng. Mỗi bằng sáng chế sẽ được gán một hoặc nhiều mã CPC trong quá trình thẩm định.

Một số mã CPC mà kỹ sư phần mềm nên biết:

• G06F — xử lý dữ liệu số (hầu hết các phát minh phần mềm đều nằm ở đây)
• G06N — máy học, mạng thần kinh, kiến trúc AI
• G06Q — hệ thống kinh doanh và thương mại (fintech, thanh toán, sàn thương mại điện tử)
• H04L — mạng và truyền dẫn kỹ thuật số (TLS, định tuyến gói tin, truyền thông IoT)
• G16Y — chuyên về Internet of Things (vạn vật kết nối)

Tìm kiếm theo phân loại vượt trội hơn từ khóa vì nó giúp bạn tìm thấy những bằng sáng chế mà bạn chẳng bao giờ đoán được từ ngữ để tìm. Hai kỹ sư có thể mô tả cùng một thuật toán bằng những thuật ngữ hoàn toàn khác nhau. Nhưng họ sẽ đều nhận được cùng một mã CPC từ thẩm định viên — những người đã phân loại hàng ngàn phát minh tương tự.

Quy trình hiệu quả là:

Bước 1 giúp bạn tìm đúng "khu phố". Bước 2 cho bạn biết tên của khu phố đó. Bước 3 giúp bạn mở rộng tìm kiếm ra mọi thứ khác trong cùng khu phố. Bước 4 tìm ra những phát minh cũ hơn mà các bản sáng chế của bạn đang dựa trên. Bước 5 tiết lộ công ty nào đang tập trung nguồn lực vào lĩnh vực đó.

Mình thấy việc coi mã CPC như các "namespace" (không gian tên) là rất hữu ích. Một khi bạn biết phát minh của mình nằm trong namespace nào, bạn có thể quét qua toàn bộ namespace đó rất nhanh.

Đọc bằng sáng chế như cách bạn review code

Khi kết quả tìm kiếm trả về thứ gì đó thú vị, câu hỏi tiếp theo là làm sao để đọc nó mà không tốn cả buổi chiều. Mẹo ở đây là hãy đọc bằng sáng chế theo thứ tự tương tự như khi bạn review một pull request: bắt đầu từ phần quan trọng nhất, sau đó mới đi sâu dần ra ngoài nếu cần.

Claim 1 xứng đáng được soi kỹ vì hầu hết các bản bằng sáng chế đều được thiết kế để mọi thứ quan trọng nhất đều xuất hiện ở đây. Một claim 1 điển hình thường là một câu rất dài với danh sách các mệnh đề "wherein" (trong đó), mỗi mệnh đề thêm vào một yếu tố bắt buộc. Nếu sản phẩm của bạn không có đầy đủ các yếu tố liệt kê trong claim 1, thì bằng sáng chế đó không áp dụng cho bạn. Nhưng nếu nó có tất cả, bạn có thể đang gặp rắc rối — ngay cả khi cách triển khai của bạn có những điểm khác biệt khác.

Mô hình tư duy giúp ích cho mình là: một claim giống như một phép toán Boolean AND của tất cả các yếu tố trong đó. Để vi phạm, bạn cần có đủ mọi yếu tố. Chỉ cần thiếu một cái thôi là bạn không vi phạm.

Các claim phụ thuộc (claim 2, claim 3, v.v.) thường có dạng "phương pháp của claim 1, trong đó [thêm yêu cầu bổ sung]". Chúng làm hẹp claim 1 bằng cách thêm các yếu tố mới. Chúng tồn tại chủ yếu như một phương án dự phòng — nếu claim 1 hóa ra quá rộng và bị bác bỏ, chủ sở hữu bằng sáng chế vẫn có thể dựa vào một claim phụ thuộc hẹp hơn nhưng vẫn được chấp nhận.

Lịch sử thẩm định: Nơi cất giấu những thông tin đắt giá nhất

Đây là phần của hệ thống bằng sáng chế mà hầu hết kỹ sư không biết là nó tồn tại. Mọi hồ sơ Office Action — mọi lần bị từ chối, mọi lập luận, mọi sửa đổi — đều được công khai trong lịch sử thẩm định (prosecution history), truy cập thông qua Patent Center của USPTO.

Bạn có thể đọc được gì trong lịch sử thẩm định:

• Các claim gốc lúc mới nộp (thường rộng hơn nhiều so với những gì được cấp)
• Những bằng chứng đối chiếu (prior art ) chính xác mà thẩm định viên đã nêu ra như một trở ngại
• Các lập luận mà luật sư đã đưa ra để vượt qua sự từ chối đó
• Những sửa cuối cùng để giúp các claim được chấp thuận

Đối với việc nghiên cứu prior art, thông tin này cực kỳ hữu ích. Thẩm định viên đã làm thay bạn công việc tìm kiếm các bằng sáng chế liên quan nhất rồi. Các trích dẫn của họ thực chất là một danh sách đọc đã được chọn lọc kỹ càng.

Đối với thông tin tình báo đối thủ, nó còn hữu ích hơn nữa. Các sửa đổi sẽ cho bạn biết chính xác ranh giới của bằng sáng chế nằm ở đâu. Nếu một đối thủ phải thu hẹp các claim của họ từ "bất kỳ phương pháp nào để làm X" thành "một phương pháp làm X bằng kỹ thuật Y", bạn sẽ biết rằng họ không thể được bảo hộ cho ý tưởng rộng hơn — điều đó có nghĩa là bạn có nhiều không gian tự do để thiết kế hơn so với những gì bản bằng sáng chế đã cấp gợi ý.

"Liệu AI có làm thay mình hết mấy việc này không?"

Đây là một câu hỏi hay, và chính mình cũng từng tự hỏi như vậy. Kho dữ liệu bằng sáng chế có khoảng 10 triệu tài liệu với cấu trúc rõ ràng. Các mô hình ngôn ngữ lớn (LLM) đọc thứ ngôn ngữ kiểu bằng sáng chế này rất tốt. Các công cụ tóm tắt bằng sáng chế, phác thảo bảng đối chiếu claim hay tự động tìm kiếm prior art đã tồn tại và đang ngày càng hoàn thiện nhanh chóng.

Tuy nhiên, có hai điều vẫn đúng ngay cả khi có những mô hình mạnh mẽ hỗ trợ:

Thứ nhất, các claim vẫn là nơi chứa đựng các ranh giới pháp lý. Một con AI có thể tóm tắt phần đặc tả kỹ thuật rất hay nhưng vẫn có thể hiểu sai ngôn ngữ của claim nào đã bị thu hẹp trong quá trình thẩm định và claim nào được giữ nguyên. Đối với bất kỳ quyết định quan trọng nào — liệu mình có đang vi phạm không, mình có thể thiết kế né nó ra sao, quyền hạn thực sự của chủ bằng sáng chế là gì — bạn bắt buộc phải tự mắt đọc các claim. LLM có thể đẩy nhanh tốc độ tìm kiếm và lướt qua lần đầu, nhưng nó không thể thay thế việc đọc kỹ lưỡng.

Thứ hai, hiểu về hệ thống mới là thứ khiến LLM trở nên hữu dụng. Nếu bạn không biết mã CPC là gì, bạn sẽ không biết để yêu cầu mô hình tìm chúng. Nếu bạn không biết lịch sử thẩm định là công khai, bạn sẽ không biết để hỏi về nó. Hầu hết đòn bẩy trong bài viết này không nằm ở cú pháp tìm kiếm — mà nằm ở việc biết mình cần tìm cái gì. Đó chính là phần mà mô hình không thể tự thân vận động hoàn toàn. Vì vậy, LLM không thay thế kỹ năng trong bài viết này; nó chỉ khuếch đại sức mạnh cho những ai đã nắm rõ nó mà thôi.

Thực tế sẽ trông như thế nào

Hãy tưởng tượng bạn là một kỹ sư sắp bắt đầu xây dựng một sản phẩm bẫy chuột thông minh (smart-trap). Trước khi viết bất kỳ dòng code nào, bạn muốn biết những gì đã được cấp bằng sáng chế trong không gian này. Đây là kết quả sơ bộ sau khoảng 20 phút tìm kiếm:

Kết thúc 20 phút đó, bạn đã biết chính xác những cơ chế nào đang được bảo hộ, những công ty nào đang đầu tư nghiêm túc vào mảng này, và — từ lịch sử thẩm định — những loại tính năng nào mà các thẩm định viên coi là hiển nhiên đến mức phải từ chối. Bạn đã thực hiện một cuộc khảo sát thị trường khắt khe hơn hầu hết các quản lý sản phẩm (PM) trước khi bật đèn xanh cho một dự án, và bạn chẳng tốn một xu nào.

Đây là điều mà mình ước chi có ai đó đã nói với mình sớm hơn. Tỷ lệ chi phí/lợi ích của việc tìm kiếm bằng sáng chế là cực kỳ lớn. Vài giờ học cách sử dụng các công cụ tìm kiếm sẽ mang lại giá trị cho mọi quyết định sản phẩm mà bạn thực hiện sau này.

Thử ngay: mở patents.google.com tối nay và chạy lệnh assignee: cho đối thủ cạnh tranh gần nhất của bạn. Mười phút, không tốn một xu — lộ trình trung thực nhất bị trì hoãn 18 tháng mà bạn từng đọc.

Ghi chú sau 20 phút tìm kiếm bằng sáng chế

• Một bản bằng sáng chế có ba phần — đặc tả, các claim, hình vẽ — và chỉ có phần claim mới định nghĩa ranh giới pháp lý.
• Thứ tự đọc: tiêu đề và tóm tắt trước, sau đó đến hình vẽ, rồi đến claim 1, cuối cùng mới là những thứ khác nếu cần.
• Google Patents giải quyết được 80% nhu cầu tìm kiếm; hãy dùng USPTO Patent Public Search khi cần các mã trường chính xác hoặc lịch sử thẩm định.
• Các truy vấn Boolean với mã trường (.ti., .ab., .cl., .as.) giúp việc tìm kiếm bằng sáng chế giống như dùng grep hơn là đi dạo trong thư viện.
• Mã CPC là các "namespace" của hệ thống bằng sáng chế — một khi bạn biết namespace đó, bạn có thể quét qua toàn bộ không gian đó rất nhanh.
• Tìm kiếm theo công ty sở hữu (assignee ) cho bạn thấy lộ trình sản phẩm của đối thủ với độ trễ khoảng 18 tháng.
• Một claim là một phép toán Boolean AND của các yếu tố — để vi phạm, bạn cần đủ mọi yếu tố; chỉ cần thiếu một cái là không vi phạm.
• Lịch sử thẩm định (prosecution history) có thể xem công khai trên Patent Center, nó cho bạn biết chính xác các góc cạnh của bằng sáng chế nằm ở đâu.
• Các trích dẫn của thẩm định viên là một danh sách đọc miễn phí về các bằng chứng đối chiếu (prior art ) gần nhất cho bất kỳ ý tưởng nào.
• Dành 20 phút tìm kiếm bằng sáng chế trước khi bắt đầu một sản phẩm là một trong những bước đi mang lại đòn bẩy cao nhất cho một kỹ sư.

Điều cuối cùng đó chính là thứ đã thay đổi hoàn toàn quan điểm của mình về chủ đề này. Hầu hết chúng ta coi bằng sáng chế là việc của người khác — luật sư, đội ngũ pháp chế, hay bộ phận sở hữu trí tuệ. Nhưng cơ sở dữ liệu đó là công khai, công cụ thì miễn phí, và mật độ thông tin thì không thể tin nổi. Đó là nguồn tin tình báo đối thủ miễn phí nằm ngay trước mắt, được viết bởi những người trực tiếp xây dựng sản phẩm và được xem xét bởi những chuyên gia kỳ cựu.

Bài viết thứ 4 — cũng là bài cuối cùng trong series — sẽ xem xét câu hỏi chiến lược khó hơn: bạn nên làm gì khi đã quyết định nộp đơn, và cách hệ thống quốc tế khiến quyết định đó rẻ hơn bạn tưởng rất nhiều.

Công cụ và tài liệu tham khảo

• USPTO Patent Public Search (patents.uspto.gov) — Dùng để: tra cứu cú pháp truy vấn, mã trường, toán tử Boolean và truy cập lịch sử thẩm định.
• Google Patents (patents.google.com) — Dùng để: giao diện tìm kiếm thay thế, biểu đồ trích dẫn và ví dụ về bản Victor Smart-Kill US10440944B2.
• USPTO Manual of Patent Examining Procedure (MPEP) — Dùng để: tìm hiểu nguyên tắc diễn giải claim và vai trò của lịch sử thẩm định.
• Cooperative Patent Classification (cpc.uspto.gov) — Dùng để: cấu trúc phân cấp CPC (Phần / Lớp / Lớp phụ) và các mã G06F, G06N, G06Q, H04L, G16Y được nhắc đến trong bài.
• Tài liệu hướng dẫn USPTO Patent Center — Dùng để: giải thích cách truy cập công khai các Office Action và lịch sử thẩm định.