WO2004081800A1 - メッセージ配信装置及びその方法並びにシステム及びプログラム - Google Patents
メッセージ配信装置及びその方法並びにシステム及びプログラム Download PDFInfo
- Publication number
- WO2004081800A1 WO2004081800A1 PCT/JP2004/002333 JP2004002333W WO2004081800A1 WO 2004081800 A1 WO2004081800 A1 WO 2004081800A1 JP 2004002333 W JP2004002333 W JP 2004002333W WO 2004081800 A1 WO2004081800 A1 WO 2004081800A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- message
- node
- header
- information
- message delivery
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- 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/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
- H04L67/63—Routing a service request depending on the request content or context
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Definitions
- the present invention relates to a message delivery device, a message delivery method, a system, and a program, and more particularly to a message delivery device for a plurality of related communication nodes via a communication network.
- the present invention relates to a message delivery method for delivering a message.
- Java Messaging Service JMS; http: // java. Sun. Com / products / jms /) whose specifications are defined by Sun (S un), and Softwire, one of its implementations
- S oftwired's i-Pass iBus: http: //www.softwired-inc.com
- other message-oriented mid-wares are designed to add keywords called topics to messages.
- the message sender sends the message with this topic to the message router.
- FIG. 21 an example of a conventional message delivery system is shown.
- the recipient's communication node (hereinafter simply referred to as the node) 550, 501 is connected to the message router 800 via the network 100, and the DB (database) 900 is the message. Managed by router 800.
- the receiver node 500 registers in advance the topic it wants to receive in the message router 800.
- the message with the topic is received by the message receiving unit 210 and passed to the splitter 220.
- the splitter 220 splits the message into a header and a payload, and sends the former to the header interpreter 230 and the latter to the synthesizer 260.
- the header interpreter 230 interprets the header, recognizes that this message is a registration request message, and extracts the topic and the URL (Uniform Resource Locator) of the recipient node 500.
- the header section 230 is DB (database). Source) Using the writing section 290, a topic is set as a keyword in the database 900, and a list of location information such as the URL of the recipient is stored as a table. If the header interpretation unit 230 succeeds in registering the data into the database 900, it creates a response message header and passes it to the synthesizing unit 260.
- the combining unit 260 combines the header received from the header interpreting unit 230 and the payload received from the splitter 220 into one response message.
- the combining unit 260 issues a registration success response message to the node 500 using the message transfer unit 2700.
- the message receiving section 520 of the node 500 receives the registration success response message and passes it to the processing section 510. As a result, the processing unit 5110 confirms the registration success.
- node 501 is a sender node.
- the message router 800 passes the message to the splitter 220.
- the splitter 220 splits the message into a header and a payload, and sends the former to the header interpreter 230 and the latter to the synthesizer 260.
- the header interpreter 230 interprets the header, recognizes that this message is a message to be routed, and extracts a topic to be transmitted.
- the header interpreting unit 230 searches the database 900 for the topic of the message using the DB reading unit 240, and obtains the position information of the node obtained as a result, for example, a set of URLs of the node 500. Get.
- the header interpreting unit 230 creates a header for each of the obtained list of position information, and passes it to the synthesizing unit 260.
- the combining unit 260 copies the payload received from the splitter 220 for each header received from the header interpreting unit 230, creates a message, and creates a message. Pass to.
- the message transfer unit 270 sends the message to a recipient node such as node 501.
- the transmitted message is received, for example, by the message receiving unit 520 of the node 500 and passed to the processing unit 510.
- the processing unit 5110 performs a process according to the received message. For example, a message to a sales department member is a topic "Sales Div". The topic of the first section of sales is "1st sec".
- the topic "Sales Div" Messages should also be sent to recipients who want the topic "Sales Div", if they don't have a hierarchical topic structure like JMS, the members of Sales Division 1 are "Sales Div" and "1st sec" You need to register recipients on both topics.
- ANG Web Services for Business Process Design
- SOAP Simple Object-Access Protocol
- the service provider provides the service by looking at the payload of the SOP message.
- the next destination of the message is determined by looking at the header.
- each transfer destination is specified in the header. Therefore, if there are a large number of service cooperation nodes, the size of the header becomes large, which is not efficient.
- Ingress filtering technology when service users are limited, physically and logically filters buckets with sender addresses other than those of the service user before they reach the service provider. Prevent denial attacks It has become so. However, if the service user cannot be identified, it is not possible to use Indialess filtering.
- connection requests of the service provider is limited, and connection requests exceeding this limit are rejected.
- a malicious service user makes a request exceeding the limit, it is difficult for a legitimate service user to use the service.
- a seal that guarantees security at the transmission source is attached to the message, and the service provider assigns a priority according to the security.
- the present invention it is necessary for the present invention to have a mechanism for marking a sender as ensuring security. This can be achieved when the service user accesses through a specific ISP (Internet Service Provider), but in general, the Internet user does not necessarily access through an ISP that has a mechanism for marking security. Not always, it is difficult to realize.
- ISP Internet Service Provider
- a distributed denial-of-service attack means that a malicious node does not attack the service provider directly, but uses other non-malicious nodes to attack the service provider.
- a node used by a malicious node is called a springboard node.
- a stepping-off node is provided with an attack blocking function. When the attack detecting function detects a distributed denial of service attack, the attack is blocked. Command the function to deny access to the service provider from the bastion node.
- the conventional technology has the following problems.
- the first problem is that there is no message-oriented middle air where nodes cooperate efficiently in a system such as the Internet where there are a large number of service provider nodes that provide services and information. For example, it is difficult to establish an authentication service providing node and restrict access to the service providing node without having to modify the existing service providing node.
- the second problem is that it is difficult to send a message to a node that is interested in the topic that contains the message and that is interested in the topic.
- Messages with the topic "Sales Div" are sent not only to nodes that have registered, 'Sales Div' as a topic, but also to nodes that have registered with the topic "1st sec” included in "Sales Div". Should.
- a node is a service provider and may be connected to the Internet, in which case it can be accessed from any node. Therefore, a malicious node puts an excessive load on the service provider, and makes it difficult to provide the service normally.
- a first object of the present invention is to provide a message delivery device having a message-oriented middleware capable of processing a message delivery procedure, a method thereof, a system and a program.
- a second object of the present invention is to provide a message delivery device having message-oriented middleware capable of designating a delivery destination by a topic having an inclusion relationship, and a method, system, and program thereof.
- a third object of the present invention is to provide a message distribution device, a method, a system, and a program capable of preventing a denial of service attack on a service provider even in an open network environment such as the Internet environment. By doing.
- a fourth object of the present invention is to provide a message distribution device, a method, a system and a program which can prevent a distributed denial of service attack against a service provider even in an open network environment such as the Internet environment. It is to provide.
- a message delivery device for delivering a message to a node connected to a network, wherein the node information of a message delivery destination is set in a predetermined relationship. Based on the database stored as the data structure and the receiving node information of this message added to the header of the message, the tree data structure of the database is accessed, and the sub-tree with the receiving node information as the root is accessed. And a transfer means for transferring a message to a distribution destination corresponding to all the searched node information.
- pairs of node information and policy information defining a policy for determining a message delivery destination are stored as a tree data structure, and the search means searches for the pair of node information and policy information.
- the transfer means may transfer the message according to the searched information! /.
- the message delivery method is a message delivery method for delivering a message to a node connected to a network, wherein the node information of the message delivery destination is tree data according to a predetermined relationship. Accessing the database stored as a structure based on the receiving node information of the message added to the header of the message, and searching for all node information included in the subtree rooted at the receiving node information; Transferring the message to a distribution destination corresponding to all the searched node information.
- a message delivery system includes a plurality of nodes connected to a network and transmitting and receiving a message; And a message delivery device that delivers a message transmitted from one node to another node, wherein the message delivery device stores the node information of the message delivery destination as a complete data structure according to a predetermined relationship. All nodes included in the subtree rooted at the received node information are accessed by accessing the database and the data structure of the database based on the receiving node information of this message added to the header of the message. It is characterized by comprising search means for searching for information, and transfer means for transferring a message to a distribution destination corresponding to all searched node information.
- a firewall may be provided between each of these nodes, the message distribution device, and the node management device and the network.
- the program according to the present invention is a program for causing a computer to implement a message delivery method for delivering a message to a node connected to a network, wherein the node information of the message delivery destination has a predetermined relationship.
- the database stored as a single data structure is accessed based on the receiving node information of this message added to the header of the message, and all data contained in the subtree whose root is the receiving node information is accessed.
- This is a program for realizing the step of searching for the node information of the above and the step of transferring the message to the distribution destination corresponding to all the searched node information.
- FIG. 1 is a block diagram showing the configuration of the first exemplary embodiment of the present invention.
- FIG. 2 is a flowchart showing the operation of the first embodiment of the present invention.
- FIG. 3 is a flowchart showing an operation related to a transmission message according to the first embodiment of the present invention.
- FIG. 4 is a diagram illustrating an example of a transmission message according to the first embodiment of this invention.
- FIG. 5 is a diagram illustrating an example of an error message according to the first embodiment of this invention.
- FIG. 6 is a diagram illustrating an example of a node leaving request message according to the first embodiment of this invention.
- FIG. 7 is a flowchart showing an operation relating to a node leave request message according to the first embodiment of the present invention.
- FIG. 8 is a flowchart showing an operation relating to an error message according to the first embodiment of the present invention.
- FIG. 9 is a flowchart showing an operation relating to the node registration request message according to the first embodiment of the present invention.
- FIG. 10 is a diagram illustrating an example of a node registration request message according to the first embodiment of this invention.
- FIG. 11 is a block diagram showing the configuration of the second exemplary embodiment of the present invention.
- FIG. 12 is a block diagram showing the configuration of the policy engine according to the second embodiment of the present invention.
- FIG. 13 is a flowchart showing the operation of the policy engine according to the second embodiment of the present invention.
- FIG. 14 is a flowchart illustrating an operation relating to a node registration request message according to the second embodiment of this invention.
- FIG. 15 is a diagram illustrating an example of a node registration request message according to the second embodiment of this invention.
- FIG. 16 is a flowchart showing an operation relating to a transmission message according to the second embodiment of the present invention.
- FIG. 17 is a block diagram showing a specific example of the second embodiment of the present invention.
- FIG. 18 is a block diagram showing a specific example of the third embodiment of the present invention.
- FIG. 19 is a part of a flowchart showing the operation of the node registration request message according to the third embodiment of the present invention.
- FIG. 20 is a part of a flowchart showing the operation of the node registration request message according to the third embodiment of the present invention.
- FIG. 21 is a block diagram for explaining a conventional technique.
- FIG. 1 a block diagram of a first embodiment of the present invention is shown.
- a message router (message distribution device) 200, a node manager (node management device) 400, a plurality of nodes 500 to 502 for transmitting and receiving messages are connected via a network 100.
- the nodes exchange messages with each other via the message router 200.
- the processing units 510 to 512 of the nodes 500 to 502 create messages as shown in Fig. 4, which will be described in detail later, and transmit the messages to other nodes using the message transmission units 530 to 532. I do. Note that message reception from other nodes is performed by the message receiving units 520 to 522.
- This message is an application protocol such as HTTP (HyperText Transfer Protocol) message or SIP (Session Initial Protocol), and is divided into a header part and a payload.
- the header portion has a header specific to the present embodiment (for example, message: send) in addition to the header specified in HTTP.
- the message receiving unit 210 of the message router 200 connected to the network 100 receives the message.
- Message receiving section 210 passes the received message to splitter 220.
- the splitter (separation means) 220 divides the message into a header part and a payload part, and passes the message part to the header interpretation part 230 and the payload part to the synthesis part 260, respectively.
- the header interpretation unit (interpretation unit) 230 uses the value of an attribute (for example, receivers attribute) indicating 0 or more receiver groups in the header portion of the message, and passes through the DB read unit (search unit) 240 Then, appropriate node information is extracted from the domain tree 310 stored in the database 300.
- the node information is position information such as a URL (Uniform Rsource Locator) of the node 500 or the like.
- the domain tree is a complete structure that has a set of node information and a set of node information called domains. Clauses are named, and node information or domain can be specified uniquely by joining the names of the clauses with "/" as a delimiter from the root of the tree. This name is called the domain path.
- the value of the receivers attribute is a domain path.
- the above “appropriate node information” is the node information specified by the domain path of the receivers attribute value, Alternatively, it is all the node information included in the sub-tree having the domain specified by the domain path as a point.
- the header interpreting unit 230 passes the set of node information and the header part to the header rewriting unit 250.
- the header rewriting unit (rewriting means) 250 removes the receivers attribute and its value from the message, and replaces it with the attribute indicating the message router location information (for example, routerURL attribute) and the message as its value. Add location information such as the URL of the router and send it to the synthesis unit 260.
- the combining section (combining means) 260 adds a payload received from the splitter 220 to the header from the header rewriting section 250 to form a new message.
- the combining unit 260 sends the message and the location information such as the URL indicating the node received from the header rewriting unit 250 to the message transfer unit 270.
- the message transfer unit (transfer unit) 270 transmits the message to the node specified by the position information such as the URL received from the synthesis unit 260.
- the message transmitted from the message transfer unit 270 arrives, for example, at the message receiving unit 521 of the node 501, and is passed to the processing unit 511 for processing.
- Node information on nodes such as node 500 needs to be registered in the database 300 in advance.
- the node manager 400 receives the node registration request. That is, the registration request receiving unit 420 receives the registration request message of the node and transmits it to the message interpreting unit 410.
- the message interpreter 410 obtains the position information such as the URL of the message router registered in the message router table 440.
- the message interpreting unit 410 sends the message to the message router 200 via the message transmitting unit (transfer means) 4330.
- the response receiving section 450 receives the result of the registration request sent to the message router 20 °.
- the response unit 460 receives the message indicating the response result from the response reception unit 450, and transmits it as a response message to the registration requester.
- FIG. 2 is a flowchart showing message transmission in the operation of the first embodiment of the present invention.
- the processing unit 5100 of the node 500 requests the message transmission unit 5300 to send a message to the message router 200 to the network 100 (step D10).
- the message receiving section 210 of the message router 20 receives the message (step D20).
- the splitter 220 splits the message into a header and a payload, and passes the header to the header interpreter 230 and the payload to the synthesizer 260 (step D30).
- the header interpreter 230 interprets the header and obtains a value of an attribute (for example, a message attribute) representing the type of the message (step D40).
- the value of the me ssage attribute is either a message transmission message (for example, the value of the message attribute is “sen dj”), a node leave request message (for example, ⁇ 1 e a V e J), or an error message (for example, "Error”). Processing branches depending on the value (step D50).
- FIG. 3 shows a process in the case where the value of the message attribute is a message transmission message, that is, “send” in the operation of the first embodiment of the present invention.
- the header interpreting unit 230 interprets the header, and requests the DB reading unit 240 to acquire appropriate node information in accordance with the value of the attribute (for example, the recivers attribute) representing the recipient of the header.
- the DB reading unit 240 returns the set of node information as the result to the header interpreting unit 230 (Step B40). The next process is repeated until the set is empty (step B60).
- the header interpreting section 230 passes one of the elements of the set of header information to the header rewriting section 250 (step B70).
- the header rewriting unit 250 rewrites the header.
- the rec eivers attribute is deleted from the header, and an attribute indicating the location information such as the URL of the currently used message router 200 (e.g., a route rUrl attribute) is added.
- the value of the routerrUr1 attribute is location information such as the URL of the message router 200 currently used.
- the rewritten header is passed to the synthesizing unit 260 (step B80).
- the combining section 260 combines the header received from the header rewriting section 250 and the payload from the splitter 220, and passes them to the message transfer section 270 (step B90).
- the message transfer unit 270 sends a message to the node indicated by the node information (step B100). From the node information, the node information that has become the recipient this time is deleted from the set of node information, and the process returns to step B60 to collect the node information. Steps B70 to B100 are repeated until the combination becomes empty. When the set of node information is empty, the process ends.
- FIG. 7 shows, as a continuation of the flowchart of FIG. 2, the operation of the first embodiment of the present invention, in which the value of the message attribute is a value indicating a request to leave the node, that is, the processing when ⁇ 1 eave J ''
- the header interpreting unit 230 interprets the header and requests the DB writing unit 290 to delete the node specified by the value of the attribute (for example, the sender attribute) indicating the transmitting node of the header (step E 40).
- the DB writer 290 deletes the specified node information from the database 300 (step E50).
- FIG. 8 shows a case where the value of the message attribute is an error message, that is, “error”, as a continuation of the flowchart of FIG. 2 in the operation of the first embodiment of the present invention.
- the node ⁇ message router that is the recipient of the message issues an error message when an error occurs in the processing of the received message whose value of the message attribute is “send”. For example, when an error occurs in the recipient node 500, the processing unit 510 creates an error message.
- the attribute of the message attribute is “error”, and the value of the sender attribute is a domain path indicating the sender of the original message in which the error occurred, and the attribute whose message identifier is the value (for example, the message ID attribute).
- the value of “Tsue” is the same value as the value of the message id attribute of the original message, and the attribute of receiver 3 is the domain path of the node that detected the error (that is, the receiver node 500).
- the created error message is sent to the location information, such as the message router URL, which is the value of the route rUr1 attribute of the original message.
- the header interpreting unit 230 interprets the header, and requests the DB reading unit 240 to acquire appropriate node information according to the value of an attribute (for example, a sender attribute) indicating the transmitting node of the header.
- DB reading section 240 returns the result to header interpreting section 240 (step F40).
- the header interpreting unit 230 acquires the location information such as URL from the node information in the response unit 280, and transmits an error message to the node specified by the location information such as URL (step F50).
- FIG. 9 shows the operation of the first embodiment of the present invention.
- the operation of registering 0 is shown.
- a message requesting addition of the node 500 is sent to the node manager 400 via the network 100 as a message as shown in FIG. 10 (step A10).
- the request receiving section 420 of the node manager 400 receives the message and transmits it to the message interpreting section 410.
- Message interpreting section 410 interprets the message (step A20). During the interpretation process, it is determined whether there is an error in the message (step A30). If an error is found in the message, the message interpreter 410 requests the responder 460 and returns an error message to the additional requester of the node 500 (step A35).
- the message interpreter 410 refers to the message router table 440 and obtains the position information such as the URL of the message router corresponding to the second attribute value (step A40). In the first embodiment, it is assumed that only one message router is registered in the message router table 440, so that the same location information such as the same URL is always returned.
- the message interpreter 410 transfers the registration request message of the node 500 to the message router (step A50).
- the message receiving section 210 of the message router 200 receives the message and throws it to the splitter 220 (step A60).
- the splitter 220 separates the message into a header and a pay mouth, and passes the header to the header interpreter 230 and the payload to the synthesizer 260 (step A 70).
- the header interpreter 230 interprets the contents of the header, and uses the DB writer (registering means) 290 to retrieve location information such as a URL with an attribute (eg, sender URL attribute) indicating the location information of the sending node. It is added as domain information to the domain specified by the sender attribute in the domain tree 310 (step A80).
- the header interpreting unit 230 transmits an additional success message including the location information such as the URL of the message router 200 to the response receiving unit 450 via the response unit 280 (step A90).
- the response receiving section 450 requests the response section 460 to transfer an addition success message to the node 500 (step A100).
- This message includes the location information such as the URL of the message router 200.
- the node 500 sends a message whose message attribute value is “send” to the message router indicated by the location information such as the URL. Send the message.
- UR L 3 ⁇ 4r htt of message '200 is: // distributor, company, com / servlet / istribut or, and the URL of ⁇ r ⁇ ma'ne 400 is http: // nodemanager. om / servlet / distributor "and the URL of node 500 as" http: //node500.portia.com/app.
- the node 500 is registered in the message router 200 as a domain path / nodes / senders / node500.
- the node registration requester issues a message as shown in FIG. 10 to the node manager 400.
- the first to fourth lines are the HTTP header
- the fifth to ninth lines are the attributes defined in this embodiment.
- the 10th line (blank line) is the header and payload separator
- the 11th and subsequent lines are the payload.
- the HTTP header and the attribute are referred to as a header.
- the message attribute indicates the type of message, and its value is defined as “; join”, “leav ej”, “send”, and “error”.
- Join is a node registration request message (Fig. 10)
- leave is a work (leave) request message to remove a registered node from registration (Fig. 6)
- S end is a data communication message (Fig. 6).
- Fig. 4 "6 1: 0 1:” becomes an error notification message (Fig. 5) when an error occurs in the "36: [1 (1)” message.
- the node registration requester issues a request message to the node manager 400.
- "1 ea V e" message leaving nodes 50 0 issues a ⁇ 1 e a V e J message to the message router 200.
- the registered node sends a message to the message router 200 for the “send” message and the “leave” message.
- the sender attribute specifies the registration destination of the registration target node by domain path.
- the message id is an identifier given by the registration requester to ensure that the message is uniquely guaranteed globally.
- the senderUr1 attribute is a URL specifying the message receiving unit 520 of the node 500.
- the message to node 500 that is, / nodes / senders / node500, is in this UR Sent to L.
- the attribute indicating the transmission mode (eg, mode attribute) specifies the mode of transmitting messages to node 500.
- the message receiving section 520 of the node 500 opens the server socket as a server and sends a message. waiting. If the receiving node cannot open a server socket, and the mode attribute value (for example, “passiVe”), the message receiver 520 periodically polls the message router 200, Check if a message addressed to 500 has not arrived. ⁇ ⁇ a ssi V e J is used when the node 500 cannot open a server socket because it is inside a firewall or has no global IP address.
- This registration request message is received by the request receiving section 420 and transmitted to the message interpreter 410.
- Message router URL "http: // distributor, company, com / servlet / distributor 3 ⁇ 4: obtained from message router table 440. Book; ⁇
- the message sender 430 has the URL "http: ⁇ distributor. Company, com / servlet / distributor, that is, Send a request message.
- the message receiving unit 210 of the message router 200 receives this message, and the splitter 220 cuts out the first to ninth lines in Fig. 10, which is the header part of the message, and the header interpreter Pass to 2 3 0.
- the header interpreting unit 230 uses the D @ writing unit 290, and uses the node information "http: ⁇ node500.portia.node" of the node 500 as an element of the domain / nodes / senders of the domain tree. com / app "in database 300.
- the header interpreting unit 230 uses the response unit 280 to return a success response to the response receiving unit 450, and the response receiving unit 450 communicates with the sender of the registration request message via the response unit 460. Returns a response.
- Node 5 0 1 is registered in the domain ompany / salesDiv- / node 50 1, and its URL is "http: // node501. Portia. Com / app '.
- Node 5 0 2 is in the domain / company / salesDiv / lstSec / node502 and its URL is' http: // node502. portia. com / app o.
- the processing unit 510 of the node 500 transmits the message shown in FIG.
- the value of the receivers attribute is a domain path that represents a set of receivers (message delivery destinations).
- the nodes 501 and 502 included in the subtree rooted at the domain / company / salesDiv are the transmission targets. This message is transmitted from the message transmitting unit 530 and received by the message receiving unit 210.
- the splitter 220 passes the header of the message shown in FIG.
- the header interpreter 230 extracts the value / nodes / recievers of the rec eivers attribute, and requests the DB ⁇ c inserter 240 to return all the nodes of the subtree that note the domain / nodes / recievers.
- the header interpreter 230 obtains “http://node501.portia.com/app” and “http://node502.portia.com/app” as node information.
- the header rewriting unit 250 first calculates the attribute value "http: // distributor, company.
- Com / servlet / distributor as the route rUr1 attribute, and the receivers attribute / com pany / salesDiv Convert the header to be / node501, / company / salesDiv / lstSec / node502.
- the header rewriting unit 250 passes the converted header to the synthesizing unit 260, and the synthesizing unit 260 attaches the payload (from the 10th line onward in FIG. 4) to the header and sends it to the message transfer unit 270 to the nodes 501 and 502. Ask to send each message.
- the domain tree 310 of the database 300 if it is a company organization, departments, sections, departments, groups, etc. are divided into branches from a large organization to a small organization sequentially. It is assembled as a file structure so as to be extended and related to each other in advance.
- the company organization is determined by the receivers attribute value, which is a domain path representing a set of recipients (message delivery destinations). If the sales department (salesDiv) of (co mpany) is specified, all nodes (recipient groups) included in the subtree whose root is the sales department (salesDiv) of this company organization (company) are sent. It is a target.
- processing unit 512 of node 502 For example, suppose that the message receiving unit 522 detects that reception has failed. At that time, the processing unit 512 creates the message shown in FIG. In this case, the message attribute is “error”, the sender attribute is the domain path of node 500 that is the sender of the original message / node / senders / node500, and the value of the receivers attribute is the domain node of node 502. In / company / salesDiv / lstSec / node502, the value of the messageid attribute is the same message id as the original message.
- the processing unit 5 1 2 uses the message transmission unit 532 to transmit the message to the message router 200 indicated by the root e rUr 1 attribute of the original message.
- the message received by the message receiving unit 210 passes through the splitter 220, and the header receiving unit 230 sends the node information URL “http: // node500portia. Com / app” of the node 500 specified by the domain path of the sender attribute. obtain.
- the header and the URL are transmitted to the synthesizing unit 260, synthesized with the payload, and transmitted to the node 500 via the message transfer unit 270.
- the processing unit 510 of the node 500 creates the 1 e a V e message shown in FIG.
- the sender attribute is the domain node / node / senders / node 500 of node 500.
- the message is transmitted to the message router 200 using the message transmission unit 530.
- the splitter 220 cuts out the header of the message received by the message receiving unit 210, and passes it to the header interpreting unit 230.
- the header interpreter 230 extracts the value of the second attribute / node / senders / node500, and deletes the node information of / node / senders / node500 using the DB writer 290.
- the 1 e a V e message is directly transmitted from the node 500 to the message router 200 has been described.
- the 1 e a V e message may be transmitted from the node 500 to the message router 200 via the node manager 400.
- the database stores node information in a tree data structure.
- a domain path that specifies the nodes of the tree allows all the nodes contained in the subtree to be specified. Therefore, it is possible to specify a node that reflects the inclusion relationship between the specified topics.
- FIG. 11 is a block diagram showing a second embodiment of the present invention.
- the message router 600 has a policy engine 6100 in place of the header rewriting section 250 of the message notator 200 in FIG.
- the policy engine (matching means) 610 receives the location information (for example, URL) of the transmission target candidate node, a set of pairs of policies (policies) attached to it, and a header, and receives the transmission target location information. And a pair of headers as output.
- the policy engine 610 checks whether the policy of the transmission target candidate node matches the header, and if it matches, creates a new header and determines whether it matches another policy.
- Figure 12 shows the structure of the policy engine.
- the ordering unit 650 extracts a set of these node information according to a certain rule, and sequentially puts them in the FIFO queue 640.
- the fixed rule may be, for example, a method of randomly extracting data using random numbers, and is not limited to this.
- the F IFO queue 640 is a matrix for storing node information.
- the node information can be extracted in the order of input into the matrix.
- the buffer 670 can store at most one header 691 of the message transmission message. Therefore, when the header is taken out from the buffer 670, the number of stored headers becomes zero.
- the policy is a description composed of a collating unit and a rewriting unit.
- the collating unit describes the pattern of the message header, and can determine whether the header can be collated by the collating unit.
- the rewriting unit rewrites the contents of the header in consideration of the collation status of the collation unit.
- the matching unit describes the header attribute value in a regular expression, determines whether matching is possible by checking the attribute value of the header against the regular expression, and the rewriting unit specifies a specific character that specifies the matched attribute value.
- a policy of replacing with a column is conceivable.
- the policy has a rewriting unit in addition to the matching unit.
- This rewriting unit describes that when a node can receive, that is, when it matches (matches) the policy of that node, other nodes match the receiving conditions.
- the policy matching check unit 630 sequentially inputs the node information and the header, determines whether the node information policy matching unit can match the node, stops if the matching is impossible, and if the matching is possible. , Node information, that is, a set of position information and a header, and a set of collation information and a header are output.
- the header rewriting unit 250 is the same as the rewriting unit 250 in FIG. 1, and receives a set of header and position information as input.
- the value of the attribute indicating the receiver of the header (for example, the receivers attribute) is set as the domain path in which the node information is stored, and the value of the attribute indicating the position information of the message router (for example, the routerUr1 attribute) is set as the value.
- the position information of the messager 600 is set, and the position information and the header are output as a set 690.
- the rewriting unit 660 receives the information of the collation work performed by the policy collation checking unit 630, the policy, and the header, checks the contents of the policy rewriting unit, rewrites the header, and outputs the rewritten header.
- the buffer 670 takes in one header 691 from outside (step P10).
- the ordering unit 650 orders the node information set 680, which is a set of the node URL and the policy, according to a certain rule, and stores it in the FIFO queue 640 (step P20).
- the fixed rule may use, for example, a random ordering method as described above.
- the policy matching check unit 630 retrieves the URL and the policy from the FIFO queue 640 and the header from the buffer 670 (step P50). At this time, if the node information does not exist in the FIFO queue 640, the processing is stopped (step P30). If there is no header in the buffer 670, the processing is stopped. Step P 40).
- the policy matching checking unit 630 checks whether the policy matching unit can match the header (Step P60). If collation is not possible, the header is returned to the buffer 670, and the process is restarted from Step P50 (Steps P80, P85).
- the URL and the header are passed from the policy matching / checking unit 630, and the rewriting unit 250 rewrites the attribute indicating the receiving node of the header (for example, the receivers attribute) to the domain path of the domain in which the node information is stored. Then, an attribute (routerUr1 attribute) indicating the position information of the message router is added as the position information of the message router, and a pair 690 of the position information and the header is output (step P90). Next, check if there is a rewrite part in the page. If not, the operation of the polyshene engine is terminated (step P100).
- the rewriting unit 660 receives the pair of the collation information and the policy and the bedder from the policy collation checking unit 630, rewrites the header according to the rewriting unit of the policy, and places it in the buffer 670 (step P110). After step P110, the process returns to step P50, and the process is repeated.
- FIG. 15 shows a node registration request message according to the second embodiment of the present invention.
- the difference from the node registration request message in the first embodiment of the present invention shown in FIG. 10 is that an attribute indicating a policy (for example, a po1icy attribute) exists.
- header interpreting section 230 has an attribute (eg, sender U) indicating location information of the transmitting node.
- attribute eg, sender U
- the value of the attribute indicating the policy 320 is added to form a group, and the pair is registered in the domain stored in the database 300.
- Steps other than step AP80 in FIG. 14, such as AP I0, AP20, etc., are the same as steps A10, A20, etc. in FIG.
- the header interpreting unit 230 interprets the header, and requests the DB reading unit 240 to acquire appropriate node information in accordance with the value of an attribute (for example, the recivers attribute) indicating the recipient of the header.
- the DB reading section 240 returns the set of node information as the result to the header interpreting section 230 (step C60).
- the header interpreter 230 passes the set of node information and the header to the policy engine 610 (step C70).
- the policy engine 610 outputs a pair of a URL and a header (Step C80). When the policy engine 610 stops outputting the pair of the position information and the header, the process is terminated (step C85).
- the policy engine 610 passes the header to the synthesizing unit 260 (step C90).
- the combining unit 260 combines the header received from the header rewriting unit 250 and the payload from the splitter 220, and passes it to the message transfer unit 270 (step C95).
- the message transfer unit 270 sends a message to the node indicated by the node information (Step C100). The process is repeated from step C100 to step C70.
- * ,," and node 502 is registered with the policy "sender / nodes / receivers /
- * , " and node 502 is registered with the policy "sender / nodes / receivers /
- Sending the "s e nd" message sends the message shown in Figure 4.
- the value of the s nd er genus is "/ nodes / senders / node500”.
- a set of node information on the node 501 and node information on the node 502 can be obtained from the rec eiv ers attribute of the message.
- the ordering unit 650 of the policy engine 610 puts the node information of the node 502 and the node information of the node 501 into the FI FO queue 640 at random in the order.
- the policy collation detection unit 630 sets the URL of the node 502 to “http: ⁇ nod e502. Portia.com/app/ Get. Since the value of the sender attribute is "/ nodes / receivers /" in the regular expression, the matching unit does not match the sender attribute value of the header. So, the next node 5 0 1 of the URL "http:. ⁇ node50 1.
- the rewriting unit 250 replaces the value of the receivers attribute with URL http. '// node50 1.ortia.com/ap of node 501, and replaces the routerUr1 attribute.
- the raw URL is "http: // distributor, company, com / servlet / distributor” of the message norator 600 and the header is passed to the synthesis unit 260.
- the synthesis unit 260 combines the header and the payload. The message is transmitted from the message transfer section 270 to the node 510.
- the policy matching section 630 passes the policy and header to the rewriting section 660.
- the rewriting part of the policy is an asterisk "*" after "", which means that the entire header is copied and output as it is, so the header is placed in the buffer 670 as it is.
- 630 tries to get the next node information from the FIFO queue 640, but stops processing because it is already empty.
- the service using node 505 sets the user name and password in the transmission message to the value of the authorization attribute in the authentication method Basic.
- the attribute Pos-Auth does not exist in the transmission message of the service providing node 507. Therefore, the message matches the policy verification unit "! Pos-Auth" of the authentication server 506, and the message is transferred to the authentication server 506.
- the authentication server 506 extracts the user name and password included in the authorization attribute value and performs authentication. If the authentication succeeds, “PoS-Auth: true” is added to the header, and if the authentication fails, “PoS-Auth: false” is added. If the transferred message has been successfully authenticated, the value of the PoS-Auth attribute is "true”, so the message conforms to the policy of the service providing node 507, and is transferred to the service using node 505. Provided.
- the policy engine 610 by using the policy engine 610, it is possible to limit the recipients specified by only the domain path. This makes it possible to determine the delivery destination based on the attribute value in the message header. By changing the attribute value, the status of the message can be displayed and the delivery destination can be changed. In other words, the node to be delivered first is determined first according to the state of the message, and the delivery destination is determined sequentially according to the change in the state of the message, enabling inter-node cooperation.
- FIG. 18 is a block diagram showing a third embodiment of the present invention.
- the difference from the second embodiment shown in FIG. 11 is that a firewall 700 is placed between the message router 600 and the network 100, and the firewall 703.
- Other configurations are the same as those in FIG. The same applies to the first embodiment shown in FIG.
- firewall 700 it is possible to set from which IP address the node manager 400 is permitted to access.
- the firewall 701 can be set from the node 500.
- An authentication table 470 is provided in the node manager 400. The authentication table 470 checks whether the user name and password from the message interpreter 410 are correct.
- the authentication method there is a BASIC authentication method based on an attribute of the attribute au- torizonat defined in HTTP.
- FIGS. 19 and 20 are flowcharts showing the operation of the third embodiment of the present invention.
- the message interpreting unit 410 that has received the node registration request message confirms that the authentication information is correct in the authentication table (steps AS 35 and AS 37).
- Sending node The node specified by the attribute indicating the location information (for example, the senderUr1 attribute) is set to be transmissible (step AS45), and at the end of the processing, the registered node 500 is processed by the firewall 701. A point has been added to confirm that is correct (step AS 12 0).
- Other processes are the same as those in FIG. 14 and are indicated by the same reference numerals.
- node 500 When registering node 500, ⁇ 1chome? Take the authentication method (for example, Basic), user information, and password as the value of the 11thhorization attribute.
- the node manager 400 performs the same processing as in the second embodiment of the present invention, and further confirms that the user information and the password are listed on the authentication table 470.
- the message interpreter 410 sends the message to the message router 600 by sending the sender's individual value "http://node500.portia.com/app node500.portia.com” to the firewall. Add permissions.
- node 500 looks at the returned message router, UR1, http: // distributor, company, com / servlet / distributor, and checks firewall 701, distributor, company. , com "Set to allow only the access of the user.
- the malicious server is not authenticated and cannot be registered. If a server that has not registered attempts to access the message router, the firewall 700 denies access. Access to node 500 is rejected by firewall 701. Therefore, it is possible to prevent attacks using a registered server such as node 500 as a stepping stone. Even if a server is not registered, even if it is a stepping stone, access from the unregistered server can be denied by the firewall, thereby preventing distributed service denial attacks.
- each of the above embodiments can be stored in a recording medium in advance as a program, read by a CPU (computer), and executed sequentially.
- the database 300 in each of the above embodiments is illustrated as being provided separately from the message routers 200 and 600, it is provided in the message routers 200 and 600. Is also good. Although only one message router is shown, there are actually multiple message routers. This is for simplification.
- the first effect of the above-described embodiment is that even when a topic defining a message recipient includes an inclusion relation, a message can be transmitted to an appropriate node according to the inclusion relation. .
- the reason for this is that node information is managed by a domain data structure called a domain, and the inclusion relationship can be represented by a domain.
- the second effect is that cooperation among a plurality of nodes can be realized. For example, a message can be sent to a node that provides one service and then sent to a node that provides another service.
- the reason is that the state of the message is managed as an attribute of the header by the policy, and an appropriate delivery destination can be specified according to the state. For example, when a node that provides a certain service rewrites the attribute value of the header and transfers the message, the policy considers the service to be completed and transfers the message to the node that provides the next service. Can be described.
- the third effect is that a denial of service attack against registered nodes / message routers can be prevented.
- the reason is that, by registering, a node can utilize the fact that it is limited to communicating only with a message router, provide a firewall, and reject communication with other nodes. Also, since the message router communicates only with registered nodes, a firewall can be set to communicate only with registered nodes to prevent denial of service attacks.
- the fourth effect is that distributed denial of service attacks against registered nodes / message routers can be prevented.
- the reason is that, by registering, a node can use the fact that it is limited to communicating only with a message router, establish a firewall, and reject communication with other nodes. . As a result, the registered node cannot be used as a springboard. Also, since the message router communicates only with the registered nodes, the message router cannot be used as a stepping stone by setting the firewall to communicate only with the registered nodes.
Abstract
Description
Claims
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2005503478A JP4356693B2 (ja) | 2003-03-12 | 2004-02-27 | メッセージ配信装置及びその方法並びにシステム及びプログラム |
US10/548,561 US20060090007A1 (en) | 2003-03-12 | 2004-02-27 | Message delivery apparatus, method thereof, system thereof, and program thereof |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003065862 | 2003-03-12 | ||
JP2003-065862 | 2003-03-12 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2004081800A1 true WO2004081800A1 (ja) | 2004-09-23 |
Family
ID=32984518
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2004/002333 WO2004081800A1 (ja) | 2003-03-12 | 2004-02-27 | メッセージ配信装置及びその方法並びにシステム及びプログラム |
Country Status (4)
Country | Link |
---|---|
US (1) | US20060090007A1 (ja) |
JP (1) | JP4356693B2 (ja) |
TW (1) | TW200426592A (ja) |
WO (1) | WO2004081800A1 (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011135575A (ja) * | 2009-12-24 | 2011-07-07 | Samsung Electronics Co Ltd | コンテンツ名ベースの端末装置、そのルーティング方法、及びルーティングテーブルを用いるネットワーク装置 |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7467399B2 (en) | 2004-03-31 | 2008-12-16 | International Business Machines Corporation | Context-sensitive confidentiality within federated environments |
US7454479B2 (en) * | 2004-05-28 | 2008-11-18 | Microsoft Corporation | Flexible teleport architecture |
US7945659B2 (en) * | 2005-01-05 | 2011-05-17 | Barclays Capital Inc. | Technology administrative portal |
US7583662B1 (en) * | 2005-04-12 | 2009-09-01 | Tp Lab, Inc. | Voice virtual private network |
US20070204275A1 (en) * | 2005-08-29 | 2007-08-30 | Rhysome, Inc. | Method and system for reliable message delivery |
CN100563203C (zh) * | 2005-11-11 | 2009-11-25 | 华为技术有限公司 | 通信网络中组播树叶子节点网元信号传送的方法 |
US8005000B1 (en) * | 2007-04-06 | 2011-08-23 | Cisco Technology, Inc. | Effective measurement/notification of SLA in a service oriented networked environment |
US8996728B2 (en) * | 2010-10-01 | 2015-03-31 | Telcordia Technologies, Inc. | Obfuscating network traffic from previously collected network traffic |
US20130091192A1 (en) * | 2011-10-11 | 2013-04-11 | Mohammed Saleem Shafi | Asynchronous messaging bus |
CN105721334B (zh) * | 2014-12-04 | 2020-02-18 | 中国移动通信集团公司 | 确定传输路径和更新acl的方法及设备 |
US10789301B1 (en) * | 2017-07-12 | 2020-09-29 | Groupon, Inc. | Method, apparatus, and computer program product for inferring device rendered object interaction behavior |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH09214556A (ja) * | 1995-11-30 | 1997-08-15 | Toshiba Corp | パケット転送方法、パケット処理装置、パケット暗号化方法、パケット復号化方法及びパケット暗号処理方法 |
JPH11134239A (ja) * | 1997-10-29 | 1999-05-21 | Fujitsu Ltd | 共用ファイル管理装置 |
JP2001257720A (ja) * | 2000-03-14 | 2001-09-21 | Kddi Corp | Dnsサーバ、dhcpサーバ、端末および通信システム |
JP2002335274A (ja) * | 2001-03-06 | 2002-11-22 | Fujitsu Ltd | パケット中継装置およびパケット中継方法 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
AU2002211482A1 (en) * | 2000-10-04 | 2002-04-15 | Enic Corporation | Providing services and information based on a request that includes a unique identifier |
US7305352B2 (en) * | 2001-03-21 | 2007-12-04 | Ricoh Company, Ltd. | System for and method of facilitating sales activities, and program generator for generating a program for realizing the same |
US7401148B2 (en) * | 2001-11-16 | 2008-07-15 | At&T Mobility Ii Llc | System for customer access to messaging and configuration data |
US7855972B2 (en) * | 2002-02-08 | 2010-12-21 | Enterasys Networks, Inc. | Creating, modifying and storing service abstractions and role abstractions representing one or more packet rules |
-
2004
- 2004-02-27 US US10/548,561 patent/US20060090007A1/en not_active Abandoned
- 2004-02-27 TW TW93105056A patent/TW200426592A/zh unknown
- 2004-02-27 WO PCT/JP2004/002333 patent/WO2004081800A1/ja active Application Filing
- 2004-02-27 JP JP2005503478A patent/JP4356693B2/ja not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH09214556A (ja) * | 1995-11-30 | 1997-08-15 | Toshiba Corp | パケット転送方法、パケット処理装置、パケット暗号化方法、パケット復号化方法及びパケット暗号処理方法 |
JPH11134239A (ja) * | 1997-10-29 | 1999-05-21 | Fujitsu Ltd | 共用ファイル管理装置 |
JP2001257720A (ja) * | 2000-03-14 | 2001-09-21 | Kddi Corp | Dnsサーバ、dhcpサーバ、端末および通信システム |
JP2002335274A (ja) * | 2001-03-06 | 2002-11-22 | Fujitsu Ltd | パケット中継装置およびパケット中継方法 |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2011135575A (ja) * | 2009-12-24 | 2011-07-07 | Samsung Electronics Co Ltd | コンテンツ名ベースの端末装置、そのルーティング方法、及びルーティングテーブルを用いるネットワーク装置 |
Also Published As
Publication number | Publication date |
---|---|
TWI295779B (ja) | 2008-04-11 |
JP4356693B2 (ja) | 2009-11-04 |
TW200426592A (en) | 2004-12-01 |
US20060090007A1 (en) | 2006-04-27 |
JPWO2004081800A1 (ja) | 2006-06-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7409425B2 (en) | Selective transmission of an email attachment | |
Clark et al. | New arch: Future generation internet architecture | |
US7428590B2 (en) | Systems and methods for reflecting messages associated with a target protocol within a network | |
US6374292B1 (en) | Access control system for an ISP hosted shared email server | |
JP4628467B2 (ja) | 中継装置、通信方法及びコンピュータプログラム | |
US8972590B2 (en) | Highly accurate security and filtering software | |
US7818565B2 (en) | Systems and methods for implementing protocol enforcement rules | |
US7707401B2 (en) | Systems and methods for a protocol gateway | |
US7620974B2 (en) | Distributed traffic scanning through data stream security tagging | |
US20160269440A1 (en) | System and method for managing email and email security | |
US7725931B2 (en) | Communications system with security checking functions for file transfer operation | |
US20040088423A1 (en) | Systems and methods for authentication of target protocol screen names | |
EP1453278A2 (en) | Name resolution server and packet transfer device | |
US20060036690A1 (en) | Network protection system | |
US20090299937A1 (en) | Method and system for detecting and managing peer-to-peer traffic over a data network | |
US7058683B1 (en) | Methods and apparatus for providing a virtual host in electronic messaging servers | |
WO2004081800A1 (ja) | メッセージ配信装置及びその方法並びにシステム及びプログラム | |
US20080104688A1 (en) | System and method for blocking anonymous proxy traffic | |
US7703124B2 (en) | System and method for implementing a private virtual backbone on a common network infrastructure | |
Komala et al. | An Enhancement of Service Function Chaining in Metro Mobile Ad-Hoc Networks in 5G Communication Using Machine Learning | |
Mogul | Using screend to implement IP/TCP security policies | |
TWI662813B (zh) | 具有固定路由的網路架構 | |
JP2000115228A (ja) | 電子メール用メールサーバ及びメールクライアント | |
CN117614647A (zh) | 通信系统及通信方法 | |
KR200349700Y1 (ko) | 웹서비스를 기반으로 하는 가상 라우팅 장치 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 2005503478 Country of ref document: JP |
|
ENP | Entry into the national phase |
Ref document number: 2006090007 Country of ref document: US Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 10548561 Country of ref document: US |
|
122 | Ep: pct application non-entry in european phase | ||
WWP | Wipo information: published in national office |
Ref document number: 10548561 Country of ref document: US |