Hmm. Well, there's also 7844610 which was filed in 2004 and does seem pretty similar. In fact their abstracts are identical. That's a little deflating.

The patent whose application was filed in April 2002 is this related one, 7502770, which isn't very similar. I think that's the one you meant.

I think I may want to contest this patent.

The patent cites Slashdot comment moderation as an example of how not to assign importance to user actions. Its authors were apparently unaware that the algorithm they described in November 2010 is virtually identical to the way Slashdot has actually assigned importance to user voting on Firehose stories since May 2008 (give or take). I know because I wrote it.

What this patent calls "authority," we call user "clout."

Multiple clouts, actually. Each Slashdot user has a number that describes how valuable the system believes their up/down votes in the firehose are, and it's separate from how valuable their descriptive tags applied to stories are. (Up/down votes are simply tags with special names, making vote-scoring and description-determination very similar under the hood.)

It's been a while since I looked at this code -- I work for sister company ThinkGeek now -- but scanning over our public repository here are some of the interesting parts:

plugs/Tags/tags_updateclouts.pl - the tags_peerclout table is the way that each type of clout is built. It has fixed entries at gen=0, the zeroth generation, which would typically be the Slashdot editors or other users considered reliable and definitive. To build gen=1, the code looks at how many users tagged or voted on the same objects as the gen=0 users did, and assigns the gen=1 users scores based on similarity (or difference). Then from the gen=1 users, gen=2 users are assigned scores similarly, and so on.

The gen=0 entries in that table "designate one or more contributing authorities by delegating to each a specific quantity of authority." I don't think I could describe that better myself.

plugins/Tags/Clout/Vote.pm process_nextgen() - here's where each new generation of user clout is successively determined, for firehose votes in particular. Line 194 invokes the algorithm and line 203 assigns that user their new voting clout. This iterative process is the automated method through which "each contributing authority may in turn designate and delegate authority to one or more additional contributing authorities."

plugins/Tags/Clout/Vote.pm init() - sum_weight_vectors totals the change in clout for each generation, and possible weight decreases exponentially. If you're in gen=1 the maximum weight you can have is only 60% of the maximum from gen=0, etc. The fraction is smaller than 100%, which helps ensure "that the total quantity of authority delegated does not exceed the quantity of authority the contributing authority was itself delegated." When the clouts are used to determine firehose item ratings, "the ratings are combined in a manner that affords a higher priority to the ratings provided by contributing authorities to which a greater quantity of authority was delegated."

All this may have changed since it was written. I don't actually know what's running on Slashdot at this moment. I'm just going by the public repository that I knew was on sf.net, and I don't even know if there's a later version of the code available anywhere.

But I suspect that this system would constitute prior art.

Also, looking over my code from 2008, boy, I really wish I'd put in more comments.