EP3811598A1 - System of dynamically managed / self-organizing object networks - Google Patents
System of dynamically managed / self-organizing object networksInfo
- Publication number
- EP3811598A1 EP3811598A1 EP19745750.0A EP19745750A EP3811598A1 EP 3811598 A1 EP3811598 A1 EP 3811598A1 EP 19745750 A EP19745750 A EP 19745750A EP 3811598 A1 EP3811598 A1 EP 3811598A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- namespace
- objects
- superior
- ownership
- inferior
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/55—Push-based network services
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
- H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
Definitions
- loT devices can at the same time be owned by different "Logical Owners” (e.g. for a “Fitness Device” the “Physical Owner” of it and a Doctor to supervise medical health). If there are means to interact, this is handled in a non-transparent mechanism within the cloud and not under control of the "Physical Owner” (lack of governance).
- the refining functionality enables to negotiate duration of contract, exclusive or shared ownership, compensation/cost for deliverables and enabling negotiation of contracts like in a free market exchange.
- the system or each object comprises an arrangement to trigger manually or automatically the describing/offering method.
- the triggering arrangement is a physical button or a voice command or a visual trigger or a face recognition means.
- each object comprises an arrangement or program to check the descriptions against their goals/embedded rules not to violate possible existing "hiring contracts" with other objects.
- objects interact with other objects either through function calls or by publishing messages to an URI in a joint namespace, said objects using a publishing/subscribe method or function calls approach.
- the system comprises further methods for enhancing the minimalistic set of methods, said further methods comprising at least one of:
- the objects using the enhanced set of methods are configured to dynamically transfer important context to adapt to varying situations that allow said objects to behave different in different situations within the constraints of contracts that may be pre-negotiated or dynamically negotiated by the objects based on need and situation.
- an object for interaction of loosely coupled independently acting networked objects for collaboration in a network environment for dynamically changing ownerships which is connected and configured for managing logical ownership on behalf of the physical owner
- said object including at least a processor using an operating system and a memory comprising an API executed by the processor and communication means through a wireless or wire link to some sort of intranet or internet network to be able to interact with other objects
- said API comprises a manager service for implementing at least one of the public or external methods “present”, “apply”, “hire”, “refine” for presenting, applying, hiring, refining data and giving access to the manifest of said object as well as providing processing functionality, said methods and manifest being contained in the memory of the object publicly accessible, the manager service communicating on one side with private or internal methods “register”, “unregister” and“remap” memorized in a first private memory of the object for respectively registering/unregistering and or remapping, and on another side with private variables memorized in a second private memory of the object
- the“apply” method of an inferior object is called by the superior object to express the intent to temporarily (probation/qualification period) incorporate it into the superior’s ownership/namespace, make the inferior knowledgeable about the services the superior is offering (manifest) and the “temporary” place in the intermediate namespace the inferior is to use during the probation/qualification period, allowing the inferior object to take decision if this transfer is compatible or not with the current state.
- the“hire” method of an inferior object is called by the superior object to express the intent to permanently incorporate it into the superior’s ownership/namespace, make the inferior knowledgeable about the services the superior is offering (manifest) and the place in the intermediate namespace the inferior is later on to be working with, allowing the inferior object to take decision if this transfer is compatible or not with the current state.
- the“refine” method of an inferior is called by a superior to make it aware of:
- each object of the system comprises a mechanism or a program for“transformation of names” which modify the own “names” (with no meaning outside the object) into "name” that have a meaning for all other objects in the global namespace.
- FIG. 1 is a schematic representation of the structure of an object of the system, according one embodiment
- FIG. 2 is a schematic representation of the structure of an object of the system, according another embodiment
- - figure 3 is a schematic representation of the initial state of a multi- level dynamic namespaces flexible relationship
- - figure 4 is a schematic representation of simple connected state of a multi-level dynamic namespaces flexible relationship, according one embodiment
- FIG. 5 is a schematic representation of a multiple connected state of a multi-level dynamic namespaces flexibles relationship, according one embodiment
- FIG. 6 is a schematic representation of a“market” node in a multi- level dynamic namespaces flexible relationship, according one embodiment
- FIG. 7 is a schematic representation of the transfer of ownership from“market” node to“employer” node in a multi-level dynamic namespaces flexibles relationship according one embodiment
- FIG. 8 is a schematic representation of a two level static namespaces hardwired relationships.
- the object (bracelet) is hardwired to one single node in the cloud of service provider, according an embodiment
- FIG. 9 is a schematic representation of interacting objects working on shared/managed context, according one embodiment
- FIG. 10 is a schematic representation of interacting objects working on shared/managed context, according one embodiment
- the present invention concerns a system for dynamic interaction of loosely coupled independently acting networked objects (1 ).
- the system for interaction of at least two loosely coupled independently acting networked objects (1 ) for collaboration in a network with an environment of dynamically changing and possibly multiple ownerships to which an object (1 ) is connected and is outside the control of the owner comprises at least a set of objects (1 ) and at least a network/communication means or arrangement for communication between said objects (1 ).
- Each object (1 ) includes at least one processor and a memory comprising an API to be executed by said processor allowing said object (1 ) be able to communicate through a wireless (for example and without limitation WLAN/Bluetooth/WIFI) or wire (for example and without limitation Ethernet) link to some sort of intranet or internet network and to interact each other (the interaction may either be between objects (1 ) directly (peer to peer) or networked (across multiple intermediate objects (1 ), but even in this case the direct peers would only see peer to peer connections), said system using a Uniform Resource Indicator (URI) to identify objects (1 ) within a“global” namespace including many local namespaces (2c), said system being characterized in that it ncludes a minimal basic set of mechanisms for ownership coordination and or transfer, said minimal basic set of mechanisms consisting of interface methods and or globally standardized rules for:
- URI Uniform Resource Indicator
- object (1 ) we mean a physical“thing” or device that may be part of the Internet of Things (loT) or a manufacturing system or infrastructure comprising devices communicating, through a network, with each other and with devices external to said manufacturing system belonging to another infrastructure or entity.
- LoT Internet of Things
- the "logical things" of a physical“thing” or object (1 ) can at the same time be controlled by several entities (logical, legal, natural ones,).
- a user of the loT may "own” the“logical things” of an object (1 ) or device because it can send input to it, change its state (represented by data internal to the object (1 ) even to the extreme to make the object (1 ) unusable or worthless for others), for example and without limitation the locking/unlocking of a smartphone or deleting its data by means of a program running on a remote device such as a computer or a server communicating with said smartphone.
- a remote device such as a computer or a server communicating with said smartphone.
- this would only have consequences for the "one and only” owner of the object (1 ) or device.
- a “shared” sense concurrent ownership at the same time
- an activity like this would also technically as well as legally impact other entities or owners (natural/legal persons) that also have some claims for rights of use for the same object (1 ) or device.
- namespace we mean a set of symbols used to organize objects (1 ) of various kinds, so that said objects (1 ) are referred to by name. It may be seen as a dictionary mapping names to objects (1 ). A namespace allows to uniquely qualify objects (1 ). Then, one knows to which domain of definition a given object (1 ) is related and how it must be interpreted according to its specification.
- the namespace specific to an object (1 ) is called a local namespace (2c) and the namespace including all the local namespaces (2c) is called a global namespace (2a).
- the system may comprise a program for defining a convention for structure allowing each object (1 ) to determine the structure of the global namespace (2a).
- system or each object of the system may comprise a mechanism or a program for“transformation of names” which modify the own“names” (with no meaning outside the object (1 )) into "name” that have a meaning for all other objects (1 ) in the global namespace (2a).
- the system or object (1 ) may comprise an arrangement to trigger manually or automatically the describing/offering method.
- said arrangement may be a physical button, voice command, visual trigger, face recognition or even some data collected to make the object (1 ) valuable for some "hirer”.
- the describing/offering requires at least:
- each object (1 ) of the system comprises an arrangement for deriving information about the published object (1 ) so as to make decisions (by coded logic or by intelligence) to connect to the said published object (1 ).
- Applying requires rules (logical or intelligence) implemented in the interacting objects (1 ) to take adequate actions to keep semantic integrity in the situation that in this case the "applying" object (1 ) is not yet “hired” (owned by the hiring object (1 )") but no longer “unbound” (like “quarantine” or “probation/qualification period”).
- the constraints of the "apply” phase are described in the description of the service offering to guide these decisions. Refining is the digital equivalent to negotiating and closing a contract.
- the system may comprise at least a computing architecture to execute a set of rules for:
- loT One common function within loT is to keep communication secret. So, one anticipated function is to ask, grant and withdraw crypto keys to related objects (1 ) to do that.
- Another one is to utilize resources that are owned by the hiring object (1 ) (money, information, space). As these resources tend to be protected against unauthorized use, authorization needs to be granted as needed. This requires methods for granting and withdrawing authorization to use resources.
- the refining functionality enables to negotiate duration of contract, exclusive or shared ownership, compensation/cost for deliverables and enabling negotiation of contracts like in a free market exchange.
- cooperating objects (1 ) manage a part of the “global” namespace, the “intermediate” namespace and the “local” namespace in an aligned and coordinate way to get a joint“intermediate” namespace between objects (1 )/things.
- the combination of the namespaces (intermediate and local for forming the joint intermediate namespace (2b)) enables a dynamic cooperation that is completely managed by both namespace (the local and the intermediate namespaces (2b)) and thus forms the foundation for cooperation. This also implies“decentralized” namespace management (no central control is necessary).
- objects (1 ) may interact with other objects (1 ) either through function calls or by publishing messages to an URI in a joint namespace, said objects (1 ) using a publishing/subscribe method or function calls approach.
- Each object (1 ) may comprise at least an arrangement for subscribing to said URI in said joint namespace and make itself visible and accessible for such published messages.
- the system comprises further methods for enhancing the minimalistic set of methods, said further methods comprising at least one of the following methods (that may be common to organizations and companies like):
- the object (1 ) using the methods are able to dynamically transfer important context to adapt to varying situations that allow the object (1 ) to behave different in different situations within the constraints of contracts that may be pre-negotiated (commonly shared by preexisting context) or dynamically negotiated by the object (1 ) based on need and situation.
- the object (1 ) using the methods are able to have bookkeeping capabilities to selectively apply these contexts to the specific interactions with specific object (1 ) (e.g. apply Identity A/credentials of A for interacting with object (1 ) A, while applying Identity B/Credentials of B for interacting with B).
- Figure 8 illustrates an example of a situation without the application of the system of the present invention.
- an loT object (1 ) or device like a connected health bracelet (or wall socket or power meter) When first deployed, it is connected to the Internet (state of the art) and associated to a "logical owner" (a person making use of the object (1 ) from remote).
- a "logical owner" a person making use of the object (1 ) from remote.
- There is one“global namespace (2a)” through which the device’s local namespace (2c) and related methods/variables can be addressed.
- the mapping is static.
- the object (1 ) in question needs to be purchased from some vendor, brought to the planned destination place and connected to e.g. a WIFI network.
- the system of the present invention introduces a “Multi-Level namespace” that may be controlled by different instances. As illustrated in Figure 3, there is a“global namespace (2a)” as in Figure 8, which is shared by all instances that apply the concept of the invention by a shared convention/understanding.
- The“Shared convention or understanding” in this statement means that all parties involved need to understand how a location in the global namespace (2a) is “written”, for example and without limitation “www.atos.net” as the location where all“Atos-Stuff that is provided and used by Atos is located. This enables all interested parties to find Atos stuff from wherever they come.
- Figure 4 corresponds to an embodiment showing the state of the overall system, when the inferior node (top level node of the local namespace (2c)) is already“owned” (incorporated) by the superior node and part of the“intermediate (2b)” and the“global namespace (2a)”.
- The“incorporation process” is implemented by a set of methods both of the superior node as well as the“inferior node”.
- the roles may also change (a superior may become an inferior of its former inferior or another objects (1 )). So, all objects (1 ) have the same rules implemented.
- “Incorporation Process” is a synonym for“transfer of ownership” from “external” to“internal”. So at the end the object (1 ) is within the other object (1 ).
- Figure 5 corresponds to an embodiment showing the state of the overall system, where one“inferior object (1 ) (for example top level node of the local namespace)” is at the same time incorporated into two different superior objects (1 ) (for example superior nodes). This means that the behavior and data of it can be addressed via the intermediate namespaces (2b) of two superior objects (1 ). Therefore, it is owned by two superiors and from a pure logical point of view the inferior object (1 ) exists in two places. To make it clear, the inferior object (1 ) instance (state, data, logic) is existing exactly once.
- the object (1 ) may decide to behave differently when addressed from the context of different superiors (“overloaded” operation). For example, and without limitation, the object (1 )“lamp” may turn on with full light if activated by a button 1 and with dimmed light when activated by a button 2.
- the object (1 )“lamp” may turn on with full light if activated by a button 1 and with dimmed light when activated by a button 2.
- “subordinate node” belongs to (is owned by) two other nodes (for example and without limitation a law office may concurrently work for two different companies at the same time and accept orders from both, even if the law office is legally not part of the customer company).
- Figure 6 introduces the concept of a“well-defined” superior node in the global namespace (2a), the so called “Market”, according an embodiment.“Market” is just a name for an entry point for all objects (1 ) that are currently not“owned” by others (like a free-market exchange where anybody can offer and hire). This is a means to make otherwise “unconnected” or“unowned” objects (1 ) addressable, accessible and visible for other objects (1 ) that intend to take ownership. As all objects (1 ) there also expose their“manifest”, this also take the role of an explicit inventory of all functionalities available in the global namespace (the capabilities of each object (1 ) in a machine-readable way).
- Figure 7 shows the handover of ownership of an inferior object (1 ) from one superior to another. In this case from the “Market” to the “employer”. But the mechanism is the same for transfer from one employer to the other. The inferior is addressable and visible through the intermediate namespace (2b) of its current superior (here the“Market”).
- the present invention also concerns an object (1 )
- each object (1 ) includes at least a processor using an operating system, for example and without limitation a Java operating system or an embedded operating system, and a memory comprising an API executed by the processor and communication means through a wireless or wire link to some sort of intranet or internet network to be able to interact with other objects (1 ), said API comprising a manager service (10) for implementing at least one of the public or external (exposed to and callable from other object (1 )) methods “present”, “apply”, “hire” and “refine” for presenting, applying, hiring, refining data and, for giving access to the manifest of said object (1 ) (the manifest is the formal description of
- the manager service (10) communicates on one side with private or internal (not callable/useable from outside the object (1 )) methods“register”,“unregister” and“remap”, memorized in a first private memory (1 1 ) of the object (1 ), for respectively registering/unregistering and or remapping, and on another side with private variables memorized in a second private memory (12) of the object (1 ) for saving information concerning at least local root node as the root for its local namespace (2c).
- Figure 1 illustrates the basic mechanism embedded in all objects (1 ) of the system, that is necessary to implement the above-mentioned scenarios of transfer of ownership and to map the inferior’s local namespace (2c) into the superior’s and thus the global namespace (2a).
- This is accomplished by providing a basic“manager service (10)” that offers a well- defined set of “methods” as well as by an internal set of methods (not accessible via the namespace, i.e. local or“private” methods). The latter is executed internally, when some public methods are executed.
- This data object (1 ) is called“manifest” and may be implemented using for example, and without limitation, JSON, Ontologies or other means. This manifest at least describes the mandatory service“manager”.
- the“present” method of a superior object (1 ) is called by an inferior object (1 ) to offer it’s services by making the superior node aware of the current location in the global namespace (e.g. on the Market intermediate space) and by providing the formal description (Manifest) of the offered services and the Top node of the local namespace;
- the“apply” method of an inferior object (1 ) is called by the superior object (1 ) to express the intent to temporarily (probation/qualification period) incorporate it into the superior’s ownership/namespace.
- the “apply” method also makes the Inferior knowledgeable about the services the superior is offering (manifest) and the “temporary” place in the intermediate namespace (2b) the Inferior is to use during the probation/qualification period, allowing the Inferior object (1 ) to take decision (through, for instance, human decision or artificial intelligence rules) if this transfer is compatible or not with the current state (e.g. other existing ownerships).
- the“hire” method of an inferior object (1 ) is called by the superior object (1 ) to express the intent to permanently incorporate it into the superior’s ownership/namespace.
- The“hire” method also makes the inferior knowledgeable about the services the superior is offering ( manifest) and the place in the intermediate namespace (2b) the inferior is later on to be working with, allowing the inferior object (1 ) to take decision (through, for instance, human decision or artificial intelligence rules) if this transfer is compatible or not with the current state (e.g. other existing ownerships);
- the inferior object (1 ) may also decide not to perform the hire activity but to apply with a different offering/Manifest to optimize interaction. Indeed, in some embodiments, the object (1 ) may comprise a program or a set of rules to be implemented depending on certain facts.
- the“refine” method of an inferior is called by a superior to make it aware of:
- - changed employment/ownership conditions being a means to “renegotiate” the ownership contract (like in a free market situation, where a person applies for many jobs at the same time) and to decide for the best terms and conditions among a set of possible terms and conditions;
- Figure 2 shows an object (1 ) with additional functionalities for self- management and cooperation in larger dynamic contexts, according an embodiment.
- Basic principle is to have objects (1 ) behave like intelligent, self-optimizing entities like Companies/Organizations that have higher structural capabilities and working principles. It makes every object (1 ) behave like a Company on its own that cares for planning, keeping track on cost, created values, expenses and resources it uses and creates and increases value all the time. For that, design patterns for organizational behavior may be implemented within the object (1 ) and be executed via services interface like the one of the“manager service (10)”.
- One of the basic principles used for organization it that of “Identity”.
- private or internal method“register” is used during initial object (1 ) creation (instantiation) (create, for example, the state of the object (1 ) so far unknown outside of its own to make it visible for all other objects that have access to the global namespace. Therefore, the local knowledge (state, functionalities, etc.) is globally visible to include the object (1 ) into the global namespace (2a) (preferably in the well-known“Market” intermediate namespace (2b)) or even within a defined “superior” intermediate namespace (2b) (e.g. development of a new service/offering within an already existing organization/company).
- the private or internal method “unregister” is used during transfer of ownership to remove the respective object’s (1 ) local namespace (2c) from the“superior” intermediate namespace (2b).
- private or internal method“remap” consist in the transformation of the local namespace (2c) into the relevant intermediate namespace (2b) of the new owner, all instances of the“local” namespace (2c) being changed, in said transformation process, by prepending prefixes describing the “intermediate” namespace to the respective names thus renaming all items to perfectly fit into the - now common - namespace of both objects (1 ), all names of the object (1 ) being then visible /accessible for other objects (1 ) (in fact it is a sort of dynamic linking).
- Figure 9 illustrates the situation in which“Manufacturing Company” and“Milling” have published their existence to the“Market” and thus made themselves know and accessible to the eco-system.
- the object (1 ) “Manufacturing Company” offers services like“Management” (required by the minimum set of methods as explained in the invention)“Sales”,“Resource Control”, “Production” and “Financial” to represent the business (non- exhaustive).
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
Description
Claims
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE102018113082.1A DE102018113082A1 (en) | 2018-05-31 | 2018-05-31 | System of dynamically managed / self-organizing object networks |
PCT/IB2019/054414 WO2019229654A1 (en) | 2018-05-31 | 2019-05-28 | System of dynamically managed / self-organizing object networks |
Publications (1)
Publication Number | Publication Date |
---|---|
EP3811598A1 true EP3811598A1 (en) | 2021-04-28 |
Family
ID=67470438
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP19745750.0A Withdrawn EP3811598A1 (en) | 2018-05-31 | 2019-05-28 | System of dynamically managed / self-organizing object networks |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP3811598A1 (en) |
DE (1) | DE102018113082A1 (en) |
WO (1) | WO2019229654A1 (en) |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7613703B2 (en) * | 2004-09-30 | 2009-11-03 | Microsoft Corporation | Organizing resources into collections to facilitate more efficient and reliable resource access |
US9491181B2 (en) * | 2009-12-28 | 2016-11-08 | Telefonaktiebolaget L M Ericsson | Social web of objects |
WO2016011361A1 (en) * | 2014-07-18 | 2016-01-21 | Convida Wireless, Llc | M2m ontology management and semantics interoperability |
DE102016011192A1 (en) * | 2016-09-15 | 2018-03-15 | Parce GmbH | Method for secure, manufacturer-independent communication between loT users |
US9860677B1 (en) * | 2016-09-30 | 2018-01-02 | Intel Corporation | Internet-of-things gateway coordination |
-
2018
- 2018-05-31 DE DE102018113082.1A patent/DE102018113082A1/en active Pending
-
2019
- 2019-05-28 WO PCT/IB2019/054414 patent/WO2019229654A1/en unknown
- 2019-05-28 EP EP19745750.0A patent/EP3811598A1/en not_active Withdrawn
Also Published As
Publication number | Publication date |
---|---|
WO2019229654A1 (en) | 2019-12-05 |
DE102018113082A1 (en) | 2019-12-05 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Li et al. | Blockchain-enabled workflow operating system for logistics resources sharing in E-commerce logistics real estate service | |
US11030281B2 (en) | Systems and methods for domain-driven design and execution of modular and dynamic services, applications and processes | |
Josey et al. | An introduction to the ArchiMate® 3.0 specification | |
Liu et al. | Blockchain-enabled ESG reporting framework for sustainable supply chain | |
Hsieh et al. | A self-adaptation scheme for workflow management in multi-agent systems | |
Lee et al. | A feature-oriented approach for developing reusable product line assets of service-based systems | |
Künzle et al. | Striving for object-aware process support: How existing approaches fit together | |
Ren et al. | Cloud manufacturing platform: operating paradigm, functional requirements, and architecture design | |
Narendra et al. | Sound conflict management and resolution for virtual-enterprise collaborations | |
Peris-Ortiz | An analytical model for human resource management as an enabler of organizational renewal: a framework for corporate entrepreneurship | |
Li | An Approach to Addressing the Usability and Local Relevance of Generic Enterprise Software | |
Calabró et al. | Integrating access control and business process for GDPR compliance: A preliminary study. | |
De Leusse et al. | A governance model for SOA | |
Schefer-Wenzl et al. | Modeling support for role-based delegation in process-aware information systems | |
Graham | Requirements modelling and specification for service oriented architecture | |
Zimmermann et al. | Architectural decisions and patterns for transactional workflows in soa | |
EP3811598A1 (en) | System of dynamically managed / self-organizing object networks | |
Saha | Analyzing The open group architecture framework from the GERAM perspective | |
Surajbali et al. | A cloud–based approach for collaborative networks supporting serviced-enhanced products | |
Autili et al. | On the model-driven synthesis of evolvable service choreographies | |
Surajbali et al. | A cloud-based collaborative platform supporting serviced-enhanced products for emerging markets | |
Guédria et al. | Research methodology for enterprise interoperability architecture approach | |
Masuda | Adaptive integrated digital architecture framework with risk management for global enterprise | |
Alani et al. | The application of service-orientation principles within service-oriented software engineering methods: a survey and comparison framework | |
Fleming | The Elephant in the Field |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: UNKNOWN |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20201209 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
AX | Request for extension of the european patent |
Extension state: BA ME |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20210730 |