The voting booth curtain and the paper-record are the most advanced and reliable voting technology that we are likely to see in our lifetimes and long after. Personally, I wouldn't be surprised if hundreds of years from now, responsible computer scientists are arguing that we need to preserve the curtain and paper industries if only so that we can use their products for elections.
No matter how far computer technology advances, we won't be able to prove to voters that electronic voting is secure. Yet, voter confidence in the integrity of the vote is the essential element of our society's ability to maintain a democratic form or government. If we use voting technologies that can only be trusted on the basis of arguments from authorities (i.e. some "experts" who say the system is secure...) then the voting system itself speaks against democracy. With curtains and paper ballots, the people are presented with a system whose security and weaknesses they can understand intuitively. The same will never be true of computer-based voting systems.
The smallest unit of data indexed by most search engines is the "word" not the "character." Thus, it isn't possible to create regular expressions that work at the character level, although something approximating "regex" on strings of words has often been implemented and there is no reason why full regex couldn't be supported fairly easily -- as long as you accept that "words" are the base symbols in the regex, not characters. For instance, "phrase search" and proximity search operators like "near," "within," "before," "after," "same sentence," have been implemented in many search engines and provide some of the capabilities of regex -- with words as the base symbol.
Many search engines implement "stemming" as a means of covering the most common requirement for sub-word query predicates. Stemming allows both "cat" and "cats" to be treated as the same word. A system that provides stemming will often use "stems" as the smallest unit of data indexed rather than words. Thus, in the index, there would only be one entry for "cat" which represents both the words "cat" and "cats."
Of course, character-based search exists today for small corpora -- grep is the most well know system, I think. But character-based search on a large corpus is a very difficult problem that, using today's algorithms, would require massive computing capacity to provide to even a small number of users. However, in some specialized applications, this can be justified. One technique for reducing the resource cost of character-based regex on large collections is to index bigrams, trigrams, quads, etc. (i.e. use multi-character sequences as the base "symbol" or smallest unit indexed. ) However, such ngram based systems still don't deliver the serving capacity that one would expect from something like a Google or Yahoo!.
One "mixed" strategy that has sometimes been employed is to support a more complex query that has a "first part" which is word-based (as in traditional search engines). This first-part is used to select a subset of all the documents in a collection. Once the candidate-result-set is produced, one would run a character-based regex (similar to grep) over the results. Of course, you can probably see that you can easily hack up such a two-phase search yourself by sending a word-based query to a search engine and then doing the character-based regex on the result pages.
I fear we are stuck with word-based search for the foreseeable future. While folk often ask for character based regex, the reality is that it is simply too hard to implement today. Also, the size of the market that has a real need, as opposed to a desire, for this capability is much smaller than one might think....
Doyle claims that the big difference between OLE (Object Linking and Embedding) and what he claims to have invented is that his system allowed one to pull the active objects over the Internet rather than just local machines and/or Local area networks. However, OLE was not, in fact, limited to local machines and LANs. There were a variety of tools that allowed the Microsoft file system (NETBIOS, etc.) to be extended over the Internet and other WANs. Thus, his claimed distinction is false.
In any case, the argument that accessing data over the Internet is somehow different from any other kind of data access is simply silly. This is a false distinction that could only convince a lawyer who is not familiar with the field.
Base_chakra: Before you get too righteous, you should understand that claiming that someone "double counts" or otherwise falsifies numbers can never be considered a joke. Your suggestion that our numbers are not honest is the sort of thing that builds myths that we will probably be responding to months if not years from now. At PubSub, we do our best to provide the best statistics we can. We publish more data than any other service and we are vastly more open about our numbers than anyone else. It isn't in any way "funny" or "joke-like" to suggest that our numbers are in any way tainted.
PubSub have not been "double-counting" and have "admitted" no such thing. Your post is a complete lie. I can only wonder whose interests are served by spreading such lies about the service we provide...
Baricom: What you're looking for is the "cloud" interface defined at: http://blogs.law.harvard.edu/tech/soapMeetsRss The documentation there is, I think, about as good as you'll find. While it says that it can be implemented in either XML-RPC or SOAP, I am aware only of XML-RPC implementations.
The cloud provides a means for blogs to notify subscribers of updates and should eliminate the need for polling -- except that the subscriptions must be renewed at least every 25 hours. Of course, this cloud stuff isn't terribly useful in most cases since it relies on the blog server being able to send an HTTP message to a remote client (subscriber). In most cases, those messages would be blocked by firewalls. This is, of course, why the "Atom over XMPP" stuff makes sense. It relies on a connection established from the client to the server -- in the same manner as is done with instant messaging clients. Thus, there are many fewer issues with firewalls.
Of course, having lots of session open between a client program and all of the various blogs it reads probably doesn't make much sense. Neither does it make sense for every blog to maintain a list of all of its "cloud" readers and go to the work of sending them all messages whenever the blog is updated. Thus, the most sensible way to do this push business is to have the individual blogs publish to a common network of aggregating servers and then have clients establish connections to the common service. Overall bandwidth consumption is thus reduced to the absolute minimum. That's what we're building at PubSub.com.
While there are some great ideas in RSS, one of the worst is polling. As discussed in Burton's post, polling results in a ridiculous waste of bandwidth. A Push approach, like the one defined in "Atom over XMPP" would result in a massively more efficient distribution system like the one that we implement in the PubSub Sidebars. But, if you insist on polling, then the best efficiency can be had by combining Gzip with the A-IM or RFC3229+feed as described on my blog. Using RFC3229+feed, your server would only serve up "unread" entries not everything in your feed. Please read and implement: http://bobwyman.pubsub.com/main/2004/09/implementa tions.html
Technorati only claims to process 900,000 new entries per day - not 9 million. Burton has the number correct in his posting. The/. article quotes him incorrectly. On the other hand, the numbers cited for PubSub are correct. We have processed an average of 1,796,574 (1.8 million) new entries per day over the last 30 days. Many of our statistics are available on our site and updated daily. The "new entries per day" data can be found graphed at: http://www.pubsub.com/linkcounts_graphs.php?type=n ewentries for more graphs and tables, see: http://pubsub.com/linkcounts.php
Your suggestion is precisely what is defined by RFC3229+feed (i.e. an RSS-specific extension to RFC3229 " delta encoding for HTTP). I maintain a list of implementation of RFC3229+feed on my blog. You can also find some empirical evidence showing massive bandwidth savings as a result of RFC3229+feed use.
Google recently bought Hello.com and has been supporting its instant messaging protocol, clients, etc. ever since the purchase. Hello's focus today is on Instant Messaging between people who share pictures, but they could open it up to a wider audience any time they wanted to. Thus, GOOGLE already has an IM client and protocol. As far as I know, the protocol is closed.
To see an example of Google/Hello IM Chatting, see: Google Chat
The question isn't whether or not Google should "adopt" XMPP, rather, the question is whether they should "change to it." My hope is that they will dump their proprietary system and switch to the XMPP IETF open standard as soon as possible.
How many people remember ALL-IN-1 which was the leading minicomputer based office automation system back in the 80's? ALL-IN-1 was a "form-driven" system that had many similarities to what you see on the Web today and made extensive use of plug-ins and "embedded" programs to allow people to construct arbitrarily complex office systems. If you imagine ALL-IN-1 to be like a Web Browser, what it did was create windows in which you could embed, in frames, just about any application that could run on VMS. You could have a window that was just text, or you could have a window that included a frame with a text editor or a database program or whatever... We even defined a "common calling convention" that allowed developers of applications on VMS to make their programs "callable" so that we could invoke them directly and consistently. (VMS coders will remember seeing a lot of programs that offered callable interfaces that looked like edt$edt, dtr$dtr, etc. That was done for ALL-IN-1...) Embedding was good enough in the 80's to make ALL-IN-1 a multi-billion dollar business. What Eolas claims was done long before they filed their claims and was implemented in many other programs.
You can find similar examples of embedding in Digital's TPU editor (especially the DECWindows version that I used to build a network based hypertext system in the late 80's), the VTX videotext product and VaxNotes (both VTX and VaxNotes helped inspire Tim Berners-Lee while he was at CERN... My TPU based "Memex" hypertext system also ran at CERN in the 80's...)
The problem, of course, is that most people have forgotten that there were computers before PC's and before 1990...
To authenticate, you must connect to your home server first. Often, the "traveling mailman" can't do that due to network partitions, slow links, etc. I've often found it difficult to connect to my home server while traveling in India, Europe, etc.
It is often possible to guess an author's age by the proposals generated. My guess is that the author of this proposal is under 35 or at least got into the business sometime after 1993... People who have never known anything other than the amazing connectivity and bandwidth that we've had in the last decade in the US tend to forget some of the more basic realities of working with networks...
mpthompson wrote: > I'm fairly certain OLE and the enabling COM > technology predates 1993 I was Senior Product Manager for Applications Programmabilty at Microsoft from 1991 to 1993 and I can assure you that not only OLE but OLE Automation (the real predecessor of ActiveX) were well understood and underdevelopment prior to 1993. In fact, when I came to Microsoft in 1991 to work on this stuff with them, the program was already underway and I considered it to be merely the Microsoft version of work that we had done at Digital (where I had been product manager for ALL-IN-1). As early as 1982 at Digital, we had demonstrations of wordprocessors that took spreadsheets and other active elements as plug-in extensions. Also, the wide-area-network Hypertext browser ("Memex Prototype 1") that I built at Digital in the mid/late 80's had plug-in extensions that used the TPU plug-in model.
21 of the 26 patents that Intertrust provides links to on their site refer to one or more of four patents on which I am the sole inventor. My four "license management" and/or DRM patents were all assigned to Digital Equipment Corporation (now HP) and are some of the earlier patents in this space.
I've watched Intertust collect their patents over the years and have been regularly struck by the realization that these folk have been successfully patenting ideas that I considered obvious and unpatentable in the 80's or already covered by my patents. Also, quite a number of the things that they have patented are things that I clearly recall having been discussed with Microsoft while I was at Digital or at Microsoft once I joined them (for a brief stay) back in the early 90's.
As many will realize, Microsoft has been long interested in and involved in the process of building DRM software. Many people will, for instance, remember Gates' letter to the industry back in the 70's in which he complained that people weren't paying for software. I personally became aware of Microsoft's interests in licensing back in the late 80's when Digital and Microsoft cooperated in submitting my "Digital Distributed Software Licensing Architecture" to the OSF in response to one of their solicitations. Having spent a great deal of time speaking with Microsoft folk back then, as well as dealing with many of the licensing issues as "Senior Product Manager for Applications Programmability" once I joined Microsoft, I can assure you that folk in Microsoft were aware of and anticipated many of the methods that InterTrust has managed to patent.
The problem, of course, is that simply knowing the methods isn't good enough. You've got to get them patented... But, back then, there wasn't much of a culture of getting software patents. People simply didn't do it. Even at Digital, I remember being regularly told by the patent attorneys that they were very happy to have found a software guy willing to work on patents and how they hoped that they'd be able to use my patents as an example for others.
While there may be "some" meat in the InterTrust case, my personal feeling is that this case is yet another example of the problems we have with software patents. The system was supposed to reward and encourage innovation yet the people who seem to be getting rewarded are not the innovators -- rather, it those who file patents who are getting rewarded. Perhaps, today, we've established that the only rational thing to do is to file for patents on anything you are doing -- no matter how obvious it may seem -- and then hope that the patent office will screw up and grant you something. But that was not always that case. It used to be that if people filed patent applications at all for software it was only for the really "special" ideas. The result is that alot of little stuff or obvious stuff went unpatented until companies like InterTrust, who live on patents -- not innovation -- came along to sweep things up. This isn't the way the system was supposed to work.
bob wyman
A good example of a bad patent.
on
Steal This Idea
·
· Score: 1
For a good example of a bad patent, try US Patent 6,314,574 which claims the method of storing HTML on CDROMs or other read-only media.
Andrew Russell's paper on the W3C PPWG seems to have been last revised on 18-Mar-2003, yet the most recent version of the W3C Patent Policy was released the next day, on 19-Mar-2003. The difference is significant since Russell's paper talks much about how the W3C had accepted a royalty-free policy, yet the policy that was released provides explicit exceptions that will allow encumbered royalty-based methods to be included in W3C recommendations in some circumstances. While Russell's paper is very interesting as a snapshot in time, it will need to be rewritten in light of the current policy in order to be truly useful.
Medio Magazine, published on CDROM from 1993 to 1995 by Medio Multimedia, and many other CDROM based titles had a "frames-based" interface which pre-dated the earliest possible date of conception for the SBC patents.
WetCat wrote: >Assume we found some "Smoldering guns". To whom shall we show the evidence?
You show it to the USPTO by doing a "Third Party Submission of Prior Art" using USPTO procedures prior to 60 days after the application was published (i.e. 60 days after 6-Feb-2003). After that time, you have to serve papers on the inventor, lawyers, assignees, etc. to inform them of the prior art and thus force them to perform their "Duty of Candor" and submit the prior art for you to the USPTO.
The application being discussed here is a "stealth application" in that it does not indicate Microsoft as the assignee although Microsoft is, unquestionably, the assignee. In this case, the failure of Microsoft to be identified as an assignee may be considered a failure to meet their duty as a monopolist to give competitors "access to their facilities." For more info, see comment #7 in the discussion of "stealth patents" at PubSub.org.
It should also be noted that analytically, the combination of an existing monopoly with the monopoly granted by a patent raises the same questions as the merger of two companies. In a case where the monopoly granted by the patent is for something not fundamental to a market, then one can permit the "merger." However, when the monopoly granted by the patent is fundamental and blocks an entire realm of competitive activity, the "merger" should not be permitted. In this case, Microsoft is clear in its intent to ensure that architectures of the.NET style afford the only reasonable mechanisms for working with their products. Thus, any patent that blocks others from developing similar, but different and competitive architectures, effectively blocks competitors from being able to build systems that work with Windows and thus blocks them from working with most computers. The result will be a loss of competition in an already monopolized market. In this case, what might otherwise be a "non-fundamental" patent becomes fundamental.
Even though a patent which issues from this application would appear on its face to only grant the right to exclude from some limited technical domain, when combined with the effects of Microsoft's existing market power, the effect of such a patent would go beyond the limited technical scope and extend so that it is coextensive with the entire economic product market.
>FSF or EFF [should]Provide a database of 'prior art
There is already a tool for collecting prior art! This is one purpose for the pubsub.org site. The idea is that if you find a patent or patent application for which you have or seek prior art, you can get it listed on the site and record your prior art. This makes a permanent record that others will be able to use as a source when filing "third party" prior art with the PTO as well as when defending against infringement cases in the future.
Today, there are many discussions of specific patents or applications scattered all over the web. This makes it difficult for those with a real interest in defending against some patent or application to find the prior art they need. However, on PubSub.org, you can write a comment directly linked to a specific patent or application and identify the prior art or other argument you might have for why the patent should not be (or have been) granted. Try it. If you don't find a patent or application that you're interested in, just use the "request new thread" option to get the patent listed.
The system on pubsub.org is different from what you'll find on other sites like BountyQuest where they are only collect prior art on "major" patents. At PubSub.org, you can provide prior art on *any* patent or application and what you provide will be publicly available and reviewable.
If there is demand to do so, I'll expand the scope of what we do at PubSub.org to include providing a place to record "defensive" or "Open Prior Art." This would allow anyone who has a method that they consider patentable to "block" anyone else from getting a patent on the same method. The PTO considers "internet publications" to be valid prior art as long as they are accessible. Should I do this?
Slashdot Mirror
The voting booth curtain and the paper-record are the most advanced and reliable voting technology that we are likely to see in our lifetimes and long after. Personally, I wouldn't be surprised if hundreds of years from now, responsible computer scientists are arguing that we need to preserve the curtain and paper industries if only so that we can use their products for elections.
No matter how far computer technology advances, we won't be able to prove to voters that electronic voting is secure. Yet, voter confidence in the integrity of the vote is the essential element of our society's ability to maintain a democratic form or government. If we use voting technologies that can only be trusted on the basis of arguments from authorities (i.e. some "experts" who say the system is secure...) then the voting system itself speaks against democracy.
With curtains and paper ballots, the people are presented with a system whose security and weaknesses they can understand intuitively. The same will never be true of computer-based voting systems.
bob wyman
The smallest unit of data indexed by most search engines is the "word" not the "character." Thus, it isn't possible to create regular expressions that work at the character level, although something approximating "regex" on strings of words has often been implemented and there is no reason why full regex couldn't be supported fairly easily -- as long as you accept that "words" are the base symbols in the regex, not characters. For instance, "phrase search" and proximity search operators like "near," "within," "before," "after," "same sentence," have been implemented in many search engines and provide some of the capabilities of regex -- with words as the base symbol.
Many search engines implement "stemming" as a means of covering the most common requirement for sub-word query predicates. Stemming allows both "cat" and "cats" to be treated as the same word. A system that provides stemming will often use "stems" as the smallest unit of data indexed rather than words. Thus, in the index, there would only be one entry for "cat" which represents both the words "cat" and "cats."
Of course, character-based search exists today for small corpora -- grep is the most well know system, I think. But character-based search on a large corpus is a very difficult problem that, using today's algorithms, would require massive computing capacity to provide to even a small number of users. However, in some specialized applications, this can be justified. One technique for reducing the resource cost of character-based regex on large collections is to index bigrams, trigrams, quads, etc. (i.e. use multi-character sequences as the base "symbol" or smallest unit indexed. ) However, such ngram based systems still don't deliver the serving capacity that one would expect from something like a Google or Yahoo!.
One "mixed" strategy that has sometimes been employed is to support a more complex query that has a "first part" which is word-based (as in traditional search engines). This first-part is used to select a subset of all the documents in a collection. Once the candidate-result-set is produced, one would run a character-based regex (similar to grep) over the results. Of course, you can probably see that you can easily hack up such a two-phase search yourself by sending a word-based query to a search engine and then doing the character-based regex on the result pages.
I fear we are stuck with word-based search for the foreseeable future. While folk often ask for character based regex, the reality is that it is simply too hard to implement today. Also, the size of the market that has a real need, as opposed to a desire, for this capability is much smaller than one might think....
bob wyman
Doyle claims that the big difference between OLE (Object Linking and Embedding) and what he claims to have invented is that his system allowed one to pull the active objects over the Internet rather than just local machines and/or Local area networks. However, OLE was not, in fact, limited to local machines and LANs. There were a variety of tools that allowed the Microsoft file system (NETBIOS, etc.) to be extended over the Internet and other WANs. Thus, his claimed distinction is false.
In any case, the argument that accessing data over the Internet is somehow different from any other kind of data access is simply silly. This is a false distinction that could only convince a lawyer who is not familiar with the field.
bob wyman
Base_chakra: Before you get too righteous, you should understand that claiming that someone "double counts" or otherwise falsifies numbers can never be considered a joke. Your suggestion that our numbers are not honest is the sort of thing that builds myths that we will probably be responding to months if not years from now. At PubSub, we do our best to provide the best statistics we can. We publish more data than any other service and we are vastly more open about our numbers than anyone else. It isn't in any way "funny" or "joke-like" to suggest that our numbers are in any way tainted.
bob wyman
PubSub have not been "double-counting" and have "admitted" no such thing. Your post is a complete lie. I can only wonder whose interests are served by spreading such lies about the service we provide...
bob wyman
Baricom: What you're looking for is the "cloud" interface defined at: http://blogs.law.harvard.edu/tech/soapMeetsRss
The documentation there is, I think, about as good as you'll find. While it says that it can be implemented in either XML-RPC or SOAP, I am aware only of XML-RPC implementations.
The cloud provides a means for blogs to notify subscribers of updates and should eliminate the need for polling -- except that the subscriptions must be renewed at least every 25 hours. Of course, this cloud stuff isn't terribly useful in most cases since it relies on the blog server being able to send an HTTP message to a remote client (subscriber). In most cases, those messages would be blocked by firewalls. This is, of course, why the "Atom over XMPP" stuff makes sense. It relies on a connection established from the client to the server -- in the same manner as is done with instant messaging clients. Thus, there are many fewer issues with firewalls.
Of course, having lots of session open between a client program and all of the various blogs it reads probably doesn't make much sense. Neither does it make sense for every blog to maintain a list of all of its "cloud" readers and go to the work of sending them all messages whenever the blog is updated. Thus, the most sensible way to do this push business is to have the individual blogs publish to a common network of aggregating servers and then have clients establish connections to the common service. Overall bandwidth consumption is thus reduced to the absolute minimum. That's what we're building at PubSub.com.
bob wyman
While there are some great ideas in RSS, one of the worst is polling. As discussed in Burton's post, polling results in a ridiculous waste of bandwidth. A Push approach, like the one defined in "Atom over XMPP" would result in a massively more efficient distribution system like the one that we implement in the PubSub Sidebars. But, if you insist on polling, then the best efficiency can be had by combining Gzip with the A-IM or RFC3229+feed as described on my blog. Using RFC3229+feed, your server would only serve up "unread" entries not everything in your feed. Please read and implement: http://bobwyman.pubsub.com/main/2004/09/implementa tions.html
bob wyman
CTO, PubSub.com
Technorati only claims to process 900,000 new entries per day - not 9 million. Burton has the number correct in his posting. The /. article quotes him incorrectly. On the other hand, the numbers cited for PubSub are correct. We have processed an average of 1,796,574 (1.8 million) new entries per day over the last 30 days. Many of our statistics are available on our site and updated daily. The "new entries per day" data can be found graphed at: http://www.pubsub.com/linkcounts_graphs.php?type=n ewentries for more graphs and tables, see: http://pubsub.com/linkcounts.php
bob wyman
CTO, PubSub.com
To get the latest info on the Earthquake, try monitoring this feed from PubSub.com:
2 bd5f.xml
http://rss.pubsub.com/ef/c3/b9173332d3d1011651b6f
Content will be updated every 15 minutes and will contain the most recent 32 blog entries that mention the event.
bob wyman
"Atom over XMPP" is supported by PubSub.com and is the subject of an Internet Draft. See: http://www.ietf.org/internet-drafts/draft-saintand re-atompub-notify-01.txt
We offer a free FireFox/IE sidebar for receiving "Atom over XMPP" on our website at: http://www.pubsub.com/sidebar_firefox.php
bob wyman
Your suggestion is precisely what is defined by RFC3229+feed (i.e. an RSS-specific extension to RFC3229 " delta encoding for HTTP). I maintain a list of implementation of RFC3229+feed on my blog. You can also find some empirical evidence showing massive bandwidth savings as a result of RFC3229+feed use.
This is a well known and "solved" issue...
bob wyman
Google recently bought Hello.com and has been supporting its instant messaging protocol, clients, etc. ever since the purchase. Hello's focus today is on Instant Messaging between people who share pictures, but they could open it up to a wider audience any time they wanted to. Thus, GOOGLE already has an IM client and protocol. As far as I know, the protocol is closed.
To see an example of Google/Hello IM Chatting, see: Google Chat
The question isn't whether or not Google should "adopt" XMPP, rather, the question is whether they should "change to it." My hope is that they will dump their proprietary system and switch to the XMPP IETF open standard as soon as possible.
bob wyman
Anyonymous Coward wrote:
"I only hope he hand typed the story."
I did.
bob wyman
Google also filed a form 10-12G today. This should be read in concert with the S-1.
bob wyman
CTO, PubSub Concepts, Inc.
http://pubsub.com
How many people remember ALL-IN-1 which was the leading minicomputer based office automation system back in the 80's? ALL-IN-1 was a "form-driven" system that had many similarities to what you see on the Web today and made extensive use of plug-ins and "embedded" programs to allow people to construct arbitrarily complex office systems. If you imagine ALL-IN-1 to be like a Web Browser, what it did was create windows in which you could embed, in frames, just about any application that could run on VMS. You could have a window that was just text, or you could have a window that included a frame with a text editor or a database program or whatever... We even defined a "common calling convention" that allowed developers of applications on VMS to make their programs "callable" so that we could invoke them directly and consistently. (VMS coders will remember seeing a lot of programs that offered callable interfaces that looked like edt$edt, dtr$dtr, etc. That was done for ALL-IN-1...) Embedding was good enough in the 80's to make ALL-IN-1 a multi-billion dollar business. What Eolas claims was done long before they filed their claims and was implemented in many other programs.
You can find similar examples of embedding in Digital's TPU editor (especially the DECWindows version that I used to build a network based hypertext system in the late 80's), the VTX videotext product and VaxNotes (both VTX and VaxNotes helped inspire Tim Berners-Lee while he was at CERN... My TPU based "Memex" hypertext system also ran at CERN in the 80's...)
The problem, of course, is that most people have forgotten that there were computers before PC's and before 1990...
bob wyman
first ALL-IN-1 Product Manager
To authenticate, you must connect to your home server first. Often, the "traveling mailman" can't do that due to network partitions, slow links, etc. I've often found it difficult to connect to my home server while traveling in India, Europe, etc.
It is often possible to guess an author's age by the proposals generated. My guess is that the author of this proposal is under 35 or at least got into the business sometime after 1993... People who have never known anything other than the amazing connectivity and bandwidth that we've had in the last decade in the US tend to forget some of the more basic realities of working with networks...
bob wyman
mpthompson wrote:
> I'm fairly certain OLE and the enabling COM
> technology predates 1993
I was Senior Product Manager for Applications Programmabilty at Microsoft from 1991 to 1993 and I can assure you that not only OLE but OLE Automation (the real predecessor of ActiveX) were well understood and underdevelopment prior to 1993. In fact, when I came to Microsoft in 1991 to work on this stuff with them, the program was already underway and I considered it to be merely the Microsoft version of work that we had done at Digital (where I had been product manager for ALL-IN-1). As early as 1982 at Digital, we had demonstrations of wordprocessors that took spreadsheets and other active elements as plug-in extensions. Also, the wide-area-network Hypertext browser ("Memex Prototype 1") that I built at Digital in the mid/late 80's had plug-in extensions that used the TPU plug-in model.
bob wyman
21 of the 26 patents that Intertrust provides links to on their site refer to one or more of four patents on which I am the sole inventor. My four "license management" and/or DRM patents were all assigned to Digital Equipment Corporation (now HP) and are some of the earlier patents in this space.
I've watched Intertust collect their patents over the years and have been regularly struck by the realization that these folk have been successfully patenting ideas that I considered obvious and unpatentable in the 80's or already covered by my patents. Also, quite a number of the things that they have patented are things that I clearly recall having been discussed with Microsoft while I was at Digital or at Microsoft once I joined them (for a brief stay) back in the early 90's.
As many will realize, Microsoft has been long interested in and involved in the process of building DRM software. Many people will, for instance, remember Gates' letter to the industry back in the 70's in which he complained that people weren't paying for software. I personally became aware of Microsoft's interests in licensing back in the late 80's when Digital and Microsoft cooperated in submitting my "Digital Distributed Software Licensing Architecture" to the OSF in response to one of their solicitations. Having spent a great deal of time speaking with Microsoft folk back then, as well as dealing with many of the licensing issues as "Senior Product Manager for Applications Programmability" once I joined Microsoft, I can assure you that folk in Microsoft were aware of and anticipated many of the methods that InterTrust has managed to patent.
The problem, of course, is that simply knowing the methods isn't good enough. You've got to get them patented... But, back then, there wasn't much of a culture of getting software patents. People simply didn't do it. Even at Digital, I remember being regularly told by the patent attorneys that they were very happy to have found a software guy willing to work on patents and how they hoped that they'd be able to use my patents as an example for others.
While there may be "some" meat in the InterTrust case, my personal feeling is that this case is yet another example of the problems we have with software patents. The system was supposed to reward and encourage innovation yet the people who seem to be getting rewarded are not the innovators -- rather, it those who file patents who are getting rewarded. Perhaps, today, we've established that the only rational thing to do is to file for patents on anything you are doing -- no matter how obvious it may seem -- and then hope that the patent office will screw up and grant you something. But that was not always that case. It used to be that if people filed patent applications at all for software it was only for the really "special" ideas. The result is that alot of little stuff or obvious stuff went unpatented until companies like InterTrust, who live on patents -- not innovation -- came along to sweep things up. This isn't the way the system was supposed to work.
bob wyman
For a good example of a bad patent, try US Patent 6,314,574 which claims the method of storing HTML on CDROMs or other read-only media.
Andrew Russell's paper on the W3C PPWG seems to have been last revised on 18-Mar-2003, yet the most recent version of the W3C Patent Policy was released the next day, on 19-Mar-2003. The difference is significant since Russell's paper talks much about how the W3C had accepted a royalty-free policy, yet the policy that was released provides explicit exceptions that will allow encumbered royalty-based methods to be included in W3C recommendations in some circumstances. While Russell's paper is very interesting as a snapshot in time, it will need to be rewritten in light of the current policy in order to be truly useful.
bob wyman
Medio Magazine, published on CDROM from 1993 to 1995 by Medio Multimedia, and many other CDROM based titles had a "frames-based" interface which pre-dated the earliest possible date of conception for the SBC patents.
bob wyman
Creator, Editor, Medio Magazine
WetCat wrote:
>Assume we found some "Smoldering guns". To whom shall we show the evidence?
You show it to the USPTO by doing a "Third Party Submission of Prior Art" using USPTO procedures prior to 60 days after the application was published (i.e. 60 days after 6-Feb-2003). After that time, you have to serve papers on the inventor, lawyers, assignees, etc. to inform them of the prior art and thus force them to perform their "Duty of Candor" and submit the prior art for you to the USPTO.
bob wyman
The application being discussed here is a "stealth application" in that it does not indicate Microsoft as the assignee although Microsoft is, unquestionably, the assignee. In this case, the failure of Microsoft to be identified as an assignee may be considered a failure to meet their duty as a monopolist to give competitors "access to their facilities." For more info, see comment #7 in the discussion of "stealth patents" at PubSub.org.
.NET style afford the only reasonable mechanisms for working with their products. Thus, any patent that blocks others from developing similar, but different and competitive architectures, effectively blocks competitors from being able to build systems that work with Windows and thus blocks them from working with most computers. The result will be a loss of competition in an already monopolized market. In this case, what might otherwise be a "non-fundamental" patent becomes fundamental.
It should also be noted that analytically, the combination of an existing monopoly with the monopoly granted by a patent raises the same questions as the merger of two companies. In a case where the monopoly granted by the patent is for something not fundamental to a market, then one can permit the "merger." However, when the monopoly granted by the patent is fundamental and blocks an entire realm of competitive activity, the "merger" should not be permitted. In this case, Microsoft is clear in its intent to ensure that architectures of the
Even though a patent which issues from this application would appear on its face to only grant the right to exclude from some limited technical domain, when combined with the effects of Microsoft's existing market power, the effect of such a patent would go beyond the limited technical scope and extend so that it is coextensive with the entire economic product market.
thogard wrote:
>FSF or EFF [should]Provide a database of 'prior art
There is already a tool for collecting prior art! This is one purpose for the pubsub.org site. The idea is that if you find a patent or patent application for which you have or seek prior art, you can get it listed on the site and record your prior art. This makes a permanent record that others will be able to use as a source when filing "third party" prior art with the PTO as well as when defending against infringement cases in the future.
Today, there are many discussions of specific patents or applications scattered all over the web. This makes it difficult for those with a real interest in defending against some patent or application to find the prior art they need. However, on PubSub.org, you can write a comment directly linked to a specific patent or application and identify the prior art or other argument you might have for why the patent should not be (or have been) granted. Try it. If you don't find a patent or application that you're interested in, just use the "request new thread" option to get the patent listed.
The system on pubsub.org is different from what you'll find on other sites like BountyQuest where they are only collect prior art on "major" patents. At PubSub.org, you can provide prior art on *any* patent or application and what you provide will be publicly available and reviewable.
If there is demand to do so, I'll expand the scope of what we do at PubSub.org to include providing a place to record "defensive" or "Open Prior Art." This would allow anyone who has a method that they consider patentable to "block" anyone else from getting a patent on the same method. The PTO considers "internet publications" to be valid prior art as long as they are accessible. Should I do this?
bob wyman
Sorry about that. The tables were generated by Microsoft Excel and seem to be causing problems in non-IE browsers. I'm trying to fix it now...
bob wyman