Patent Application
20100054242
The exemplary and non-limiting embodiments of this invention relate generally to the generation of a unique identifier for a node, such as one bidirectionally coupled with an information-containing system, such as the semantic web.
Various abbreviations that appear in the specification and/or in the drawing figures are defined as follows:
The “Semantic Web” in its current form represents information that is either static or monotonically changing. It has its roots in the WWW and thus takes on a “web-wide” persona. The information and ontologies used have standard web-wide semantics grounded in generally accepted real-world concepts.
Much of the usage of information, that will invariably become part of the Semantic Web, will be personal and/or local. The semantics, structure and adherence to real-world concepts will be grounded by the local users of that information, thus resulting in many localized Semantic Webs.
These local Semantic Webs will contain information that is highly dynamic, non-monotonically changing, adhering loosely (if at all) to their stated ontologies, or not to any standardized, written and commonly understood ontology, and will behave and be reasoned about according to localized, non-standard and non-intuitive logics.
The dynamicity and monotonicity of information in and forming the Semantic Web will vary depending upon locality and be organized according to person, usage, etc., as what may be termed as “spaces” or, more descriptively, as “SmartSpaces”. Of particular interest herein are such small, localized information or knowledge spaces by which persons, via autonomous ‘agents’, interact through control-flow-free mechanisms.
A problem that arises is how to generate unique and meaningful identifiers for nodes or agents in a SmartSpace-based system, such that these unique identifiers can be read (through decryption if necessary) for information that cannot be readily faked or misrepresented. The information derived from such identifiers may be used, for example, for identification, trust and policy enforcement purposes.
The foregoing and other problems are overcome, and other advantages are realized, by the use of the exemplary embodiments of this invention.
In a first aspect thereof the exemplary embodiments of this invention provide a method that includes receiving a request for a node identifier, the request including a first information element; in response, generating a unique node identifier that includes a plurality of second information elements and the first information element; and responding to the request with the generated unique node identifier.
In a further aspect thereof the exemplary embodiments of this invention provide a computer-readable memory media that stores a computer program instructions, where execution of the computer program instructions results in the performance of operations that comprise receiving a request for a node identifier, the request including a first information element; in response, generating a unique node identifier that includes a plurality of second information elements and the first information element; and responding to the request with the generated unique node identifier.
In another aspect thereof the exemplary embodiments of this invention provide an apparatus that comprises a receiver configured to receive a request for a node identifier, the request including a first information element; a generator configured to respond to the received request to produce a unique node identifier that includes a plurality of second information elements and the first information element; and a transmitter configured to send the generated unique node identifier.
In the attached Drawing Figures:
Reference may be had to a publication entitled: Personal Semantic Web Through A Space Based Computing Environment”, by Ian Oliver and Jukka Honkola, in proceedings: Middleware for the Semantic Web, Second IEEE International Conference on Semantic Computing, Santa Clara, Calif., USA, Aug. 4-7, 2008, which is incorporated by reference herein in its entirety.
The generation of a unique identifier can be achieved by a number of means, such as by randomly generating unique identifiers, or by using serial numbers of hardware. At present, currently known generation methods do not provide for encryption of such an identifier (which is typically random in its information content).
The exemplary embodiments of this invention pertain to the generation of unique identifiers for various multiple agents or nodes, such as multiple agents or nodes in a SmartSpace-based system. The exemplary embodiments also pertain to other use cases and scenarios, such as RDF blank node identifier generation for the secure inclusion of additional information.
These exemplary embodiments combine various identifier generation techniques and apparatus with the inclusion of random number and unique identifier generation techniques, as well as internal information about a host application, to produce a unique identifier which may also contain semantic information if desired.
In certain exemplary embodiments it should be noted that the described identifier generation code returns an UUID4 number via a unique ID generator component (item 28 in
General reference to UUID may be made to, for example, RFC 4122, “A Universally Unique Identifier (UUID) URN Namespace”, P. Leach et al., July 2005.
Also described is a scenario in which a node identification may be used within the context of an RDF graph for uniquely identifying “blank nodes” with a meaningful unique identifier, which may carry meta-information in a secure form.
General reference with regard to RDF may be made to, for example, a document entitled “RDF Primer”, W3C Recommendation 10 Feb. 2004, eds. F. Manola et al. (www.w3.org).
In the context of these exemplary embodiments a “knowledge processor” contains one or more nodes to facilitate connection to a Space, e.g., a SmartSpace. A SmartSpace is constructed from a number of SIBs which represent and perform the processing of the SmartSpace.
A node joins a SmartSpace by passing a set of credentials which are then evaluated by a SIB. If successful the node is enabled to join the SmartSpace, and the ID of the node is noted for subsequent transactions between the node and any SIB in that SmartSpace. Such transactions between the node and the SmartSpace include information insertion, retraction, querying and subscriptions, as described more fully below with respect to
There is no restriction as to whether each node must present a unique identifier, although a SmartSpace may decide to degrade the trust and functionality if two or more nodes attempt a join with the same identifier.
In order to provide further context for the exemplary embodiments of this invention, reference may be made to
The inventors have developed a system, which may be referred to as “Sedvice”, that takes conventional agent, blackboard and publish/subscribe concepts and reimplements them in a lightweight manner suitable for small, mobile devices. These agents, termed “knowledge processors” (KPs), operate autonomously and anonymously by sharing information through spaces. These spaces contain a store of information to which the KPs have access and can change at will, processing capabilities for reasoning, modifying and analyzing that information, as well as security and policy functions.
The Sedvice system assumes that information is shared through localized (potentially) personal spaces; that the information can be highly dynamic (changing), and that the information has a semantics primarily given through the interpretation of the information by any given KP. No control flow mechanism need be present, and KPs may share information concerning how external communication, synchronization and coordination can be achieved.
The Sedvice architecture at its simplest is a publish/subscribe system having distributed KPs. Each KP includes a user interface (UI), as well as the logic and/or internal workings of the knowledge processor and nodes. Spaces contain information brokers (known as SIBS), an information store and reasoners.
A KP is considered as a composite structure which is capable of running on a single device, e.g., a mobile device (such as a wireless communication device), a personal computer or a sensor, as a few examples. A particular device may host more than one KP depending on, for example, the operating system and the available memory. The UI is not required in all cases and, if present, may be very simple in nature, e.g., an LCD display, a single button. A node is the part of the KP which contains the logic and functionality to connect to some Space, including the logic for parsing messages and pointers to subscription handlers between the KP and the Space. A node may potentially connect to more than one Space at a time, thus distributing and synchronizing operations across all connected Spaces. Alternatively a KP may contain more than one node.
The basic functionality for manipulating information by a node is given by the following operations:
A Space at its simplest contains a single method for listening on some transport protocol (e.g., a TCP socket interface), the logic for processing messages, policy/security and handling subscriptions and the information store itself. Additionally a set of “reasoners” may also be present, which may be considered to be (effectively) nodes operating in a restricted environment.
The reasoner nodes operate subsequent to all the pending requests for insertion and retraction of information being completed, and process the information in the information store. This processing may be truth maintenance, belief revision, information consistency management, information creation, or any other atomic processing required by that space. Reasoner nodes are scheduled according to priority classes, with the reasoner nodes in each class running concurrently, and all completing after the next priority class is scheduled. One reason for providing priority classes of reasoners is to control the ordering to avoid a situation where two reasoners may interact in unpredictable ways if run concurrently. A reasoner node may be scheduled to run more than once during one reasoning cycle if it exists in two different priority classes.
In a present, non-limiting implementation the SIB stores information as a graph, and conforms to the rules of RDF. The basic operations performed upon the information store are insertion of a graph, retraction of a graph, querying, and subscription for information. Insertion and retraction may be combined into a single transactional structure in order to perform an atomic update through the atomic application of a retract and an insert operation.
Queries are synchronous in nature, while subscriptions are persistent and asynchronous in nature and have a lifetime governed by the creating node. In one exemplary implementation of the system two types of query formats are admitted: triple queries and WQL queries.
No attempt is made by the Space to enforce consistency or integrity of information according to the stated ontologies (through the RDF typeOf relation). Internal reasoning nodes may be present which perform this activity if the Space has been instantiated in this manner. Information is explicitly semi-structured and may take on any form that a KP inserts/retracts. While certain typing constructs and namespaces may be present (if this information is inserted), these do not mean that a node querying for that information will necessarily interpret that information according to the implied ontology. The semantics of the information is interpreted by the reader, merely implied by the writer, and is grounded in the real-world context of the node (any two given KPs may disagree about the ultimate interpretation of the information).
The Space provides further functionality regarding the joining and leaving of KPs/Nodes, as well as policy management. KPs have a set of credentials which are passed during the join operation.
The dual of the KP/node instantiated leave and join operations are Space instantiated invite and remove operations. These operations are not necessarily provided by every Space, nor understood by every KP/node.
Connectivity is provided through a set of “listeners” that provide access via any given specified protocol. One suitable protocol is TCP/IP through standard socket mechanisms, although other protocols can be used to provide, for example, a Bluetooth™ enabled listener, or a listener that uses HTTP/S. Listeners can provide preprocessing of the incoming messages if necessary, for example, with Bluetooth™ profiles. Any number of listeners may be provided at any time, although it is assumed that there is always at least one present.
A Space is constructed from a number (at least one) of the SIBs which contain the aforementioned schedulers, management information, listeners and information store. A Space is represented by these SIBS, and the total possible connectivity methods are defined by the distributed union of all the represented SIB listeners. The SIBs communicate internally to ensure and verify the membership and credentials of the KP/nodes that have joined that Space, which may connect via any listener and any SIB in that Space.
From the point of view of any KP, the information available is always the distributed union over the transitive closure of the routes between all the SIBs (each SIB contains routing tables to other SIBS), and within a given Space all of the SIBs are totally routable (but not necessarily totally connected).
Having thus provided an overview of one non-limiting type of environment in which the exemplary embodiments of this invention may be practiced, reference is now made to the basic architecture of the system that is shown in
Also shown in
During the construction of a message to be sent to a Space (e.g., a SmartSpace) a node identifier (ID) is needed. This is achieved by at least two mechanisms: creation of the ID and getting the ID. Both mechanisms return an ID in some suitable form, such as a string of bytes/characters, or in a more structured form such as an XML representation.
Both mechanisms take a parameter (or parameters if not expressed as a single parameter with structure) that is used during the final processing of the node identifier.
Technically, a create( ) is a wrapper for a get( ) that stores a completely new ID based upon triggering the generation mechanism. Both take the form:
If one were to embed this in some program:
the output may appear as follows:
Id is =0x38abc876d8e787ff,
which assumes the non-limiting case of a hexadecimal representation.
For a case of identifier embedding in a message, a typical message between the node 5 and a SIB, in the non-limiting case of the Sedvice SmartSpace described above with respect to
A typical instantiation of this can be seen below in the exemplary SSAP message with the node ID highlighted:
All communication between the node 5 and the SIB/SmartSpace may be performed in this manner, using the explicitly embedded node_id.
Discussed now in further detail are the constituent components of the node ID generator 10 shown in
The primary interface is via the node ID constructor 20 which provides the create and get functions to the outside world, in this case the message constructor 40 (see
The encryption engine 22 encrypts the generated identifier before usage, and provides a mechanism for protecting the information stored within the identifier, if the identifier contains such information that could be used to ascertain certain aspects of the device and/or the hardware or software used for creating the identifier (e.g., the node 5). If the identifier is generated from a single unique source, for example UUID4, then the encryption engine 22 may not be needed. However, if the identifier is generated from a multiplicity of sources, such as other UUID standards or clocks, network addresses, and so forth, then the use of the encryption engine 22 is desirable, but not mandatory. In other words, the encryption engine 22 may be viewed as an optional component in a given implementation.
The encryption engine 22, if present, may use any suitable technology, such as a one-time pad or a public-private key. It may be assumed that the encrypted key can always be decrypted by a trusted recipient, and any information that the identifier contains can thus be read by the trusted recipient.
The secondary identifier generator 24 may be used to add any hard coded information into the key. Such information may be, by example, a serial number of the node identifier generator component 10. While node identifier generation may also be influenced by any passed parameters to the node ID constructor 20, the secondary identifier generator 24 may override this information, or it may add to this information. The secondary identifier generator 24 may be operated so that the information stored by this component is obtained from some other source.
The node manager or knowledge processor 12 may be located outside of the node ID generator 10, although information pertaining to the generation of the identifier can be obtained dynamically at run-time from hardware, software or other components, in particular the node manager 12 (which contains information about its run-time environment and which nodes/agents are running), or a particular node/knowledge processor itself.
The hardware ID generator 26 generates identifier information based upon reading some hardware component, such as the SIM card 14, or a CPU serial number, as two non-limiting examples.
The unique ID generator 28 is connected to, or contains, a random number generator of suitable quality to generate a “guaranteed” unique identifier. An example of such a scheme is the UUID4 identifier. Other identifier schemes are also valid. This information can be gained also by exploiting certain characteristics of hardware, such as specific fault or test instructions, for example, floating-point division bugs in Pentium™ class processors, AMD x86 processor serial numbers, CPU microcode configurations and so forth.
The temporal ID generator 30 generates identifiers based upon the current time (e.g., some aspect of the current time such as the year, full date, hour/minute/second, Unix-time, etc.) This information is typically obtained from the external time source 16, such as an on-board hardware clock, a software call to a function such as POSIX time( ), GPS (or other positioning system) clock signals, or national broadcast radio clock signals, as non-limiting examples.
The positional ID generator 32 generates identifiers based upon the current position of the device. The positional ID generator 32 takes its information from the positioning unit 18, such as the above-noted GPS or WLAN triangulation, GSM/3G/mobile device base station position triangulation, 3GPP, attitude sensors and/or accelerometers, as non-limiting examples.
As was noted, the foregoing components are not to be construed as constituting a full set of identifier generation components or modules. In general, any unit which can supply information suitable for these devices, as well as others not described, can be used for identifier generation. Non-limiting examples of such units include, but are not limited to, sensors such as temperature sensors, humidity sensors, light meters and camera functionality.
In this example there is described typical behavior and messaging that can be seen in a system of interest (one including the node identifier generator component 10). Reference is made to
In this additional non-limiting example the internal operation of the various components of the node ID generator 10 shown in
Initially node 5 makes the call Get(“12345”) in order to receive a node identifier. The following messages are numbered as Message x, where x is a number 1-16 in the message flow diagram shown in
1. Call to the hardware ID generator 26 to return an identifier
2. Call to the CPU 14A to return (in this example) its serial number
3. Return of the CPU 14A serial number in an internal/device specific format
4. Call to the SIM card 14B in the device for its serial number
5. Return of the SIM Card 14B serial number in an internal/device specific format
6. Return of the hardware identifier in some node generator format (see below)
7. Call to the temporal ID generator 30 for the current time
8. Call to the hardware clock 16 in the system
9. Return of the time in some internal format, e.g.: 32-bits containing the BIOS date
10. Return of the time in some node generator format (see below)
11. Call to the secondary ID generator with parameters (“12345”)
12. Return of the secondary ID (see below)
13. Processing of the returned information by the node ID constructor 20
14. Passing of the processed information to the encryption engine 22
15. Return of the encrypted information to the node ID constructor 20
16. Return of the final unique (meaningful) identifier to the node 5
The identifier returned to the node ID constructor 20 from the hardware ID generator 26 may take the following form, if represented using XML:
The identifier returned to the node ID constructor 20 from the temporal ID generator 30 may take the following form, if represented using XML:
Note that in both examples above the hardware ID generator 26 and temporal ID generator 30 process the incoming information from their respective sources 14, 16 in order to produce a format that is usable and understandable by the node ID constructor 20.
The actual functionality of the secondary ID generator 24 is relatively unconstrained. For example, in one non-limiting embodiment it takes the parameters supplied using the Get( ) call to the node ID constructor 20 of the node ID generator 10 and processes the parameters with (potentially) some statically coded information. In this example the return may take the form:
<secondary_id=12345_aaaaa>,
where “aaaaa” represents the potentially statically coded information.
The node ID constructor 20 performs some function on all of the returned information. In one non-limiting embodiment the function may be a simple concatenation of the information, while another, more complex function may be to further refine and process the information to produce the identifier. For example, the node ID constructor 20 may perform concatenation and MD5 production. MD5 (Message-Digest algorithm 5) is a widely used, partially insecure cryptographic hash function with a 128 bit hash value.
In this non-limiting example the node ID constructor 20 concatenates the information received from the various components of the node ID generator 10 and computes a suitable hashing function (e.g., a MD5 hashing function) over the concatenation:
The value in H may then be passed to the encryption engine 22 (message 14 in
Encrypt(H)=“f2fedbcf87487dafcbed762374fadfafde010182387213bcfdeb345b62f2deaf”
This encrypted value is returned to the node 5 and used in whatever way necessary, typically as the node ID (highlighted below) in some message to the space 42 (e.g., an SSAP message to a SmartSpace), for example:
Further with regard to the uses of these exemplary embodiments, the RDF standard defines the notion of blank node. As all nodes in an RDF graph must be uniquely identified this means that a “blank node” has a uniquely generated identifier. Using the exemplary embodiments of this invention it is possible to generate unique identifiers that contain encoded information. Such information can then only be read by certain parties having knowledge of the required decryption key. This is fully within the remit, scope and official-definition of the universal resource identifier scheme.
Such an RDF triple is described below using the XML representation; where the generated identifier is highlighted:
83d7ab28fb35</subject><predicate>!rdf:type</predicate>
Note the addition of the generated identifier to the namespace declaration.
As should be appreciated, this describes a method of “secretly” encoding meta-information or other information into the URI of a node, such as a blank RDF node.
Described now are examples of instantiated messages. In these example messages the generated node_id is highlighted. Also highlighted are other identifiers which may be generated in the same or similar manner, in accordance with the exemplary embodiments of this invention.
The forgoing message elements, construction and syntax are deemed to be illustrative and exemplary, and are not intended to be construed as restricting in any manner the scope and use of the exemplary embodiments of this invention.
It can be noted that there may be different latencies in the response times of the various units shown in
One non-limiting advantage that may be realized by the use of these exemplary embodiments is that the identifier structure returned may be highly structured and readable by systems capable of supporting semantic web constructs (as well as those systems that do not). The identifier may also be encrypted, giving a degree of protection to the identifier such that systems that cannot use the identifier information or read the information contained within the identifier can still use the identifier and guarantee its uniqueness.
Based on the foregoing it should be apparent that the exemplary embodiments of this invention provide a method, apparatus and computer program(s) to generate a structured and possibly encrypted identifier of a node, such as a node configured to be coupled with a space containing information brokers and other nodes.
Referring to
The method of the preceding paragraph, where the first information element comprises static information.
The method of the preceding paragraphs, further comprising encrypting the generated unique node identifier.
The method of the preceding paragraphs, where the second information elements comprise a temporal information element.
The method of the preceding paragraphs, where the second information elements comprise a serial number associated with the node.
The method of the preceding paragraphs, where the second information elements comprise a random number.
The method of the preceding paragraph, where the random number is a universal unique identifier.
The method of the preceding paragraphs, where the second information elements comprise a value obtained from a characteristic of a data processor or a data processor instruction set associated with the node.
The method of the preceding paragraphs, where the second information elements comprise a value obtained from a hardware element that forms a part of, or that is coupled with, the node.
The method of the preceding paragraphs, where the second information elements comprise a value obtained from a sensor.
The method of the preceding paragraphs, where generating comprises executing a function using the plurality of second information elements and the first information element.
The method of the preceding paragraph, where the function is concatenation.
The method of the preceding two paragraphs, further comprising executing a hashing operation on a result of the execution of the function.
The method of the preceding paragraph, further comprising encrypting a result of the hashing function.
The method of the preceding paragraphs, where in response to responding further comprising including the generated unique node identifier in a message.
The method of the preceding paragraph, further comprising sending the message to a semantic information broker.
The method of the preceding paragraphs, where the message is a smartspace application protocol message.
The method of the preceding paragraphs, where the message is a resource description framework message.
The method of the preceding paragraph, where the resource description framework message is associated with a blank node.
The various blocks shown in
These exemplary embodiments also encompass an apparatus that includes means for receiving a request for a node identifier, the request including a first information element; means, responsive to the request, for generating a unique node identifier that includes a plurality of second information elements and the first information element; and means for responding to the request with the generated unique node identifier.
In general, the various exemplary embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. The various embodiments may be implemented at least partially by computer program instructions that are stored or otherwise embodied in computer-readable memory media, such as semiconductor or disk-based memory devices or modules or systems.
While various aspects of the exemplary embodiments of this invention may be illustrated and described as block diagrams, logic flow diagrams, message flow diagrams, or by using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof. As such, it should be appreciated that at least some aspects of the exemplary embodiments of the inventions may be practiced in various components such as integrated circuit chips and modules. For example, the node ID generator 10 may be wholly (or partially) implemented within an integrated circuit package, either alone or in combination with other functional units.
Various modifications and adaptations to the foregoing exemplary embodiments of this invention may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-limiting and exemplary embodiments of this invention.
For example, while the exemplary embodiments have been described above in the context generally of the Semantic Web and RDF, it should be appreciated that the exemplary embodiments of this invention are not limited for use with only these particular types of systems and standards, and that they may be used to advantage in other systems and standards. In addition, the exemplary embodiments of this invention may be used in applications and systems other than the above described SmartSpace and/or the Sedvice applications and systems.
Further, the various names used for the described parameters are not intended to be limiting in any respect, as these parameters may be identified by any suitable names. Further, any formulas and logical expressions, including message formats and the like, that use these various parameters may differ from those expressly disclosed. Further, the various names assigned to different components and units (e.g., node ID constructor, unique ID generator, etc.) are not intended to be limiting in any respect, as these various components and units may be identified by any suitable names.
It should be noted that the terms “connected,” “coupled,” or any variant thereof, mean any connection or coupling, either direct or indirect, between two or more elements, and may encompass the presence of one or more intermediate elements between two elements that are “connected” or “coupled” together. The coupling or connection between the elements can be physical, logical, or a combination thereof. As employed herein two elements may be considered to be “connected” or “coupled” together by the use of one or more wires, cables and/or printed electrical connections, as well as by the use of electromagnetic energy, such as electromagnetic energy having wavelengths in the radio frequency region, the microwave region and the optical (both visible and invisible) region, as several nonlimiting and non-exhaustive examples.
Furthermore, some of the features of the various non-limiting and exemplary embodiments of this invention may be used to advantage without the corresponding use of other features. As such, the foregoing description should be considered as merely illustrative of the principles, teachings and exemplary embodiments of this invention, and not in limitation thereof.
