משרד דרורי סתיו מלווה חברות טכנולוגיה, יזמים וממציאים בניסוח ובהגשה של בקשות פטנט בתחום התוכנה ומדעי המחשב. ניסיוננו בתחום מבוסס על שילוב של הבנה טכנולוגית במערכות מחשוב עם מומחיות משפטית בדיני פטנטים, בניסוח תביעות ובהליכי רישום פטנטים בישראל ובעולם.
בתהליך רישום פטנטים בתחום התוכנה, עבודת הניסוח מתחילה הרבה לפני כתיבת התביעה הראשונה. צריך להבין מהי הבעיה הטכנולוגית, באילו רכיבים ומנגנונים היא מתבטאת וכיצד הפתרון המוצע משנה את דרך פעולתה של מערכת מחשוב או של תהליך טכנולוגי אחר. כאשר הממציא מתאר רק את התוצאה – ״המערכת פועלת מהר יותר״, ״האפליקציה מאובטחת״ או ״השרת מזהה תקלות״ – קשה לדעת מה בדיוק ניתן לדרוש כהגנת פטנט.
בקשה טובה אינה מסתפקת בהצמדת המונחים ״מעבד״, ״זיכרון״ או ״שרת״ לרעיון מופשט, ואינה מבססת את האמצאה רק על תועלת עסקית. עליה לתאר באופן מספק את המנגנון הטכנולוגי, את רצף הפעולות, את יחסי הגומלין בין הרכיבים ואת המאפיינים שמבדילים את הפתרון מן הידוע. לאחר מכן אפשר לבחון אילו תביעות מתאימות להגדרת היקף ההגנה.
מאמר זה עוסק במלאכת הניסוח של בקשת פטנט בתחום התוכנה, ולא בשאלה המקדמית של הכשירות לפי דיני המדינות השונות. לדיון בהבחנה בין אמצאה טכנולוגית לבין רעיון מופשט ובמבחני ישראל, אירופה וארה״ב, ראו פטנטים בתחום התוכנה – כשירות לרישום בישראל, באירופה ובארה״ב.
השלב הראשון: זיהוי החידוש הטכנולוגי לפני ניסוח התביעות
מפתחי תוכנה נוהגים לתאר את המוצר דרך מה שהמשתמש רואה: מסך, שירות, תוצאה או ממשק. לעורך הפטנטים דרוש מידע נוסף. עליו להבין כיצד המערכת בנויה, אילו נתונים עוברים בין רכיביה, מתי מתרחשים האירועים שבבסיס הפעולה ומה משתנה ביחס למערכות קיימות.
נניח שחברה מפתחת פלטפורמה המקבלת נתוני חיישנים ממאות מתקנים. כאשר התקשורת הסלולרית אינה יציבה, חלק מהמדידות אובדות וחלקן נשלחות יותר מפעם אחת. מהנדסי החברה פיתחו מנגנון שמצמצם אובדן נתונים בלי לשדר מחדש את כל המידע שנאגר. מנקודת המבט של המשתמש ניתן לתאר זאת כ״סנכרון אמין״, אך הביטוי אינו מלמד כיצד הושגה התוצאה.
כדי לנסח בקשת פטנט צריך לברר, למשל, אם החידוש נמצא במבנה רשומה הכוללת מספר רצף, באופן שבו הנתונים נאספים בזיכרון מקומי, במנגנון אישור הקבלה של השרת, בהחלטה אילו מקטעים יש לשדר שוב או בשילוב מסוים של הפעולות. רק לאחר מכן אפשר להעריך איזה רכיב הוא חיוני להגדרת האמצאה ואילו רכיבים הם חלופות או תוספות.
הבירור נעשה לצד חיפוש ידע קודם, כדי להימנע מהצגת פרוטוקול תקשורת מוכר כהמצאה חדשה. להרחבה ראו בדיקת פטנטביליות לפני רישום פטנט.
כיצד עוברים מתיאור של תוצאה לתיאור של דרך פעולה?
ביטויים פונקציונליים כגון ״מעבד המזהה תקלה״ או ״מודול המצמצם שימוש בזיכרון״ עשויים להיות שימושיים כחלק מניסוח התביעה, אך אם הם ניצבים לבדם, ללא תיאור מימוש מתאים, הם אינם מסבירים כיצד בעל מקצוע בתחום יכול לבצע את האמצאה.
נחזור למערכת החיישנים. במקום לומר רק שהמערכת ״משחזרת נתונים חסרים״, אפשר לתאר כי יחידת הקצה שומרת רשומות בסדר עוקב, משייכת להן מזהים, מעבירה מקטעים לשרת ומקבלת ממנו אישור המציין את המזהה הרציף האחרון שהתקבל. לאחר ניתוק תקשורת, יחידת הקצה מזהה את האישור האחרון ומעבירה שוב רק את הרשומות שלא אושרו, תוך טיפול במצבים שבהם הגיעו רשומות שלא לפי סדרן.
תיאור זה עדיין אינו מוכיח חידוש או התקדמות המצאתית, אך הוא מאפשר להבין את המנגנון שעליו רוצים לבקש הגנה. ניתן להוסיף כיצד מזהים רשומה כפולה, מה קורה כאשר הזיכרון המקומי מתמלא ואיך מונעים מצב שבו אישור קבלה מאוחר גורם למחיקת נתון שטרם אושר.
הפרטים האלה הם לעיתים המפתח לניסוח נכון. הם גם עשויים לחשוף מגבלות טכנולוגיות שהממציא לא זיהה בתחילה, ולסייע לו לפתח שדרוגים חדשים לפני הגשת הבקשה.
ניסוח תביעה בלתי תלויה באמצאה המיושמת באמצעות תוכנה
התביעה הבלתי תלויה מגדירה מערכת, שיטה או אמצאה אחרת בלי להסתמך על תביעה קודמת. עליה לכלול את המאפיינים הנדרשים להגדרת הפתרון המבוקש, באופן ברור ומגובה בפירוט. כאשר מנסחים תביעה בתחום התוכנה, השאלה אינה אם מופיעות בה מילים רבות מתחום המחשבים, אלא אם היא מתארת את המאפיינים שמובילים לתרומה הטכנולוגית.
לשם המחשה בלבד, אפשר לשקול תביעה לשיטה המתבצעת במערכת תקשורת הכוללת יחידת קצה ושרת, שבה יחידת הקצה מצמידה לכל רשומת מדידה מזהה רציף, שומרת את הרשומה בזיכרון מקומי, מעבירה לשרת מקטע של רשומות, מקבלת אישור קבלה המצביע על מזהה רציף מסוים, ולאחר זיהוי ניתוק וחידוש תקשורת בוחרת לשידור חוזר רשומות שמזהיהן מאוחרים מן המזהה שאושר.
הדוגמה ממחישה את רמת הפירוט המבנית והפעולתית שאפשר לבחון בתביעה; אין מדובר בנוסח של תביעה מוכנה להגשה, ולא נטען שהמנגנון המתואר חדש. בפועל יש לבדוק את הידע הקודם, לקבוע אילו מאפיינים חיוניים, לבחור את רמת ההכללה המתאימה ולנסח תביעות בהתאם לדרישות המשרד שבו יוגש הפטנט.
נוסח צר מדי עלול לאפשר למתחרה לשנות פרט שאינו חיוני ולצאת מהיקף ההגנה. נוסח רחב מדי, המגדיר רק תוצאה בלי מנגנון מתאים או בלי תמיכה בפירוט, עלול להיתקל בהשגות בדבר חוסר בהירות, היעדר תמיכה או היעדר התקדמות המצאתית. האתגר הוא להגדיר נכון את מכלול המאפיינים שמספק את השיפור הטכנולוגי.
לניתוח של תביעה בלתי תלויה בפטנט אמיתי מתחום התוכנה, ראו את מקרה הבוחן של הפטנט האמריקאי של Waze. בתביעה הראשונה של פטנט US 8,762,035 מוגדרים שרת, מכשירי ניווט, קליטת מיקומים, הצגת נתוני תנועה ובחירת מסלול לפי נתוני משתמשים בקבוצת נסיעה. כך ניתן לראות כיצד התביעה מגדירה קשר בין רכיבים ופעולות, להבדיל מתיאור כללי של ״אפליקציה לניווט״. אין בכך המלצה לאמץ את נוסח התביעה ללא בדיקת הדין והידע הקודם.
תביעות תלויות: תיעוד של שיפורים ודרכי ביצוע חלופיות
לאחר גיבוש התביעה הבלתי תלויה רצוי לבחון אילו מאפיינים נוספים ראויים לתביעות תלויות. במערכת החיישנים אפשר לבחון, למשל, מנגנון לאיתור רשומות חסרות במקטע שאושר חלקית, סף לקביעת מועד שידור חוזר, דרך חלופית לשמירת נתונים כאשר הזיכרון מוגבל או מנגנון להתאוששות לאחר הפעלה מחדש של יחידת הקצה.
תביעה תלויה יכולה להוסיף מאפיין טכני שעשוי להקנות בסיס הגנה חלופי אם בהליך הבחינה יימצא שהרעיון הרחב כבר פורסם. עם זאת, תביעות תלויות אינן תחליף לפירוט האמצאה. אם שיפור מופיע לראשונה רק לאחר הגשת הבקשה ולא היה לו בסיס מתאים במסמכי ההגשה המקוריים, לא תמיד ניתן יהיה להוסיף אותו לתיק הקיים בלי להתמודד עם מגבלות על הוספת חומר חדש.
לכן חשוב לבחון מראש מספר דרכי ביצוע אפשריות. רצוי להסביר איזה רכיב יכול להיות מוחלף, אילו חלופות משיגות את אותה תרומה טכנולוגית ואילו מגבלות של המימוש חיוניות להשגתה. לעיתים דווקא החלופה שהתגלתה בדיון עם המהנדסים היא שתאפשר להתמודד מאוחר יותר עם פרסום קודם.
לרקע נוסף על התפקיד של תביעות בלתי תלויות ותלויות ראו איך מנסחים פטנט.
האם אפשר לנסח תביעה לתוכנה עצמה או לאמצעי אחסון?
בקשות לפטנטים בתחום התוכנה עשויות לכלול, בהתאם לדין הרלוונטי, תביעות לשיטה ממוחשבת, למערכת הכוללת רכיבי מחשוב ולעיתים גם לאמצעי אחסון קריא למחשב או לתוצר תוכנה. בכל מסלול יש לבדוק את הכללים לגבי קטגוריות התביעות, ואת הקשר בין ההיקף המבוקש לבין המימוש הטכנולוגי שתואר בפירוט.
לפי הנחיות ה־EPO לשנת 2026, אמצאות המיושמות במחשב יכולות להיתבע בקטגוריות שונות, אך התביעה צריכה לכלול את המאפיינים החיוניים לאפקט הטכני המתואר. לא די להחליף באופן מילולי את המילה ״שיטה״ ב״תוכנה״ או ״מערכת״. למשל, אם השיפור תלוי באופן שבו יחידת קצה ושרת מחליפים אישורי קבלה, יש לתאר את יחסי הגומלין האלה גם בקטגוריית התביעה המתאימה.
בארצות הברית יש להיזהר מתביעות לאמצעים שאינם מוגדרים כאמצעי אחסון שאינו ארעי (non-transitory) כאשר הדין והפרקטיקה מחייבים זאת, ואין להניח שכל קטגוריית תביעה תעמוד בפני עצמה במבחן הכשירות לפי סעיף 101 לחוק האמריקאי. קטגוריית התביעה היא חלק מהתכנון, אך אינה משנה את מהותה הטכנולוגית של האמצאה.
לעיון בפרקטיקה האירופית ראו הנחיות EPO בנושא ניסוח תביעות לאמצאות מיושמות מחשב.
כיצד כותבים את פירוט האמצאה כך שבעל מקצוע יוכל לבצע אותה?
הפירוט נועד לתאר את האמצאה בדרך שתאפשר לבעל מקצוע בתחום לבצעה. בתוכנה אין משמעות הדבר שחייבים תמיד לצרף את מלוא קוד המקור, אך אין להסתפק במתן שם למודול ולהצהיר שהוא מבצע תוצאה רצויה. יש להסביר כיצד מתבצעת הפעולה הטכנולוגית, אילו נתונים מעובדים, איזה מידע נשמר ומהם הקשרים בין המרכיבים.
במערכת החיישנים ראוי לתאר את מבנה המידע של הרשומות, את דרך הקצאת המזהים, את יחסי הגומלין בין יחידת הקצה לשרת ואת הטיפול במצבי חריגה. למשל, יש לתאר איך נוהגת המערכת כאשר מתרחשת הפסקת חשמל לפני שמתקבל אישור קבלה, כאשר מגיעות רשומות לא לפי הסדר או כאשר אותו מקטע משודר פעמיים.
במקרים המתאימים אפשר לציין גם אילו רכיבים מוכרים משמשים לביצוע הפעולה, למשל זיכרון בלתי נדיף, יחידת עיבוד או ממשק תקשורת, ובלבד שמובהר מהו אופן השימוש הטכנולוגי הרלוונטי בהם. אם האמצאה קשורה למימוש מסוים של אלגוריתם, הפירוט צריך לתמוך בצעדים המהותיים שלו ובחלופות הטכנולוגיות שעליהן מבקשים הגנה.
רשות הפטנטים הישראלית מדגישה בהנחיות ההגשה כי הפירוט צריך לכלול רקע טכנולוגי, תיאור הידע הקודם, הגדרת האמצאה, הסבר ההבדלים מן המוכר ודרך הפעולה. כמו כן, אין די ברשימת רכיבים ללא תיאור היחסים ביניהם. ראו את הנחיות רשות הפטנטים לעריכת בקשת פטנט.
תרשימי ארכיטקטורה, זרימה ורצף בהכנת בקשת פטנט תוכנה
בבקשות תוכנה תרשימים יכולים להיות חשובים במיוחד, משום שהם מאפשרים להבין את האמצאה מבלי לעיין בקוד המקור. תרשים ארכיטקטורה יכול להציג את יחידות הקצה, השרת, מסד הנתונים וממשקי התקשורת ביניהם. תרשים זרימה יכול להמחיש את תנאי ההחלטה: מתי מבוצע שידור חוזר ומתי נתון מסומן כמאושר. תרשים רצף (Sequence Diagram) יכול להראות את סדר החלפת ההודעות בין יחידת הקצה לבין השרת.
התרשימים צריכים לתמוך בתיאור המילולי ולא לסתור אותו. אם תרשים מציג רכיב בשם ״מנהל שידורים״, רצוי להסביר בפירוט מה הוא עושה ואילו פעולות הוא מבצע. אם מוצגים כמה מצבי פעולה, יש להבהיר מה גורם למעבר ביניהם. רצוי להשתמש בסימוני רכיבים עקביים לאורך השרטוטים והתיאור.
תרשים סכמטי מדי שבו מופיעים רק ״משתמש״, ״ענן״ ו״בינה מלאכותית״ אינו בהכרח מלמד על הדרך שבה האמצאה פועלת. מנגד, אין צורך לשרטט כל שורת קוד. יש לבחור ברמת פירוט המאפשרת להבין את המנגנון הנתבע ואת דרכי ביצועו.
תיאור הרקע הטכנולוגי בלי להודות מעבר לנדרש בידע קודם
חלק הרקע נועד להסביר את הבעיה הטכנולוגית ואת הפתרונות הרלוונטיים המוכרים. הוא אינו המקום להבטחות שיווקיות כגון ״המערכת המהפכנית הראשונה בעולם״. ראוי לתאר את הבעיה באופן מדויק, להסביר אילו קשיים קיימים במערכות מוכרות ולהימנע מקביעות נחרצות שאינן מבוססות.
במערכת החיישנים אפשר להסביר שתקשורת אלחוטית אינה זמינה תמיד וששידור חוזר בלתי מבוקר עשוי להעמיס על הרשת ולגרום לכפילויות. אולם אין להניח שכל מערכת קודמת אינה מסוגלת להתמודד עם הבעיה. יש לבחון מה מוכר בתחום ולהסביר איזה שילוב מסוים של מאפיינים מוצע בבקשה החדשה.
המטרה היא ליצור רקע אמין לבחינת האמצאה, בלי לייחס לעצמנו בטעות הודאה רחבה בדבר מצב הידע הקודם ובלי לבנות את הבקשה על הנחה שקל להפריך בחיפוש פטנטים.
איך מבססים טענה לשיפור טכנולוגי, ולא רק לתוצאה עסקית?
תיאורים כגון ״המערכת מפחיתה את העלות ב־30 אחוזים״ או ״משפרת את חוויית המשתמש״ אינם מספקים כשלעצמם תמיכה באפקט טכנולוגי. אם יש טענה להפחתת שימוש בזיכרון, לצמצום מספר השידורים, להגדלת אמינות הסנכרון או להפחתת השהיה, רצוי להסביר כיצד נמדד השיפור ומהו המנגנון שגורם לו.
לא תמיד קיימים נתוני ניסוי בשלב הכנת הבקשה, ואין להמציא נתוני ביצועים. אפשר לתאר את התוצאה הטכנולוגית הצפויה בהקשר למאפייני המערכת, ולהוסיף נתוני השוואה אמיתיים אם הם זמינים. בהמשך, אם נערכות בדיקות, ניתן לבחון כיצד הן תומכות בטענות שכבר הופיעו בפירוט. אולם אין להניח שניתן יהיה להשתמש בנתונים מאוחרים כדי להשלים בדיעבד תיאור טכנולוגי שהיה חסר בבקשה כפי שהוגשה.
בהנחיות ה־EPO בנושא אמצאות המשלבות מאפיינים טכניים ולא טכניים, הבחינה מתמקדת במאפיינים התורמים לאופי הטכני ובהשפעתם על הפתרון לבעיה טכנית. לכן ראוי שהתיאור הטכנולוגי יבהיר את הקשר בין המאפיינים הנתבעים לבין האפקט הרלוונטי. ראו הנחיות EPO לשנת 2026 לפי גישת COMVIK.
ניסוח בקשה אחת המיועדת לישראל, לאירופה ולארה״ב
ממציאים רבים מגישים תחילה בקשה אחת ומתכננים להמשיך ממנה למדינות שונות. בתחום התוכנה כדאי לחשוב על כך כבר בעת הכנת הפירוט, משום שהמשרדים השונים עשויים להתמקד בשאלות שונות: בישראל באופי הטכנולוגי של האמצאה, באירופה בתרומה הטכנית ובהתקדמות ההמצאתית, ובארה״ב גם בשאלה אם התביעה מכוונת לרעיון מופשט או לשיפור טכנולוגי המיושם באופן מעשי.
אין פירוש הדבר שצריך לנסח בקשה מלאכותית המשבצת את כל המונחים המשפטיים של כל המדינות. עדיף לתאר היטב את הטכנולוגיה, להציג מימושים ודרכי פעולה חלופיות ולספק בסיס נאות לכמה אפשרויות תביעה. לאחר מכן אפשר להתאים את נוסח התביעות להליכי הבחינה המקומיים, בלי להוסיף חומר שלא נחשף כדין בבקשה המקורית.
למשל, אם המימוש כולל יחידת קצה ושרת, כדאי להסביר גם כיצד עובד הפתרון במערכת מקומית, כיצד ניתן לשנות את חלוקת החישוב בין הרכיבים והאם המאפיין הטכנולוגי החיוני תלוי בסוג התקשורת. אין לפרט חלופות דמיוניות שאין להן בסיס הנדסי, אך גם אין לצמצם את התיאור לגרסה מסחרית יחידה אם קיימות דרכי ביצוע ממשיות נוספות.
לתכנון מסלול ההגשה ראו גם את המאמר בקשת PCT – הליך הגשה בינלאומית לפטנט.
דוגמה למבנה של בקשת פטנט בתחום התוכנה
בקשה המבוססת על מנגנון סנכרון נתוני החיישנים יכולה להתחיל בתיאור הבעיה של איבוד רשומות וכפילויות בעת ניתוקי תקשורת. לאחר מכן היא תציג את מבנה יחידת הקצה והשרת, את הדרך שבה מוקצים מזהים ואת אופן שמירת הרשומות. בהמשך יוסבר כיצד נשלחים מקטעים, כיצד מאשר השרת את קבלתם וכיצד נבחרות הרשומות שטרם אושרו להעברה חוזרת.
אפשר להוסיף דוגמאות של רצפי הודעות במצב תקין ובמצב של ניתוק, להתייחס לפעולה לאחר אתחול המערכת ולתאר חלופות של שימוש בזיכרון שונה או בפרוטוקולי תקשורת שונים. לבסוף ייבחנו התביעות: איזו תביעה מתארת את המנגנון המרכזי, אילו תביעות תלויות מוסיפות מאפיינים מועילים ואילו קטגוריות תביעה מתאימות לדין במדינות היעד.
זו אינה תבנית שניתן להעתיק לכל בקשה. אם האמצאה היא שיטה חדשנית לניהול מטמון (Cache), דחיסת תמונה או בקרת מכונה באמצעות למידת מכונה, הפרטים והתרשימים הרלוונטיים יהיו שונים. המבחן הוא האם בעל מקצוע יוכל להבין מן הבקשה את הפתרון הטכנולוגי, והאם התביעות מגדירות אותו באופן ברור ומגובה בפירוט.
לפני ההגשה: התאמת התביעות לפירוט ולאסטרטגיית ההגנה
לפני שמגישים בקשת פטנט בתחום התוכנה כדאי להשוות את התביעות לפירוט ולשרטוטים. לכל מאפיין מהותי שבתביעות צריך להיות בסיס מתאים בתיאור. יש לבדוק אם מוצגות דרכי ביצוע חלופיות, אם המונחים עקביים, אם ניתן להבין את סדר הפעולות ואם החידוש הנטען נמצא באמת במנגנון הטכנולוגי ולא רק בתיאור של תוצאה.
נוסף על כך יש לבחון את הפרסומים הקודמים ואת ההשפעה האפשרית של שינויים עתידיים בפיתוח. תביעה רחבה שאינה נתמכת בפירוט, או תיאור שאינו מאפשר להבין כיצד לבצע את הפתרון, עלולים להקשות על המשך הבחינה ועל השגת היקף הגנה מתאים.
לשאלה העקרונית מתי אמצאה ממוחשבת כשירה לפטנט ראו פטנטים בתחום התוכנה – ישראל, אירופה וארה״ב.
להרחבה נוספת על ניסוח אמצאות ממוחשבות ראו בספרי: י' דרורי, ״דיני פטנטים״, הוצאת פרלשטיין־גינוסר, עמ' 266–296 (2023), הפרק העוסק בפטנטים בתוכנה. בפרקטיקה האירופית מומלץ לעיין גם בהנחיות EPO לגבי תביעות לאמצאות המיושמות במחשב.
