Mood:  accident prone

So let's get down to describing what you can do. Again, the two lines describing what Siteflash makes available to you.

These arbitrary objects may include encapsulated legacy data, legacy systems and custom programming logic from essentially any source in which they may reside. Any language supported by the host system, or anylanguage that can be interfaced to by the host system, can be used to generate an object within the application. (Column 2, lines 29-34, Exhibit A.)
* * *
Arbitrary objects can include text file pointers, binary file pointers, compiled executables, scripts, data base queries, shell commands, remote procedure calls, global variables, and local variables. (Column 3, lines 43-46, Exhibit

First, the necessary architectural structure that sets Siteflash apart from traditional systems. The ability to treat any code or data from anywhere as a universally usable software object all the way to higher level frameworks.

No wonder Microsoft and IBM both have patents citing this patent as prior art. Microsoft talks about automated model construction for testing of software to IBM's automated software factory. When you're able to treat abstract objects as easily connected components,  you are freed to build to fit the problem... not as a compromise between the platform allowances and the problem.

These arbitrary objects may include encapsulated legacy data, legacy systems and custom programming logic from essentially any source in which they may reside.
This means the system allows you to apply a layer of software over the existing data that allows the selected object to work with all other objects to be used in the Siteflash ecology. This also says the boundaries are essentially unlimited.

One may also assume, I would believe, one could encapsulate these parts of running applications and frameworks by which the applications and frameworks would be doing multiple duty for no additional effort. More about that idea later when we've dithered over whether objects or words are best for computerized tasks.

"legacy data, legacy systems and custom programming logic"
Both the data and the operational code in an existing system can be taken in pieces and redeployed across any platform needed.

"from essentially any source in which they may reside"
And that assembly process can proceed from the resource to the rest of the assembled application without the programmer requiring information about how to put the encapsulated body to use.

This effectively allows the SME (subject matter expert) to do the application building based on objects targeted for the SME's vertical and discipline. It removes the programmer as a middleman for the workflow and event management and puts more control into those who are experts in application look and feel. Look and feel has to do with friendliness and the undervalued likability aspect of any software.

All the requirements poured into selecting and mating library objects in program development now becomes a commodity rather than a requirement.

The GUI can be put in the hands of a designer while the SME does the workflow construction. Or the SME can do the GUI and farm the workflow construction out to multiple vendors for a component application fronted by the SME's interface. All multiple capabilities with lower skill requirements and life-cycle-wide ecological systems (that shows later in the discussion)  that make a Siteflash application a thogoroughly encapsulated and therefore another component in larger frameworks lorded over by a Siteflash governance framework.

These are the kinds of systems one can speak of as inherent results of the aspects and characteristics of the kind of operational architecture the patent claims.

All in my opinion and you have every opportunity to have those opinions double-checked by someone you know who knows technology.

the following added May 26, 2008

I want to focus on the same bits of VCSY claims construction as above but for a different purpose.

I'm putting this here as an edit to this post because I want to keep as much of this information physically correlated (my content [the text I write and present as references] is data constrained by format [being placed on this post with previously written text gives the content the form], giving format an ability to convey information [formed content]).

We'll probably return to the subject of form and content. Last year, an argument like this wouldn't be seen as important. This year and the years to come, the developments in web application development are going to illustrate broadly the differences between content, format and functionality and the importance in being able to manage all of them within one development ecology.

The discussion we'll have now will attempt to cover what you can encapsulate and how that encapsulation can be used.

These arbitrary objects may include encapsulated legacy data, legacy systems and custom programming logic from essentially any source in which they may reside. Any language supported by the host system, or anylanguage that can be interfaced to by the host system, can be used to generate an object within the application. (Column 2, lines 29-34, Exhibit A.)
* * *
Arbitrary objects can include text file pointers, binary file pointers, compiled executables, scripts, data base queries, shell commands, remote procedure calls, global variables, and local variables.

But I'll discuss this in the next post as soon as it's written. I'll point to it by embedding a link to the post in this word.

Posted by Portuno Diamo at 4:58 PM EDT

Updated: Monday, 26 May 2008 1:19 PM EDT

Share This Post

Post Comment | Permalink

Mood:  rushed

I left off in the previous post giving these lines from the VCSY claims construction for VCSY v MSFT on patent 6826744:

These arbitrary objects may include encapsulated legacy data, legacy systems and custom programming logic from essentially any source in which they may reside. Any language supported by the host system, or anylanguage that can be interfaced to by the host system, can be used to generate an object within the application. (Column 2, lines 29-34, Exhibit A.)
* * *
Arbitrary objects can include text file pointers, binary file pointers, compiled executables, scripts, data base queries, shell commands, remote procedure calls, global variables, and local variables. (Column 3, lines 43-46, Exhibit

And I asked, "What can you do with something like that?"

First, all applications or any web page or GUI (Graphic User Interface) must have data to work with. As has been said earlier, objects are a wonderful way to handle bodies of data as the data body (stored and referred to as a file on hardware) is considered an "object" or a virtual representation of the subject data body.

In order to use such objects in traditional IDE's like FrontPage or Visual Studio, the programmer was required to pay careful attention to the particular needs of each object as the object was being used in the application. This required library references and training manuals showing how each objects methods and properties should be used to add functionality to a developed application.

Siteflash claims to have done away with that requirement by providing an arbitrary use of any data body. This arbitrary use means the application builder no longer has to know anything more about the object than its name to employ that object in developed software.

As the patent claims construction brief says:
"Using arbitrary objects allows the independence and separation that is the central benefit of this invention."

Arbitration is the facility that enables a Siteflash user to encapsulate any body of data available on any supported platform and use that as construction material for new applications.

The traditional IDE (Integrated Development Environment) such as FrontPage or ColdFusion enables the user to use a variety of code platforms and libraries from which to build and integrate functionality. By no stretch of the imagination or claims do IDE's like FrontPage or ColdFusion provide and "arbitrary" capability in any data file types or sources. Certainly neither FrontPage nor ColdFusion can claim to build web applications using any fragment of functional code in an arbitrary fashion with any of a number of other code fragments from any other resources.

The central capability that enables this kind of use and facility is what the patent claims construction brief is pointing to. VCSY says Microsoft's response: disregards this critical intrinsic evidence and instead selectively collects self-serving specific examples and language to improperly import them into the claims.

In other words, they wish to ignore the meaning of the word "arbitrary" while claiming prior art performed the same functions... avoiding the subject of limits and constraints on prior art methods in treating all objects in the same way.

If they had accomplished these things already, we wouldn't be talking about how to bond various platforms together. That would have been done already.

This blog is open to any comment by someone who has a response to VCSY's use of the word arbitrary and the properties impact on code management. I've offered the same opportunity on Raging Bull and on Yahoo and on Programmersheaven. I make the same offer here.

I moderate the comments here ( if you want to hear me ragged out go to the Yahoo VCSY forum) but if you will post a comment on the technical contentions, I'll flag you straight through. Otherwise, you need to win me over with flattery.

I do ask the technologist to discuss the productivity and facility made available by the patent teachings as opposed to the productivity and facility limites showing in traditional methods.

As an example, VCSY continues in another blurb from the claims construction:
For instance, if a company would like to roll out a  new look or syndicate  its content and functionality to another business, this  can be  easily accomplished using the present invention. Since  there is no application  code resident in a web page itself, the same data can be  repackaged in a  number of different ways across multiple sites.

Notice two things:
1) "if a company would like to roll out a  new look or syndicate  its content and functionality to another business, this  can be  easily accomplished using the present invention."
Thus any perfected workflow in any vertical could be packaged and sold customized to the buyer's look, feel and functionality. 

2) "there is no application  code resident in a web page itself,"
This is in contrast to something FrontPage and ColdFusion would do by embedding script and binary functional code in the html pages, in effect mucking up the way the pages should best be handled as GUI components and not actual hosts to embedded application functionality. Any time such functionality had to be re-used in another web page, the various properties and methods, passed and returned parameters had to be accounted for by the programmer. In contrast, the Siteflash patent teaches no need to have to learn about the properties and methods, passed and returned parameters as you will only invoke the object by its name and the siteflash architecture absords, abstracts and arbitrates for you the necessary interconnection and interoperation capabilities.

Thus, the web page can be the GUI (built using any objects from any resources under any formatting regime) and the functionality can reside on the browser or on the desktop or on bare metal as application functionality. And the application development is further managed by the ecology, freeing the programmer to become a programming designer without further proprietary skills able to architect the application and framework with pieces and parts available anywhere the internet can reach.

That's the part I would think would give hedge funds a fit.

Heck. That's nothing.

Posted by Portuno Diamo at 4:17 PM EDT

Updated: Sunday, 25 May 2008 4:53 PM EDT

Share This Post

Post Comment | Permalink

Mood:  cool

So, when the patent describes the ability to construct applications using fragments of any code, the advance in the patent is the ability to provide the kind of arbitration facilities necessary to knit PIECES of programs of any kind into other applications. Thus, if you see specific capabilities in other applications and you want to combine them together into an integrated application, what part of Frontpage would you use?

Think about it now. I see fragments and modules of source code and I want to apply the functionalities represented by the code in my application. In Frontpage you have to rewrite the code to conform to your development platform to get it into the monolithic application. In SiteFlash, the development platform conforms to the code and absorbs the arbitrated code fragment into the integrated application.

ANY source code? That's what the brief is saying. It's the way I read it because I know what virtualization can accomplish. Arbitration CAN BE but is not always a result of virtualization. There must be a well articulated and granular ability to specify functionality across the entire project and across a single requirement case at the same time.

ANY source code? Or (I would assume) any binary file that can be run on bare metal... Why not? It's what VCSY is saying when they say "objects" may be anything data.

From the VCSY claims construction brief: 

An arbitrary object is simply a program piece that can be retrieved by using only its name.

Microsoft disregards this critical intrinsic evidence and instead selectively collects self-serving specific examples and language to improperly import them into the claims.

Microsoft needs to demonstrate it can provide the following list of data bodies as arbitrary objects to be used anywhere:

These arbitrary objects may include encapsulated legacy data, legacy systems and custom programming logic from essentially any source in which they may reside. Any language supported by the host system, or anylanguage that can be interfaced to by the host system, can be used to generate an object within the application. (Column 2, lines 29-34, Exhibit A.)
* * *
Arbitrary objects can include text file pointers, binary file pointers, compiled executables, scripts, data base queries, shell commands, remote procedure calls, global variables, and local variables. (Column 3, lines 43-46, Exhibit 

We'll cover what you can do if you're able to simply name any part, piece, fragment or whole of any data object including applications and use any combinations of a library of named objects as an integrated application including any content, any format specifications or executions, any functionality... all from any resource in any form.

What can you do with something like that?

Posted by Portuno Diamo at 1:42 PM EDT

Updated: Sunday, 25 May 2008 2:53 PM EDT

Share This Post

Post Comment | Permalink

Mood:  on fire

I promised I would discuss what we've seen so far from the VCSY patent claims construction brief to be reviewed by the court in VCSY v MSFT for patent infringement on 6826744.

So, here's a first shot based on what little we've seen so far. 

Many rightly argue “object-oriented” programming (OOP) was a fundamental improvement in the ability to build efficient applications. Describing the subjects of an application’s work as virtual objects allowed programmers to move from “linear code” to more modular ways of assembling representations of the real world.

This ability to describe a real “thing” in a virtual representation allowed programmers to simplify the application concepts into abstracts more easily recognized by non-programmers. Thus, OOP made the act of programming and maintaining the program code more manageable and efficient, while allowing others not skilled in programming a more easily understood view of the program construction and purposes.

The following article is an excellent explanation of object-orientation for the novice:

http://java.sun.com/docs/books/tutorial/java/concepts/object.html

The advantages of OOP over the “spaghetti code” derived from an earlier age of linear programming (having all functionality described within a single application body) are well known and acknowledged.

However, an ability to virtualize code in such a way as to remove knowledge requirements from the programming process means

the advantages derived by certain properties of OOP work may be further extended to build an even higher degree of abstraction with greater resulting efficiencies and capabilities.

In other words, the less you need to know about building something the more you can build while knowing less.

(from the tutorial:

Modularity: The source code for an  object can be written and maintained  independently of the source code for  other objects. Once created, an object  can be easily passed around inside the  system.

Information-hiding: By interacting only  with an object's methods, the details  of its internal implementation remain  hidden from the outside world.

Code re-use: If an object already  exists (perhaps written by another  software developer), you can use that  object in your program. This allows  specialists to implement/test/debug  complex, task-specific objects, which  you can then trust to run in your own  code.

Pluggability and debugging ease: If a  particular object turns out to be  problematic, you can simply remove it  from your application and plug in a  different object as its replacement.  This is analogous to fixing mechanical  problems in the real world. If a bolt  breaks, you replace it, not the entire  machine.

)

So, while the way in which software objects may be made and used may be difficult for the novice to understand, the advantages of object-orientation should be fairly easy to grasp.

The novice may ask "What if we are able to further stream-line the handling of objects in programming tasks? Will the four benefits of OOP itemized above return even greater advantages?"

The answer will be ‘yes’ if the amount of information hidden by the abstraction allows the programmer to know less about the object before it can be used. 

Having a system which is able to handle that information for the programmer brings modularity; the ability to combine the object with other objects without confusing the boundaries between the objects. Modularity brings “pluggability” and makes debugging and adaptation easier. Pluggable modularity allows for code re-use; the ability to use something written once to be used in many different ways without having to modify the object.

How can we improve on the OOP methods? Easy: Hide even more information. Hide the calling values. Hide the returning values. Hide the kind of information traditional OOP requires the programmer to find, learn, and employ without error. Hide it in the infrastructure of the system in which the application is being built.

In other words, allow the programmer to use the object by simply invoking the object’s name. The programmer should not be bothered with the various input and output information the object needs in traditional OOP. The system should be able to handle that information, thus, “arbitrating” the objects for a common use.

If the system can be tasked with accounting for all the values passed to the object by the application, and if the system can arbitrate the object behavior into acceptable performance with all other objects in the application body, the programmer will only need to know the name of the object to embed and actuate the object in the application.

I’ve posted a few gathered snippets from the VCSY brief filed for the claims construction process leading up to the Markman Hearing scheduled for early July 2008: https://ajaxamine.tripod.com/PortPot/index.blog/1814440/pieces/

VCSY’s lawyers say "A critical distinction between the present invention and previous object oriented development systems is the need to know how a function can be called and what to expect it to return, rather than just knowing the function's name." 

We focus here on “…the need to know how a function can be called and what to expect it to return…”

“the need to know how a function can be called”

Each object (an object may represent a kind of functionality as well as a kind of “thing”) has a wide variety of properties and methods necessary to make the object operate properly with other objects. The VCSY patent claims to be able to hide and manage all that information in background layers freeing the programmer to use only the name of the object (or function) to construct the application.

“…and what to expect it to return…”

Just as the traditional OOP programmer needs to be intimately and flawlessly familiar with the parameters to be inputted into the object (calling parameters to be passed from the application to the object), the OOP programmer also must know precisely what the object being used will return (returned parameters derived within the object function to be passed back to the application) after being called or invoked to perform.

With the VCSY 744 patent, these requirements go away. The system “knows” what the objects need in terms of input and output. The system provides for those needs, thus hiding that sort of information from view. The system thus “arbitrates” use of the objects for the programmer, freeing the programmer to select objects and use in an “arbitrary” fashion.

OK, so that’s what one phrase in the patent claims construction describes. “Arbitrary” is the word to be dissected in the claims context. Without paying attention to what that single word says in the patent language, you’re going to be left with a “so what?” attitude that’s showing in the various dismissals written by supposedly expert “programmers”.

They don’t realize the main reason for their skill-evolutions and employment is vanishing.

Where do we go with a system that can free programmers from having to know anything about the objects available in an object library? What can a “programmer” do with such a system? It all depends on what you think can be done with universally accessible virtual versions of “things”.

We will need to examine what kinds of “things” are available in a virtual form in software. Knowing this will tell us if we (with no programming experience or knowledge) would be empowered to build applications using arbitrary objects.

Would you?

Use your imagination. We’ll attempt to discover what “arbitrary” programming brings in the next post after you’ve had a chance to digest this first advantage. And, we’ll see if your imaginations are correct.

Posted by Portuno Diamo at 3:16 PM EDT

Updated: Friday, 23 May 2008 3:34 PM EDT

Share This Post

Post Comment | View Comments (1) | Permalink

Mood:  don't ask

There are all sorts of liars in the world but the worst liar is someone who takes your identity and uses it to discredit you.

That kind of person is capable of any kind of lying.

From the comments section of Microsoft-Watch
portuno diamo :

Posted by portuno diamo | May 21, 2008 10:25 AM

Posted by Portuno Diamo at 9:10 PM EDT

Updated: Wednesday, 21 May 2008 9:46 PM EDT

Share This Post

Post Comment | Permalink

What ever happened to Windows 7?

http://reddevnews.com/features/article.aspx?editorialsid=2478

I guess we won't know until they figure out how to build it.

Microsoft won't be able to build another one-size-fits-all operating system like Vista because Vista turned out not to fit anybody.

So, Microsoft's most likely track is to build Windows 7 as a modular component operating system... precisely the kind of operating system that runs somewhat like this:

Or, maybe not, depending on whether Microsoft has the intellectual property in house to be able to produce a micro-kernel (more than one if you're going to do a modular OS) like "mini-win".

Posted by Portuno Diamo at 6:09 PM EDT

Updated: Wednesday, 21 May 2008 9:09 PM EDT

Share This Post

Post Comment | Permalink

Mood:  chatty

And now some homework for the home schoolin' crowd.

Johnny, get your finger out of your nose.

Please take a bit to see what the "next generation" operating scenario will be (and is not "viable" now). This will be a focal point of a SiteFlash thought experiment I hope to use to demonstrate the simplicity of systems built using the 6826744 and 7076521 patent approaches.

As you can see, the industry took a very long time to come up with these realizations. The Emily/MLE whitepaper in 2000 was written in 1999.

We also will, hopefully, do another thought experiment looking at the pros, cons and value of doing things this way as opposed to the traditional software architectures available in the current monolithic operating system approach.

This excerpt describes an alternate operating system architecture. I believe, were you were able to press Microsoft on details about Windows 7 architecture, (it has to have been architected by now even if it's no more than a paper mache mockup - kind of like their "we own XML" campaign and demos up to 2004) you would find Windows 7 will be modular construction similar to the below article approach.

http://flex.sys-con.com/read/566399.htm

Now, having said all that, I’d like to take a closer look at the alternate approach to having virtualization placed within the operating system.  In this scenario, there is virtualization functionality that sits below the idea of today’s general purpose OS.  For those of you familiar with ESX Server, think of it that way - some sort of bare metal virtualization layer that controls the hardware. From there, a collection of VMs will cooperatively provide the various services that are today provided by the general purpose OS.  This idea is expressed in this article by Ron Oglesby (also linked to by this VMTN Blog entry as well).

In this approach, you might have a networking VM that is responsible for scanning inbound and outbound traffic, managing security policies, interacting with corporate networks and network access controls, etc. You can think of this as the “firewall” component of the general purpose OS (Windows Firewall on Windows, ipfw on Mac OS X, iptables on Linux), but more feature-rich and more isolated (the idea being that it is therefore more secure and harder to bypass or disable).  Likewise, you might have a VM designed specifically for running sensitive corporate applications, a VM for surfing the Internet, and a VM that provides anti-virus services to the other VMs.  Taken individually, none of these VMs could replace today’s general purpose OS; taken as a whole, the collection of VMs provides the services and functionality of a general purpose OS, but with greater isolation, encapsulation, and protection between these “service” VMs.

Is this a viable approach?  Not today, in my opinion, but certainly in the future.

This sort of thing is inherently possible using VCSY technology.

The bare metal "VM's" (Virtual Machines) can be played out by patent 7076521 and VCSY product XML Enabler Agent [most powerful of which is the IBM Data Collector with XML Bridge.]. In fact, the  VCSY MLE method places its own VM's as micro-kernel web servers (talking to local hardware in various ways down to machine language and talking TCP/IP over http as XML) - running on browsers, operating systems or bare metal.

That is granular virtualization. That is transactional virtualization.

In other words, the application doesn't need to know how to work with the document and the document doesn't need to know anything about the application. And yet the application and the document will work together using an agent to do the processing of an arbitrary output from the application rendered to the arbitrary input of the document.

It's the automating processor (the MLE - Markup Language Executive kernel - Emily is the XML dynamic programming language - dynamic from 1999) and the resources (operating code, storage, transactional audit chain and third party storage and maintenance, governance) available via web addresses that will perform the task of the traditional operating system, then, when not needed, disappear from the system to not burden memory or processing speed.

The MLE/Emily patent allows applying an arbitration layer on any legacy code or data, burying the mechanics of action, control, and transaction so only the process' name name is needed to invoke the associated process. Because each arbitrated interface fits the use requirements of the adopting or further arbitrating community... thus, universal use and fit and scaleable abstraction up to single word and complex phrase commands setting off chains of processes, each literally running concurrently on other machines. Because each arbitrated unit fit everywhere, it was accepted and worked with everywhere.

The SiteFlash patent provides this modular transactional/deterministic virtualization property that makes possible complex operating system framworks... today - since 1999. ResponseFlash will be one example of a tailored web based operating system molding the community operating resources into a next generation system.

The overarching coordination and orchestration of an operating framework (an assembly of various operating system functions performed by the VM's) is then architected / created / maintained / governed / decommissioned by facilities based on patent 6826744.

This assembly of diverse distributed agents (744) supervised by a community ecology (744) performs as a web-based operating system managing the resources for storage, processing power, information repositories available across URL's.

So each VM agent acts as a bare metal web-server on the local machine. Each agent is able to essentially provide off loaded processing and local processing to bear upon any situation the local machine is being asked to deliver.

This sort of operating system can grow or shrink in targeted facility and power, allowing a custom OS to be available for any scenerio. A "operating system" dedicated to each application is possible - and desirable. This provides maximum security as one application's vulnerability does not make things worse for any other application as each operating framework is private and applied only to the processing purpose.

Note the author writing about this method says this is not "viable" today... meaning the method exists, but it's not practical for anyone to put it into practice.

I thought the beauty of software was you created it from nothing and it can be banged out once and used anywhere? Why would folks NOT be making this viable already if they write software for a living?

Fascinating. I agree with the author. It's not "viable".

Posted by Portuno Diamo at 1:32 PM EDT

Updated: Sunday, 18 May 2008 9:14 PM EDT

Share This Post

Post Comment | Permalink

Mood:  bright

I will be taking the claims construction material (as poster intheend101 makes available on the Yahoo VCSY forum)  and leave excerpts from that here for a couple days (unless I feel very energetic) and let you think on the text.

Then I'll provide my interpretations and interpretation of what the claims construction says.

These are excerpts from the text in the previous post: 

And checkback at the edit date at the bottom of this post display. I may be adding excerpts to shepherd along the thinking exercises and you will be able to tell that if the edit timestamp is changed. Or, you can do an RSS subscription and you will get an update with every edit. Of course, all you may get is an update for a spelling correct. Diligence can be frustrating.

A critical distinction between the present invention and previous object oriented development systems is the need to know how a function can be called and what to expect it to return, rather than just knowing the function's name.  

An arbitrary object is simply a program piece that can be retrieved by using only its name.

Microsoft disregards this critical intrinsic evidence and instead selectively collects self-serving specific examples and language to improperly import them into the claims.

The specification includes a large number of examples, descriptions, and words of inclusion for “arbitrary objects:” Those examples include the following:

These arbitrary objects may include encapsulated legacy data, legacy systems and custom programming logic from essentially any source in which they may reside. Any language supported by the host system, or anylanguage that can be interfaced to by the host system, can be used to generate an object within the application. (Column 2, lines 29-34, Exhibit A.)
* * *
Arbitrary objects can include text file pointers, binary file pointers, compiled executables, scripts, data base queries, shell commands, remote procedure calls, global variables, and local variables.

Using arbitrary objects allows the independence and separation that is the central benefit of this invention.

For instance, if a company would like to roll out a  new look or syndicate  its content and functionality to another business, this  can be  easily accomplished using the present invention. Since  there is no application  code resident in a web page itself, the same data can be  repackaged in a  number of different ways across multiple sites.

Posted by Portuno Diamo at 2:25 AM EDT

Updated: Sunday, 18 May 2008 10:42 AM EDT

Share This Post

Post Comment | Permalink

Mood:  celebratory

As intheend101 makes available excerpts from the VCSY claims construction, I'll add things here, then begin picking off areas to expand on:

http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_V/threadview?m=tm&bn=33693&tid=4403&mid=4403&tof=2&frt=1

VCSY claim construction brief filed     16-May-08 07:42 pm    
200+ pages. Too much to post. Thought this excerpt was interesting..
____________________________________________

The part of the specification that provides a definition for “arbitrary object” is the following:
Many functions are stored within an object library on an arbitrary object framework such that those functions can be accessed by name arbitrarily.

This is in contrast to a traditional model where the function must be explicitly invoked with all its parameters included. (Column 5, lines 42-46, Exhibit A.)
* * *
A critical distinction between the present invention and previous object oriented development systems is the need to know how a function can be called and what to expect it to return, rather than just knowing the function's name. This means that typically the system administrator calls the name of an object and passes parameters to the object. Any and all variable information or environmental information can be available to every object.

The environment space can be available to all objects executed and an object can arbitrarily take advantage of any of the environmental information, depending on the design of the object. (Emphasis added. Column 5, line 62 to column 6, line 5, Exhibit A.)

The ‘744 patent thus provides a clear distinction between the invention that it describes and claims and the prior art; and in the process provides a definition for “arbitrary objects.”

An arbitrary object is simply a program piece that can be retrieved by using only its name.

Microsoft disregards this critical intrinsic evidence and instead selectively collects self-serving specific examples and language to improperly import them into the claims.

The specification includes a large number of examples, descriptions, and words of inclusion for “arbitrary objects:” Those examples include the following:

These arbitrary objects may include encapsulated legacy data, legacy systems and custom programming logic from essentially any source in which they may reside. Any language supported by the host system, or anylanguage that can be interfaced to by the host system, can be used to generate an object within the application. (Column 2, lines 29-34, Exhibit A.)
* * *
Arbitrary objects can include text file pointers, binary file pointers, compiled executables, scripts, data base queries, shell commands, remote procedure calls, global variables, and local variables. (Column 3, lines 43-46, Exhibit 

http://messages.finance.yahoo.com/Stocks_%28A_to_Z%29/Stocks_V/threadview?m=tm&bn=33693&tid=4403&mid=4428&tof=1&frt=1
Re: VCSY claim construction brief filed     17-May-08 11:33 am     Interesting...

Vertical submits that the following two sections of the specification compel adoption of its definition:
More specifically, the present invention provides a method for generating software applications in an arbitrary object framework. The method of the present invention separates content, form, and function of the computer application so that each may be accessed or modified independently.
(Column 2, lines 9-14, Exhibit A.)
* * *
The present invention provides an important technical advantage in that content, form, and function are separated from each other in the generation of the software application. Therefore, changes in design or content do not require the intervention of a programmer. This advantage decreases the time needed to change various aspects of the software application. (Column 2, lines 19-25, Exhibit A.)

The prosecution history also includes these statements in highlighting the benefits of the invention. Using arbitrary objects allows the independence and separation that is the central benefit of this invention. Therefore, the only meaning can be Vertical’s construction.

The invention of the ‘744 patent includes creating and using arbitrary objects which enables the separation of form, content and function. But, the invention does not compel this separation every time. Neither the ‘744 patent nor its prosecution history requires that the method perform this separation all the time. In fact, quite the contrary, the large number of descriptions for arbitrary objects make certain that an arbitrary object can contain these three components separately or in any combination. Thus, Microsoft’s definition and its “Disavowal” statement do not find any support in the internal record or elsewhere. 

From an email source:

For instance, if a company would like to roll out a  new look or syndicate  its content and functionality to another business, this  can be  easily accomplished using the present invention. Since  there is no application  code resident in a web page itself, the same data can be  repackaged in a  number of different ways across multiple sites. [Emphasis  added.] The examiner of the '744 patent did just that when  comparing the claims with  the prior art in an office action dated April 3,  2003

( would be interested in knowing if any other references to that April 3, 2003 event are available)

Posted by Portuno Diamo at 11:13 PM EDT

Updated: Saturday, 17 May 2008 5:16 PM EDT

Share This Post

Post Comment | Permalink

An article by Phil Wainewright at http://blogs.zdnet.com/SAAS/?p=522

When you understand what Wainewright is saying here, you will understand why the old paradigm technologies will be scrapped in due time.

Posted by Portuno Diamo at 3:48 PM EDT

Updated: Friday, 16 May 2008 4:06 PM EDT

Share This Post

Post Comment | Permalink