Message Repository for Interprocess Communication

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current interprocess communication methods are inefficient due to tight coupling between processes, resource overload, and delayed notification of actions, leading to inadequate preparation and response time for processes impacted by other processes' actions.

Innovation Solution

Implementing a message repository with a standard API for processes to proactively post and retrieve messages, allowing loose coupling and reducing resource usage, enabling advanced notification of actions before they occur, and allowing processes to prepare effectively.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If processes continuously listen for messages from each other, then message delivery is reliable, but processing overhead increases

Engineering Contradiction:
Improvemessage delivery reliabilityVSAvoidprocessing overhead
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The patent applies preliminary action by having the publishing process proactively post messages to the repository before other processes need to access them. This eliminates the need for continuous listening, as messages are already available when needed, reducing processing overhead while maintaining reliability.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent inverts the traditional communication model by switching from pull-based (continuous listening) to push-based (proactive posting) architecture. Instead of processes waiting for messages, processes actively publish messages to the repository, fundamentally changing the communication paradigm to reduce overhead.

Inventive Principle:
Principle #13The other way round (Inversion)

2Reliability

If a process sends messages to multiple recipients separately, then each recipient receives the message, but communication resources are overwhelmed

Engineering Contradiction:
Improvemessage delivery completenessVSAvoidcommunication resources
Core Design Contradiction:
ReliabilityVSQuantity of substance

Solution Approach 1:

The patent merges multiple separate message transmissions into a single publication event. One process can publish a message to the repository that is then accessible by multiple subscribing processes simultaneously, eliminating the need to send duplicate messages to each recipient and conserving communication resources.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The message repository serves as a universal communication medium that handles delivery to multiple processes simultaneously. A single message posted to the repository can be consumed by any number of subscribing processes, providing multi-functional communication capability.

Inventive Principle:
Principle #6Universality (Multi-functionality)

3Device complexity

If monitoring agents detect actions after they occur, then system overhead is minimized, but response time is insufficient

Engineering Contradiction:
Improvesystem overheadVSAvoidresponse preparation time
Core Design Contradiction:
Device complexityVSLoss of time

Solution Approach 1:

The patent enables processes to post messages about future actions or current intentions before the actions occur or before other processes need to respond. This preliminary notification provides advance warning, allowing receiving processes to prepare appropriate responses in advance, reducing response time while maintaining simple system architecture.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS9235457B2Proactively communicating information between processes through a message repository
Publication Date: 2016.01.12 ORACLE INT CORP
  • US9235457B2 patent drawing
  • US9235457B2 patent drawing
  • US9235457B2 patent drawing

AI summary

A method and apparatus for proactively communicating information between processes through a message repository is provided. To communicate with other processes, a process may post a message to a message repository. Other processes may, at regular or irregular intervals, search the message repository for new messages that have been posted to the repository since the last search, and retrieve those new messages. Processes may post and retrieve messages relative to the message repository by invoking methods provided by an application programming interface (API). By posting a message to the message repository, a particular process can inform other interested processes proactively of actions that the particular process has taken, is taking, or will take. By retrieving messages from the message repository, a process can determine what actions other processes have taken, are taking, or will take, and adjust accordingly.