Re: database integrity

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:q1cem2-am2.ln1_at_pluto.downsfam.net...
> mountain man wrote:
>
>>>> Additionally, in more complex change, the retrospectively entered
>>>> data may need to be addressed and essentially "converted" to conform
>>>> to the implementation of new rules. This conversion will be a once
>>>> off update of the data, to get it to conform to new rules.
>>>>
>>>
>>> Can we tie this to some examples?
>>
>> A more complex example might be furnished from the column
>> "NEXT_RENEWAL_DATE" (often called ANNUITY_DATE)
>> for a patent application or registration in any given country,
>> held in an IP management database for patent attorneys.
>>
>> In some schemas there is provision (as separate dates) for
>> the first, second, third, etc annuity, because - dependent upon
>> the country - there may many renewals due.
>>
>> Intellectual property legislation is country specific, every country
>> essentially having its own patent "Act" or "Laws" etc. This
>> legislation changes from time to time. IOW the rules governing
>> the calculation of this date (NRD) may need to be altered from
>> time to time (for future annuities).
>>
>> So therefore, if you were to be running such a system which
>> has already pre-calculated the series of next renewal dates
>> in respect of a particular patent, and the legislation changes,
>> it is quite possible that some of the future dates would require
>> change, to reflect the changed legislation.
>>
>> Sample example: a country pays patent annuities at years
>> 3,4,5,6,7,8 through 17 on the anniversary of lodgement date.
>> Thus a case lodged 1/1/2005 will require a renewal action on
>> 1/2008, 1/1/2009, through 1/1/2022.
>>
>> However today (25/5/2005) a new patent law decrees that
>> annuities will be due 5 years after lodgement and then every
>> two and half years thereafter. It will probably have a savings
>> provision such that existing renewals will be in force, but
>> once renewed, the following renewal will THEN be for 2 years.
>>
>> In such examples, where the schema uses a fixed series of
>> dates for the future range of NRD's of a patent, the data
>> existent in that series may be made INVALID as a result
>> of new rules. Yes, it was valid, but with effect from the
>> new patent law, today, it is invalid, and a conversion of
>> that data will be required.
>>
>>
>>
>> In summary, some data entered as valid today in projection
>> of todays business rules, may not be valid tomorrow due to
>> changes in the business rules, and will need to be converted.
>>
>> Especially data relating to future workflow.
>
> I would say at first glance that data should not be generated that far in
> the future. Consider this. You know that the law can change, and
> therefore the data _cannot_ _be_ _considered_ _valid_ _when_ _saved_,
> therefore it should not be saved. It is not that the data was valid and
> then became invalid, it is that it was never valid in the first place.

Well, in one sense it is valid in the first place, and if the client asks for an estimate of future expenses then this is provided on the basis that the current legislation remains in force. While the law does not impact upon (for example) any of the future next_renewal_dates then the data remains valid.

You might like to call these future scheduled dates estimated dates, the estimate being arrived at by rules encoding the current legislation. Would you store such data as estimates?

Alternatively, if your argument remains that some data is best considered invalid if it is so futuristic, and thus amenable to being changed (even if it is not in fact changed), then exactly at what future point is this threashold between validity and invalidity?

> Better to design tables that hold these schedules of annuities, and work
> out
> which scheme applies to each patent. Then you run your annuity scheduler
> once/month, once/week, or whatever seems appropriate.
>
> Am I in the right ball park?

A number of solutions similar to this are to be found in some of the IP management software available today. As you know, many solutions to one problem are able to be found (in time).

Another complication to be considered here is this: a patent may not arrive for data entry that is new, it may be in fact an old patent transferred from another attorney (system). Thus, a history of the rules applicable needs to be used in order to calculate the NEXT_RENEWAL_DATE, commencing with the rules reflecting the legislation when the patent was first lodged, through the period of time the patent has remained in force.

-- 
Pete Brown
Falls Creek
Australia
www.mountainman.com.au