decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Oracle spouting more nonsense | 380 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Oracle spouting more nonsense
Authored by: clemenstimpler on Thursday, May 24 2012 @ 04:49 PM EDT
The JVM relies on BSF uncertainty: What a reference is depends on its being
observed by a lawyer.

[ Reply to This | Parent | # ]

Oracle spouting more nonsense
Authored by: PolR on Thursday, May 24 2012 @ 05:21 PM EDT
In patent law there is something called the doctrine of equivalents. In constructing the term "symbolic reference" courts are not obligated to follow the literal execution of the instruction. Of course they could decide the literal execution is the proper one. But they are free to choose otherwise.

[ Reply to This | Parent | # ]

Symbolic is ill defined, the 'name' is what matters.
Authored by: Anonymous on Thursday, May 24 2012 @ 08:51 PM EDT
See that dead horse? SEE IT? Let's flippin' BEAT IT!

This is compiler / interpretor level stuff.
Symbolic means as of or like a symbol.
Symbols are textual NAMES from source code, names of classes, interfaces,
functions / methods, variables, etc. The binary location on disk or in memory
of these things is referred to by a name for ease of use. NAMES. Another
common name for "symbolic reference" is "named reference".

The patent is supposed to be clear and concise to an individual ordinarily
skilled in the art of VMs, interpretors and compilers.

The definition given of "symbolic" that excludes numbers and mentions
names is precisely to exclude pointers, table indices, offsets, etc. As THESE DO
NOT REQUIRE RESOLVING.

"Resolving a symbol" to an individual ordinarily skilled in the art
means going into a symbol table and comparing the name you have with a list of
possible names, then getting the relative offset or index.

Once you have an offset or index to the binary location the name represents then
the SYMBOL HAS BEEN RESOLVED, the index or offset itself is a "Numeric
Reference", and is no longer symbolic.

The part that many people are tripping up over is that Oracle patented the wrong
thing, symbolic names in the instructions. They shouldn't have included that
part about being in the instructions, it doesn't flippin matter where the hell a
symbolic reference IS, you must resolve it before using it.

No bytecode or machinecode interpretor stores the actual names in the
instructions, they ALL store a pointer or index to the symbolic reference that
needs to be looked up.

However, all this symbolic crap is pointless. IMHO, Davlik DOES do symbolic
name resolution, and the patent probably meant to cover that particular symbolic
configuration where the bytecode held a numeric reference to the symbolic
reference which would be looked up... but the ignorant lawyer who filed the
patent goofed, so the patent is useless.

Despite that, even if they wouldn't have screwed up, and Davlik's numeric
reference to a symbolic reference was covered, it wouldn't matter at all because
of the requirement that the resolution be dynamically (at run time). The other
claims in the patent make it perfectly clear that they're talking about a
resolution happening while the program is actually running.

It would be furthest from ones mind, as an individual skilled in compilers and
interpretors, that this patent cover any static (non run time) symbolic
resolution.

Most people arguing over symbolic are ignorant that Oracle's partially right on
this point. They're retroactively trying to fix their patent to cover the
original intended scope of symbolic reference... which IMO, is wrong, but it's
understandable, not completely out in left field like some have suggested.

Now, before you can execute instructions that have symbolic elements (symbolic
references, or placeholders for symbolic references) you need to resolve the
symbolic reference.

You can either do the name resolution at install time, load time, or during run
time. If you do the resolution any time that the program itself is not being
executed, it's not a dynamic resolution (not at run time). All other resolution
types are called "static" because the reference (numeric or symbolic)
does not change during program execution.

C code with .DLL or .SO code does its symbol resolutions all at once when the
library is loaded, BEFORE any code within the .DLL or .SO is executed. The
patent is over running the .DLL and resolving the symbolic links as you go, so
it wouldn't cover C style "dynamic linking and loading", as some have
suggested it might -- These are NOT prior art IMO, but the multitude of VM
languages and Interpreted languages that use such a technique (Perl (including
its regular expression compiler), Lisp interpretors, all current JavaScript
interpretors), would be prior art or illustrate that the technique is obvious /
anticipated.

One other thing that people get tripped up over is the fact that after Davlik
has done all the symbol name resolutions, it keeps the symbol names in a big
table inside the data file (but not in the instructions). These are totally
unneeded from an execution perspective, you could delete them and the program
would run just fine (if the programmer new to avoid reflection...)

The reason for the symbolic names being in the file is because the objects'
names can be queried at run time. You can ask an object for a list of its
method names. You can then call a method or instantiate an object by name --
This DOES perform a dynamic symbolic name resolution at run time.

HOWEVER, it DOSE NOT write over any byte code afterward to "optimize"
the next call. It's a one-off method call or object instantiation that gets
looked up each time because the contents of the name (string) may be different
each time that set of compiled instructions is executed -- There's nothing to
save over.

The '501 patent is inapplicable. Open a text document and do a search and
replace manually -- That's not simulating a reading of the text and replacing
one meaning with another (what Java's patent is over), instead that's pattern
matching.

Eg:

The sky was so blue, the most beautiful azure I've ever seen.

Now, if you do simulation (understanding) of that sentence and I tell you to
replace any blue with "red" then you get this:

The sky was so red, the most beautiful red I've ever seen.
(this is what Java's '501 patent is over)

But, if you do a pattern match of that sentence and I tell you to replace
"blue" with "red" then you get this:

The sky was so red, the most beautiful azure I've ever seen.
(this is what Davlik does, and it misses ^ azure here)

Bottom line, Oracle is wrong, but most of the statements and arguments here
about the '104 patent are ridiculously ignorant of how it actually works; Saying
things like "Oracle spouting more nonsense" make you out to be a fool
-- Only a fool would make such strong statements about things they've no real
knowledge of.

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )