|
|
|
| Authored by: Anonymous on Thursday, May 17 2012 @ 11:41 PM EDT |
How much thought do you suppose went into the wording of the patent? From what
I know about patents, the goal is to make them as broad as possible by using
ambiguous words and phrases. That practice can come in useful if the patent
ever gets litigated (as we are now seeing).
The idea of patenting a "symbolic reference" is absurd.[ Reply to This | Parent | # ]
|
- Semantics - Authored by: Anonymous on Friday, May 18 2012 @ 12:48 AM EDT
- Semantics - Authored by: Anonymous on Friday, May 18 2012 @ 12:12 PM EDT
- Index units - Authored by: Anonymous on Friday, May 18 2012 @ 04:00 PM EDT
| |
| Authored by: Anonymous on Friday, May 18 2012 @ 12:54 AM EDT |
Oh, wise "over educated" computer scientist, please tell me more of
the false dichotomy of which you speak.
For, is it not true that BOTH Oracle's and Google's claims can be true at once?
I put it to you that one does not exclude the other.
Indeed, Oracle would like "numeric reference" to mean only one thing,
but by the very definition it should include all references that are numeric in
nature.
Wise sage, please illuminate my erroneous assumption and bring us peace by
dividing the one into two separate concepts -- The possibility of conjunction is
too much for my small self educated mind to bear.
[ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, May 18 2012 @ 02:55 AM EDT |
It isn't.
The reason is that the patent wouldn't have been issued for resolving numeric
references since every compiler does that anyway and has done since since
compilers were invented.
That's what Google failed to get across, Oracles patent is narrowly worded so
they could GET the patent issued in the first place - the slightest step out
side those bounds, no violation.
[ Reply to This | Parent | # ]
|
| |
| Authored by: csawtell on Friday, May 18 2012 @ 03:08 AM EDT |
The court may have to look beyond its poor definitions to resolve
this. Since the claim language limits the claim to "symbolic", and we
know that the alternative is "numeric", we must consider that the claim
limitation actually precludes some "non-symbolic" references. Being
that process on modern computers are inevitably sufficiently sandboxed to
preclude writing to "real" hardware memory addresses (unless you are
working
at the OS or kernel level), all "numeric" memory values are actually
symbolic
in one sense, in that they are re-mapped to physical memory
locations at some
other level of abstraction in the system. Hence Oracle can,
in a reasonable
sense, claim that Android's numeric references are "symbolic."
So if you
apply "symbolic" to include numeric indexes or numeric
registers, since these
aren't the "actual" hardware memory locations, then you
have in fact argued
that the term "symbolic" should be defined such that it
provides no limitation
on the scope of the claim. Any value could be
considered a symbolic
value. If we instead use Googles argument,
that numeric indexes are
non-symbolic in that they do not require a step to
"resolve" the symbol to a
numeric value, then we have a distinction that
actually limits the claim,
providing a difference between "symbolic" references
and those that are
non-
symbolic (numeric). Since this is the interpretation that legitimizes the
claim
limitation, it should be the proper one. ---
My ideas are my own - if you agree with me, does that make you a thief? [ Reply to This | Parent | # ]
|
| |
| Authored by: Chromatix on Friday, May 18 2012 @ 06:58 AM EDT |
Both Oracle and Google seem to have established that what is involved is, in
fact, indirect references to values, which before dexopt are
symbolic
and after dexopt are not. Where they differ is whether:
1) An indirect
reference to a symbolic reference is sufficient to consider the
symbolic
reference itself to be "inside" the instruction.
2) An indirect reference is
itself a form of symbolic reference.
Google, and most of the rest of the
tech community, are of the opinion that
neither is true, at least in the
context given.
The first point is arguable, but Google presented a pretty
compelling
argument that is easy for lay people to understand - the data
representing the
symbol that has to be searched for is in a completely
different location (in a
table in one of several non-executable data sections)
to the instruction
referencing it (which, obviously, is in an executable
section).
The second point is easy to disprove by appropriately defining
"symbolic
reference" as "a reference which has to be resolved by searching,
rather than
by (a series of) simple lookups". There are a number of different
methods of
searching, some more efficient than others, but it should be pretty
clear that
chasing a pointer a small, fixed number of times is not a
search.
So, to requote an example I gave earlier, suppose you have a
reference to a
verse in the Bible, which you want to look up in your electronic
copy. You
need to search in the list of book names to resolve the name of the
book (a
symbolic reference) into a direct reference to the correct book
(consisting of a
list of chapters, each of which is a list of strings that are
verses). After that
you can simply index to the chapter and then to the
verse.
You could define a data structure containing the name of the book and
the
chapter and verse numbers. A reference to this structure would be an
indirect
symbolic reference (the book lookup), with two-level post-indexing
(the
chapter and verse lookups).
You could also add a fourth field to that
data structure which contains the
index of the book (eg. for Genesis this would
be zero indicating the first
book, Exodus would be index 1, Relevations would
have the highest index
indicating the last book), obtained by searching the
list of book names. A
reference
to that structure, assuming it had already
been resolved, would now be a
triple-indexed indirect reference, with nothing
symbolic about it - the fact
that the symbol is still present is irrelevant,
since it is no longer used. Indeed
you could delete the symbol name and, if
you do need it later, use the book
index on the list of book names. [ Reply to This | Parent | # ]
|
| |
| Authored by: Gringo_ on Friday, May 18 2012 @ 09:17 AM EDT |
Obviously to we programmers, a "symbolic reference" is
not an index - they
are two very different things. However,
what a "symbolic reference" means to us
doesn't apply in the
instant case, because what meanings to apply to these
words
was already resolved by the parties involved. Now they need
to prove or
disprove their case using the definitions they
all agreed to, not what we think
these words means.
From Oracle's argument...
A
field index in a Dalvik bytecode
instruction meets the Court’s definition of
“symbolic
reference.” The Court construed the term “symbolic
reference” as “a
reference that identifies data by a name
other than the numeric memory location
of the data..."
So without actually going to the document
where the
agreed definitions are, we can take Oracle at its word here
as to
the definition that was agreed upon. A symbolic
reference is a reference that
identifies data by a name. Now
they didn't define "name", so that must take on
its ordinary
meaning. They also didn't define "field index" so index must
also
take on its ordinary meaning. Clearly a name is not an
index, and there is no
way the conventional view could
possibly equate a name with an index. A rose is
not a
petunia. Oracle has gone well beyond arguing a rose is a
petunia and is
saying a rose is a bicycle. [ Reply to This | Parent | # ]
|
| |
| Authored by: Anonymous on Friday, May 18 2012 @ 03:55 PM EDT |
I think the defining characteristic of the "numeric memory location" is that
it is sufficient to get the data. If the JVM's JITC's convention is to keep the
address of the current Object (called "this" in Java) in a register, then a
"numeric memory location" for this.xyz may well be an offset from the address in
that register.
By contrast, a symbolic reference is something that won't
get you to the data without looking up a name like "xyz" in some table
somewhere. [ Reply to This | Parent | # ]
|
|
|
|
|
