Make your own free website on
Blog Tools
Edit your Blog
Build a Blog
View Profile
« November 2011 »
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30
You are not logged in. Log in
Entries by Topic
All topics  «
Apple Fritters
Chinadotcom and VCSY
DD to da RR
Microsoft and VCSY
Nobody Can Be That Stupid
Notable Opinions
Off the Wall Speculation
Pervasive Computing
The Sneaky Runarounds
VCSY / Baseline
VCSY / Bashed
VCSY / Infotech
VCSY / MLE (Emily)
VCSY / NOW Solutions
VCSY - A Laughing Place #2
Saturday, 19 November 2011
A big pile of do for those who pooh.
Mood:  bright
Now Playing: "Planet of the Aped" Mad scientist antagonizes crazy monkeys (brief anxieties)
Topic: Notable Opinions

From Case3:10-cv-04645-RS Document76 Filed11/14/11

Interwoven Claim Construction

page 9

Interwoven: Data, including information, photographs, illustrations, and articles, that appears in the computer application or on the web site, which is not form or functionality.
Vertical: Data, including information, photographs, illustrations, articles.

Interwoven: Structured format or appearance of the computer application or web site, which is not content or functionality.
Vertical: Formatting including graphic designs, user interfaces, graphical representations.

Interwoven: Software code that implements logical functionality within the computer application or web site, which is not form or content.
Vertical: Software code.

Again we see Interwoven attempting to use the concept "must" (absolute requirement) when any common sense reader will come to the conclusion Vertical says "may" (available option).

"Vertical’s proposed construction contradicts the record, which prohibits any combination of content, form, and functionality"

Interwoven wants the reader to believe since Vertical is so fired up on keeping content, form and functionality separate the patent intended to preclude any operation that might combine content and form, content and functionality, form and functionality. It's quite easy to thumb through the patent language and see references to the combination of these data object types into compound objects of content/form, form/functionality, content/functionalty which are additionally kept separate as their own composite object qualities i.e. formatted content, content functionality as is practiced by traditional object use. Again relying on previous methods used in a novel patentable way does not preclude use of the previous methods as an available option in use of the method. This is the accepted current ruling per "negative limitations".

Interwoven is desperate to have the court see the case as "must" because Interwoven has been practicing the art of compositing object structure for automating content management (combining objects of content, form and functionality) just as Autonomy has been practicing the art of compositing applications (combining objects of content, form and functionality). We don't know in what manner they've been doing this sort of compositing but it's obvious they haven't presented anything showing they do not use the methods claimed by Vertical's patents.

Therefore, if the judge fails to see things Interwoven's way, there is a cascade effect in all of Interwoven/Autonomy's work that puts everything they've done for the past decade in jeopardy.

That is the impetus for the trick Interwoven is attempting to use to confuse the judge. It's really that simple. But apparently Niro went and stuck a broomstick in Interwoven's spokes so Interwoven is riding into the December 14 Markman hearing with an already damaged steering position.

Now we know Interwoven is going to have to argue the Markman with Vertical's "may" position in place. If the judge does not take up the motion earlier than the January 12 data proposed by Interwoven, Vertical's language will be the dominant position when the Markman hearing is held December 12. But, even if the judge takes the matter before that, the common sense approach and therefore not negatively limited is Vertical's treatment.

(continued on next post)

(continued from previous post)
The separation of content, form and functionality has been a key controversy throughout software industry history. On one hand, information theory teaches maintaining a separation of each of these quality/type data entities is a more elegant, efficient and productive way of working. On the other hand, human developers continually point to work experience showing the separation of these data entities is not possible.

The 744/629 patent teaches not only is the theory correct but the achievement of the theory is possible by making use of architecture and language designed primarily for the purpose of maintaining an arbitrary use throughout the workflow. As is typical in human work development, an advance seen and declared as impossible as a human employment becomes possible once a machine is designed to accomplish the purpose.

Interwoven is here basing their case on two ideas:

1) Vertical describes their patent as maintaining the separation of content, form and functionality, therefore, there can be no discussion of combined content, form and/or functionality anywhere in Vertical's consideration.

2) Vertical's patent enables separation of content, form and functionality, therefore, a user of Vertical's patent can not combine content, form or functionality.

Yes it's a flimsy position but it's really all Interwoven has. The prior art concepts were hashed out quite thoroughly as 744 was first granted in 2004 and the 629 continuance was granted in 2010 after a de-facto full review of 744.


So now we get into the concepts embodied in the terms Content, Form and Functionality.

page 12-13
2. Content

Interwoven provides a self contradicting claim:
"The patent specification consistently describes "content" as data appearing in a web site or computer application."

"In contrast, Vertical’s proposed construction is improper, as it merely substitutes "data" for "content".


But Interwoven just said in their opening statement to "2. Content":
"The patent specification consistently describes "content" as data..."

Duhhhh. If Interwoven describes "content" as "data" then who are we (or they) to argue?

Next issue:

"The term "data", used in its ordinary sense without limitation, could have nonsensical meanings in the context of the ’744 and ’629 patents. It might even include the
machine-level 1’s and 0’s that define all information stored in a computer."

Content may be any data as that data (including the 1's and 0's representing the binary code in a computer) may need to be seen and considered by human and/or machine for information purposes. Are we to prevent a human from seeing binary code simply because it appears nonsensical to Interwoven to look at something like that?

This: 0101 * 0100 = 10100 is very informative to a student of computer information. 0001 + 0001 = 0010 informs someone skilled in even the most basic computing art. These are data represented to the human (you) as "content". These are therefore "content" in this container which happens to be called a document (swhich started life in a notepad container and ends up in a web post container).

Are we to then strike the consideration of thousands of lines of information already in textbooks presenting such "nonsensical meanings" as content? Interwoven would have it that way.

(continued on next post)

(continued from previous post)
Interwoven continues: "This sense of the generic word "data" defies the teachings of the patent specification, because the purported point of the claimed invention is to "separate" content so that writers, photographers, and editors can access it independently without having to deal with computer-level data. ’744 patent col.1 l.21-22, col.2 l.22-23."

But I just showed what "computer-level data" can just as easily be considered by "writers, photographers, and editors".

Interwoven continues:
"Plainly, "data" alone may also refer to "a new look" or "functionality" based on the specification, both of which are independent from content."

The art of demonstrating correctness lies in being able to use your opponents paradigm to explain your own argument. Thus:

"data" in a computer comes in binary form. We humans "abstract" data into data types just as we abstract data into data entities also called data objects. The purpose of human use of machines as a quality multiplier dictates that the human understanding supercedes the more base and non-abstracted machine terminology.

At first glance, as all information can be considered "data" by the machine, Interwoven's adoption of the human programmer paradigm would appear to be correct by saying "everything is data so there is no separation possible".

But the machine is not in control of the language. The human is. And the human chooses to qualify and therefore categorize the raw treatment of data into three particular useful sets to reach a realistic (not dumbed down) language construct:

1) data as data: information as contained and available for consumption from its most raw state to its most transformed processed result.

2) data as data about data: information qualifying the contained information from its most basic containment as raw content to it's most refined presentation as formatted content.

3) data that transforms data and/or data about data and/or data that transforms etcetera (see the code can achieve?): information instructing the machine (and the human capable of reading the machine instructions) to perform tasks intended to transform the data and/or data about data AND/OR data that transforms data, data about data and data that transforms.

Words work because they express being, perception and action and any abstraction must first result from those three qualities.

We can abstract the above 1,2,3 discussion to the following terms to stand in for the above:

1) data (from Latin L. datum meaning "(thing) given") = It is what it is.

2) metadata (from Greek meta (preposition) "in the midst of, in common with, by means of, in pursuit or quest of,") = It can be what we want it do be.

3) code (Latin codex, earlier caudex "book, book of laws," lit. "tree trunk,") = It will be what we make it do be.

These three abstractions are closer to machine descriptions than human. So we continue to abstract the terms upward to human understanding as follows:

1) content (Latin contentus "contained, satisfied,") It is.

2) form (Latin forma "form, contour, figure, shape; appearance, looks' model, pattern, design; sort, kind condition,") It appears.

3) functionality (Latin functionem (nom. functio) "performance, execution," noun of action from functus, pp. of fungi "perform, execute, discharge,") It does.

PS You might want to print all this out to stick on your refrigerator so you can be reminded lawyers only play with words. Real people make them live.


Little Ol' Insufferable Me

(continued on next post)

(continued from previous post)

Discussion about data beyond those three sets is so far pointless as no-one has shown a viable state beyond those three.

Who knows - if we continue to kick this particular dead horse long enough it may rise up as a fourth state of data. That happened with the possible states of matter - why not abstract thought?

Now that we have two sets of experiments saying objects can travel faster than light (albeit only a few kilometers per hour but who's quibbling with the speed limit, right?) we humans may be shown a state of data previously unconsidered.

Perhaps it will be our machines who will teach us this new state. But until then data comes in three forms (there. I said it.): content, form and functionality.

Interwoven is going to have a terrible time attempting to restrict the idea of data as being only one thing everywhere. But that thinking is central to the traditional programmer's declaration throughout software history that separation of content, form and functionality is not possible no matter how advantageous information theory says it would be... and that's where Interwoven wants the court to camp.

Fortunately the USPTO is tasked to analyze invention and innovation and therefore sees things beyond a human limitation as considerations and tasks achieved by machine.

Onward and upward:


page 13-14
3. Form

"Vertical contends incorrectly that Interwoven is importing specific examples from the specification. VOB, at 13. Though the Federal Circuit warns against wholesale importation of "very specific embodiments", it also approves of interpreting limitations to the extent they match definitions that persons of ordinary skill in the art might assign to the claims."

Since we see a lack of such in Interwoven and/or their representation, we need to consider what Interwoven means by "skill".

As I showed earlier the "skill" embodied in the typical software architects and software developers throughout software industry history up to the publication of the 744 patent application has taught them that separation of content, form and functionality is a desirable theoretical position but can not be achieved in human hands.

So Interwoven would have us believe that, although Interwoven agrees Vertical has achieved separation of content, form and functionality and insists it must be used everywhere, architect and programmer ignorance of such a capability over history equates to "skill" used by Interwoven to lampoon Vertical's brief.

"Further, Interwoven’s proposed construction is not limited to one specific example in the specification; confirming citations are replete throughout."

Explaining something in a dumbed down way over and over, as Interwoven does, does not make it smart.

(continued on next post)

(continued from previous post)
page 14-15
4. Functionality

"Vertical’s proposed construction substituting "software code" for "functionality" is inconsistent with the prosecution history and is overly broad. For example, in order to overcome a cited reference, Vertical stressed that "Ferrel merely describes a system
that achieves only one ‘function,’ if at all specifically, to present (publish or print) the structured content using the forms. There is no other function described in Ferrel, and the forms and structured content are integrated to only serve this one purpose.""

A "function" is a single operational capability. "Functionality" is a set of functions and Interwoven knows that as evidenced by their attempt to play fast and loose with the words they just quoted:

"If “function” truly meant something as broad as “software code,” there would necessarily have been more to Ferrel than this purpose of presenting structured content using the forms." page 14 line 24 and page 15 lines 1 and 2

So did the passage Interwoven cites say "function = software code"? Noooooo. Vertical was pointing out a single "function" does NOT equate to functionality and therefore does not qualify as "software code"... and that's precisely what Interwoven "accidentally" said at line 24.

It's this kind of quick handed playing with what's said that plagues Interwoven's brief. I would suggest a team of lawyers who thinks sneaking under a "good faith negotiation" to file first indicates a team of lawyers who will try every trick they can to get their way.

Interwoven concludes the paragraph on page 15 by saying: ""the logical functionality of software code" is a subset of functionality."

I don't see that in that phrase, do you? What I do see is "functionality of software code" meaning functionality is a subset of software code. If you read it the way Interwoven wants you to see it as you have to conclude: "functionality (primary subject of the phrase) is a subset of functionality"???? Duhhh....

"Moreover, the entire patent is about "software." Arbitrary objects and the object library all comprise software code."

While an arbitrary object (the thing) may be "software" and the object library (the structure) may be "software, neither of them are "code" meaning the thing does nothing by itself and the structure does nothing by itself. The "software code" works on all other "software". "WORKS" being the operative quality of "code".

Again Interwoven wants the dumbed down "skill" of traditional programming to take precedence declaring data is nothing but data. I agree everything is data but as I've shown language must qualify and quantify and not fall at the feet of those too unskilled to parse and debate.
(continued on next post)

(continued from previous post)
"Arbitrary objects and the object library all comprise software code."

"software" is a nebulous term describing "data". The issue here is not data nor is it about data about data. It is about data that transforms both data and data about data. It is about data used in a way traditional users have seen for decades but failed to recognize in the novel way the 744/629 patents have: data as code in its own right as an object. Yes it's been used that way - just as steam was used by Heron to make a toy spin around. But the inventiveness of others superceded the millenia of ignorance to build steam engines. Many have used the wheel. But only a few first understood the wheel as more than a means of conveyence and presented the wheel as a way to power conveyence.

All data is "soft" "ware". We've already seen language about computing is abstracted from most rudimentary considerations (as would be seen by a machine should that machine be able to "think") to more useful language for human discussion and specification.

Saying something like "all data is software" and therefore "all software is code" compounds Interwoven's painfully obvious effort to cloud the court's understanding and play word games with a judicial consideration of the issues.

"Vertical’s proposed construction of "functionality" as merely "software code" prevents the separation of "content" and "form" from "functionality.""

Interwoven obviously doesn't understand the difference between "being" and "doing". Two entirely different states. Content and form "be". Functionality "does".

Content sits and just is. Content in raw form may or may not be available to the human or to the machine in an understandable manner but that doesn't change the fact that data as content exists.

Form is a description of content. Form is information that may be used (by code) to transform the raw content into a way understood by human and/or machine. Without function acting on the form the content does not get presented in the desired way.

Functionality is the act of "doing. Functionality uses information provided by form to transform available content.

Content is a state of being. Form is a state of representing. Functionality is a state of doing.

Pretending to not know such distinctions does not reflect well upon a team of lawyers who are supposed to know the difference between "fact", "appearance" and "argument".

Oh boy we're about to go into the mental gymnastics of "B. Arbitrary Object Framework". Working up a good sweat here. I can hardly wait.

(end post) 




"B. Arbitrary Object Framework"

"This term is indefinite. To the extent that this term may be given any meaning, Interwoven proposes the following construction: A hierarchical structure of arbitrary objects, within which the arbitrary objects of various object types are created by the user based on individual preference, managed in an object library, and deployed into a design framework to generate a computer application or deployed into a container page to create a web site."

"A hierarchical system that can separate content, form and functionality to generate a product, and facilitates creation of arbitrary objects, management of arbitrary objects, and deployment of arbitrary objects."

page 16

Interwoven says: "The first problem with construction is one of functional definition; the patents contain multiple instances of the term "arbitrary object framework", yet never explain what it is or how it serves the purposes or functions described. For example, it supposedly "allows arbitrary objects to be referenced in a consistent manner""

I think Interwoven is forcing itself to appear rational here because the patent plainly states the arbitrary quality of the object is held by the fact the programmer need only know the name of the arbitrary object. The traditional world of software objects knows quite well invocation of an object requires enumerated parameters and the sequence of parameter invocation be known in order to successfully use the objects.

When you can access and employ software objects by only knowing the object name... when the system itself relieves you from having to know the number, type and/or sequence of parameters to be supplied by the invoking software statements... just how much more consistently can objects be referenced?

So ONE operational requirement declared by the patent is all that is needed to demonstrate the novel productive quality of the arbitrary object. How many different ways does one need to say knowing "only the name of the object is required"?

Interwoven says: "These statements describe tasks the "arbitrary object framework" can do but not how it can accomplish them. They fail to provide requisite notice of claim boundaries. But the law requires claims to "delineate the scope of the invention using language that adequately notifies the public of the patentee’s right to exclude.""

BUT "Interwoven does not submit that a claim term must be defined in non-functional terms." "Vertical’s proposed construction only exacerbates the vagueness of this term by merely echoing other limitations."

Apparently the Interwoven lawyers know nothing about using software objects to build applications. AND Interwoven continues to couch Vertical's terms of usefulness as "limitations" which we've covered earlier sections with Vertical pointing out these are negative limitation assertions which are disallowed.

Vertical describes operational treatment to traditional objects to render them as arbitrary objects which is what Interwoven says is a permitted way to describe and make plain claims. But at the same time Interwoven wants to portray Vertical's language as limiting... again attempting to pass along to the court as unseen negative limitation.
    Interwoven says: "These statements describe tasks the "arbitrary object framework" can do but not how it can accomplish them."

The plain and simple operation of arbitrary objects makes elaborate explanation unnecessary beyond descibing the simplified operation.

Manual sweeping: "Broom must be applied against unclean portion of floor forcing dust and dirt into manageable and disposable collections by use of user's arms and body positions and actions.
Arbitrary sweeping: "Broom applies itself against unclean portion of floor forcing dust and dirt into manageable and disposable collections."

Is anyone here too stupid to recognize the advantage and operation? Don't understand how it's done? Look at the diagrams and read the supporting information. These are CLAIMS and simple claims are self describing.

As additional support, VCSY has operational examples of their arbitrary object framework claims which can plainly demonstrate how the operational qualities can be achieved. Interwoven fails to acknowledge those examples because considering the examples demonstrate the arbitrary qualities are NOT limiting but are enhancing.

"Interwoven does not submit that a claim term must be defined in non-functional terms." but that's precisely the thrust of their complaint which they redundantly supply.

Interwoven says: "A second problem of construction is definiteness, which depends on whether claim terms can be given a reasonable meaning by a person of ordinary skill in the art. See Datamize, 417 F.3d at 1347. No reasonable meaning can be given to the term "arbitrary object framework" because of the lack of common definition in the art and the inventor’s failure to fulfill his duties as lexicographer.10"

Vertical says the "arbitrary" term could just as well have been "intelligent". The term itself is a semantic tag to convey the automation qualities of the system in relieving the programmer from the traditional manual expertise required in using traditional objects. There need be no more definition than that to describe such an elegant and simplified requirement.

This is tiresome. Methinks they doth protest too much.

Interwoven attempts to couch "separates content, form, and function" is a support of the arbitrary claim but that is incorrect. The ability to separate content, form, and function is an additional claim which provides something traditional manual programming has failed to accomplish since software objects were invented.

Interwoven says: "But just as one would not expect to find fur coats at a "rain coat sale", one should not expect to find anything but arbitrary objects in an "arbitrary object framework."

That might be true in an old world (and purposely disingenuous) scenario perhaps. But were a fur coat to be treated to make it rain proof it would be perfectly at home in a rain coat sale. This is befitting a novel treatment and the added value that treatment gives.

But does that preclude wearing the same fur coat to a posh soirée? Of course not! The idea of a novel treatment is that treatment enhances the use of the original objects while maintaining the traditional object qualities as well. We call this "backward compatibility" and it is the hallmark of proper software use design... but Interwoven refuses to acknowledge how it should be provided by VCSY's patented system. Thus Interwoven is clearly applying negative limitations in their attempt to deny VCSY claims as valid.
page 18 lines 12-22 show Interwoven attempting to limit the discussion to manual tasks rather than VCSY's claims showing the system claims do the tasks in lieu and instead of required manual operation.

page 19

"C. that separates a content of said computer application, a form of said computer application and a functionality of said computer application"

"In which the content, form, and functionality of said computer application are kept apart and distinct from each other, so that each may be accessed or modified independently.
Prosecution history disavowal: Content, form, and functionality of said computer application or web site are kept apart and distinct from each other."

"The ability to independently modify Content, Form and Function Objects."

Interwoven's contention here: "The preamble term "that separates a content of said computer application" is a limitation to the claim rather than merely a statement of its purpose." is a further continuation of Interwoven's disingenuous feigned ignorance of the importance of the ability to handle objects without being forced to know and handle the required object parameters and their further requirements.

Interwoven's various references to USPTO examiner prosecution throughout their brief is a weak tactic attempting to re-argue the same ground the examiner covered both in the first prosecution toward the 744 grant and a subsequent re-examination leading to the grant of the 629 continuance. Interwoven attempts to suggest the examiner must have forgotten the material of his objections which were successfully argued by Vertical. I wonder if the judge will be so easily fooled.

Interwoven: "The Federal Circuit found that an applicant under these circumstances cannot avoid the limiting effect of the very language that the applicant relied on to obtain issuance of its patent."

Interwoven continues to attempt to apply negative limitations. When an argument during prosecution in favor of a further enhancement beyond the described prior art limitations raised by the examiner achieves a successful argument by the patentee such language is no longer a description of patent claim limitations but is an underscored description of traditional limitations.

"Interwoven’s proposed construction is in line with the intrinsic record, which requires the separation of content, form, and functionality."

The "arbitrary" quality applied to the objects by the system does not REQUIRE the separation of content, form, and functionality. The arbitrary quality applied to objects allows a further enhancement applied to objects by providing for the quality of separation of content, form, and functionality.

Nuff said.
page 21 "D. Arbitrary Objects"

Interwoven: "Discrete entity accessed by its corresponding arbitrary name, created by the user based on individual preference, used to generate the form, the functionality, and the content of said computer application or web site, that are interchangeable and referenced in a consistent manner within the arbitrary object framework."

Vertical: "An object that can be created independently by individual preference and that can be optionally accessed solely by name, the object being an entity that can have form, content or functionality or any combination of form, content and functionality"

Interwoven: "Vertical’s construction (i) fails to recognize that "arbitrary objects" must be discrete and interchangeable in the context of the "present invention" and (ii) attempts to recapture the idea of an "object" being "any combination of form, content, and functionality," which Vertical repeatedly disclaimed during prosecution."

Again more disingenuous obfuscation of positive enhancement by the claims which Interwoven is attempting to turn into negative limitation.

Interwoven's case gets weaker by the word.

page 22 "1. The Intrinsic Record Requires Arbitrary Objects to Be Interchangeable
and Be Referenced in a Consistent Manner"

I'm going to skip for now sections 1, 2, and 3 on pages 22, 24, and 25 to allow all the previous study to sink in. Interwoven is using a veiled twist to the actual intent of the VCSY patent language to attempt to say VCSY has been inconsistent in describing what the arbitrary framework does and MUST do rather than Vertical's intended MAY meaning. This is the reason for the conflict suggested in Interwoven's motion to strike a large portion of Verticals claim definition and brief.

Interwoven apparently fails to realize their subsequent writings end up nulling their contentions, so I'm going to move on to the discussion on Object amd Design terms in the next post then come back to "1. The Intrinsic Record Requires Arbitrary Objects to Be Interchangeable and Be Referenced in a Consistent Manner", "2. The Claimed Invention Defines Arbitrary Objects as Discrete Entities", and "3. Arbitrary Objects Need to Be Accessed by Their Corresponding Arbitrary Names" just before Vertical files their response November 27.

Why am I writing all this? In order to educate VCSY longs who don't have the time, energy or experience to look at complex issues in this patent language so they can do proper DD and inform themselves using publicly available documents from the web... because I'm just a free wheeling modern kind of guy.
 Interwoven: "As usual, Vertical’s proposed construction would also fail to bring any clarity to the term. Merely shifting the words "design" and "framework" around would not help clarify the true scope of this term."

(A "framework" is a metaphor to describe work around a software construct derived from the practice of building scaffolding around a building upon which workers stand and move in order to perform the work necessary to build or renovate a building (whether that building exists at the time of the scaffolding built or not). Naturally the first and primary elements in the use of that scaffolding will be those concentrated in the implementation of a design of the building. Such a framework is thus a design framework first then a construction framework and thereafter an inspection framework.)

(Interwoven's attempt to confine the concept of "Design Framework" in the patent language to only such activities limited to the deployment of "arbitrary objects" is typical of the myopic attitudes tempting those faced with a disruption of their traditional work paradigms. Such attitudes can be traced to the attempt to restrict entry into specialized skills such as bricklayers and [comparatively] programmers who contrive guilds and attempt to restrict access to the frameworks necessary around any work to only those workers belonging to their guild. The idea of masons being a highly regarded profession essential to the building trades withered in time due to the advances of materials and methods applied to the existing prior state art. Programmers face the same assault by advancement typical of the teachings of 744/629. Denying those teachings does not make a mason irreplaceable. Denying only shows how out of touch such a mason has become from the art skills supposedly learned and practiced.)

(Today the guild of masons is a rarely seen but still existing closet of men who cleave to ancient ideas and mumbled incantations - secrets which deny the expansion of knowledge and work to those not educated in the clique. The fact masons were once necessary to building great cathedrals a long time ago does not enforce itself onto the mind of modern builders. They remain an artifact of a time before invention made their specialized knowledge and skilled tasks unnecessary. I do not desire to insult masons. I desire to insult programmers who covet codifying the manual nature of software construction and attempt to delay or deny the advancement of techniques that may be used by anyone in a subject matter discipline other than programming.)

(The use of hidden languages and secret signs such as Interwoven attempts to promote in this brief demonstrates the mindset that prevented "persons skilled" in the software arts in the 1990's from seeing the potential and desired impact of the advances embodied in 744/629 at the time of development of these patented claims.)

(The 744/629 patent advancements teach an extension of programming capabilities to people not necessarily educated in the ways of programming. It also opens the way for machines to employ the advancements toward autonomous handling and building of software applications. This does not preclude its use by manual programmers any more than the invention of the motorcycle prevented those who wish to pedal from dropping the engine off and replacing it with pedals.)
page 28

"H. Container Page"
Interwoven: "A web page that can logically contain arbitrary objects, into which arbitrary objects are deployed from the object library."

Vertical: "A web page that includes object(s).

Interwoven: "For this final term, the primary dispute is again the same as the previous three, and the reasoning is similar. Interwoven’s proposed construction finds ample textual support. Everywhere the term "container page" appears in the patent, it is encumbered with the same qualifiers that Interwoven has placed in its proposed construction: "arbitrary object" and "deploying arbitrary objects from said object library." See id. at col.4 l.15-20, 55-56, claims 26, 43, 52 (with dependent claims 43 and 52 deriving from the wording of claim 26). Vertical’s attempt to expand the scope of this term suffers from the same faults as its other misguided attempts: it fails to capture limitations that are recorded throughout the patent specification and claims, and further fails to bring clarity to the term."

(The most bare and obvious of Interwoven's attempt to apply negative limitation to the patent terms. While the intent appears to saturate the court with the view that "arbitrary" aka "advanced" prevents this patent from being used in conjunction with any existing "non-advanced" entities, I think this last attempt is nothing more than a dull pop coming from the last bullet drawn a soaked ammunition pouch. If Interwoven had been able to argue the patents do not provide an advancement of the state of the software arts, I would have been stymied from seeing the negative limitation attempt... more appropriately, the attempt would not have been necessary in the first place. But since, the final declaration relies on seeing the patent language as a limitation rather than an advancement, I have to conclude Interwoven saw the Microsoft brief's attempts to paint the term "arbitrary" as a term too broad to apply to software objects as unsuccessful - thus they had to go to the other extreme and paint the term "arbitrary" as a term too limiting.)

(Preliminary Conclusion: The weakness of their argument shows up in the conclusion on page 28. Had they a real argument to press, this is where the whole of their argument should be enveloped and presented in a parcel. But this is more a bag of flaming poop than a debate. Interwoven is ringing the doorbell of a court that will have disdain and ridicule for such a contrived assault. I have to conclude Interwoven intended this case to be decided by dullards and nincompoops. The attempt at manipulating the language is so obvious here I would say the lawyers who prepared this case are young and of the sort of talent level employed to post on financial message boards. They certainly do not see [or are paid to not see - a hireling must do the client's bidding] the advances embodied in automating the process of building and handling objects. Microsoft's brief was actually more substantial, although it suffered from the same delusion that a court can be impressed by language skills in lieu of language meaning. This brief is pathetic.)

So now we go back to the three areas I held back to drive the final nail. I will also continue on the discussion of prior art presented in pages 5-7. We are waiting now for Vertical's response to this document to be filed November 27.


Posted by Portuno Diamo at 8:52 PM EST
Updated: Wednesday, 23 November 2011 2:37 AM EST
Post Comment | Permalink

View Latest Entries