言語による制約記述のチュートリアル

をここに書いています。

数独を題材にして、制約プログラミングの仕方について述べています。途中なので、ソフトは未だリリースできませんが、来年早々にソフトはリリースします。

制約プログラムというのは、答えを求めるアルゴリズムを記述することではありません。制約を課すことで、答えは自動的に求まります。ですから、その記述は、一通りではありません。が、出来れば、直感的に分かりやすく、なおかつ短い記述が求められます。

今回、そのための言語を設計したのですが、なるべく短い行数で、狙った仕様が記述できるように心がけました。　その結果ですが、かなり短く書けているのではないかと思います。数独のプログラミングは、他のサイトで散見されますが、その中でもかなり短い方ではないかと思います。

以下は、数独の全記述(34行）です。

//数独列制約
for (day in 全日){
 for (シフト in 全シフト){
  vector V;
  for (人 in 全スタッフ){
   V.push_back(X[人][day][シフト]);
  }
  $Onlyone(V);
 }
}
//数独行制約
for (人 in 全スタッフ){
 for (シフト in 全シフト){
  vector V;
  for (day in 全日){
   V.push_back(X[人][day][シフト]);
  }
  $Onlyone(V);
 }
}
//ブロック制約
for (人 in スタッフブロックトップ){
 for (シフト in 全シフト){
  for (day in ブロックトップ日集合){
   vector V;
   for (i=0 to 2){
    for (j=0 to 2){
     V.push_back(X[人+i][day+j][シフト]);
    }
   }
   $Onlyone(V);
  }
 }
}
dayは、本当は”日”にしたかったのですが、そうすると　日曜が、日として使われていたのでエラーとなってしまいます。

なお、ＷＥＢ版でも制約言語は動作しますが、Ｊａｖａｓｃｒｉｐｔのセキュリティ上、テキストファイルを呼び出すという風にはできないので、ＴＥＸＴＢＯＸに貼り付けになってしまいます。（デバッグについては、ＰＣ版の方が便利そうです。）

スタッフプロパティでフレキシブルな勤務表にする

下は、ある看護師長（ICU)のスタッフプロパティテーブルです。

各スタッフには、12個も属性があり、その属性を変更するだけで月々の些細な変更を吸収できるようにしています。このテーブルは、未だ作りがけであり、これから数ヶ月をかけて、看護師長共々、ブラッシュアップしていく予定です。（永久ライセンスをご購入頂きました。）

スタッフプロパティは、その病棟に固有な属性だと思います。同じスタッフプロパティは、この世に二つとないでしょう。それ故、自身の職場については、自身の言葉で制約を語れることが必要条件になります。それをお伺いして、私が制約化した結果が下のテーブルです。数ヶ月の後、安定してきたときには、中身は殆どいじくることなく、大体このテーブルだけでできるようになります。（経験則）

注目していただきたいのは、単に各スタッフの個人の要望を聞くだけではなくて、中々夜勤ができないスタッフも、可能な条件を聞いて、その中でも最大限、夜勤をしてもらっている事です。また、SS（深夜深夜）　JJ（準夜準夜）等、スタッフの好みや可否を入れて配置をしていることです。

個人の要望を受けつつも、なおかつ組織全体のバランスやQOLを考えていることが伺える内容になっていると思います。素晴らしい看護師長さんですね。
　
　

特許証が届きました。

どちらもスケジューリングに関する特許です。

早期審査制度を使っても、特許出願から特許査定が届くまでには、1年と6ヶ月かかりました。
図面作成、出願、審査請求、補正書、意見書、審判まで長い道のりでした。

 

経緯は　以下の通りです。


震災の日から3年目に出願しました。

出願　　　　　　　　　　　平成２６年３月１１日

審査請求　　　　　　　　平成２６年５月１１日

拒絶理由の通知（発送日）　平成２６年８月１９日
意見書（提出日）　　　　　平成２６年１０月８日
手続補正書（提出日）　　　平成２６年１０月８日
拒絶査定（起案日）　　　　平成２７年１月８日
同謄本到達（送達日）　　　　平成２７年２月３日
手続補正書（提出日）　　　平成２７年４月２７日
前置移管通知　　　　平成27年6月3日
特許査定受領　　　平成27年　8月26日
減免申請書提出　平成27年8月27日
特許証受領　　平成27年10月7日

教訓として、

1. 特許提出の前に特許性を押さえておくこと。
2. 特許提出の前に信頼できる専門の弁理士さんに見てもらうこと。

が挙げられます。

特許図面や、特許調査は、全て自分で行ない、それなりの特許性を持っているという
自信はあったのですが、審査官に理解してもらわなくてはいけないというハードルが結構高かった、という印象です。拒絶査定通知のとの対話　という本に、大事なポイントが書かれているので出される前に、一読されることをお勧めします。

2番めの点は、弁理士さんです。拒絶査定通知を受けてから、慌てて弁理士さんを探したのですが、ソフトウェアに関する高度な専門性な為、中々受けて頂ける弁理士さんが見つかりませんでした。幸いにも仙台市内で専門の弁理士さんおられたので、指導を頂くことができました。数々のご指摘を受けたので、特許を出す前から見てもらったほうがよかった、と思いした。早期審査制度を使っても、拒絶査定不服審判は、普通に費用がかかります。最初から弁理士さんに相談していたら審判までは行く必要はなかったかどうかは分かりませんが、折角、膨大な時間と費用を使って特許が落ちなかった（弁理士さん用語？）では、泣くになけません。勿論、弁理士さんに見てもらえば、必ず落ちるという保証はありませんが、確度が上がることは間違いないでしょう。

今回の一連の経験を通じて、特許成立の可否は、補正書や意見書を通じて、1人の審査官との対話にある、と感じました。拒否の理由を色々言ってくるのですが、その真意や理解度を推し量りながら書いていく必要があります。特許特有の言い回しもあり、その点でもやはり弁理士さんに見てもらうことをお勧めします。


最後に、特許庁とのやりとりは、通知を除いて書留めで送られてくるのですが、最後の特許証だけは普通郵便です。特許証の性格を考えるとそれも納得です。（ただ、法律上は、1ヶ月以内に特許料を納めることになっています。減免申請が通れば、問題ないのですが、減免申請後一ヶ月経っても音沙汰がないのであせりましたが、無事到着しました。）

仙台のソフトウェア関係の特許に強い弁理士さんでしたら紹介できます。メールでお問い合わせください。

要求の多いスタッフにどう対処する？

我侭とは言いません。色々家庭の事情で夜勤の出来ないあるいは、殆どできないスタッフはいるものです。しかし、そうすると周りのスタッフとのインバランスが目立ち、どうしても不公平感を持たれてしまいます。実際の職場でスケジュールナースを御使用の看護師長の設定をお借りして紹介します。

サーバ契約

サーバを契約しました。ここは、将来アクセスが増えても、簡単に対応可能なことが決め手になりました。パフォーマンスの雰囲気としては、悪くない感じです。

別途、CPU負荷をかけたときのパフォーマンスをCPUコア数をパラメータとして評価予定です。

CentOS インストール

VPS練習用

1. CentOS x86_64_LiveDVCD.iso をダウンロード
2．Windows７でDVD　Rを作成
3．ifconfig //で自身のIP　ADDRESSを得る
4. service sshd start //ssh
5. teraterm をWindos7にインストール
6. SSH接続by teraterm using the ip address
su

7. yum install gcc //gcc install
8. sudo yum -y install gcc-c++　//c++　install
10．Winscpを　Windows7にインストール　rootでログイン　フォルダ毎転送
9. make :gcc　は、4.7　-Ofastは、効かないので-O3に変更
10．vi /etc/sysconfig/iptables //firewall port 追加
11.　vi /etc/rc.local　// server をブート時にデーモン起動
12. reboot //

特許査定の通知

予定通り、特許庁から特許査定の通知を2件、頂きました。内容は、

前置審査　
 原査定を取り消す。　　この出願については、拒絶の理由を発見しないから、特許査定をします。

となっています。

なんだか、あっけないですね。

ただ、特許査定だけでは、特許にならず、3年分の特許料を納めて初めて登録になります。
また、特許を維持するには、毎年、前年度までに特許料を納めなければなりません。これが、結構
かかります。

　登録時

　（２，３００円＋請求項数×２００円）×３　←３年分の特許料

※平成１６年３月３１日以前に審査請求をした出願については、
　　　　　　　　　（１３，０００円＋請求項数×１，１００円）×３

登録後３年以降

　４年～６年 毎年7,100円＋500円×請求項数

　７年～９年 毎年21,400円＋1,700円×請求項数

　10年～25年^※ 毎年61,600円＋4,800円×請求項数

10年目以降は、結構かかりますね。
 
とりあえず、1-3年分の減免申請書を提出しました。
これで、特許証書が来るのを待つだけとなりました。早期審査を使っても、特許取得までは、1年半以上かかります。特許証書が着いたら、これまでの経過をまとめたいと思います。

職権訂正

審判中の特許ですが、ご丁寧に職権訂正の連絡を頂きました。

明らかに、軽微の場合に適用されるようですが、一々補正書を出す必要がないので大助かりです。　実は、職権訂正は2回目なのですが、連絡を頂けれるのは初めてです。

特許出願から、特許査定まで、長い道のりなのですが、ようやく先が見えてきました。個人で特許を出願するというのは、費用の問題が一番大きいのですが、図面や、出願書類は自分で作成するにしても、信頼できるその道のプロ、弁理士さんに、出願時から、相談するのが一番近道だと思います。　このことについては、機会を見て詳しく綴りたいと思います。　

多様な勤務形態の実現のために

日本看護協会の資料です。

この中でも、勤務ソフトの利用が挙げられていますが、多様な勤務形態実現のためには、欠かせません。

具体的例で見ていきましょう。
下記は、ある病棟の例です。

各個人ごとに設定する箇所がありますが、夜勤のある看護師について8項目もの設定項目があります。グループやスキルの設定は勿論ですが、シフトパターンについてもかなりスタッフ個々人の要望を聞いています。運用の最初は、こんなに設定が多くなかったのですが、個々のスタッフの要望を訊いていくうちに、段々多くなってきてしまいました。

たとえば、大抵は、深夜深夜パターンを嫌うのですが、むしろその方がよい方がいたり、水木曜日しか夜勤は入れられなかったり、とかなり特殊なことまで入れ込んでいます。準夜準夜の連続、深夜深夜の連続の可否、日勤深夜/公休深夜の選択等は、運用最初の段階から入っていましたが、特殊事情を抱えるスタッフもいて中々大変です。

一律に深夜深夜を全部禁止するよりも、もしも深夜深夜をいとわないスタッフがいるのでしたらその方を活用したほうが全体としてのシフト表作成の質は高くなります。　（勤務表の質というのは、実は、ソフト開発者にとっても重いテーマでして、このことについては、別な機会にお話ししたいと思います。）

最初に制約として入れ込むところは、少し大変ですが、（といっても1-2行の追加なのですが）　そのスタッフがいる限りは後は、変える必要がないのでそのほうが楽なのです。このプロパティ（スタッフの緒元）設定は、スタッフの移動、出産、病気等で、ほぼ毎月、更新していると思います。つまり自動シフト勤務表というのは、一回設定したらそれでおしまい、というものではありません。更新がつきものなのです。それは、人間が頭にあるやりたいことを、コンピュータに指示する作業です。ですから、是非自分で出来るようになっていただきたいのです。

この方のように、スケジュールナースを使いこなせるようになると、スタッフ希望が出揃ったその日のうちにシフト表を完成させることが出来ます。



少しの手間で、スタッフの希望を適えることができるのなら、出来る限り聞いてあげたいですね。

前置審査移管の葉書が届いた

この拒絶査定不服審事件は、審判請求と同時に明細書、特許請求の範囲又は図面について補正がありましたので、特許法代162条の規定により審査官に審査（前置審査）をさせることになりましたのでお知らせします。

という葉書が2通届きました。”事件”になるので、少し驚きました。前に出していた特許申請について、審査官のご理解が得られなかったので、クレームの補正をして不服審判申し立てをしていたのですが、その場合、合議体（審査官の上司達のイメージ）に行くまえに、前に見て頂いた審査官にもう一度目を通してもらうという内容です。弁理士さんによると、内容を周知しているので、その方が早いということだそうです。そこでも拒絶査定になると、合議体に行って審判になる訳ですが、その場合も通知が来るはずです。ただし、そうなると相当の時間がかかってしまうので、できるならば前置審査で通ることが期待されます。

もし同時に、特許請求の範囲を補正を行っていないならば、合議体に直接に行くことになります。どちらにしても、いきなり拒絶査定がくることはありません。
弁理士さんによれば、補正を行って前置審査してもらうケースが多いようです。

病院向けプレゼンテーション作成

フルカスタマイズのおまかせ設定で、看護師勤務表作成
http://www.nurse-scheduling-software.com/tutorial/presentation_for_hospitals.pdf

ある病院でこれをベースにプレゼンしました。