Who needs another social network?

Here is an excerpt from Miguel Helft's April 25th blog article in Bits - The New York Times.

When it comes to becoming a force in social networks, Google and Yahoo have tried and largely failed .... So now Google and Yahoo are taking another tack — turning themselves into social sites without building a social network.

What does that mean? It means that Yahoo [and Google] will attempt to bring the kinds of features that are common on Facebook and MySpace to its own sites. Users may be able to share photos, videos, news reading habits or calendars with their friends and receive alerts about what friends are up to ....

For the complete article go to Who needs another social network? 

US Patent 6,493,719: Method and system for scripting for system management information (Microsoft Corporation)

Title: Method and system for scripting for system management information
Patent Number: US Patent 6,493,719
Issued: December 10, 2002
Filed: July 26, 1999
Parent case: n/a
Inventor(s): Booth, Roger W. et al
Assignee: Microsoft Corporation
Referenced at issuance: US Patent 6,101,509 (Apple Computer Inc.), US Patent 6,151,610 (Digital Equipment Corporation), and US Patent 6,188,401 (Microsoft Corporation)
Distinguished after issuance from: US Patent 6,671,696 (Pardalis Inc.)
Blogger comment: 

There were 12 prior US patents referenced at issuance, including US Patent 6,101,509, US Patent 6,151,610, and US Patent 6,188,401, with the remaining 9 deemed unremarkable for the scope and purposes of this blog. 

An advanced search at USPTO online on May 9, 2008 for references to this patent using ref/6493719 reveals 12 references. A more refined search reveals US Patent 6,671,696, referenced above.

Abstract:

A method and system that simplify the management of enterprise network devices and information through the use of scripts and a scripting object model. An application programming interface (API) is provided that transforms scripts passed from a scripting engine into the existing "low-level" Component Object Model (COM) syntax required for accessing system management object information. A scripting engine interprets a script and works with the API to translate script instructions into the COM method calls needed to directly access properties and methods of Common Information Model Object Manager (CIMOM) objects from a script.

Independent claims (as numbered):

1. A method for providing access to system information via a centralized manager of the system information, comprising: receiving information corresponding to at least one script instruction from a client process, the information directed to an object and property corresponding to a managed system device; locating an object identifier in response to the received information; generating a property identifier in response to the information, including adding information to the property identifier indicative of a dynamic property; returning the object identifier and the property identifier; receiving a request for accessing system information, the request corresponding to the script and including the object identifier and the property identifier; recognizing from the information added to the property identifier that the request is directed to accessing a dynamic property of a managed system device, translating the request into at least one call for accessing the system information, and via the at least one call, calling an interface of the centralized manager to access the system information; in response to each call, the centralized manager determining at least one provider associated with the managed system device and communicating with each provider to access the system information; and returning data to the client process indicative of the result of the call.

12. A computer-readable medium including computer-readable instructions, comprising: receiving at least one call from a scripting engine that is interpreting a script, the at least one call providing a first identifier corresponding to a managed object that represents a managed system device and a second identifier corresponding to a dynamic property of the managed object; determining a managed object identifier based on the first identifier; determining a property identifier based on the second identifier; associating the property identifier with information that indicates that the property of the managed object is dynamic; returning the object identifier and the property identifier to the scripting engine; receiving an invoke call from the scripting engine, the invoke call including the object identifier and property identifier; recognizing that the property is dynamic from the information associated with the property identifier; accessing system information from the managed system device by providing translated data corresponding to the object identifier and property identifier to a centralized manager, the centralized manager determining at least one provider of data for the dynamic property based on the translated data and communicating with each provider to access the system information; and returning an access result to the scripting engine.

25. A system for accessing system information managed by a centralized manager of the system information, the centralized manager arranged for communication via a se t of object interfaces, comprising: a scripting engine configured to interpret a script; an interface component connected to the scripting engine, the scripting engine providing at least one request to the interface component to obtain a property identifier of a property of a managed system object that represents a managed system device corresponding to the system information, the request originating in the script; a mechanism in the interface component that returns an object identifier and the property identifier corresponding to the at least one request to the scripting engine; and the interface component accessing the system information including: 1) receiving the object identifier and the property identifier from the scripting engine in an access request from the scripting engine that originated in the script, 2) recognizing that the access request is directed to a dynamic property of the managed system object, and 3) accessing the property of the managed system object based on the object identifier and the property identifier by providing a translated request to an object interface of the centralized manager, the centralized manager determining a provider therefrom that is associated with the system device corresponding to the managed system object and communicating with the provider to access the system information.

34. In a computing environment, a method comprising: receiving a script instruction set corresponding to at least one script instruction from a client process, the script instruction set including a first request for an object identifier of a managed system object, and a second request for a value of a property of the managed system object; and processing the script instruction set to satisfy the first and second requests, including: 1) determining that the first request for an object identifier is a request for static data, 2) obtaining the object identifier, 3) determining that the second request is a request for dynamic property data of an object, and 4) accessing the dynamic property data via a centralized manager of a managed system device corresponding to the dynamic property data, including translating the second request into a format understood by the centralized manager.

Key Drawing(s):

"FIG. 8 [below] represents the principal objects and their relationships within the WBEM [Web-based Enterprise Management] Scripting Object Model 90, wherein the boxes within the diagram represent objects in the scripting model 90. The Event Sink, Locator, NamedValueSet, Service, Last Error, CIM Object and Object Path objects represent objects which can be created directly by the scripting API 74. Note that the Locator object is created using conventional methods for creating coclasses, while the other objects can be created using Moniker display names, described below. Further, note that the SWbemNamedValueSet, SWbemObjectPath, SWbemLastError and SWbemSink objects are also coclasses and accordingly may be directly created. The NamedValueSet, CIM Object Collection, Privilege Collection, Property Collection, Qualifier Collection and Method Collection objects represent Automation Collection objects. In FIG. 8, an arrow from one object (e.g., the Locator Object) to another object (e.g., the Service Object) indicates that the object (the Locator object) can obtain the other object (the Service object) from a call to that object (the Locator object) via the Scripting API 74 relationship ...."

[Original image modified for size and/or readability]"Note that the NamedValueSet object is immutable, but can be cloned to provide a mutable copy. Further, note that when the SWbemObjectPath is returned as the Path_ property of a SWbemObject, the above Read-Write properties marked (.dagger-dbl.) become Read-Only. Read-only means that the Property cannot be set, but methods can be called on the collection which will modify the contents thereof. Also, the term DEFAULT is applied to a property or method to indicate that it is the "Dispatch Default" property/method on an automation object. This means that the property name can be omitted, e.g., the following VBScript fragment "WScript.Echo MyObjectPath" where MyObjectPath is an Object Path object, would output the value of the Path property of an Object Path.

The Security_ property allows security attributes to be associated with an SWbemObjectPath, whereby scriptwriters may build object paths containing Privilege override information without requiring the scriptwriters to know how to build strings from scratch. Note that this property does not affect the runtime security behavior of the SWbemObjectPath of which it is a member, but is there solely to allow security information to be specified easily when defining a path. Further, note that when the SWbemObjectPath is returned as the Path_ property of an SWbemObject, the Security_ property of the object path is immutable. This is consistent with the immutability of the Path_ property value currently enforced by the scripting API 74."

US Patent 6,438,560: Reuse of immutable objects during object creation (IBM Corporation)

Title: Reuse of immutable objects during object creation
Patent Number: US Patent 6,438,560
Issued: August 20, 2002
Filed: September 16, 1999
Parent case:
Inventor(s): Loen, Larry Wayne
Assignee: IBM Corporation
Referenced at issuance: US Patent 5,724,588 (Microsoft Corporation)Φ
Distinguished after issuance from: US Patent 6,671,696 (Pardalis Inc.) and US Patent 7,136,869 (Pardalis Inc.)
Blogger comment(s): 

There were 6 prior US patents referenced at issuance, including US Patent 5,724,588, of which the remaining 5 are unremarkable for the scope and purposes of this blog. There were also 2 foreign patent documents referenced at issuance; however, until such time as I have time to review them, no comment is made.

An advanced search at USPTO online on May 9, 2008 for references to this patent using ref/6438560 reveals 10 references. A more refined search reveals US Patent 7,136,869 and US Patent 6,671,696, referenced above.

Abstract:

An apparatus, program product, and method of processing a request to create an immutable object reuse of an existing immutable object in appropriate circumstances to represent redundant data without the necessity for creating an additional immutable object.

Independent claims (as numbered):

1. A method of processing a request to create an immutable object, the method comprising: (a) determining whether a matching immutable object exists having redundant content with respect to the requested immutable object; (b) if a matching immutable object exists, returning a reference to the matching immutable object as a response to the request; and (c) if no matching immutable object exists, creating a new object and returning a reference to the new object as the response to the request;

wherein determining whether a matching immutable object exists includes accessing an immutable object data structure that identifies at least one existing immutable object, and wherein creating the new object further includes storing an identifier for the new object in the immutable object data structure.

8. A method of accessing data from a database, the method comprising: (a) generating a result set in response to a database query; (b) retrieving data from the result set, including: (i) generating a request for an immutable object in the result set; (ii) determining whether a matching immutable object exists having redundant content with respect to the requested immutable object; (iii) if a matching immutable object exists, returning a reference to the matching immutable object as a response to the request; and (iv) if no matching immutable object exists, creating a new object and returning a reference to the new object as the response to the request;

wherein retrieving data from the result set further includes generating a get string request to retrieve a field from a database record in the result set to retrieve a reference to an immutable string object and retrieving the contents of the requested field.

10. A method of accessing data from a database, the method comprising: (a) generating a result set in response to a database query; (b) retrieving data from the result set, including: (i) generating a request for an immutable object in the result set; (ii) determining whether a matching immutable object exists having redundant content with respect to the requested immutable object; (iii) if a matching immutable object exists, returning a reference to the matching immutable object as a response to the request; and (iv) if no matching immutable object exists, creating a new object and returning a reference to the new object as the response to the request; (c) tracking a performance characteristic associated with successfully locating matching immutable objects over a plurality of iterations of creating immutable objects; and (d) inhibiting determining whether a matching immutable object exists in response to the performance characteristic matching a predetermined state.

11. An apparatus, comprising: (a) a memory; and (b) a program, resident in the memory, the program configured to determine, in response to a request to create an immutable object, whether a matching immutable object exists having redundant content with respect to the requested immutable object, and if so, to return a reference to the matching immutable object as a response to the request, wherein the program is further configured to create a new object and return a reference to the new object as the response to the request if no matching immutable object exists, and wherein the program is further configured to determine whether a matching immutable object exists by accessing an immutable object data structure that identifies at least one existing immutable object, and, during creation of a new object, to store an identifier for the new object in the immutable object data structure.

13. An apparatus, comprising: (a) a memory; and (b) a program, resident in the memory, the program configured to determine, in response to a request to create an immutable object, whether a matching immutable object exists having redundant content with respect to the requested immutable object, and if so, to return a reference to the matching immutable object as a response to the request, wherein the program is further configured to track a performance characteristic associated with successfully locating matching immutable objects over a plurality of iterations of creating immutable objects, and to inhibit determination of whether a matching immutable object exists in response to the performance characteristic matching a predetermined state.

15. An apparatus, comprising: (a) a memory; and (b) a program, resident in the memory, the program configured to determine, in response to a request to create an immutable object, whether a matching immutable object exists having redundant content with respect to the requested immutable object, and if so, to return a reference to the matching immutable object as a response to the request, wherein the request to create an immutable object is generated in response to an attempt to access data from a result set generated in response to a database query, and wherein the requested immutable object is a string object representing a field from a database record in the result set.

16. A program product, comprising: (a) a program configured to determine, in response to a request to create an immutable object, whether a matching immutable object exists having redundant content with respect to the requested immutable object, and if so, to return a reference to the matching immutable object as a response to the request, wherein the program is further configured to create a new object and return a reference to the new object as the response to the request if no matching immutable object exists, and wherein the program is further configured to determine whether a matching immutable object exists by accessing an immutable object data structure that identifies at least one existing immutable object, and, during creation of a new object, to store an identifier for the new object in the immutable object data structure; and (b) a signal bearing media bearing the program.

Key Drawing(s):

[Original image modified for size and/or readability] "Immutable object reuse may be implemented in a number of programming applications. For example, as shown in FIG. 3, one representative generic create object routine, called in response to a request to create a new object, is illustrated at 50. Such a request may be an explicit request by a specific program instruction in a computer program. In the alternative, however, such a request may be an inherent component of a particular request, e.g., a request to retrive a field from a record in a result set from a database."

"Routine 50 begins in block 52 by determining first whether the object is immutable. Such a determination may be based upon a particular field or flag defined for the object, or by analyzing the context in which an object is created. In other instances, however, an object of a particular class type may be inherently immutable, with the create object routine utilized to create such an object being specific to that particular class type. As such, in some implementations block 52 may be omitted, it being understood that the object requested to be created must be previously known to be of an immutable type."
"If the object is not mutable, a conventional object creation operation is performed by passing control to a construct new object lock 54. Construction of a new object includes both allocating storage for the object and initializing the object with the requested information. Once the new object is being constructed, control passes to block 56 to return a reference to the new object as the result of routine 50."

"Returning to block 52, if the object is determined to be immutable, control passes to block 58 to search for an existing immutable object having redundant content with respect to the requested object, typically by determining if the respective contents of an existing and requested object are the same. It will be appreciated that performing such a search will vary depending upon the particular storage data structure in which immutable objects are stored. Furthermore, the comparison of contents may vary depending upon the particular data type representing the contents of an object."

"Typically, all of the contents must match between an existing object and an object to be created before a successful (found) result is returned. However, in some instances it may be possible for only a particular data field within a more complex immutable object to be reused, without necessarily reusing the entire object. "

"Control next passes to block 60 to determine whether the search for an existing immutable object with the same content was successful. If not, control passes to block 54 to construct a new object and return a reference to the new object, representing the conventional creation of an object."

"However, if a matching immutable object has been found, block 60 passes control to block 62 to simply return a reference to the existing object that was found in response to the search. As a result, the calling object or routine will receive a reference to the existing object that can be utilized in essentially the same manner as a newly constructed object would be utilized were a new object created."

"In addition, as represented at block 64, in some implementations it may also be desirable to selectively enable or disable the immutable object reuse function to optimize the performance of routine 50 based upon the perceived redundancy of data accessed by the routine. In such instances, rather than passing control from block 52 to block 58 upon determining that an object to be created is immutable, control instead would pass first to block 64, which, based upon whether the reuse function was enabled, would pass control either to block 58 or block 54."

"As one example of a situation where selective enablement would be desirable, consider that in any database, some information is usually more redundant than other information. In a database of customer records containing fields with state, city, street, last name, first name, etc., for example, the state information would likely be highly redundant, while other information, e.g., the first name information, would likely be less redundant. In the latter instance, the overhead associated with searching for existing immutable objects might in actuality decrease performance due to a relatively low rate of success in attempting to locate matching immutable objects. As such, it may be desirable in some implementations to track the performance of the immutable object reuse function and selectively enable or disable the function based upon the tracked results."

US Patent 5,724,588: Method and system for network marshalling of interface pointers for remote procedure calls - Part II (Microsoft Corporation)

Title: Method and system for network marshalling of interface pointers for remote procedure calls (Part II)
Patent Number: US Patent 5,724,588
Issued: March 3, 1998
Filed: June 7, 1995
Parent case: This application is a continuation of U.S. patent application Ser. No. 08/158,627, filed Nov. 29, 1993, now US Patent 5,511,197 (Microsoft Corporation)Φ.
Inventor(s): Hill, Richard D. et al.
Assignee: Microsoft Corporation
Distinguished after issuance from: US Patent 6,438,560 (IBM Corporation) Φ, US Patent 6,671,696 (Pardalis Inc.) and US Patent 7,136,869 (Pardalis Inc.)
Blogger comment: 

There were 12 prior US patents referenced at issuance, none of which are remarkable for the scope and purposes of this blog.

An advanced search at USPTO online on April 23, 2008 for references to this patent using ref/5724588 reveals 119 references. A more refined search of the claims of these referenced patents reveals hits for US Patent 6,438,560, US Patent 6,671,696 and US Patent 7,136,869.

Abstract:

A computer method and system for passing a pointer to an interface from a server process to a client process.

Independent claims (as numbered):

1. A method in a computer system for providing a client with access to a client implementation of an interface corresponding to a server implementation of the interface provided by a server, comprising:

under control of the server, sending to the client an indication of unmarshalling code and information for use by the unmarshalling code to provide the client implementation of the interface that corresponds to the server implementation of the interface; and

under control of the client,

receiving the indication of the unmarshalling code and the information; and

executing the indicated unmarshalling code to generate a pointer to the client implementation of the interface in accordance with the received information

whereby the client uses the generated pointer to access the client implementation of the interface.

3. The method of claim 1 wherein the interface has a function member that provides a behavior, wherein the server implementation of the interface has associated state information and wherein the sending of information to the client includes the state information, and including

under control of the client,

using the generated pointer to invoke the function member of the client implementation of the interface wherein the invoked function member accesses the received state information to provide the behavior of the function member without requesting that the server invoke the function member of the server implementation of the interface.

4. The method of claim 3 wherein the state information is immutable information.

11. A computer system for providing a client with access to a client interface through which the client accesses a server, comprising:

server means for sending to the client an indication of unmarshalling code and information for use by the unmarshalling code to provide the client interface; and

client means for receiving the indication of the unmarshalling code and the information, and executing the indicated unmarshalling code to generate a pointer to the client interface in accordance with the received information whereby the client uses the generated pointer to access the server through the client interface.

16. A method in a computer system for unmarshalling a pointer to a server interface sent from a server to a client, the server interface for providing a service to the client, comprising:

receiving an indication of unmarshalling code and information describing the server interface of the server;

locating the unmarshalling code indicated by the received indication;

executing the located unmarshalling code to generate a pointer to a client interface; and

using the generated pointer to invoke a function member of the client interface wherein the invoked function member provides the service to the client using the information describing the server interface.

19. A method in a computer system for custom marshalling of a pointer to an object from a server to a client, the object having data members and function members comprising:

instantiating the object;

determining whether custom marshalling code is provided for the object;

when it is determined that custom marshalling code is provided, executing custom marshalling code to provide an indication of custom unmarshalling code and information describing the object to the custom unmarshalling code; and

when it is determined that custom marshalling code is not provided, executing standard marshalling code to provide an indication of standard unmarshalling code and information describing the object to the standard unmarshalling code; and

sending the provided indication and information to the client so that the client can execute the indicated unmarshalling code to provide a custom or standard proxy object through which to request services of the instantiated object.

23. A method in a comptuer system for marshalling a pointer to an interface from a first server to a client, the pointer pointing to an interface of the first server that is marshalled from a second server, the interface having a function member providing a behavior, wherein the client, the first server, and the second server each have an implementation of the function member, wherein the implementation of the function member of the first server requests the implementation of the function member of the second server to perform the behavior of the function member, comprising:

under control of the first server, sending to the client an indication of unmarshalling code and information indicating the second server; and

under control of the client,

receiving the indication of the unmarshalling code and the information; and

executing the indicated unmarshalling code to generate a pointer to an interface with a client implementation of the function member that when invoked requests the second server to provide the behavior

whereby when the client implementation of the function member is invoked, then the client requests the second server to perform the behavior without requesting the first server to perform the behavior.

24. A computer-readable medium containing instructions for causing a computer system to provide a client with access to a client implementation of an interface corresponding to a server implementation of the interface provided by a server by:

under control of the server, sending to the client an indication of unmarshalling code and information for use by the unmarshalling code to provide the client implementation of the interface that corresponds to the server implementation of the interface; and

under control of the client,

receiving the indication of the unmarshalling code and the information; and

executing the indicated unmarshalling code to generate a pointer to the client implementation of the interface in accordance with the received information.

26. The computer-readable medium of claim 24 wherein the interface has a function member that provides a behavior, wherein the server implementation of the interface has associated state information and wherein the sending of information to the client includes the state information, and including

under control of the client,

using the generated pointer to invoke the function member of the client implementation of the interface wherein the invoked function member accesses the received state information to provide the behavior of the function member without requesting that the server invoke the function member of the server implementation of the interface.

27. The computer-readable medium of claim 26 wherein the state information is immutable information.

34. A computer-readable medium containing instructions for causing a computer system to marshal a pointer to an object from a server to a client, the object having data members and function members by:

instantiating the object;

determining whether the custom marshalling code is provided for the object;

when it is determined that custom marshalling code is provided, executing custom marshalling code to provide an indication of custom unmarshalling code and information describing the object to the custom unmarshalling code; and

when it is determined that custom marshalling code is not provided, executing standard marshalling code to provide an indication of standard unmarshalling code and information describing the object to the standard unmarshalling code; and

sending the provided indication and information to the client so that the client can execute the indicated unmarshalling code to provide a custom or standard proxy object through which to request services of the instantiated object.

Key Drawings(s):

"FIG. 13 [below] is a block diagram illustrating custom marshalling with shared memory. In certain situations, an object may store its data members in memory that is shared across processes to avoid the overhead of remote procedure calling to access the data members. In FIG. 13, the data 1302 for cell object 1301 is stored in shared memory. Cell object 1303 is created when a pointer to cell object 1301 is marshalled and sent from process P1 to process P2. The custom methods of the IMarshal interface for a cell object are implemented by the following pseudocode.

void IMarshal::MarshalInterface (pstm, iid, pInterface, DestContext)
     { if(DestContext = Shared) then
          { Marshal (pstm, address of data);}
     else
          { MakeStub ("Cell", iid, pInterface, &MessageAddress);
          Marshal (pstm, MessageAddress)};
     }
void IMarshal::GetUnmarshalClass (iid, pInterface, DestContext, cid)
     { if (DestContext = Shared)
          {cid = "Cell"}
     else
          {cid = "CellProxy"}
     }
void IMarshal::UnMarshalInterface (pstm, iid, pInterface);
     { UnMarshal (pstm, address of data);
      initialize object to point to shared data
     }

The parameter DestContext of the method IMarshal::MarshalInterface indicates whether the data of the cell object is stored in shared memory. If the data is not stored in shared memory, then the equivalent of the standard marshalling is performed. If, however, the data is stored in shared memory, then the address of the shared data is marshalled into the message. The method IMarshal::GetUnmarshalClass determines the unmarshal class based on whether the data is in shared memory. If the data is not in shared memory, then the CellProxy class is the unmarshal class. If the data is in shared memory, then the Cell class is the unmarshal class. The unmarshal class and address of the shared data are sent to process P2. After process P2 instantiates the cell object 1303, the process P2 invokes the custom method IMarshal::UnMarshalInterface, which unmarshals the address of the shared data and initializes the object to point to the data."

[Original image modified for size and/or readability]"Custom marshalling can be used to provide more efficient access to immutable objects. An immutable object is an object whose data members (state) cannot be changed. When an interface pointer to an immutable object is passed from one process to another, custom marshalling can be used to make a copy of the object in the other process. Thus, when the other process accesses the object, it accesses the local copy and no interprocess communication is needed. To allow copying of immutable objects, the methods of the IMarshal interface of the immutable objects are implemented in the following way. In a preferred embodiment, the method IMarshal::GetUnMarshallClass specifies that the unmarshal class is the same class as the class of the immutable object. This ensures that the same type of object is instantiated by the other process. The method IMarshal::MarshalInterface stores the data members of the immutable object into a message for passing to the other process. The method IMarshal::MarshalInterface creates no stub. When the other process receives the message, the other process creates an object of the class of the immutable object. The method IMarshal::UnMarshalInterface then retrieves the data members from the message and initializes the newly-created object. The other process can then access the immutable object."

US Patent 5,511,197: Method and system for network marshalling of interface pointers for remote procedure calls - Part I (Microsoft Corporation)

Title: Method and system for network marshalling of interface pointers for remote procedure calls (Part I)
Patent Number: US Patent 5,511,197
Issued: April 23, 1996
Filed: November 29, 1993
Parent case: Abandoned. However the subject patent is the parent to US Patent 5,724,588 (Microsoft Corporation) Φ.
Inventor(s): Hill, Richard D. et al.
Assignee: Microsoft Corporation
Distinguished after issuance from: US Patent 6,671,696 (Pardalis Inc.)
Blogger comment(s): 

There were 7 prior US patents referenced at issuance, and 1 foreign patent document, none of which are remarkable for the scope and purposes of this blog. 

An advanced search at USPTO online on May 9, 2008 for references to this patent using ref/5511197 reveals 176 references. A more refined search reveals US Patent 6,671,696. 

Abstract:

A computer method and system for passing a pointer to an interface from a server process to a client process.

Independent claims (as numbered):

1. A method in a computer system network for passing a pointer to an interface of an object from a server process in one node of the network to a client process in another node of the network to enable the client process to invoke function members of the interface, the method comprising the steps of:

within the server process,

instantiating the object, the object having an implementation of the interface, the interface having a function member;

creating an interface stub for receiving a request to invoke the function member of the interface and for invoking the requested function member upon receiving the request;

creating a stub channel for receiving the request to invoke the function member of the interface and for forwarding the request to the created interface stub; and

sending an identifier of the stub channel to the client process via network communications; and

within the client process,

receiving the identifier of the stub channel from the server process;

creating an interface proxy for receiving the request to invoke a function member of the interface and for sending the request to a proxy channel;

obtaining a pointer to the created interface proxy; and

creating the proxy channel for receiving the request from the created interface proxy and sending the request to the stub channel identified by the received identifier,

whereby the client process may use the pointer to the interface proxy to invoke the function member of the interface of the object instantiated within the server process.

7. A method in a computer system for passing a pointer to an interface of an object from a server process to a client process to enable the client process to invoke function members of the interface, the method comprising the steps of:

within the server process,

instantiating the object, the object having a plurality of interfaces, each interface having a function member;

identifying an interface of the object to pass to the client process;

creating a stub for receiving a request to invoke the function member of the identified interface and for invoking the function member upon receiving the request, the stub having an identifier; and

sending the identifier of the stub to the client process; and

within the client process,

receiving the identifier of the stub from the server process;

instantiating a proxy object for receiving requests to invoke a function member of the interface and for sending the request to the identified stub; and

obtaining a pointer to the instantiated proxy object,

whereby the client process may use the pointer to the interface proxy to invoke the function member of the interface of the object instantiated within the server process.

13. A method in a computer system for passing a pointer to an interface of an object from a server process to a client process to enable the client process to invoke function members of the interface, the method comprising the steps of:

within the server process,

instantiating the object, the object having a plurality of interfaces, each interface having a function member, the object further having a marshalling function member for performing object-specific marshalling for a pointer to one of the plurality of interfaces;

identifying an interface of the object to pass to the client process;

invoking the marshalling function member of the object to marshal the identified interface; and

sending to the client process a reference to the object instantiated within the server process and an unmarshal class identifier identifying the class of the proxy object to be instantiated by the client process; and

within the client process,

receiving from the server process the reference to the object instantiated within the server process and the unmarshal class identifier;

instantiating an object of the class identified by the unmarshal class identifier, the object of the class identified by the unmarshal class identifier having an unmarshalling function member;

obtaining a pointer to the object of the class identified by the unmarshal class identifier: and

invoking the unmarshalling function member of the object of the class identified by the unmarshal class identifier using the obtained pointer and passing the reference to the object instantiated within the server proxy, the unmarshalling function member for performing object-specific unmarshalling for the pointer to the identified interface,

whereby the client process may use the pointer to the object of the class identified by the unmarshal class identifier to invoke a function member of the identified interface of the object instantiated within the server process.

19. A method in a computer system of passing a pointer to an object from a server process to a client process to enable the client process to invoke function members of the object, the method comprising the steps of:

within the server process,

instantiating the object;

creating a stub for receiving a request to invoke a function member of the object and for invoking the requested function member upon receiving the request, the stub having an identifier; and

sending an unmarshal class identifier identifying the class of a proxy object to instantiate within the client process and the identifier of the stub to the client process; and

within the client process,

receiving the unmarshal class identifier and the identifier of the stub from the server process;

accessing code to instantiate the proxy object of the class identified by the unmarshal class identifier; and

executing the accessed code, including the substeps of;

instantiating a proxy object of the class identified by the unmarshal class identifier, and

initializing the proxy object to contain a reference to the identified stub so that when the proxy object receives requests to invoke a function member of the object, the proxy object sends the request to the identified stub; and

obtaining a pointer to the instantiated proxy object,

wherein the client process may use the pointer to the proxy object to invoke function members of the object instantiated within the server process.

24. A method in a computer system of passing a pointer to an object from a server process to a client process to enable the client process to invoke function members of the object, the method comprising the steps of:

within the server process,

instantiating the object, the object having a marshalling function member for performing object-specific marshalling for a pointer to the object;

invoking the marshalling function member of the object to marshal the identified interface; and

sending to the client process a reference to the object instantiated within the server process and an unmarshal class identifier identifying the class of a proxy object to instantiate in the client process; and

within the client process,

receiving from the server process the reference to the object instantiated within the server process and the unmarshal class identifier;

accessing code to instantiate the object of the class identified by the unmarshal class identifier;

executing the accessed code to instantiate an object of the class identified by the unmarshal class identifier, the object of the class identified by the unmarshal class identifier having an unmarshalling function member;

obtaining a pointer to the object of the class identified by the unmarshal class identifier; and

invoking the unmarshalling function member of the object of the class identified by the unmarshal class identifier using the obtained pointer and passing the reference to the object instantiated within the server process, the unmarshalling function member for performing object-specific unmarshalling for the pointer to the object,

whereby the client process may use the pointer to the object of the class identified by the unmarshal class identifier to invoke function members of the object instantiated within the server process.

29. A method in a computer system for passing a pointer to an object from a server process to a first client process and from the first client process to a second client process to enable the client process to invoke function members of the object, the method comprising the steps of:

within the server process,

instantiating the object;

creating a stub for receiving a request to invoke a function member of the object and for invoking the requested function member upon receiving the request, the stub having an identifier; and

sending an unmarshal class identifier identifying the class of an object to be instantiated in the first and second client processes and the identifier of the stub to the first client process;

within the first client process,

receiving the unmarshal class identifier and the identifier of the stub from the server process;

accessing code to instantiate a first proxy object of the class identified by the unmarshal class identifier;

executing the accessed code, including the substeps of:

instantiating a first proxy object of the class identified by the unmarshal class identifier and having a marshalling function member to specify that the identifier of the stub is to be sent to the second client process, and

initializing the first proxy object to contain a reference to the identified stub so that when the first proxy object receives requests from the first client process to invoke a function member of the object, the first proxy object sends the request to the identified stub;

obtaining a pointer to the first proxy object;

invoking the marshalling function member of the proxy object; and

sending the unmarshal class identifier and the identifier of the stub to the second client process; and

within the second client process,

receiving the unmarshal class identifier and the identifier of the stub from the first client process;

accessing code to instantiate a second proxy object of the class identified by the unmarshal class identifier;

executing the accessed code, including the substeps of:

instantiating a second a proxy object of the class identified by the unmarshal class identifier, and

initializing the second proxy object to contain a reference to the identified stub so that when the second proxy object receives requests from the second client process to invoke a function member of the object, the second proxy object sends the request to the identified stub; and

obtaining a pointer to the second proxy object,

whereby the first client process may use the pointer to the first proxy object to invoke function members of the object instantiated within the server process and the second client process may use the pointer to the second proxy object to make function members of the object instantiated in the server process.

35. A method in a computer system of passing a pointer to an object of a selected class from a server process to a client process to enable the client process to invoke function members of the object, the method comprising the steps of:

within the server process,

instantiating the object in shared memory that is accessible by the server process and the client process, the instantiated object having a data access function member to access data members of the object;

storing an identifier of the selected class in a message as an unmarshal class identifier;

invoking a marshalling function member of the object instantiated within the server process to store a pointer to data members of the object in the message; and

sending the message to the client process; and

within the client process,

receiving the message from the server process;

retrieving the unmarshal class identifier from the message;

accessing code to instantiate an object of the class identified by the unmarshal class identifier;

executing the accessed code to instantiate an object of the class identified by the unmarshal class identifier, thereby instantiating an object of the selected class, the object of the class identified by the unmarshal class identifier having an unmarshalling function member;

obtaining a pointer to the instantiated object of the class identified by the unmarshal class identifier: and

invoking the unmarshalling function member of the object of the class identified by the unmarshal class identifier, including the substeps of:

retrieving from the message the pointer to data members of the object instantiated within the server process, and

storing in the object of the class identified by the unmarshal class identifier the retrieved pointer to the data members so that the data access function member of the object of the class identified by the unmarshal class identifier can access the data members in shared memory.

42. A method in a computer system of passing a pointer to an immutable object having data members and function members from a server process to a client process, the method comprising the steps of:

within the server process,

instantiating the immutable object;

storing an unmarshal class identifier in a message;

invoking a marshalling function member of the immutable object to store the data members of the object in the message; and

sending the message to the client process; and

within the client process,

receiving the message from the server process;

retrieving the unmarshal class identifier from the message;

accessing code to instantiate an object of the class identified by the unmarshal class identifier;

executing the accessed code to instantiate an object of the class identified by the unmarshal class identifier, the object of the class identified by the unmarshal class identifier having an unmarshalling function member; and

invoking the unmarshalling function member of the object of the class identified by the unmarshal class identifier, including the substeps of:

retrieving the data members from the message, and

storing the retrieved data members in the object of the class identified by the unmarshal class identifier so that the function members of the object of the class identified by the unmarshal class identifier can access the data members of the immutable object.

43. The method of claim 42 wherein the immutable object has a class, and wherein the unmarshal class identifier identifies the class of the immutable object.

44. The method of claim 42 wherein the immutable object has a plurality of interfaces and the pointer to the immutable object is a pointer to one of the interfaces of the immutable object.

49. A method in a computer system for performing a function call from a server process to a function within a client process, the function call having an in parameter that is a pointer to an interface of a real object instantiated within the server process, the interface of the real object having a function member, the method comprising the steps of:

within the server process,

creating a stub for receiving a request invoke the function member;

marshalling an identifier of the stub into a message; and

sending the message to the client process; and

within the client process,

receiving the message from the server process;

unmarshalling the identifier of the stub;

creating a proxy for receiving the request to invoke the function member from the client process and sending it to the stub identified by the unmarshalled identifier;

obtaining a pointer to the created proxy; and

calling the function within the client process, passing the obtained pointer to the created proxy as an in parameter.

50. A method in a computer system for performing a function call from a client process to a function within a server process, the function call having an out parameter that is a pointer to an interface of a real object instantiated within the server process, the interface of the real object having a function member, the method comprising the steps of:

within the client process,

initiating a call to the function within the server process;

within the server process,

calling the function within the client process, the function producing the out parameter that is a pointer to the interface of the real object;

creating a stub for receiving a request invoke the function member;

marshalling an identifier of the stub into a message; and

sending the message to the client process; and

within the client process,

receiving the message from the server process;

unmarshalling the identifier of the stub;

creating a proxy for receiving the request to invoke the function member from the client process and sending it to the stub identified by the unmarshalled identifier;

obtaining a pointer to the created proxy; and

returning the obtained pointer to the created proxy as an out parameter of the function call initiated within the client process.

Key Drawing(s):

"FIG. 13 [below] is a block diagram illustrating custom marshalling with shared memory. In certain situations, an object may store its data members in memory that is shared across processes to avoid the overhead of remote procedure calling to access the data members. In FIG. 13, the data 1302 for cell object 1301 is stored in shared memory. Cell object 1303 is created when a pointer to cell object 1301 is marshalled and sent from process P1 to process P2. The custom methods of the IMarshal interface for a cell object are implemented by the following pseudocode.

void IMarshal::MarshalInterface (pstm, iid, pInterface, DestContext)
     { if(DestContext = Shared) then
          { Marshal (pstm, address of data);}
     else
          { MakeStub ("Cell", iid, pInterface, &MessageAddress);
          Marshal (pstm, MessageAddress)};
     }
void IMarshal::GetUnmarshalClass (iid, pInterface, DestContext, cid)
     { if (DestContext = Shared)
          {cid = "Cell"}
     else
          {cid = "CellProxy"}
     }
void IMarshal::UnMarshalInterface (pstm, iid, pInterface);
     { UnMarshal (pstm, address of data);
      initialize object to point to shared data
     }

The parameter DestContext of the method IMarshal::MarshalInterface indicates whether the data of the cell object is stored in shared memory. If the data is not stored in shared memory, then the equivalent of the standard marshalling is performed. If, however, the data is stored in shared memory, then the address of the shared data is marshalled into the message. The method IMarshal::GetUnmarshalClass determines the unmarshal class based on whether the data is in shared memory. If the data is not in shared memory, then the CellProxy class is the unmarshal class. If the data is in shared memory, then the Cell class is the unmarshal class. The unmarshal class and address of the shared data are sent to process P2. After process P2 instantiates the cell object 1303, the process P2 invokes the custom method IMarshal::UnMarshalInterface, which unmarshals the address of the shared data and initializes the object to point to the data."

[Original image modified for size and/or readability]"Custom marshalling can be used to provide more efficient access to immutable objects. An immutable object is an object whose data members (state) cannot be changed. When an interface pointer to an immutable object is passed from one process to another, custom marshalling can be used to make a copy of the object in the other process. Thus, when the other process accesses the object, it accesses the local copy and no interprocess communication is needed. To allow copying of immutable objects, the methods of the IMarshal interface of the immutable objects are implemented in the following way. In a preferred embodiment, the method IMarshal::GetUnMarshallClass specifies that the unmarshal class is the same class as the class of the immutable object. This ensures that the same type of object is instantiated by the other process. The method IMarshal::MarshalInterface stores the data members of the immutable object into a message for passing to the other process. The method IMarshal::MarshalInterface creates no stub. When the other process receives the message, the other process creates an object of the class of the immutable object. The method IMarshal::UnMarshalInterface then retrieves the data members from the message and initializes the newly-created object. The other process can then access the immutable object."