Many software patents do end up being EXTREMELY narrow, due to the volume of prior art in certain fields. It all depends on what the Examiner comes up with.
Can you give an example of such an "EXTREMELY narrow" software patent? I haven't seen any yet. Of course, my definition of "EXTREMELY narrow" may differ from yours, but I'm still curious about what you consider to fulfill that condition.
You mean you don't come up with an invention before you start writing the code? Remind me never to use your software...
This is indeed a mental disconnect between most programmers and most proponents of software patents. Programmers in general do not feel they are "inventing" when solving the hundreds of problems when they are programming. Just like a writer doesn't feel he is inventing while solving logical problems in his plot, a mathematician when solving logical problems in his proofs, etc.
It's their basic job, and they realise that if all that problem solving becomes patentable subject matter (given that it's new/not obvious), they should in theory spend more time on figuring out whether anything they do is already patented than on programming, and more money on getting licenses than they can ever make selling their software (unless they are a huge company with tons of patents ready for cross licensing).
It's just not economically feasible, unless you feel that software development and distribution should be reserved to large companies with enough lawyers etc to afford the costs a software patent system imposes on software development businesses. Basically anyone with a computer, internet access and a basement can currently start and run a successful software development company.
I don't see this as a problem which requires more red tape in order to prevent that, nor do I see any problems in the current software development model which would be solved by software patents (unless you consider many small independent companies as a problem and consolidation as a solution).
Why can't the Zune store recognize that that you own a PlaysForSure-protected version of a music title, and allow you to download the same title in Zune-protected format at no charge?
Probably because of the "copy" in "copyright". Every new copy they allow you to download is presumably another copy they have to pay for to the RIAA, regardless of whether you owned it or not (unless the RIAA made an exception for the above situation and refused money in that case... yeah right).
I am in the same position. I moved to the US a few years ago,and have not had to borrow money, thus I have 'enquiry only' logged against me by the credit agencies.
A while ago I read an interview with a Belgian journalist who works/lives in New York (who happens to be called Suzy Hendrickx:), and she related a similar story. In fact, in the end she got a credit card and made sure she always had a little debt on it. The reason is that otherwise she got trouble in several places because "no credit card" or "no credit card debt" was interpreted as "probably a lot of debt or shady financial affairs, but somehow hidden from view".
A very strange situation indeed from a foreigner point of view...
I don't think patents on methods of solving problems like this are a good idea because closed source software companies can hide their execution method to get around a patent like this
No, they can't, because the patent Microsoft applied for is so broad that it covers pretty much any way you could devise to do this. Which mean they could probably subpoena the source code since it is a reasonable assumption that it will infringe.
You cant just read the few sentences in the abstract and assume that they are trying to patent everything which even remotely fits that description
That's correct. In fact, you can just disregard the entire abstract, because what defines the scope of the patent are the claims. Each independent claim (a claim which does not refer to another claim) is an independent patent monopoly. Claim 1 is usually the broadest, so let's have a look at it:
A method in a computer system for conjugating verbs in a target language, the method comprising: receiving a verb in a base language; identifying verb forms in the target language using a translation of the received verb from the base language to the target language; and displaying the identified verb forms in the target language.
So the "method" they want to patent consists of asking a computer to translate the verb. That's it. The other claims simply add other words or different forms of the verb as input when translating, and allow for a user to select a different verb.
Splitting functions into different source files doesn't change anything about this.
s/Splitting functions into different source files/Putting each function in a different source file/ is what I obviously meant. Refactoring one big function in several smallers ones obviously does reduce potential collisions, but that's independent of whether you put the result in separate files or all in the same file.
I routinely work on PPC, ARM, x86 [32 and 64-bit] boxes. Show me the copy of Delphi that works on all of those please.
As I mentioned, I work on FPC. We support all of those and more. In fact, we supported Win64 before GCC did. No, I do not think you (or anyone else) should switch to FPC for that reason. But FPC is also multi-processor and multi-platform (not as much as GCC, but it's generic enough to be able to do so without making the compiler any slower). In fact, its code generator is object-oriented and every single opcode which gets emitted requires passing through at least one virtual method call. Yet FPC is much faster than GCC.
GCC is not a bad compiler compared to the competition (in terms of optimized code quality), but it is slow. It's not because it does more (because also without any optimizations it's slow), it's not only because it supports many platforms (FPC also does), it simply is a slow compiler. That's really all I said in my original post, and I stand by that point. You may think that's not relevant, fine, but other people do (including me, in spite of the fact that I'm not the imaginary person with 100k lines per source file you quoted)
If you are working in a team of 30 and you all need concurrent access to the tree putting all your eggs in one basket can make collisions a bitch to work around.
Collisions only occur if you edit the same code (or at least code only a few lines apart). Splitting functions into different source files doesn't change anything about this.
The speed has nothing to do with the fact it's Pascal derived as there are very fast C compilers out there.
And although there are much faster C compilers out there than GCC, Pascal compilers tend to be faster in general because Pascal is designed to be parsed in a single pass, while C is designed to be parsed in two passes (preprocessor followed by the regular compiler, although it may be possible to fold both into one pass). And no, this does not mean that Pascal is inherently superior to anything, that GCC is inherently inferior to anything, that you should put all your source code in a single file or that Delphi is the panacea for all development work.
Even if you turn off all optimizations GCC is still quite slow, in particular when compiling C++ code. Things got a lot better in 4.0 and 4.1, but it still not exactly fast.
It's not meant for that problem. GCC is meant to be cross-platform highly optimizing standards adhering compiler platform [not just for C but C++, F77, Ada, Java, etc]. If your goal is "lines per second" and not quality of the output use something like LCC.
Just like with all programs, people don't use a compiler just because of one metric (there's always for example the ability to compile your program -- I'm not sure whether LCC can actually compile e.g. the Linux kernel or OpenOffice.org). Apparently for you compilation speed does not matter in any way. And you also seem to look down on anyone who does care about the speed of a compiler. That's all fine. I'm happy for you that this is one thing you do not care about in the least, since that obviously makes it easier to choose a compiler.
I really truly honestly 100% believe that if you spend too much time building stuff you need to refactor your code. It's really that simple. Keeping single functions per.c file for instance is a quick way to make the code accessible, CVS [etc] ready and keep compile times low.
If you have to refactor your code down to one function per source file (particularly nice for classes, or for different functions needing access to the same static variable) to keep compilation swift, there's something wrong with the compiler or build system you are using. This practice will also effectively kill any and all auto-inlining most compilers (including GCC) might otherwise do (except for static inline functions declared in header files).
I took a course 2 weeks ago at a summerschool from David Padua who works a lot on compiler optimizations. His conclusion was all the time that basically all current compilers suck at optimizing, except in very specific cases and often only if you know how to write your code so the compiler recognises what you want to do.
"suck" is subjective.
Absolutely.
Do you maintain the position that GCC 4.1.1 is no better than GCC v1? Or how about Turbo C++ 3.0?
I'm not sure how I'm supposed to maintain a position I never took.
I'd say they're far from perfect but they're not sub-ideal. GCC routinely produces output of ideal quality. It often makes use of exotic opcodes [like movzbl] instead of emulating them with more basic opcodes. It knows how to move code blocks around, unroll, inline, CSE, etc.
movzbl is anything but exotic. You'd really have to do your best not to use that opcode in a code generator.
Unrolling is still mostly black magic at this time, which is why libraries such as Spiral actually create dozens of differently unrolled and tiled versions of themselves when you install them on your machine, benchmark themselves for different input set sizes and then configure themselves to use the optimal unrolling for each input size and function you call for you particular machine. If you don't perform this sort of exhaustive searching, your unrolling can just as well cause a slowdown rather than a speedup.
Inlining has a similar problem: apart from inlining calls when the inlined result is smaller than the calling sequence, inlining can also often cause unforeseen slowdowns (mostly because of different alignments caused by inlining, or instruction cache spilling). CSE is nice (and pretty common in contemporary compilers), but only goes so far and most of the time fails as soon as a function call to an external module is involved (really great if you put each and every function in a separate source file). That's why th
I'd say GCC does far more optimizations than FPK or Delphi
Even if you turn off all optimizations GCC is still quite slow, in particular when compiling C++ code. Things got a lot better in 4.0 and 4.1, but it still not exactly fast.
Honestly, how much time do you spend rebuilding your entire application?
Since you ask: actually, since I work on FPC (not FPK, that name is long gone), I spend a lot of time rebuilding the entire compiler and run time library (often 2 to 3 times in a row, compiling the next iteration with the previous result) as a first quick check against newly introduced code generation or parser bugs.
Chances are if you have to rebuild a million lines of code when you fix a typo in some function, then you need to really think about factoring your code properly. I can see if we were talking about 1000 loc/min vs. 1000 loc/sec or whatever. But if Delphi's only feature is that the [from the customers point of view] the SINGLE build is fast but the code generated sucks... then you're stuck.
As you know (since you mention it below), that isn't Delphi's only feature from the customers point of view. But it's nevertheless extremely convenient when you're used to it. People have been ranting since day one on Apple's Xcode list about the slowness of GCC compared to CodeWarrior (even when comparing a distcc'd build against a single threaded CodeWarrior build), also in debug mode (i.e. no optimizations). Compilation speed is far from a non-issue these days.
Also, Delphi's code generator doesn't suck, it's just average. Which as it happens didn't matter all that much for x86 until now, since the processor itself optimizes a lot behind the scenes. Also, unless you are building numerical applications or 3D engines, most advanced optimizations such as loop tiling, all sorts of prefetching tricks etc have little impact.
I took a course 2 weeks ago at a summerschool from David Padua who works a lot on compiler optimizations. His conclusion was all the time that basically all current compilers suck at optimizing, except in very specific cases and often only if you know how to write your code so the compiler recognises what you want to do.
In my personal experience, a good register allocator and some peephole optimizations can get you a long way with most applications.
GCC performs a lot of passes on the code to look for ways to optimize the code it produces. I think you should take some non-trivial function, pass it to GCC with "-O3" and then look at the assembly code it produces. You'll be amazed at the complexity of the output.
I've already spent plenty of time looking at assembly code generated by various compilers, including GCC:)
the Delphi grammer is supposedly proprietary and a trade secret, and that no one else can build a parser that handles all of the corner cases
Of course it's possible to build a parser which handles all corner cases, be it not in one shot since there is indeed no design document to base yourself on. But by now at least we (the Free Pascal Compiler) do support most of it.
I am kinda switching over to Java Swing for the GUI, C++ through the JNI for the hardcore numeric stuff -- a person sees the handwriting on the wall about Borland longevity. I kinda want to get off Windows by the time Vista, Aero, and whatever Windows-specific GUI gobbeldygook takes hold, and Java looks attractive to me. It is easy to get spoiled by GC and some other Java hacks, but I miss the fast compiles -- javac is dog slow.
You might want to have a look at Lazarus. Although the underlying Free Pascal Compiler is not as fast as Delphi, it's a lot faster than most other compilers (and javac). Have a look here for a small unscientific test. Can't compare to Delphi, because the compiler itself is not written in a Delphi-compilable way.
For Java, try using IBM's jikes compiler instead (not to be confused with the JikesRVM -- jikes is simply a Java compiler, not a whole virtual machine).
Eclipse, on the other hand, is still something I am struggling with -- it is IBMish in its weirdness about a whole bunch of stuff -- how do you just take a bunch of.java files in a directory and call it a project? It doesn't like a directory that is already there, and it wants to create some other directory in some standard location instead of where you want it. Still working on that one. So even Java needs "make files" of some kind of external metadata to organize multi-file source codes. Object Pascal famously has all of the dependencies specified in source code as a feature of the language.
Java does specify the dependencies in the source as part of the language. You have to "import" all packages you need, much like a uses clause (and it allows for both more fine-grained and coarse-grained control regarding what you want to import).
The only difference is indeed, as you mentioned, that packages should recide in a directory called the same (or in a jar file). This organisation however avoids problems you can have in Pascal if you e.g. have multiple units with the same name in different directories. It does not necessitate the use of "makefiles of some kind of external metadata" in any way though (unless you consider directories falling under that).
If there are two features, no, make that three features! that make Delphi problematic for the future, they are 1) Delphi has some real solid Windows lock-in, especially since Kylix didn't go anywhere -- the Delphi extension to Pascal are quite Windows-specific even if you are not doing GUI programming,
Most Delphi extensions can be perfectly ported to other platforms. FPC runs on Dos, Windows, Linux, Mac OS X, FreeBSD, Solaris, Gameboy Advance,... and the supported basic features are the same everywhere (except for threading, which is not supported on Dos and some other lightweight platforms).
2) while Delphi is great and everything, it is behind the times with collection classes and other library richness of everything from Java to Python -- what collection classes are there are also tied into the VCL and bloat non-GUI or GUI-non-VCL programs,
I do agree with you here (in spite of the fact that there are some third party container collections for Delphi).
I can build my LibTomMath project [~9K lines of source] in 2.3 seconds on my 2P Opteron 285 setup.:-)
I can compile and link the Free Pascal Compiler (158612 lines of code including comments) using itself in 15.9 seconds on my G5/1.8GHz (using one cpu). That's 9975 loc/s, compared to your 3913 (and you were possibly even using two cpus?).
And guess what: people still sometimes complain about how "slow" our compiler is compared to Delphi. So don't underestimate Delphi's compilation speed...
It still is:) And there's a Free alternative to Kylix as well: Lazarus + Free Pascal. The main reason Kylix was not well-received was because it's extremely buggy and slow (the IDE was Wine-based), and it runs on just a few distributions.
The data retention directive does mandate data retention (that's why it's called like that). However it does not mandate retaining email bodies (in fact, even the EU Commission seems to think that would go against the EU privacy laws), but "only" who sent when an email from which address to which address (that's all as far as emails are concerned at least).
That was not someone rebranding Firefox and selling it under his own name, nor did anyone get sued for that matter. Someone was merely selling CDs with the regular Firefox on them and it was a trading office official who got confused because she indeed was not familiar with the concept of Free Software.
ROTFL:) Have a look here, in particular under the "president" entry (yes, our old site is horribly out of date regarding the board composition, but we are working on it).
The problem is that this is not a software patent, it's a process patent, the managment system, taking in all uses of computer networks for teaching
All software patents are process patents (although they can also contain product claims). A software patent is never on a particular piece of software, it's always on something you can do with software. They are patents on algorithms which can be implemented using a computer, but these algorithms can be specified at a very high/abstract level.
Sure, this is a quite broad software patent, but most of them are. And the main reason for this is exactly that they are covering completely abstract entities with little or no inherent relation to the physical world.
Blackboard was garbage until GWU sold them Prometheus, which practically makes up their Blackboard software now. Can you patent something somebody made without patenting and sold to you?
Software patents are not patents on particular pieces of software, but on concepts. Blackboard didn't patent their or someone else's implementation of a CMS geared towards education, but the generic principle of such a CMS.
Slashdot Mirror
Can you give an example of such an "EXTREMELY narrow" software patent? I haven't seen any yet. Of course, my definition of "EXTREMELY narrow" may differ from yours, but I'm still curious about what you consider to fulfill that condition.
This is indeed a mental disconnect between most programmers and most proponents of software patents. Programmers in general do not feel they are "inventing" when solving the hundreds of problems when they are programming. Just like a writer doesn't feel he is inventing while solving logical problems in his plot, a mathematician when solving logical problems in his proofs, etc.
It's their basic job, and they realise that if all that problem solving becomes patentable subject matter (given that it's new/not obvious), they should in theory spend more time on figuring out whether anything they do is already patented than on programming, and more money on getting licenses than they can ever make selling their software (unless they are a huge company with tons of patents ready for cross licensing).
It's just not economically feasible, unless you feel that software development and distribution should be reserved to large companies with enough lawyers etc to afford the costs a software patent system imposes on software development businesses. Basically anyone with a computer, internet access and a basement can currently start and run a successful software development company.
I don't see this as a problem which requires more red tape in order to prevent that, nor do I see any problems in the current software development model which would be solved by software patents (unless you consider many small independent companies as a problem and consolidation as a solution).
There is virtually always a mirror of pages linked from slashdot stories at mirrordot.
Probably because of the "copy" in "copyright". Every new copy they allow you to download is presumably another copy they have to pay for to the RIAA, regardless of whether you owned it or not (unless the RIAA made an exception for the above situation and refused money in that case... yeah right).
GP was not replying to the submitter, but to a reply to the story. That reply said:
Strange that in spite of how lifelike it is, they switched around the bending curve of the of the front and hind legs compared to real animals.
A while ago I read an interview with a Belgian journalist who works/lives in New York (who happens to be called Suzy Hendrickx :), and she related a similar story. In fact, in the end she got a credit card and made sure she always had a little debt on it. The reason is that otherwise she got trouble in several places because "no credit card" or "no credit card debt" was interpreted as "probably a lot of debt or shady financial affairs, but somehow hidden from view".
A very strange situation indeed from a foreigner point of view...
No, they can't, because the patent Microsoft applied for is so broad that it covers pretty much any way you could devise to do this. Which mean they could probably subpoena the source code since it is a reasonable assumption that it will infringe.
No, it isn't.
That's correct. In fact, you can just disregard the entire abstract, because what defines the scope of the patent are the claims. Each independent claim (a claim which does not refer to another claim) is an independent patent monopoly. Claim 1 is usually the broadest, so let's have a look at it:
So the "method" they want to patent consists of asking a computer to translate the verb. That's it. The other claims simply add other words or different forms of the verb as input when translating, and allow for a user to select a different verb.
It's on the last page of the review. And it's very bad (a laptop that can't even run 2 hours on a battery charge?)
Imagine what would happen if they could also harness Diebold's flops...
s/Splitting functions into different source files/Putting each function in a different source file/ is what I obviously meant. Refactoring one big function in several smallers ones obviously does reduce potential collisions, but that's independent of whether you put the result in separate files or all in the same file.
As I mentioned, I work on FPC. We support all of those and more. In fact, we supported Win64 before GCC did. No, I do not think you (or anyone else) should switch to FPC for that reason. But FPC is also multi-processor and multi-platform (not as much as GCC, but it's generic enough to be able to do so without making the compiler any slower). In fact, its code generator is object-oriented and every single opcode which gets emitted requires passing through at least one virtual method call. Yet FPC is much faster than GCC.
GCC is not a bad compiler compared to the competition (in terms of optimized code quality), but it is slow. It's not because it does more (because also without any optimizations it's slow), it's not only because it supports many platforms (FPC also does), it simply is a slow compiler. That's really all I said in my original post, and I stand by that point. You may think that's not relevant, fine, but other people do (including me, in spite of the fact that I'm not the imaginary person with 100k lines per source file you quoted)
Collisions only occur if you edit the same code (or at least code only a few lines apart). Splitting functions into different source files doesn't change anything about this.
And although there are much faster C compilers out there than GCC, Pascal compilers tend to be faster in general because Pascal is designed to be parsed in a single pass, while C is designed to be parsed in two passes (preprocessor followed by the regular compiler, although it may be possible to fold both into one pass). And no, this does not mean that Pascal is inherently superior to anything, that GCC is inherently inferior to anything, that you should put all your source code in a single file or that Delphi is the panacea for all development work.
Just like with all programs, people don't use a compiler just because of one metric (there's always for example the ability to compile your program -- I'm not sure whether LCC can actually compile e.g. the Linux kernel or OpenOffice.org). Apparently for you compilation speed does not matter in any way. And you also seem to look down on anyone who does care about the speed of a compiler. That's all fine. I'm happy for you that this is one thing you do not care about in the least, since that obviously makes it easier to choose a compiler.
If you have to refactor your code down to one function per source file (particularly nice for classes, or for different functions needing access to the same static variable) to keep compilation swift, there's something wrong with the compiler or build system you are using. This practice will also effectively kill any and all auto-inlining most compilers (including GCC) might otherwise do (except for static inline functions declared in header files).
Absolutely.
I'm not sure how I'm supposed to maintain a position I never took.
movzbl is anything but exotic. You'd really have to do your best not to use that opcode in a code generator.
Unrolling is still mostly black magic at this time, which is why libraries such as Spiral actually create dozens of differently unrolled and tiled versions of themselves when you install them on your machine, benchmark themselves for different input set sizes and then configure themselves to use the optimal unrolling for each input size and function you call for you particular machine. If you don't perform this sort of exhaustive searching, your unrolling can just as well cause a slowdown rather than a speedup.
Inlining has a similar problem: apart from inlining calls when the inlined result is smaller than the calling sequence, inlining can also often cause unforeseen slowdowns (mostly because of different alignments caused by inlining, or instruction cache spilling). CSE is nice (and pretty common in contemporary compilers), but only goes so far and most of the time fails as soon as a function call to an external module is involved (really great if you put each and every function in a separate source file). That's why th
Even if you turn off all optimizations GCC is still quite slow, in particular when compiling C++ code. Things got a lot better in 4.0 and 4.1, but it still not exactly fast.
Since you ask: actually, since I work on FPC (not FPK, that name is long gone), I spend a lot of time rebuilding the entire compiler and run time library (often 2 to 3 times in a row, compiling the next iteration with the previous result) as a first quick check against newly introduced code generation or parser bugs.
As you know (since you mention it below), that isn't Delphi's only feature from the customers point of view. But it's nevertheless extremely convenient when you're used to it. People have been ranting since day one on Apple's Xcode list about the slowness of GCC compared to CodeWarrior (even when comparing a distcc'd build against a single threaded CodeWarrior build), also in debug mode (i.e. no optimizations). Compilation speed is far from a non-issue these days.
Also, Delphi's code generator doesn't suck, it's just average. Which as it happens didn't matter all that much for x86 until now, since the processor itself optimizes a lot behind the scenes. Also, unless you are building numerical applications or 3D engines, most advanced optimizations such as loop tiling, all sorts of prefetching tricks etc have little impact.
I took a course 2 weeks ago at a summerschool from David Padua who works a lot on compiler optimizations. His conclusion was all the time that basically all current compilers suck at optimizing, except in very specific cases and often only if you know how to write your code so the compiler recognises what you want to do.
In my personal experience, a good register allocator and some peephole optimizations can get you a long way with most applications.
I've already spent plenty of time looking at assembly code generated by various compilers, including GCC :)
Of course it's possible to build a parser which handles all corner cases, be it not in one shot since there is indeed no design document to base yourself on. But by now at least we (the Free Pascal Compiler) do support most of it.
You might want to have a look at Lazarus. Although the underlying Free Pascal Compiler is not as fast as Delphi, it's a lot faster than most other compilers (and javac). Have a look here for a small unscientific test. Can't compare to Delphi, because the compiler itself is not written in a Delphi-compilable way.
For Java, try using IBM's jikes compiler instead (not to be confused with the JikesRVM -- jikes is simply a Java compiler, not a whole virtual machine).
Java does specify the dependencies in the source as part of the language. You have to "import" all packages you need, much like a uses clause (and it allows for both more fine-grained and coarse-grained control regarding what you want to import).
The only difference is indeed, as you mentioned, that packages should recide in a directory called the same (or in a jar file). This organisation however avoids problems you can have in Pascal if you e.g. have multiple units with the same name in different directories. It does not necessitate the use of "makefiles of some kind of external metadata" in any way though (unless you consider directories falling under that).
Most Delphi extensions can be perfectly ported to other platforms. FPC runs on Dos, Windows, Linux, Mac OS X, FreeBSD, Solaris, Gameboy Advance, ... and the supported basic features are the same everywhere (except for threading, which is not supported on Dos and some other lightweight platforms).
I do agree with you here (in spite of the fact that there are some third party container collections for Delphi).
I can compile and link the Free Pascal Compiler (158612 lines of code including comments) using itself in 15.9 seconds on my G5/1.8GHz (using one cpu). That's 9975 loc/s, compared to your 3913 (and you were possibly even using two cpus?).
And guess what: people still sometimes complain about how "slow" our compiler is compared to Delphi. So don't underestimate Delphi's compilation speed...
It still is :) And there's a Free alternative to Kylix as well: Lazarus + Free Pascal. The main reason Kylix was not well-received was because it's extremely buggy and slow (the IDE was Wine-based), and it runs on just a few distributions.
The data retention directive does mandate data retention (that's why it's called like that). However it does not mandate retaining email bodies (in fact, even the EU Commission seems to think that would go against the EU privacy laws), but "only" who sent when an email from which address to which address (that's all as far as emails are concerned at least).
http://mirrordot.com/stories/14b7a5a68c2b653db431b eae72d1d8c7/index.html
That was not someone rebranding Firefox and selling it under his own name, nor did anyone get sued for that matter. Someone was merely selling CDs with the regular Firefox on them and it was a trading office official who got confused because she indeed was not familiar with the concept of Free Software.
ROTFL :) Have a look here, in particular under the "president" entry (yes, our old site is horribly out of date regarding the board composition, but we are working on it).
All software patents are process patents (although they can also contain product claims). A software patent is never on a particular piece of software, it's always on something you can do with software. They are patents on algorithms which can be implemented using a computer, but these algorithms can be specified at a very high/abstract level.
Sure, this is a quite broad software patent, but most of them are. And the main reason for this is exactly that they are covering completely abstract entities with little or no inherent relation to the physical world.
The European sister patent application is still pending. I can perfectly imagine the European Patent Office (EPO) holding it valid though. After all, they already granted patents for e.g. submitting data to a database via forms and computer-based testing.
Software patents are not patents on particular pieces of software, but on concepts. Blackboard didn't patent their or someone else's implementation of a CMS geared towards education, but the generic principle of such a CMS.