OOO L DD PP RR OOO CCC EEEE SSS SSS O O L D D P P R R O O C E S S O O L D D PP RR O O C EE SSS SSS O O L D D P R R O O C E S S OOO LLLL DD P R R OOO CCC EEEE SSS SSS ================================================================================================ ================================================================================================ Japan relies on Delphion to update its US Application data, which Sandy does weekly. There are two pieces of the US Application data to update, that unfortunately, are updated asynchronously. - The bibliographic data is updated weekly via data we ftp from the USPTO site every Thursday. - The images we get from DVD directly from the USPTO, but these tend to lag the bibliographic data by 3 weeks or so. On top of that, the USPTO oftentimes distributes occasional images in even later weeks. For example, 1,387 out of 2,728 images for the week of 1-3-2002, were not delivered until 3-xx-2002. Also, when bundling up the data to be shipped to Patolis, collect the data on a week boundary so that Patolis can (re)load and (re)index on those boundaries. Do not ship multiple weeks of data together. To update the US Application data manually, follow these nn steps. It should take about 10 minutes total. ----------------------------------------------------------------------------------------------- 1) Collect the newly-added information from a Southbury database (or replica). From jasper@jasper, ssh -l inst1 dephds059 set -o vi cd Japio.US.Apps.Update cat last_dates to see when things last ran successfully. This file contains one line, e.g. LAST_DATE='10/10/2002' These are Thursday dates and reflect the last ISD of when we extracted US Apps data. The script will extract the data for any weeks it finds after these dates. Run the script to extract the US Application data from the following 6 tables, abst, assg, clas_icl, clas_xcl, invt, main, and prir. The load files will be tar'd and compressed into weekly_update.YYMMDD.tar.Z. Apps_update.sh *************************************************************************************** * Typically, the image data is the last set of data to be loaded each week. * * I have this script set up such that if the image data has not been loaded yet, * * you would get an error message and this script will abort, not extracting the * * rest of the bibliographic data, which is likely there. * * * * The reason for this is if the imag data isn't there, I want you to be aware * * of it. I have two other scripts you run in this situation, * * - Apps_update.noimag.sh, which will extract everything EXCEPT the imag data, * * - and Apps_update.imag.sh, which wlll extract just the imag data. * * * * If the imag data isn't there yet, you can run Apps_update.noimag.sh and send * * that to the Japanese, of course informing them that the imag data is late and * * you'll provide that data when it's available. * * * * Later you'll run Apps_update.imag.sh and update their imag table yourself. * * For example, from inst1 on dephds059, * * Apps_update.imag.sh 08/15/2002 * * scp1 -p imag.020815.ld inst1@ips06i.ips4db2.com:/dfs/convdata/pa020815/imag.ld * * rm imag.020815.ld * * Then from inst1 on ips03i, * * db2 connect to patent * * cd /dfs/convdata/pa020815 * * db2 "import from imag.ld of del modified by coldel| chardel0x01 \ * * commitcount 1000 insert into inst1.imag (PATN, SRH, ABS, DESC, \ * * AMEND, DRAWING, CLAIM, BIBLIO, IMAGE_PAGES, BIB_STATUS, CDLABEL, XKIND)" * * * * * *************************************************************************************** If Apps_update.sh (or Apps_update.noimag.sh) runs successfully, the lines in last_dates will be updated for the next run. To verify ls -l *Z cat last_dates You should see a weekly_update...tar.Z file, e.g. weekly_update.020815.tar.Z and LAST_DATE updated, e.g. LAST_DATE='08/15/2002' ----------------------------------------------------------------------------------------------- 2) Now ship that(those) tar.Z file(s) over to Patolis. As jasper on ips06i, YYMMDD=021031 mkdir /dfs/convdata/pa$YYMMDD where YYMMDD is the Thursday day, e.g. pa020228. If you're still on dephds059, you can YYMMDD=021031 scp1 -p weekly_update.$YYMMDD.tar.Z inst1@ips06i.ips4db2.com:/dfs/convdata/pa$YYMMDD Then back as jasper on ips06i, YYMMDD=021031 cd /dfs/convdata/pa$YYMMDD zcat weekly_update.*.tar.Z | tar -xvf - rm -f weekly_update.*.tar.Z ----------------------------------------------------------------------------------------------- 3) Send a note to the following people, telling him that the weekly US Apps data has been sent and resides in /ips/convdata/paYYMMDD. "Shizuo Shibata" "Takayuki Nakada" "Takashi Ogawa" "Yuji Takashima" The easiest way is to use the usapps nickname from Lotus Notes. One of them will load the files into DB/2 using their normal importpat procedure, then index the data, again with their normal bibupdidx procedure. OOO RRR O O R R O O RRR O O R R OOO R R if you want to load and index the stuff yourself, login as ipsadmin on ips03i, week=021031 cd /dfs/convdata/pa$week /ips/bin/importpat pa$week > importpat.log Then as ipsadmin on ips05i, week=021031 cd /dfs/convdata/pa$week /ips/bin/bibupdidx pa$week > bibupdidx.log If you're going to do the loading and indexing for them, it's worthwhile to check your work AND the status of their US Apps Verity index. rcvdk /ips/coll/coll_usapps | grep finished s banana quit You want to insure that the last number in this line, Search update: finished (100%). Retrieved: 6(6)/102758. 102,758 in this example on 4-24-2002, matches the number of US Applications in the database. db2 connect to patent user ipsrun using inst1_password db2 "select count(*) as count from inst1.main where patn like 'US2%'" which also matches the count in Southbury db2 "select count(*) as count from inst1.main where patn like 'US2%' and datasrc='UPA'"