It doesn't have to be external to the computer on which the program is run; reduced hard disk access time or an enhanced user interface could also be a technical effect.
Which implies that my second example, of a data compression program that runs on a general purpose computer, is patentable, because it has a technical effect.
This creates a serious difficulty in the interpretation of section 52(2)c. Computer programs that lack a technical effect cannot be the target of the exclusion in this section because lack of a technical effect already excludes them from patentability. Computer programs that possess a technical effect are not the target of this exclusion because possession of a technical effect exempts them from the exclusion. So what does the exclusion exclude?
I've read the draft directive and it is unclear. Imagine that a manufacturer of drilling machines invents a torque controller to reduce drill bit breakage. In the past that would have been done with slipping clutches and springs, and obviously would have been patentable. Today one does that kind of thing in software. However Article 52 of the EPC excludes:
(c) schemes, rules and methods for performing mental acts, playing games or doing business, and programs for computers
Has the realm of patentability effectively been narrowed? The directive clarifies that the drilling machine manufacturer can patent his new machine and claim royalities from other drilling machine manufacturers even though the invention lies solely in the software embedded in the machine.
Unfortunately the directive clarifies this area of law by confusing another. What happens when there is no drilling machine, when the invention is only a computer program? For example a data compression program that runs on a general purpose computer. The directive suggests that the general purpose computer, implicit in the notion of a computer program, counts as a machine in the way that the drilling machine did, thus extending the scope of patentability, directly contrary to 52(2)c.
The origin of the high temperatures is the symmetry of the bubbles. On earth, larger bubbles rise up the liquid and go out of shape or break up. In space it is hard to boil liquids. The bubbles grow big and fat, and with no convection they just hang around the heating surface, blocking the heat flow.
So, this might work better ( or at all) in space under micro-gravity, due to larger more symmetric bubbles
(loop for x from 0
for y in '(a 1 b c 3 4 d 5)
when (symbolp y)
collect (list x y))
=>((0 A) (2 B) (3 C) (6 D))
and was compared favourably to a more Lispy alternative
(do ((x 0 (+ x 1))
(y-list '(a 1 b c 3 4 d 5) (cdr y-list))
(result '()))
((null y-list)
(nreverse result))
(let ((y (first y-list)))
(when (symbolp y)
(push (list x y) result))))
Since I'm learning ANSI Common Lisp from Graham's book,
I thought it would be an interesting exercise to use mapcon.
As Steele explains, mapcon allows "the mapped function to
return a variable number of items to be put into the output
list. This is particulary useful for effectively returning
zero or one item:
(mapcan #'(lambda(x) (and (symbolp x) (list x))) '(a 1 b c 3 4 d 5))
=>(A B C D)
In this case the function serves as a filter; this is a
standard LISP idiom using mapcan."(I've tweaked Steele's example)
The problem is than mapcan doesn't tell the mapped function
where it is in the list, so I elaborated:
(let ((i 0))
(mapcan
#'(lambda (x)
(prog1 (and (symbolp x)(list (list i x))) (incf i)))
'(a 1 b c 3 4 d 5)))
=>((0 A) (2 B) (3 C) (6 D))
At this point I realised there was something wrong
with the discussion. It starts with a quote from
Graham's book and ends by contrasting the aesthetism of
Scheme with the pragmatism of Common Lisp. On the one hand
Graham has been painted into the aesthetes corner, but on
the other hand his book on Common Lisp is striking for its
pragmatism; he is trying to rescue Lisp from the aesthetes.
Graham covers DO in chapter 5, macros in chapter 10 and only
gets round to disapproving of LOOP in chapter 14. This
distinctive approach cries out for explanation and it is
clearly not due to Graham sharing the minimalist aesthetic
of Scheme.
I am going to stick my neck out and risk putting words into
Grahams mouth. His distinctive claim is that programmers
spend their days sitting at their keyboards typing in macro
expansions. If they could step back from the nitty-gritty of
coding and type in macro definitions instead, then the
computer could do the expansions for them, and much work
would be saved.
In the example the mapping functions, mapcar and mapcon, are
inapplicable because they lack a sense of place, of where
the mapped function is in the list. One way of responding to
this is to start typing. One cannot use the built-in mapping
functions, so one falls back on the basic iteration
capability. The surface syntax had better be attractive
because one will be typing it alot. An alternative way of
responding is to start thinking. How does one add a sense of
place to the mapping functions?
(countcan
index
#'(lambda(x)
(if (symbolp x) (list(list index x))))
'(a 1 b c 3 4 d 5))
=>((0 A) (2 B) (3 C) (6 D))
and one is back in business as far as mapping over several
lists in parallel
(countcan
index
#'(lambda(x y)
(if (eql x y)(list (list index x))))
'(c b a d)
'(a b c d))
=>((1 B) (3 D))
So Graham is not concerned with balancing the purity of
typing
(DO blah blah blah blah...
against the pragmatism of typing
(LOOP blah blah...
because he is intending not to type either of them all that
often. His plan is to type
(DEFMACRO purpose-built-iterator-17 blah blah...
and then to win back the time he spent thinking with
quicker, easier coding in the rest of the program.
DO fits into this plan better than LOOP.
Without having read the original Appl. Phys. Rev. article, I fail to see what all the fuss is about. It has been possible to grow hetero-epitaxial (100) diamond on silicon, again using bias-enhanced nucleation, for some years now. these films often give a far smoother and more cohesive appearance than that belonging to the image reproduced in the Nature article. Silicon wafers are a reasonably cheap commodity these days, much more so than single crystal iridium, I'd suggest.
Slashdot Mirror
Which implies that my second example, of a data compression program that runs on a general purpose computer, is patentable, because it has a technical effect.
This creates a serious difficulty in the interpretation of section 52(2)c. Computer programs that lack a technical effect cannot be the target of the exclusion in this section because lack of a technical effect already excludes them from patentability. Computer programs that possess a technical effect are not the target of this exclusion because possession of a technical effect exempts them from the exclusion. So what does the exclusion exclude?
The origin of the high temperatures is the symmetry of the bubbles.
On earth, larger bubbles rise up the liquid and go out of shape or break up.
In space it is hard to boil liquids.
The bubbles grow big and fat, and with no convection they just hang around the heating surface,
blocking the heat flow.
So, this might work better ( or at all) in space under micro-gravity,
due to larger more symmetric bubbles
The example given is
,func x yz)
,index)))
,list ,@more-lists)))
...
...
...
(loop for x from 0
for y in '(a 1 b c 3 4 d 5)
when (symbolp y)
collect (list x y))
=>((0 A) (2 B) (3 C) (6 D))
and was compared favourably to a more Lispy alternative
(do ((x 0 (+ x 1))
(y-list '(a 1 b c 3 4 d 5) (cdr y-list))
(result '()))
((null y-list)
(nreverse result))
(let ((y (first y-list)))
(when (symbolp y)
(push (list x y) result))))
Since I'm learning ANSI Common Lisp from Graham's book,
I thought it would be an interesting exercise to use mapcon.
As Steele explains, mapcon allows "the mapped function to
return a variable number of items to be put into the output
list. This is particulary useful for effectively returning
zero or one item:
(mapcan #'(lambda(x) (and (symbolp x) (list x))) '(a 1 b c 3 4 d 5))
=>(A B C D)
In this case the function serves as a filter; this is a
standard LISP idiom using mapcan."(I've tweaked Steele's example)
The problem is than mapcan doesn't tell the mapped function
where it is in the list, so I elaborated:
(let ((i 0))
(mapcan
#'(lambda (x)
(prog1 (and (symbolp x)(list (list i x))) (incf i)))
'(a 1 b c 3 4 d 5)))
=>((0 A) (2 B) (3 C) (6 D))
At this point I realised there was something wrong
with the discussion. It starts with a quote from
Graham's book and ends by contrasting the aesthetism of
Scheme with the pragmatism of Common Lisp. On the one hand
Graham has been painted into the aesthetes corner, but on
the other hand his book on Common Lisp is striking for its
pragmatism; he is trying to rescue Lisp from the aesthetes.
Graham covers DO in chapter 5, macros in chapter 10 and only
gets round to disapproving of LOOP in chapter 14. This
distinctive approach cries out for explanation and it is
clearly not due to Graham sharing the minimalist aesthetic
of Scheme.
I am going to stick my neck out and risk putting words into
Grahams mouth. His distinctive claim is that programmers
spend their days sitting at their keyboards typing in macro
expansions. If they could step back from the nitty-gritty of
coding and type in macro definitions instead, then the
computer could do the expansions for them, and much work
would be saved.
In the example the mapping functions, mapcar and mapcon, are
inapplicable because they lack a sense of place, of where
the mapped function is in the list. One way of responding to
this is to start typing. One cannot use the built-in mapping
functions, so one falls back on the basic iteration
capability. The surface syntax had better be attractive
because one will be typing it alot. An alternative way of
responding is to start thinking. How does one add a sense of
place to the mapping functions?
(defmacro countcan (index func list &rest more-lists)
`(let ((,index 0))
(mapcan
#'(lambda (x &rest yz)
(prog1 (apply
(incf
does the trick, allowing one to write
(countcan
index
#'(lambda(x)
(if (symbolp x) (list(list index x))))
'(a 1 b c 3 4 d 5))
=>((0 A) (2 B) (3 C) (6 D))
and one is back in business as far as mapping over several
lists in parallel
(countcan
index
#'(lambda(x y)
(if (eql x y)(list (list index x))))
'(c b a d)
'(a b c d))
=>((1 B) (3 D))
So Graham is not concerned with balancing the purity of
typing
(DO blah blah blah blah
against the pragmatism of typing
(LOOP blah blah
because he is intending not to type either of them all that
often. His plan is to type
(DEFMACRO purpose-built-iterator-17 blah blah
and then to win back the time he spent thinking with
quicker, easier coding in the rest of the program.
DO fits into this plan better than LOOP.
Without having read the original Appl. Phys. Rev. article, I fail to see what all the fuss is about. It has been possible to grow hetero-epitaxial (100) diamond on silicon, again using bias-enhanced nucleation, for some years now. these films often give a far smoother and more cohesive appearance than that belonging to the image reproduced in the Nature article. Silicon wafers are a reasonably cheap commodity these days, much more so than single crystal iridium, I'd suggest.