Organizing resources into collections to facilitate more efficient and reliable resource access
22 claims: 8 independent, 14 dependent
- 1複数のコンピュータを含む名前空間フェデレーションインフラストラクチャにおいて該複数のコンピュータの少なくとも一台によって実行される、異なるネットワーク通信スキームを有する名前空間であって階層構造の複数の異なる名前空間の各々において横断可能な名前空間パスを通じたアクセスが可能なリソースを、前記階層構造の複数の異なる名前空間において登録するための方法であって、前記異なるネットワーク通信スキームの少なくとも2つが、特定の名前空間内で前記リソースを識別するためのシンタックスを識別する異なるリソースを有している、方法において、 前記リソースについて一意のリソース識別子を確立するステップであって、該一意のリソース識別子を用いて前記階層構造の複数の異なる名前空間において前記リソースを識別可能であり、前記階層構造の複数の異なる名前空間中の各名前空間が前記異なるネットワーク通信スキームとは別のネットワーク通信スキームを有しており、前記名前空間フェデレーションインフラストラクチャにおいて実装されるすべての名前空間を通して前記一意のリソース識別子が一意である、ステップ、 前記階層構造の複数の異なる名前空間中の、前記異なるネットワーク通信スキームからの第1のネットワーク通信スキームを有する第1の名前空間において、前記リソースの有用性を発行するステップ、 前記リソースを識別するために第1のネットワーク通信スキームを用いて横断される前記第1の名前空間において、前記一意のリソース識別子を第1の名前空間ノードリソースにリンクさせるステップ、 前記第1の名前空間における前記横断可能な名前空間パスを横断して、該第1の名前空間において有用性が発行された前記リソースを突き止めるステップ、ここで、該ステップは、前記第1の名前空間における1つまたはそれよりも多い名前空間ノードリソースにナビゲートして、前記第1の名前空間内での前記リソースの名前空間ロケーションを判定することを含んでいる、 前記階層構造の複数の異なる名前空間中の、前記異なるネットワーク通信スキームからの第2のネットワーク通信スキームを有する第2の名前空間において、前記リソースの有用性を発行するステップ、ここで、該ステップは、前記第2の名前空間内の少なくとも複数のノードに、前記リソースが前記第2の名前空間内に存在することを知らせる通知をブロードキャストすることを含んでいる、 前記リソースを識別するために前記第2のネットワーク通信スキームを用いて横断される前記第2の名前空間において、前記一意のリソース識別子を第2の名前空間ノードリソースにリンクさせるステップ、及び、 ブロードキャストされた前記通知を受信した前記横断可能な名前空間パスを、前記第2の名前空間におけるノードのいずれかから横断して、該第2の名前空間において有用性が発行された前記リソースを突き止めるステップ、ここで、該ステップは、ブロードキャストされた前記通知を受信した、前記第2の名前空間における1つまたはそれよりも多い名前空間ノードリソースにナビゲートして、前記第2の名前空間内での前記リソースの前記名前空間ロケーションを判定することを含んでいる、を含むことを特徴とする方法。
- 2前記第1の名前空間において前記リソースの有用性を発行する前記ステップは、前記第1の名前空間において、名前空間の範囲のための基礎を提供するリソースを分割する複数の名前空間の中から前記リソースの有用性を発行することを含むことを特徴とする、請求項1に記載の方法。
- 3前記第1の名前空間において前記リソースの有用性を発行する前記ステップは、前記リソースを他のリソースが前記第1の名前空間内で識別するためにクエリされる従業員名前空間ノードリソースを持った、前記階層構造の複数の異なる名前空間中の前記第1の名前空間において、該有用性を発行することを含む特徴とする、請求項1に記載の方法。
- 4前記一意のリソース識別子を前記第1の名前空間ノードリソースにリンクさせる前記ステップは、URIを前記リソースに関連付けるステップを含むことを特徴とする、請求項1に記載の方法。
- 5前記関連付けるステップは一意のURIを前記リソースに関連付けることを含み、該一意のURIは、前記リソースに単独でアクセスするために使用されることを特徴とする、請求項4に記載の方法。
- 6さらに、追加のリソースに前記階層構造の複数の異なる名前空間のうち1つの中で、アクセスするための1つまたはそれよりも多い追加のURIを前記リソースに割り当てることを含むことを特徴とする、請求項5に記載の方法。
- 7前記一意のリソース識別子を前記第1の名前空間ノードリソースにリンクさせる前記ステップは、前記リソースと前記第1の名前空間ノードリソースとの間で名前空間のセグメントを形成することを含むことを特徴とする、請求項1に記載の方法。
- 8前記第2の名前空間において前記リソースの有用性を発行する前記ステップは、前記第2の名前空間において、名前空間の範囲のための基礎を提供するリソースを分割する複数の名前空間の中から前記リソースの有用性を発行することを含むことを特徴とする、請求項1に記載の方法。
- 9前記第2の名前空間において前記リソースの有用性を発行する前記ステップは、前記リソースを他のリソースが前記第2の名前空間内で識別するためにクエリされる従業員名前空間ノードリソースを持った、前記階層構造の複数の異なる名前空間中の前記第2の名前空間において、該有用性を発行することを特徴とする、請求項1に記載の方法。
- 10前記一意のリソース識別子を前記第2の名前空間ノードリソースにリンクさせる前記ステップは、前記第2の名前空間のためのURIを前記リソースに関連付けることを含むことを特徴とする、請求項1に記載の方法。
- 11前記一意のリソース識別子を前記第2の名前空間ノードリソースにリンクさせる前記ステップは、前記リソースと前記第2の名前空間ノードリソースとの間で名前空間のセグメントを形成することを含むことを特徴とする、請求項1に記載の方法。
- 12前記リソースは名前空間ノードリソースであることを特徴とする、請求項1に記載の方法。
- 13前記第1及び第2の名前空間の各々のための少なくとも1つの一意でないリソース識別子が前記リソースに割り当てられ、前記リソースにアクセスするために前記リソース識別子が横断されることを特徴とする、請求項1に記載の方法。
- 14前記一意でないリソース識別子は、追加の位置を通じた前記リソースへのアクセスを、前記名前空間フェデレーションインフラストラクチャにおいて実装される少なくとも1つの他の名前空間内で提供することを特徴とする、請求項13に記載の方法。
- 15前記一意のリソース識別子は、1つまたはそれよりも多い名前空間の管理の特性をハッシュすることから生成されることを特徴とする、請求項1に記載の方法。
- 16異なるネットワーク通信スキームを有する、階層構造の複数の異なる名前空間の各々において横断可能な名前空間パスを通じたアクセスが可能なリソースを、前記階層構造の複数の異なる名前空間において登録するための方法を実施するための及び名前空間フェデレーションインフラストラクチャにおいて使用するための、コンピュータ実行可能な命令をストアした、1つまたはそれよりも多い記録可能タイプのコンピュータ読み取り可能な記憶媒体に記憶されたコンピュータプログラムであって、前記異なるネットワーク通信スキームの少なくとも2つが、特定の名前空間内で前記リソースを識別するためのシンタックスを識別する異なるリソースを有している、コンピュータプログラムにおいて、該コンピュータプログラムがプロセッサにより実行されると、前記名前空間フェデレーションインフラストラクチャを、 前記リソースについて一意のリソース識別子を確立する手段であって、該一意のリソース識別子を用いて前記階層構造の複数の異なる名前空間において前記リソースを識別可能であり、前記階層構造の複数の異なる名前空間中の各名前空間が前記異なるネットワーク通信スキームとは別のネットワーク通信スキームを有しており、前記名前空間フェデレーションインフラストラクチャにおいて実装されるすべての名前空間を通して前記一意のリソース識別子が一意である、手段、 前記階層構造の複数の異なる名前空間中の、前記異なるネットワーク通信スキームからの第1のネットワーク通信スキームを有する第1の名前空間において、前記リソースの有用性を発行する手段、 前記リソースを識別するために第1のネットワーク通信スキームを用いて横断される前記第1の名前空間において、前記一意のリソース識別子を第1の名前空間ノードリソースにリンクさせる手段、 前記第1の名前空間における前記横断可能な名前空間パスを横断して、該第1の名前空間において有用性が発行された前記リソースを突き止める手段、ここで、該手段は、前記第1の名前空間における1つまたはそれよりも多い名前空間ノードリソースにナビゲートして、前記第1の名前空間内での前記リソースの名前空間ロケーションを判定することを含んでいる、 前記階層構造の複数の異なる名前空間中の、前記異なるネットワーク通信スキームからの第2のネットワーク通信スキームを有する第2の名前空間において、前記リソースの有用性を発行する手段、ここで、該手段は、前記第2の名前空間における少なくとも複数のノードに、前記リソースが前記第2の名前空間内に存在することを知らせる通知をブロードキャストすることを含んでいる、 前記リソースを識別するために第2のネットワーク通信スキームを用いて横断される前記第2の名前空間において、前記一意のリソース識別子を第2の名前空間ノードリソースにリンクさせる手段、及び、 ブロードキャストされた前記通知を受信した前記横断可能な名前空間パスを、前記第2の名前空間におけるノードのいずれかから横断して、該第2の名前空間において有用性が発行された前記リソースを突き止める手段、ここで、該手段は、ブロードキャストされた前記通知を受信した、前記第2の名前空間における1つまたはそれよりも多い名前空間ノードリソースにナビゲートして、前記第2の名前空間内での前記リソースの前記名前空間ロケーションを判定することを含んでいる、として動作させることを特徴とするコンピュータプログラム。
- 17前記一意のリソース識別子を第1の名前空間ノードリソースにリンクさせる前記手段が、前記リソースと前記第1の名前空間ノードリソースとの間で名前空間のセグメントを形成することを特徴とする、請求項16に記載のコンピュータプログラム。
- 18前記一意のリソース識別子を第2の名前空間ノードリソースにリンクさせる前記手段が、前記リソースと前記第2の名前空間ノードリソースとの間で名前空間のセグメントを形成することを特徴とする、請求項16に記載のコンピュータプログラム。
- 19複数のコンピュータを含む名前空間フェデレーションインフラストラクチャにおいて該複数のコンピュータの少なくとも一台によって実行される、階層構造の複数の異なる名前空間の各々において横断可能な名前空間パスを通じたアクセスが可能なリソースを、前記階層構造の複数の異なる名前空間において登録するための方法において、 前記リソースについて一意のリソース識別子を確立するステップであって、該一意のリソース識別子を用いて前記階層構造の複数の異なる名前空間において前記リソースを識別可能であり、前記階層構造の複数の異なる名前空間中の各名前空間が異なるネットワーク通信スキームを有しており、前記名前空間フェデレーションインフラストラクチャにおいて実装されるすべての名前空間を通して前記一意のリソース識別子が一意であり、前記横断可能な名前空間パスを通じて前記リソースにアクセス可能である、ステップ、 前記階層構造の複数の異なる名前空間中の第1の名前空間であって該第1の名前空間に一意の第1のフォーマットの第1のネットワーク通信スキームを有する第1の名前空間において、前記リソースのイベントトピックを示す有用性を加入者に知らせるメッセージを発行するステップ、ここで、前記第1のフォーマットが前記第1の名前空間における別のリソースによって認識されたセマンティックを含んでおり、前記イベントトピックが前記リソースのための前記一意のリソース識別子にちなんで名付けられる、 前記リソースを識別するために第1のネットワーク通信スキームシンタックスを用いて横断される前記第1の名前空間において、前記一意のリソース識別子を第1の名前空間ノードリソースにリンクさせるステップ、 前記第1の名前空間における前記横断可能な名前空間パスを該第1の名前空間に一意の前記第1のフォーマットを用いて横断して、該第1の名前空間において前記有用性を加入者に知らせる前記メッセージが発行された前記リソースを突き止めるステップ、 前記階層構造の複数の異なる名前空間中の第2の名前空間であって前記異なるネットワーク通信スキームからの第2のネットワーク通信スキームを有する第2の名前空間において、前記リソースの前記イベントトピックを示す前記有用性を知らせる前記メッセージを、該第2の名前空間に一意の第2のフォーマットで前記加入者に発行するステップであって、前記イベントトピックが前記リソースのための前記一意のリソース識別子にちなんで名付けられ、前記第2の名前空間に一意の前記第2のフォーマットが該第2の名前空間における別のリソースによって認識されたセマンティックを含んでいる、ステップ、ここで、該ステップは、前記第2の名前空間における複数のノードに、該第2の名前空間にノードが存在することを知らせる通知をブロードキャストすることを含んでいる、 前記リソースを識別するために第2のネットワーク通信スキームを用いて横断される前記第2の名前空間において、前記一意のリソース識別子を第2の名前空間ノードリソースにリンクさせるステップ、及び、 ブロードキャストされた前記通知を受信した前記横断可能な名前空間パスを、前記第2の名前空間におけるノードのいずれかから横断して、該第2の名前空間において前記有用性を知らせる前記メッセージが発行された前記リソースを突き止めるステップ、を含むことを特徴とする方法。
- 20前記第1のフォーマットと前記第2のフォーマットには互換性がなく、前記第1のフォーマットに対応する識別子を、前記第2のフォーマットの識別子を認識するように構成された装置では認識できないことを特徴とする、請求項19に記載の方法。
- 21前記リソースがネットワークから落ちていることに気付いたノードが、前記リソースの前記一意のリソース識別子にちなんで名付けられた前記イベントトピックに対し、活性通知メッセージを発行するように構成されることを特徴とする、請求項19に記載の方法。
- 22階層構造の複数の異なる名前空間の各々において横断可能な名前空間パスを通じたアクセスが可能なリソースを、前記階層構造の複数の異なる名前空間において登録するための方法を実施するための及び名前空間フェデレーションインフラストラクチャにおいて使用するための、コンピュータ実行可能な命令をストアした、1つまたはそれよりも多い記録可能タイプのコンピュータ読み取り可能な記憶媒体に記憶されたコンピュータプログラムにおいて、該コンピュータプログラムがプロセッサにより実行されると、前記名前空間フェデレーションインフラストラクチャを、 前記リソースについて一意のリソース識別子を確立する手段であって、該一意のリソース識別子を用いて前記階層構造の複数の異なる名前空間において前記リソースを識別可能であり、前記階層構造の複数の異なる名前空間中の各名前空間が異なるネットワーク通信スキームを有しており、前記名前空間フェデレーションインフラストラクチャにおいて実装されるすべての名前空間を通して前記一意のリソース識別子が一意であり、前記横断可能な名前空間パスを通じて前記リソースにアクセス可能である、手段、 前記階層構造の複数の異なる名前空間中の第1の名前空間であって該第1の名前空間に一意の第1のフォーマットの第1のネットワーク通信スキームを有する第1の名前空間において、前記リソースのイベントトピックを示す有用性を加入者に知らせるメッセージを発行する手段、ここで、前記第1のフォーマットが前記第1の名前空間における別のリソースによって認識されたセマンティックを含んでおり、前記イベントトピックが前記リソースのための前記一意のリソース識別子にちなんで名付けられる、 前記リソースを識別するために第1のネットワーク通信スキームシンタックスを用いて横断される前記第1の名前空間において、前記一意のリソース識別子を第1の名前空間ノードリソースにリンクさせる手段、 前記第1の名前空間における前記横断可能な名前空間パスを該第1の名前空間に一意の前記第1のフォーマットを用いて横断して、該第1の名前空間において前記有用性を加入者に知らせる前記メッセージが発行された前記リソースを突き止める手段、 前記階層構造の複数の異なる名前空間中の第2の名前空間であって前記異なるネットワーク通信スキームからの第2のネットワーク通信スキームを有する第2の名前空間において、前記リソースの前記イベントトピックを示す前記有用性を知らせる前記メッセージを、該第2の名前空間に一意の第2のフォーマットで前記加入者に発行する手段であって、前記イベントトピックが前記リソースのための前記一意のリソース識別子にちなんで名付けられ、前記第2の名前空間に一意の前記第2のフォーマットが該第2の名前空間における別のリソースによって認識されたセマンティックを含んでいる、手段、ここで、該手段により、前記第2の名前空間における複数のノードに、該第2の名前空間にノードが存在することを知らせる通知をブロードキャストする、 前記リソースを識別するために第2のネットワーク通信スキームを用いて横断される前記第2の名前空間において、前記一意のリソース識別子を第2の名前空間ノードリソースにリンクさせる手段、及び、 ブロードキャストされた前記通知を受信した前記横断可能な名前空間パスを、前記第2の名前空間におけるノードのいずれかから横断して、該第2の名前空間において前記有用性を知らせる前記メッセージが発行された前記リソースを突き止める手段、として動作させることを特徴とするコンピュータプログラム。
Independent claims22
153 paragraphs, as filed
The present invention relates generally to organizing resources, and more specifically to facilitating more efficient and reliable resource access by organizing resources into collections.
Computer systems and related technologies affect many aspects of society. In fact, the ability of computer systems to process information is changing the way we live and work. Computer systems now generally perform a number of tasks that were manually performed prior to the advent of computer systems (eg, document processing, scheduling, and database management). More recently, computer systems have been combined with each other and with other electronic devices to form wired and wireless computer networks, through which computer systems and other electronic devices transfer electronic data. can do. As a result, many tasks performed on computer systems (eg, voice communication, email access, home electronics control, web browsing, and document printing) are over wired and / or wireless computer networks. Includes electronic communication between several computer systems and / or other electronic devices.
A variety of different access mechanisms have been developed due to the quality and variety of resources (eg, devices and services) that are accessible through computer networks. Many access mechanisms utilize different protocols. For example, accessing a web page on the World Wide Web (WWW) is usually facilitated using the Hypertext Transfer Protocol (HTTP). On the other hand, accessing files from a remote location can be facilitated using a file transfer protocol (FTP). Sometimes the same content can be transferred at different times using different protocols. For example, forwarding an email message between multiple mail servers using the Simple Mail Forwarding Protocol, and then using the Internet Message Access Protocol ("IMAP") or the Post Office Protocol ("POP"). Can be forwarded to the client.
However, before a resource can be transferred or accessed using a protocol, the corresponding access mechanism must have some way of identifying the resource to be accessed or transferred. For example, before a web browser can access a web page using HTTP, the web browser must have some way of identifying the web page that should be accessed. Similarly, before a mail client can receive an e-mail message using IMAP or POP, the mail client has some way to identify the mail server that is storing the e-mail. Must be done. Thus, virtually all resource access mechanisms also include identification mechanisms that can be used to identify resources.
One identification mechanism involves utilizing network addresses (eg, Internet Protocol "IP" addresses) to identify corresponding computing devices (eg laptops, mail servers, printers, PDAs, etc.). .. Identifying computing devices by network address may be sufficient on smaller networks (eg, home area networks (HAN)) and / or on networks where network addresses change relatively rarely. is there. However, on larger distributed networks, the use of network addresses as an identification mechanism is often problematic. For example, due to the large number of computing devices on the Internet, it is difficult, if not impossible, to remember the IP addresses for any computing device that a user may want to access. It may be. In addition, there is always the possibility that a provider will change the network address of a computing device or transfer ownership of the computing device to a different provider that controls a different network address. Therefore, later attempts to access a computing device at a previously known network address can fail, and there may be no easy way to determine a more recent network address.
Therefore, other identification mechanisms represent network addresses as strings of alphabetic characters that are usually more memorable, providing some level of abstraction from network addresses. For example, a domain name service (DNS) can be used to represent an IP address as an alphabetic string (eg, corresponding to a domain name). When an alphabetic string is used to identify a computing device, DNS checks the translation database and translates the alphabetic string into the corresponding IP address for the computing device. In addition, when a new IP address is assigned to a computing device, the translation database can be updated so that the previously used alphabetic string identifying the computing device corresponds to the new IP address. .. In this way, DNS provides a level of abstraction that allows you to change the IP address for a computing device without having to change the alphabetic string that represents the computing device. .. Therefore, if the provider changes the IP address for the computing device, the same alphabetic string can often be used to access the computing device.
However, using DNS alone may not be sufficient to identify a particular resource of a computing device, as a computer system can be configured to provide several different services at the same time. .. For example, in some environments, using DNS as a single identification mechanism makes it difficult to distinguish between different services (email, search functionality, etc.) provided by the same web server. there is a possibility. That is, identifying a web server (eg, by network address or alphabetic string) does not necessarily provide instructions for any of the particular services provided by the web server. Thus, in order to access a web server's email service, the identification mechanism will need some way to distinguish the email service from other services on the web server.
Uniform resource identifiers (URIs) are a mechanism developed to more accurately identify resources. The URI can include a network address or alphabetic string that identifies the computing device, as well as an additional alphanumeric string that identifies a particular resource at the computing device. A uniform resource locator (URL) refers to a subset of URIs that identify resources through a representation of their primary access mechanics (eg, their network location). A universal resource name ("URN") refers to a subset of URIs that must remain globally unique and persist even when the corresponding resource ceases to exist.
URLs are typically used to access resources on the Internet. For example, the URL "http: // [domain name] / [alphanumeric string]" can be used to identify a particular resource on a computing device on the WWW. URLs are also usually subdivided into different schemes that represent different (often hierarchical) namespaces. For example, some of the different schemes used on the Internet include ftp, http, gopher, mailto, news and telnet. Each of these schemes represents a different and corresponding namespace. This is useful because the identification of resources can range over different namespaces, and each scheme can have different syntax for identifying resources within its corresponding namespace. For example, the syntax for identifying resources within the http namespace and the syntax for identifying resources within the ftp namespace may differ.
Unfortunately, at least in part, it is often difficult, if not impossible, to configure access to a resource so that it can be accessed from within multiple namespaces by different schemes with different syntax. Is. That is, making a resource accessible from one namespace usually prevents the resource from being accessible from another namespace. For example, the http scheme cannot normally be used to identify (and transfer using ftp) resources that are configured for identification using the ftp scheme. That is, URLs of the form http: // [domain name] / [alphanumeric strings] cannot usually be used to identify resources within the ftp namespace.
In addition, conventional resource identification mechanisms have limited ability to query. For example, one subset of URIs shares a common syntax for expressing hierarchical relationships with a specified namespace. The URI of this subset can be in the form <scheme>: // <authority> <path>? <Query>, where the query part is <scheme>: // <authority> <path>. A string of information that should be interpreted by the resources of. This facilitates issuing queries to resources, such as performing resource search or discovery functions.
However, the usual resource identification mechanism is limited in some cases, even if it has the functionality to query the namespace for resources contained within the namespace by using a URI. The URI syntax for some namespaces allows query functionality, but only at the lowest level in the namespace hierarchy (eg leaf nodes). This result results, at least in part, from the fact that existing namespace mechanisms do not see intermediate nodes as resources. In this way, you can formulate a URI, for example a URI that represents a website for a given company, and query for a text file at a particular endpoint. However, formalizing URIs and querying the same namespace hierarchy for text files from only domains ending in ".com" can be difficult, if not impossible.
In addition, existing search mechanisms require a large amount of resource information to be cached. For example, most internet discovery engines constantly scan the internet for new URLs and cache the URLs locally. When a search (or query) is submitted to a search engine, the search engine searches for cached URLs. Therefore, if the URL for the resource is not cached or the URL changes after caching, the URL for the resource or the correct URL may not be returned in the search results. Therefore, systems, methods and computer program products that facilitate more efficient and reliable resource access would be advantageous.
<p> The aforementioned problems of the prior art are overcome by the principles of the present invention, the invention being a method, system and computer program for organizing resources into collections to facilitate more efficient and reliable resource access. Target products.</p>
<p> In some embodiments, namespace registration requests are forwarded in the namespace federation infrastructure. A namespace registration request is received to register a namespace branch, and the namespace registration request contains a namespace string that identifies the namespace branch. At least one-way equivalent numeric identification value, for example, the hash value is based on the entire namespace string for flat URI schemes, or for hierarchical URL schemes. Is generated based on the portion of the namespace string up to the first path segment. A namespace registration request is sent (and) to a namespace management that has an identifier that is quantitatively closer to the identifier of the same number in at least one direction than the identifier of the other namespace manager. Potentially routed). Namespace branching is tied to namespace management.</p><p> In other embodiments, namespace registration requests are migrated within the namespace federation infrastructure. It is determined that namespace management meets policy constraints. A namespace branch that can be migrated to satisfy the policy action associated with the policy constraint is identified. Existing registrations for namespace bifurcation are migrated to partner namespace management in response to policy actions.</p><p> In yet another embodiment, namespace registration requests are processed within the namespace federation infrastructure. A namespace registration request is received to register a namespace branch. The namespace registration request includes a namespace string that identifies the namespace branch and an identifier for the provider requesting registration within the namespace branch. It is determined that namespace management is interested in namespace branching. Namespace strings are stored in a properly indexed namespace registration database. It is further determined how often the activity of the registration request source (eg, the namespace provider) should be verified later.</p><p> In a further embodiment, namespace search requests are sent (and potentially routed) within the namespace federation infrastructure. A namespace search request is received that contains a namespace string that identifies the namespace branch. Equal numeric identification values in at least one direction, such as hash values, are based on the entire namespace string for flat URI schemes, or the first path segment of the namespace string for hierarchical URI schemes. It is generated based on the part up to. Namespace search requests are sent (and potentially routed) to destination namespace management, for example according to an accessibility metric. Destination namespace management is within the predefined range of namespace management that has a unique identifier that is quantitatively closest to the equivalence identification value in at least one direction, near namespace management. Can be any one of. A namespace search request is intended for delivery to the corresponding source of the registration request (eg, the namespace provider) who is interested in or is responsible for the namespace branch. Will be transferred to.</p><p> In a further embodiment, namespace search requests are migrated within the namespace federation infrastructure. Namespace management receives namespace search requests for namespace branching. Namespace management includes a unique namespace identifier that identifies a namespace branch. A namespace management unique identifier for namespace management is a unique identifier for the branch of the generated namespace (rather than a namespace management unique identifier that belongs to one or more other namespace management. For example, it is close to (identification value of the same numerical value in at least one direction). Instructions are detected that the namespace branch has been migrated to the management of a different namespace with a unique identifier for the management of the different namespace.</p><p> In yet another embodiment, namespace search requests are processed within the namespace federation infrastructure. A namespace search request is received that contains a namespace string that identifies a namespace branch that belongs to the namespace. Namespace search request The namespace search request type is identified. It is detected that one or more providers are registering for the part of the namespace associated with the namespace branch. Namespace search requests are forwarded to at least one provider based on the identified namespace search request type.</p><p> In an additional embodiment, the resource participates in multiple namespaces in the namespace federation infrastructure. A unique resource identifier is established for the resource. In the first namespace, the usefulness of the resource is published. A unique resource identifier is linked to a node resource in an existing namespace within the first namespace that identifies the resource across the first namespace. In the second namespace, the usefulness of the resource is published. A unique resource identifier is linked to a node resource in an existing namespace in a second namespace that identifies the resource across the second namespace.</p><p> In yet additional embodiments, a subset of resources in the namespace federation infrastructure is identified. The query is received from the source. The query includes a first query part that identifies the first part of a resource that meets the first query criteria at the first level in the namespace hierarchy. The query includes a second query part that identifies the second part of the resource, selected from among the resources contained within the first part of the resource. The second part of the resource is identified by a second different location within the namespace federation infrastructure. The identity of the second part of the resource is returned to the caller.</p><p> In a further additional embodiment, a plurality of resources are organized. It is determined that a resource should be contained within one or more namespaces, and each of the one or more namespaces is configured to organize one or more resources. The first resource in the first namespace of one or more namespaces that should be associated with the resource is identified. The first namespace segment is used to link the resource to the first resource and the namespace segment can be traversed to navigate from the first resource to the resource in the namespace. To be done.</p><p> These and other purposes and features of the present invention will become more apparent from the following description and the appended claims, or can be learned by practicing the present invention as set forth below.</p><p> To further clarify the above and other advantages and features of the invention, a more detailed description of the invention is provided by reference to the particular embodiment exemplified in the accompanying drawings. It should be understood that these drawings show only typical embodiments of the present invention and therefore should not be considered to limit their scope. The present invention will be described with additional specificity and details through the use of the accompanying drawings.</p>
The principles of the present invention provide the organization of resources into collections to facilitate more efficient and reliable resource access. In some embodiments, namespace registration requests are forwarded within the namespace federation infrastructure. A namespace registration request is received to register a namespace branch, and the namespace registration request contains a namespace string that identifies the namespace branch. Equal numeric identification values in at least one direction, such as hash values, are based on the entire namespace string for flat URI schemes, or the first path segment of the namespace string for hierarchical URL schemes. It is generated based on the part up to. Namespace registration requests are sent (and potentially routed) to namespace management that has an identifier that is quantitatively closer to the identifier of the same number in at least one direction than the identifier of the management of the other namespace. ). Namespace branching is tied to namespace management.
In other embodiments, namespace registration requests are migrated within the namespace federation infrastructure. It is determined that namespace management meets policy constraints. A namespace branch that can be migrated to satisfy the policy action associated with the policy constraint is identified. Existing registrations for namespace bifurcation are migrated to partner namespace management in response to policy actions.
In yet another embodiment, namespace registration requests are processed within the namespace federation infrastructure. A namespace registration request is received to register a namespace branch. The namespace registration request includes a namespace string that identifies the namespace branch and an identifier for the provider requesting registration within the namespace branch. It is determined that namespace management is interested in namespace branching. Namespace strings are stored in a properly indexed namespace registration database. It is further determined how often the activity of the registration request source (eg, the namespace provider) should be verified later.
In a further embodiment, namespace search requests are sent (and potentially routed) within the namespace federation infrastructure. A namespace search request is received that contains a namespace string that identifies the namespace branch. Equal numeric identification values in at least one direction, such as hash values, are based on the entire namespace string for flat URI schemes, or the first path segment of the namespace string for hierarchical URL schemes. It is generated based on the part up to. Namespace search requests are sent (and potentially routed) to destination namespace management, for example according to an accessibility metric. Destination namespace management is within the predefined range of namespace management that has a unique identifier that is quantitatively closest to the equivalence identification value in at least one direction, near namespace management. Can be any one of. A namespace search request is for delivery to the corresponding source of a registration request (eg, a namespace provider) that states that it is interested in or is responsible for namespace branching. Will be transferred to.
In a further embodiment, namespace search requests are migrated within the namespace federation infrastructure. Namespace management receives namespace search requests for namespace branching. Namespace management includes a unique namespace identifier that identifies a namespace branch. A namespace management unique identifier for namespace management is a unique identifier for the branch of the generated namespace (rather than a namespace management unique identifier that belongs to one or more other namespace management. For example, it is close to (identification value of the same numerical value in at least one direction). Instructions are detected that the namespace branch has been migrated to the management of a different namespace with a unique identifier for the management of the different namespace.
In yet another embodiment, namespace search requests are processed within the namespace federation infrastructure. A namespace search request is received that contains a namespace string that identifies a namespace branch that belongs to the namespace. Namespace search request The namespace search request type is identified. It is detected that one or more providers are registering for the part of the namespace associated with the namespace branch. Namespace search requests are forwarded to at least one provider based on the identified namespace search request type.
In an additional embodiment, the resource participates in multiple namespaces in the namespace federation infrastructure. A unique resource identifier is established for the resource. In the first namespace, the usefulness of the resource is published. The unique resource identifier is linked within the first namespace to the node resource in the existing namespace so that the first namespace can be traversed to identify the resource. In the second namespace, the usefulness of the resource is published. The unique resource identifier is linked in the second namespace to the node resource in the existing namespace so that the second namespace can be traversed to identify the resource.
In yet additional embodiments, a subset of resources within the namespace federation infrastructure is identified. The query is received from the source. The query includes a first part of the query that identifies the first part of the resource that meets the first query criteria at the first level in the namespace hierarchy. The query includes a second query part that identifies the second part of the resource, selected from among the resources contained within the first part of the resource. The second part of the resource is identified by a second different location within the namespace federation infrastructure. The identity of the second part of the resource is returned to the caller.
In a further additional embodiment, a plurality of resources are organized. It is determined that a resource should be contained within one or more namespaces, and each of the one or more namespaces is configured to organize one or more resources. The first resource in the first namespace of one or more namespaces that should be associated with the resource is identified. The first namespace segment is used to link the resource to the first resource so that the namespace segment can be traversed to navigate from the first resource to the resource in the namespace. To.
Embodiments within the scope of the invention include computer-readable media for transporting or having stored computer-executable instructions or data structures. Such computer-readable media may be any usable medium accessible by a general purpose or dedicated computer system. By way of example, such computer-readable media are RAM, ROM, EPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage media, or computer-executable instructions. , Computer-readable instructions, or any other medium that can be used to carry or store desired program code in the form of data structures and accessible by general purpose or dedicated computer systems, etc. Physical storage medium can be included.
To the extent of this specification and the following claims, a "network" allows the transfer of electronic data between computer systems and / or modules (eg, hardware and / or software modules) (in some cases). Defined as one or more data links (of different speeds). When information is transferred or provided to a computer system via a network or another communication connection (hardwired, wireless, or a combination of hardwired or wireless), this connection is considered to be a properly computer readable medium. Is done. Thus, any such connection is referred to as a properly computer readable medium. The above combinations should also be included within the range of computer readable media. Computer-executable instructions include, for example, instructions and data that cause a general purpose computer system or a dedicated computer system to execute a function or group of functions. The computer executable instruction may be, for example, an intermediate format instruction such as binary or assembly language, or source code. In some embodiments, hardware modules such as dedicated integrated circuits or gate arrays are optimized to implement the principles of the invention.
As used herein and in the claims below, a "computer system" is one or more software modules, one or more hardware modules, or a combination thereof that work together to perform operations on electronic data. Defined as. For example, the definition of a computer system includes the hardware components of a personal computer as well as software modules such as the operating system of a personal computer. The physical layout of these modules is not important. A computer system may include one or more computers connected over a network. Similarly, a computer system may contain a single physical device (such as a mobile phone or personal digital assistant "PDA"), and internal modules (such as memory and processor) work together to provide electronic data. Perform the operation at. In addition, computer systems may include dedicated hardware, such as routers that include dedicated integrated circuits.
The present invention can be implemented in a network computing environment having many types of computer system configurations, which include personal computers, laptop computers, handheld devices, multiprocessor systems, and micros. Includes processor-based or programmable consumer electronics, networked PCs, minicomputers, mainframe computers, mobile phones, PDA, pagers, routers, gateways, brokers, proxies, firewalls, redirectors, network address translators, etc. Will be understood. The present invention can also be implemented in a distributed system environment, in which local and remote computer systems are linked over a network (either by a hard-wired data link, a wireless data link, or a combination of hard-wired and wireless data links. (By), perform tasks together. In a distributed system environment, program modules can be located in local and remote memory storage.
Within the scope of this specification and the following patent claims, "resources" are used to satisfy specified functions, such as storing data, defining data formats, printing documents, and so on. It can be defined as any module, component, object, computer system, device, file, database item, schema, service, etc. Resources can be assisted and / or hosted by service components. For example, a file resource can have a file server as a service component for accessing files. Similarly, a meeting room can have a receptionist's mailbox as a service component for scheduling meetings. The implemented resources can be distributed across multiple other resources.
Resources are also defined to include, for example, namespace node resources contained within a namespace, and namespace node resources have access to namespace features, such as namespace security and management capabilities. Can be facilitated or provided and / or traversed to access other resources, such as node resources, computer systems or computer system components in different namespaces. In some embodiments, namespace node resources can be implemented in a distributed manner. In addition, namespace node resources can represent corresponding nodes in the namespace tree.
Within the specification and claims below, a "resource descriptor" is defined as a data structure that describes a resource (eg, formatted according to a resource descriptor schema).
To the extent of this specification and claims, a "namespace" is used to divide a resource (eg, all resources on the Internet) into parts through which resolution, discovery, and message routing can be performed. , Defined as a range mechanism. Namespaces are extensible so that new scopes can be defined and individual scopes can be hierarchical.
You can think of namespaces as forests, and each namespace (tree) is represented by a scheme as a uniform resource identifier ("URI"), and the part immediately after it acts as a root. URI schemes can be hierarchical or flat. Hierarchical schemes such as "name" and "http" (as opposed to flat schemes such as "uuid") can be identified by the presence of the ": /" character sequence after the scheme name. The first part of the hierarchy scheme can identify the naming authority responsible for the rest of the URI component. Such URIs are identified by the presence of the ": //" character sequence after the scheme name. The namespace can be hierarchical and routable, which means that the namespace acts as an identifier that can be used to identify the communication path from the sender to the receiver. Is.
In some embodiments, the namespace can be defined as follows: Namespace: = Flat | Hierarchy Flat: = scheme ":" opaque _ part Hierarchy: = Scheme ": /" ("/" Authority "/")? Segment ("/" segment) * Scheme: = Defined in URI generic syntax by RFC-2396 Opaque_part: = Defined by RFC-2396 in URI generic syntax Authority: = Defined by RFC-2396 in URI generic syntax Segment: = Defined by RFC-2396 in URI generic syntax
A resource can be made available to any branch in the tree, and a given resource can be exposed within multiple namespaces. Also, a given namespace can identify a single resource or a branch of the namespace (a group of resources). Such grouping can be logical or physical, depending on the namespace semantics. The group is obtained by performing a depth-first search at the branch of the identified namespace. After a group of resources has been identified, perform a number of operations on the group of resources, such as selecting resources that meet certain criteria, sending (and potentially routing) a given message only to those within the group. can do.
A single resource can be considered a trivial collection. Therefore, you can assign a name (space) to any resource. Namespaces are routable, so messages can be routed through the namespace's federation infrastructure to any resource that has a name. Such routing can cross trust boundaries and cross firewalls.
In general, a resource can be assigned one or more URIs that can be used to access the resource. Make a resource ID, a URI assigned to a resource, unique across at least all namespaces implemented by the federation infrastructure of a given namespace so that this resource can be referenced independently. be able to. Other, potentially non-unique URIs can also be assigned to resources. These other, potentially non-unique URIs provide access to resources through additional locations within the namespace implemented by the federation infrastructure of a given namespace. A resource can be assigned at least one potentially non-unique URI for each namespace that can be traversed to access that resource.
FIG. 5 illustrates an embodiment of a namespace federation infrastructure and a namespace collection view from a provider. The namespace federation infrastructure 500 indicates that providers can be registered at any branch in the namespace tree. In addition, providers can be registered with branches in multiple namespaces, potentially within different trees. For example, provider 501 is registered for the namespace branches location: / CorporateBuildings / bldg34, location: / CorporateBuildings / bldg50 / floor2, and location: / CorporateBuildings / bldg50 / floor1 / room1304. Provider 502 is registered for the namespace branches location: / CorporateBuildings / bldg50 and location: / CorporateBuildings / bldg26. Provider 503 is registered for location: / CorporateBuildings / bldg50 / floor1.
As shown in Figure 5, an application can think of a namespace as a logical collection of resources that can be nested hierarchically. That is, nodes in the intermediate namespace (eg location: / CorporateBuildings / bldg50 / floor1 and location: / CorporateBuildings / bldg50) are considered resources, namenode resources. Applications can efficiently operate in such logical collections in a coherent and scalable manner, including publishing, searching, positioning, tracking, targeting, and sourcing events from within the collection. Is done. Note that not all resources inside a logical collection are necessarily located on a single computer system or device. Resources can be distributed in space and time across many computer systems and devices. The namespace federation infrastructure handles the efficient routing of search requests to computer systems and devices that participate in any given collection, thereby providing the application with a uniform and consistent view. ..
FIG. 6 illustrates an embodiment of a namespace federation infrastructure in which resources are made available within multiple namespaces. URI Organization: / Product identifies the root of tree 601 in the namespace. Similarly, URI Location: / Bldg42 identifies the root of tree 602 in the namespace. As shown, printer 603 is exposed in both namespace tree 601 and namespace tree 602.
Within the specification and the following claims, namespace node resources can simply be considered nodes in the namespace tree. Node resources in some namespaces can be considered as root nodes (eg Location: / Bldg42), and node resources in other namespaces can be considered as intermediate nodes (eg Organization: / Product / Devices Team). You can think of node resources in other namespaces as leaf nodes (eg Location: / Bldg 42 / Floor 1 / Room 1226 / Printer 603). However, it should be understood that a namespace node resource in a namespace tree can reference a namespace node resource (or another resource) in another namespace tree. Thus, considering a namespace node resource as the root, middle, or leaf within a namespace tree does not limit queries for that namespace node resource from other namespace trees.
Namespaces also contain segments of namespaces that link (or relate to) node resources in two or more namespaces. Namespace segments can be used to link namespace node resources within the same namespace. For example, namespace segment 611 (Devices) links Organization: / Product to the Devices Team. In addition, namespace segments can link node resources in namespaces (otherwise connected) within trees in different namespaces, thereby providing the functionality of symbolic links. Crossing namespace segments involves navigating to node resources in all target namespaces. For example, namespace segment 641 (Project) connects PM Team to the file resources SpecTemplate.doc and Milestone.prj.
Therefore, the namespace segment 611 (Devices), the namespace segment 621 (Dev), and the namespace segment 631 (Printer) are traversed within the namespace tree 601 to the printer 603. It is possible to identify. Similarly, namespace segment 612 (Floor 1), namespace segment 622 (Room 1226), and namespace segment 632 (Printer) are traversed within the namespace tree 602. It is possible to identify the printer 603. It should be understood that the URI scheme of namespace tree 601 and the URI scheme of namespace tree 602 can be different.
Also, due to the presence of symbolic link functionality, a global view of all namespaces and the resources that participate in them forms a directed graph and segments of the namespace, because the same resource can participate in multiple namespaces. Acts as the edge of a labeled graph, and namespace node resources and other resources act as graph nodes. The namespace root effectively divides the namespace node resources and other resources in this global graph into a collection of start and reachable resources, and the start namespace node resources are namespace ranges. Provides the basis for. Therefore, the cached information for executing queries is reduced and distributed across each namespace.
Also, any given namespace can form a graph, which can make the same resource available in multiple namespace branches, a name with several segments connected in other ways. This is because the node resources in the space can be connected.
FIG. 1 illustrates an embodiment of a namespace federation infrastructure. Namespace federation infrastructure 100 includes namespace management 101, 102, 103, 111 and 112, which can form different types of federation partnerships. For example, namespace management 101, 102, 103 federate between each other without managing the root namespace. On the other hand, namespace management 111 and 112 are associated with namespace management 101 and 102, and namespace management 101 and 102 serve as root namespace management, respectively. Different types of devices can participate in namespace federation infrastructure, and these devices include hosts (eg, PCs that host resources), message routers, message gateways (eg, firewalls, network address translation). Contains NAT boxes), and redirectors), and message brokers (eg, publish / subscribe (pub-sub) mediation). The namespace federation infrastructure 100 facilitates bus protocols (eg, activation, control, eventing and streaming). In addition, the namespace federation infrastructure 100 can interoperate with third-party software and hardware stacks using relevant WS protocols, such as WS-Discovery and WS-Eventing.
In general, namespace management 101, 102, 103, 111 and 112 can utilize namespace federation protocols to form partnerships and exchange namespace information. Forming partnerships and exchanging namespace information facilitates more efficient and reliable access to namespace resources. Management of a peer's namespace (eg, namespace management 101, 102, 103) can exchange namespace information with other peer's namespace management. However, other namespace management (eg namespace management 111 and 112) can be exchanged for namespace information with the corresponding root namespace management (eg namespace management 101 and 102). .. Namespace management Each of 101, 102, 103, 111 and 112 can maintain a database of namespace information, which information can be used, for example, in what namespace management or provider branches into which namespace. Are you interested?
The namespace federation infrastructure 100 includes providers 121, 122, 123, 124, 126 and 127. Each provider may be interested in branching one or more namespaces within the namespace federation infrastructure. The provider exchanges namespace information with the management of the corresponding namespace. For example, provider 122 exchanges namespace information with namespace management 111. Corresponding namespace management then facilitates the transfer of namespace information to other namespace management. For example, namespace management 111 can transfer namespace information to namespace management 101, and namespace management 101 can transfer relevant parts of namespace information to namespace management 102 and 103. Can be done.
The namespace federation infrastructure (eg, namespace federation infrastructure 100) facilitates the distribution of search requests across namespaces to the appropriate providers. For example, providers 501, 502 and 503 may be one of providers 121, 122, 123, 124, 126 or 127, respectively.
Namespace management can be combined using a variety of different mechanisms. The first federation mechanism involves that peer namespace management transfers namespace information to all other peer namespace management. When namespace management comes to be coupled to namespace federation infrastructure, namespace management announces its existence (broadcast / multicast) using broadcast / multicast discovery protocols such as WS-Discovery. Hello), issue a broadcast / multicast probe to detect the management of other namespaces. Namespace management then establishes a simple transfer partnership with the management of other namespaces already on the network and accepts new partnerships with the management of newly combined namespaces. Namespace management can then forward any namespace request to its partner.
The second federation mechanism involves that peer namespace management efficiently transfers information from all namespaces to other peer namespace management. When new namespace management comes to be combined with namespace federation infrastructure, new namespace management announces its existence (broadcast) using broadcast / multicast discovery protocols such as WS-Discovery. / Multicast Hello), issue a broadcast / multicast probe to discover the management of other namespaces that are part of the namespace federation infrastructure. After discovering the management of another namespace, the management of the new namespace establishes a partnership with the management of the other namespace. From established partnerships, new namespace management learns about the existence of other namespace management that are already participating in the namespace federation infrastructure. New namespace management then establishes partnerships with these newly learned namespace management and accepts any new partnership requests.
Both arrival / departure of namespace management and namespace registration are flooded through the namespace federation infrastructure, and any namespace management has global knowledge of other namespace management and namespace registration. The result is. With such global knowledge, any namespace management can forward search requests only to partners who have providers / subscribers registered under the namespace branch specified in the request.
A third federation mechanism involves the management of a peer's namespace indirectly transferring namespace information to the management of another peer's namespace. In the third mechanism, namespace management is assigned a unique identifier (ID), for example a 128-bit or 160-bit ID. The namespace management responsible for the tree in a given namespace should have the ID closest to that obtained by at least a one-way mapping function, for example, hashing the tree in a given namespace. Will be decided. Such a hashing-based mapping scheme for namespaces is described in more detail below.
In this third mechanism, namespace management arrivals and departures are flooded through the fabric. On the other hand, namespace registration is transferred to namespace management determined to be responsible for the namespace branch specified in the request. For scalability, load balancing, and fault tolerance, namespace management that receives namespace registrations floods these registrations reliably between the management of these namespaces that are in its neighborhood set. be able to. A neighborhood set for managing a specified namespace is a set of namespace management that has IDs within a predefined range on either side of the specified namespace management ID in a finite modular ID address space. Is determined to be.
Similar to Mechanism 2, the management of newly joined namespaces uses a broadcast / multicast discovery protocol such as WS-Discovery to announce its existence (broadcast / multicast Hello) and issue a broadcast / multicast probe. And discover the management of namespaces that are already part of the namespace federation infrastructure. New namespace management establishes a partnership with discovered namespace management and uses that partnership to learn about the existence of other namespace management participating in the namespace federation infrastructure. .. New namespace management then establishes further partnerships with newly discovered namespace management and accepts any new partnership requests. New namespace management can accept namespace registrations coming in from its partners under the namespace branch it is responsible for, and flood these namespace registrations through its neighborhood set.
In response to incoming search requests, the new namespace management examines its registration database and makes these requests a namespace with providers / subscribers registered under the branch of the namespace specified in the request. Transfer to management. Therefore, when using this third mechanism, the management of any namespace in the namespace federation infrastructure has global knowledge of the management of all other namespaces, while the registration information is the management of namespaces. Efficiently divided between. Namespace management thus indirectly forwards search requests only to partners who have providers / subscribers registered under the namespace branch specified in the request. This indirecting is done through namespace management with global knowledge of namespace registration under the namespace branch specified in the request.
A fourth federation mechanism involves the management of a peer's namespace indirectly routing namespace information to the management of other peers' namespaces. This fourth mechanism differs from the third mechanism in that both namespace management arrivals / departures and namespace registration / search requests are all routed rather than flooded. Routing protocols are designed to guarantee a set between namespace search requests and namespace registration requests.
FIG. 2 illustrates an embodiment of a computer architecture that facilitates the indirect routing of requests to partners. Computer Architecture 200 represents a different type of computer system and device that potentially extends across multiple locally discovered scopes that participate in a namespace federation infrastructure.
Workstation 233 can include a PnP provider instance that registers with the management of the corresponding namespace under the namespace branch of location: / architecture200 / scope221 / Devices. To notify its partner of the existence of this PnP provider instance, workstation 233 routes namespace registration request 201 through the namespace federation infrastructure. Namespace registration request 201 is first forwarded to laptop 231, laptop 231 forwards namespace registration request 201 to message broker 237, and message broker 237 forwards namespace registration request 201 to message gateway 241. To do. The message gateway 241 stores the registration information registration request 201 in its database and returns the success message 204 to workstation 233.
Then another provider instance, this time the one of the running service, activates in workstation 233 and makes itself the corresponding namespace under the namespace branch of location: / architecture200 / scope221 / Services. Register for management. This time, namespace management recognizes that message gateway 241 is responsible for registration under location: / architecture200 and forwards registration request 205 directly to message gateway 241. The message gateway 241 stores the registration information registration request 205 in its database and returns the success message 206 to workstation 233.
The printer 236 (eg, UPnP printer) is then turned on and sends the announcement 207. Server 234 detects announcement 207, assigns namespace location: / architecture200 / scope224 / Devices to printer 236, and routes registration request 208 to message broker 237. Message broker 237 forwards registration request 208 to message gateway 241. The message gateway 241 stores the registration information registration request 208 in its database and returns the success message 210 to the server 234.
The personal computer 242 then issues discovery request 211 to discover all devices under the namespace branch location: / architecture200. The personal computer 242 does not know where to forward the discovery request 211, so it routes the discovery request 211 through workstation 243. The routing protocol essentially guarantees a set of registration and search requests for the tree in a given namespace, so workstation 243 forwards discovery request 211 to message gateway 241. Message gateway 241 forwards discovery request 211 to workstation 233 and server 234. Workstation 233 and server 234 send response messages 214 and 216 to personal computer 242, respectively.
This fourth mechanism requests the management of namespaces (Message Gateway 241) with global knowledge of namespace registration under the namespace branch specified in the request (eg location: / architecture200). Works by routing. This fourth mechanism essentially ensures that routing can be performed on O (log N) hops, where N is the number of namespace managements that participate in the namespace federation infrastructure. Is. This fourth mechanism efficiently divides namespace registration information and does not require global knowledge of namespace management for all participants, so it scales to very large networks, the Internet.
Figure 3 illustrates an embodiment of a binary relation between managing multiple namespaces within a namespace federation infrastructure. The binary relation shown in Figure 3 is one relation that can be used to perform more efficient routing between namespace management. Namespace management that participates in namespace federation infrastructure is organized as a sorted list using binary relations that are recursive, antisymmetric, transitive, and global, and for namespace management. Defined in the area that belongs to the identity. The ends of the sorted list are joined together to form ring 306. This allows the management of each namespace in the sorted list to consider itself at the center of the sorted list. The sorted list can be biconnected so that any namespace management can traverse this sorted list in both directions. In addition, there is a one-to-one mapping from the value domain belonging to the namespace management identity (eg, 2, 50 or 151) to the namespace management itself. This mapping reveals the sparseness of namespace management in the value domain when the mapping is not tight.
Each namespace management on ring 306 can include a routing table, which facilitates routing namespace information (eg, registration and search requests) to other namespace management. The routing table of the embodiment for managing the namespace having ID64 is shown in FIG. This routing table indicates that ID64 follows ID76. Subsequent can be within the management of the namespace immediately adjacent clockwise from ID64 on ring 306. Subsequent changes, for example, when a new namespace management (eg, one with 71 IDs) joins or an existing namespace management (eg ID76) leaves the namespace federation infrastructure. There is a possibility of becoming.
This routing table indicates that ID64 precedes ID50. The predecessor can be the management of a namespace immediately adjacent counterclockwise from ID 64 on ring 306. Predecessors, for example, change when a new namespace management (eg, one with 59 IDs) joins or an existing namespace management (eg ID50) leaves the namespace federation infrastructure. There is a possibility of becoming.
This routing table indicates that the neighbors of ID64 are IDs 83, 76, 50 and 46. Neighbors can be identified using the larger of the two coefficients, size and range. Namespace management is such that the corresponding ID is within the minimum range of the target ID (eg, clockwise or counterclockwise in ring 306), or a size less than a configured minimum neighborhood is within the neighborhood. When it already exists, it is identified as a nearby member. For example, on ring 306, the specified range can have a size of 20, which size can be greater than 4. Therefore, IDs within 20 locations of ID64 in the clockwise (+10) and counterclockwise (-10) directions are in the vicinity of ID64. Neighbors can change, for example, when namespace management joins or leaves the namespace federation infrastructure, or when a specified range changes. For example, for a size equal to 4, managing a new namespace with ID 48 can replace managing a namespace with ID 46.
This routing table indicates that ID64 can be routed directly to IDs 200, 2, 30, 46, 50, 64, 76, 83, 98 and 135. Therefore, if the namespace management with ID64 receives the request, the namespace management can route the request to the namespace management that has an ID in the routing table that is closer to the namespace management ID in the request. it can.
Figure 4 illustrates an architectural embodiment that facilitates the integration of namespace federation infrastructure with other protocols. Namespace federation infrastructure can support provider-based expansion models. Therefore, if the resource model of an existing protocol is compatible with the resource model of a namespace, the namespace federation infrastructure can be integrated with the existing protocol. Architecture 400 indicates that namespace management 401, 404, 406 (eg, from namespace federation infrastructure) interoperate with Active Directory 402 and UDDI Server 403. This solid arrow indicates that namespace management communicates using the namespace federation protocol, and the dashed area indicates that namespace management uses Active Directory 402 and the LDAP protocol. The dotted arrow indicates that namespace management communicates with UDDI Server 403 using the UDDI protocol.
The publish / join topic is another use case for namespaces. Publishing / joining topics can be considered as a collection of subscribers to that topic, so topic names are treated as namespaces. The advantage of treating publishing / joining topics as namespaces is that you can use the namespace federation infrastructure to route notification messages from publishers to subscribers. A subscription to a topic can be considered a namespace registration request, and a publication to a topic can be considered a namespace search request.
In some embodiments, the namespace federation infrastructure can provide programmers with bus-like abstractions to develop distributed applications. For example, namespace federation infrastructure can abstract the mechanism that an application uses to know when a resource that the application is interested in is down from the network. To keep track of a given resource, join the application to a notification sent to a publishing / joining topic named after the URI (ie, its name) of that resource's identity. Any component (eg, an application) that notices that a given resource is down the network publishes an activation notification message to a topic named after the URI of that resource's identity, thereby tracking the resource. You can notify other applications that are interested in. Since issuance / subscription subscriptions are federated across the namespace infrastructure, and because many identity schemes are hierarchical (to capture the nature of resource inclusion in terms of activity), the system Simple detection system n<sup>2</sup>Avoid pinging problems and scale very well. Moreover, the more interested a component (eg, an application) is in a given resource, the faster it is advantageous for something to notice that that resource is falling off the network.
Developers can think of a namespace federation infrastructure as a cloud in which resources such as files and event sources are registered. The application can issue a discovery request to the cloud to discover the registered resource. Applications can also require the cloud to subscribe to current and future event sources that register with the cloud on their behalf. In addition, applications can subscribe to published / subscribed topics maintained in the cloud. Anything can issue a notification message, and the cloud handles forwarding this message to the subscribers of the event topic for which it was issued.
Various types of resources can be published within a namespace, including services, devices, files, hosts, components, items in databases, metadata (schema) about metadata, and more. .. A resource can have a service component that hosts / supports it. For example, a file resource can have a file server as a service component for accessing files. The meeting room can have a receptionist's mailbox as a service component for scheduling meetings.
Each resource can be associated with a resource descriptor that captures its descriptive aspect. Therefore, the resource descriptor can be queried to identify the resource of interest. When a resource is identified, it can be accessed through the resource's corresponding service aspect. The type of message that can be sent to a service that hosts / supports a resource depends on the resource type. For example, a file server supports opening a file resource, and a receptionist accepts a scheduling request for a conference room.
The data model for implementing resource descriptors can be versionable, extensible and interoperable. Such a resource data model can be shared across many of today's frameworks, including distributed file systems (DFS), AD and UDDI. Such a single shared data model allows AD objects and DFS files (or resources from other resource management systems) to be considered resources and coalesced using namespace techniques, and they. You can make it easier for them to be accessed by sending messages to the service that hosts them.
Therefore, a resource can be defined to have the following properties: Resource ID: A URI that can optionally be augmented by a set of reference properties and can be stable in space and time. It can be represented as an instance of the resource reference schema. The resource ID can collectively represent the identity of the resource together with the resource property. Descriptor: A resource-specific schema instance that contains semi-static metadata about a resource. This metadata is useful for resource selection. You can classify the resource descriptor schema. Config number: A monotonous increment that identifies a particular version of the resource description data. This number is incremented whenever the resource description is modified. Instance ID: A monotonous increment that identifies a particular instance of an active resource. For example, this can be the same as the boot time for service / equipment resources or the file modification time for file resources.
Further with respect to descriptors, the device can have metadata according to one or more schemas. For example, a printer can have metadata according to different schemas that describe different aspects of the printer. The resource descriptor schema can be standardized by organizations such as the UPnP Forum Working Group (eg, the printer schema can be standardized by the UPnP Printer Working Group) and the W3C. FIG. 13 shows an embodiment of a taxonomy to describe a resource. Within taxonomy 1300, the different schemas are generally represented as:
Service Reference Schema: Extends the resource reference schema to specify a list of behavior types that identify messages supported by the resource, a policy container for its assertions (such as supported transports), and an extension set. Resource Descriptor Schema: Extends the resource reference schema to specify the descriptor configuration number (see below for a description), the friendly name of the resource, the service reference of the service that supports the resource, and the extension set. Namespace node descriptor schema: Extends the resource descriptor schema and then specifies the reachable resources as instances of the edge descriptor schema. Edge Descriptor Schema: Specifies the edge name, edge type, and target resource for the local range. Device Descriptor Schema: Extends the resource descriptor schema to specify the serial number and manufacturer name. Printer Descriptor Schema: Extends the device descriptor schema to specify printer-specific properties such as resolution, color printability, number of pages per minute, and supported paper sizes.
Any of the information defined in any of the above descriptive schemas can be included in the query to identify resources within the namespace federation infrastructure. For example, you can explore descriptor data and navigate using filter (or query) expressions. For example, you can filter by descriptor schema type or field value, navigate from its referenced field to reachable instances, apply subfilters to them, and so on. In some embodiments, XPath-based filter expressions are used. Looking back at Figure 6, you can use the XPath syntax to print in color using a filter expression that works on the descriptive data specified by the resource descriptive schema in Location: / Bldg42 / Floor1. You can find the printer.
Namespaces can specify filter expressions for selections and traversals, in the form of URI segment parameters, for fields / attributes defined on the namespace's node resources. For example, the namespace Location: / Bldg42 / Floor1 / Room1226; employee = "employee1" / printer is for the namespace only if the descriptor for "Room 1226" has an "employee" field with the value "employee1". It will cross the node resource "Room 1226". Similarly, the namespace Organization: / Product / DevicesTeam; building = "Bldg33" / Dev / Computer604; printer = "color" has a "building" field whose descriptor has the value "Bldg33" (hence the resource). Only if you identify the first part of the namespace node resource "Devices" Namespace only if it now traverses "Team" and its descriptor has a "printer" field with the value "color" (meaning to identify that a color printer is attached to it) Node resource "Computer 604" will be selected.
As mentioned above, namespace management can be assigned a unique numeric identifier, such as a 160-bit ID. In some embodiments. Unique identifiers are generated by hashing the management characteristics of one or more namespaces, such as domain name service (DNS) names, locations, and departments. You can use one of a variety of different hashing functions, for example SHA, to generate a unique ID.
Utilizing the unique namespace management identity, the following functions can provide routing of namespace information in the namespace federation infrastructure. RouteNumerically (V, Msg): Given a value V from a value region that belongs to the namespace management identity, and the message "Msg", it has an identity that allows the message to be mapped to V using a mapping function. Deliver to namespace management X. Neighborhood (X, S): Neighborhood is a set of namespace management on either side of namespace management X (eg, on ring 306) with cardinality equal to S.
Further, embodiments of the present invention can also utilize proximity criteria that belong to the management of namespaces that participate in federation. The proximity criterion can be defined as an equivalence relation that divides a set belonging to the management of an associated namespace into disjoint sets of classes (or divisions). In general, the relation R on the set S is an equivalence relation if the following characteristics are satisfied.
Recursive: x xRx belonging to the element of S -Symmetric: given the elements x and y of S, xRy yRx Transitive: given the elements x, y, z of S, xRyyRz xRz Embodiments of the present invention can support a plurality of different proximity criteria, and the proximity criteria can be arranged in semi-order. For example, the criteria that node resources of all namespaces belonging to "Corporation 1" are considered to be close to each other is higher than the criteria that all namespaces in "Corporation 1, Location A" are considered to be close to each other. Is. This is because the set of namespace management that was considered close by the former criterion (belonging to "Corporation 1") is close by the latter criterion (belonging to "Corporation 1, Location A"). Due to being a superset of the namespace management set considered to be close to. On the other hand, the criteria for considering the management of all namespaces in "Corporation 1" as close to each other and "Corporation 1, Location" There is no ordering relationship between the criteria for considering the management of all namespaces in "A" as close to each other.
Each routing hop on the path to the final destination makes a request by taking into account proximity considerations when calculating the management of routing namespaces for the management of each namespace in the federation. This results in an increased likelihood of remaining in the proximity of the outgoing namespace management. Moreover, bridging the distance between namespace management within a numeric space can still be significantly advanced.
Utilizing unique identities with proximity criteria, the following additional functions can provide routing of namespace information in the namespace federation infrastructure. RouteProximally (V, Msg, P): Given the value V from the region belonging to the namespace management identity, and the message "Msg", the message is considered to be equivalent by the proximity criterion P for namespace management. In between, deliver to namespace management Y with an identity that can be copied to V.
When a provider / subscriber registers for namespace management at a namespace branch, the registration request is responsible for maintaining the registration information for the namespace tree specified in the registration request. Sent (and potentially routed) to the management. Alternatively, namespace management that sends namespace registration requests to the fabric may be responsible namespace management. Method 710 describes the federation infrastructure of the namespace in Figure 1 and the namespace in Figure 6.
Method 710 includes the action of receiving a namespace registration request to register a namespace branch, and the namespace registration request includes a namespace identifier that identifies the namespace branch (action 711). For example, namespace management 112 can receive registration request 132, including namespace ID 142, from provider 131. Namespace management 112 is not peer namespace management, so namespace management 112 can forward registration requests 132 to namespace management 102. Namespace management 112 can normalize namespace ID 142 by the rules identified by its scheme before forwarding registration request 132 through namespace federation infrastructure 100.
Method 710 includes an action that generates an equivalence identification value in at least one direction, along with at least a portion of the path portion of the namespace identifier, based on the scheme portion of the namespace identifier (action 712). For example, namespace management 102 can generate hash 152, along with at least part of the path portion of namespace ID 142, based on the scheme portion of namespace ID 142. You can use one of a variety of different hashing functions, for example SHA, to generate a hash value from the string portion of the namespace. The generation of hash values for namespace strings can vary based on the configuration of the namespace federation infrastructure.
Non-hierarchical namespace schemes such as "uuid" (eg, identified by the lack of a ": /" character sequence after the scheme) can generate hashes over the entire namespace. For example, the entire namespace string "uuid: a36fab9c-9c7f-42c3-97d8-36cd57e9bd29" can be used to generate a SHA hash value.
Hierarchical namespaces can be authoritative or non-authoritative, and these two are distinguished, for example, by the character sequences ": //" and ": /" that follow the scheme component. .. For authoritative namespaces such as "name", the hash is generated on the scheme part, followed by the ": //" character sequence, the authority component, and the first path component of the namespace. For example, using part of the namespace string "name: //red.prn.xrx: 200 / Printers / b42-1749-a" "name: //red.prn.xrx: 200/Printers" , SHA hash values can be generated. In an unauthorized namespace, such as the "location" scheme in Figure 6, the hash is generated on the scheme part, followed by the ": /" character sequence, followed by the first path component of the namespace. For example, a SHA hash value can be generated using a part of the namespace string "location: / Bldg42 / Floor1 / Room1226" "location: / Bldg42".
Method 710 includes sending a namespace registration request to namespace management, which has an identifier that is quantitatively closer to the identifier of an equivalent number in at least one direction than the identifier of other namespace management. (Operation 713). For example, namespace management 102 can call the RouteNumerically function and take the hash 152 and registration message 132 as inputs to supply, for example, the RouteNumerically function (hash 152, registration message 132). Alternatively, you can use the RouteProximally function. In some embodiments, namespace registration requests are sent directly and no routing occurs.
The namespace federation infrastructure 100 then utilizes the federation protocol to forward registration messages to the appropriate namespace management. For example, registration message 132 can be routed to namespace management 103. Namespace management 103 may shift responsibility for namespace branching to another namespace management. Therefore, namespace management 103 can return entrusted messages to namespace management 102. Therefore, when responsibility for namespace branching is delegated, namespace management 102 can receive a delegate message specifying the appropriate namespace management. Namespace management 102 can send registration requests 132 to the appropriate namespace management. You may encounter one or more entrustments until namespace management accepts or rejects the registration request.
Method 710 includes actions that link namespace management with namespace branching (action 714). For example, namespace management 103 can be associated with a namespace branch identified by namespace ID 142 (via provider 131). Namespace ID 142 can identify, for example, a part of namespace 601 or namespace 602. By linking between namespace management and namespace branching, a request that specifies a namespace branch directly below what is specified in the registration request (for example, a search request) is placed in the namespace specified in the linking. It is possible to transfer to management instead of routing. If a namespace management failure is detected or a delegation to the management of a different namespace is obtained, the bond is broken. If a failure is detected, subsequent requests will be routed until a new bond can be formed.
FIG. 7B illustrates a flowchart of an embodiment of Method 720 for migrating namespace registration requests. Method 720 is described for the federation infrastructure of the namespace in Figure 1 and the namespace in Figure 6.
Method 720 includes actions that determine that namespace management meets policy constraints (action 721). For example, Namespace Management 103 states that the amount of namespace information (related to Namespace Federation Infrastructure 100) processed by Namespace Management 103 exceeds the configured threshold. Can be decided. The configured threshold can be, for example, the total number of registrations maintained by namespace management, or the total number of search requests serviced by namespace management.
Method 720 includes actions that identify namespace branches that can be migrated to meet policy actions associated with policy constraints (action 722). For example, namespace management 103 can be migrated to reduce namespace information processed in namespace management 103 below the configured threshold (namespace branching (). For example, it can identify (corresponding to ID 142 in the namespace). Namespace management can identify more mass-populated and / or mass-serviced namespace branches for migration.
Method 720 includes the action of migrating an existing registration for namespace branching to management of a partner's namespace in response to a policy action (eg action 723). For example, in response to an action that would occur to ease the burden of branching a massively popular and / or massively serviced namespace, Namespace Management 103 would register an existing registration. You can move to managing namespaces for partners (eg, neighbors).
Method 720 can also include the operation of receiving a namespace request corresponding to a namespace branch. For example, namespace management 103 can receive registration request 132, which corresponds to the namespace branch represented by namespace ID 142.
Method 720 can also include actions that redirect namespace requests to partner namespace management. For example, namespace management 103 can reroute registration request 132 to namespace management 101, as indicated by the dotted arrow. Namespace management that migrates namespace branches can call RouteNumerically to reroute requests to different namespace management. For example, call RouteNumerically (H, migrateMsg) to make a request to namespace management (eg, namespace management 101) identified by equivalence values in at least one direction of the migrated namespace branch. Can be rerouted. For example, to migrate the branch location: / Bldg42 / Floor1, namespace management 103 generates a hash H on the string "location: / Bldg42 / Floor1" and calls RouteNumerically (H, migrateMsg) to migrate. Identified namespace management 101 responsible for the branch, and identified all namespace registrations directly under the migrated branch, such as location: / Bldg42 / Floor1 / Room1226 and location: / Bldg42 / Floor1 / Room119. Move to namespace management 101.
Namespace management also determines to forward all namespace registrations encountered along the spine of the migrated namespace branch to the namespace management of the partner hosting the branch. You can also do it. This allows the partner namespace management branch to serve all search requests that specify the namespace branch at any time, directly or indirectly, without having to go through the namespace management to migrate. Becomes easier. The management of the namespace to be migrated can leave a stub indicating that it is migrating the registration information under the branch of the specified namespace. Management of the migrated namespace can also be revoked if there is an activation notification subscription that tracks the provider / subscriber specified in the migrated registration. Therefore, any subsequent namespace registrations received under and along the migrating namespace branch spine received by the migrating namespace management are transferred to the partner namespace management.
FIG. 7C illustrates a flowchart of an embodiment of a method for processing a namespace registration request. Method 730 is described for the federation infrastructure of the namespace in Figure 1 and the namespace in Figure 6.
Method 730 includes the action of receiving a namespace registration request to register a namespace branch, where the namespace registration request is a namespace URI string that identifies the namespace branch, and the namespace. Contains a unique reference or identifier for the provider (or subscriber) requesting registration within the branch of (Action 731). For example, namespace management 103 can receive a registration request 132 that includes a reference to provider 131.
Method 730 includes an action that determines that namespace management is interested in namespace branching (action 732). For example, namespace management 102 can determine whether namespace management 102 is responsible for the namespace branch represented by namespace ID 142 (eg, Organization: / Product / Messaging Team). When namespace management 102 is not responsible, namespace management 102 is responsible for namespace registration requests (eg, registration request 132) for the specified namespace branch (eg, namespace management). It can be transferred to management 103). Alternatively, when namespace management 102 is not responsible, namespace management 102 sends the delegated message 134 to namespace management (eg, namespace management 103) that initiated the registration request (eg, registration request 133). It can be sent to contact namespace management (eg, namespace management 101) that it takes on its behalf. When namespace management 102 is responsible, namespace management 102 can store namespace registration requests.
Method 730 involves storing the namespace identifier in a properly indexed namespace registration database (action 733). For example, if the namespace identifier is a URI string, it is stored in the namespace registration database index so that the longest string in alphabetical order is ranked higher. For example, namespace management 103 can store namespace ID 142 in the namespace registration database. The dashed line and the corresponding dashed box around provider 131 indicate that namespace management 103 refers to provider 131 as having an interest in the namespace represented by namespace ID 142.
Method 730 can also include actions to determine how often the activity of the provider should be verified later. For example, namespace management 103 can determine how often the activity of provider 131 should be verified later. Namespace management 103 can optionally subscribe to activity notifications issued on the issue / subscription topic of provider 131 identified by ID 161. Publishing / joining topics can be identified by ID161. Alternatively, if no active subscription is made, the registration will be assigned a time-limited lease. Provider 131 may renew its registration by contacting namespace management 103 directly before the lease expires. Other activation mechanisms can also be used.
Namespace management and provider activity can be distributed hierarchically. Management of namespaces located at higher levels in the hierarchy relies on management of other similarly located namespaces to report activity information about the corresponding lower level namespace management and providers. be able to. For example, in FIG. 1, namespace management 103 can track the activity of namespace management 102 (both root namespace management). Namespace management 103 relies on namespace management 102 to report any corresponding lower-level namespace management (eg, namespace management 112) or provider (eg, provider 124) failure. Can be done. Namespace management 102 will also rely on namespace management 103 to report similar types of failures (eg, provider 126 failures).
Following the success (or failure) of registration of provider 131, namespace management 102 may send a message to provider 131 instructing success (or failure).
From time to time, a consumer (another computer system or device) may want access to resources within a branch of a namespace managed by a provider. To gain access to a resource, the consumer can issue a search request and attempt to identify the resource. Search requests can be received with namespace management and delivered to one or more appropriate providers. In general, namespace management, when receiving a search request, sends the search request to the namespace management of the closest partner (determined by some predefined proximity metric) and within the request. Routes to the vicinity of namespace management that is responsible for the branching of the specified namespace. Since the registration information is replicated across the management of neighboring namespaces, the search request can be satisfied by managing any namespace in the neighborhood set.
Routing through namespace management, which is closest to namespace management that originates search requests, results in improved network throughput and dynamic load balancing, which automatically makes search requests in terms of satisfying search requests. This is because it is effectively and efficiently divided over the management of neighboring namespaces. To facilitate routing, the algorithm for copying the namespace ID specified in the search request can be essentially the same as the algorithm for copying the namespace ID specified in the registration request. There is sex. For example, a one-to-one mapping from the namespace identity value domain to namespace management can be used to copy namespace identities for both search and registration requests.
FIG. 8A illustrates a flowchart of an embodiment of a method for routing namespace search requests. Method 810 is described for the federation infrastructure of the namespace in Figure 1 and the namespace in Figure 6.
Method 810 involves receiving an action to receive a namespace search request, including a namespace identifier that identifies a namespace branch (action 811). For example, namespace management 103 can receive search request 133. Search request 133 can specify a namespace ID 143 that identifies a branch of the namespace tree 602, for example Location: / Bldg42 / Floor2 / Room2005.
Method 810 includes the operation of generating equivalence identification values in at least one direction based on namespace identifiers (operation 812). For example, namespace management 102 can generate hash 153 by hashing the scheme portion of namespace ID143 with at least part of the path portion of namespace ID143.
Method 810 involves sending a namespace search request to the destination namespace management (action 813). Destination namespace management is within the predefined scope of namespace management, having a unique identifier that is quantitatively closest to the equivalence identification value in at least one direction. Included in the vicinity. To route search request 133, namespace management 103 can call the RouteProximally (or RouteNumerically) function. For example, namespace management 103 can call RouteProximally (hash 153, search message 133, proximity criterion P) to route search message 133 to partner namespace management 102, which is the partner's Assuming that namespace management 102 has the unique ID that is quantitatively closest among namespace management that is considered close to namespace management 103 under the specified proximity criterion P. , Because it is identified. The namespace management 102 can be identified from the RouteProximally function.
Method 810 can also include the operation of forwarding a namespace search request for delivery to one or more providers interested in namespace branching. For example, namespace management 103 can forward search request 133 to namespace management 102. Namespace management 102 can forward search request 133 to provider 131.
FIG. 8B illustrates a flowchart of an embodiment of a method for migrating namespace search requests. Method 820 describes the federation infrastructure of the namespace in Figure 1 and the namespace in Figure 6.
Method 820 includes the action of receiving a namespace search request for a namespace branch (action 821). A namespace search request contains a unique namespace identifier that identifies a branch of a particular namespace. For example, the namespace identifier can be URI ID 143. In addition, the received namespace search request contains at least one unidirectional equivalent numeric identification value generated based on the optionally specified namespace branch identifier. For example, hash 153 may be generated from at least part of the namespace ID143 scheme and path portion. A namespace management identifier for a namespace management is closer to a namespace branch identifier than a namespace branch identifier that belongs to one or more other namespace management. Namespace management 102 receives search request 133 as a result of unique ID 172 being closer to hash 153 than the unique identifier for managing other namespaces in namespace federation infrastructure 100 (eg, ID 174). can do.
Method 820 includes an action of detecting an indication that a namespace branch has been migrated to management of a different namespace with an identifier of management of a different namespace (action 822). For example, namespace management 102 can detect the presence of a stub that indicates that the namespace branch represented by namespace ID 143 has been migrated to namespace management 101.
Method 820 can also include at least notifying that the namespace management of the calling party has transitioned to the management of a different namespace. For example, namespace management 102 can at least notify namespace management 103 that the namespace branch represented by namespace ID 143 has been migrated. For example, namespace management 102 should send a consignment message 134 to namespace management 103 so that namespace management 103 should contact namespace management 101, or for a migrated branch. It can indicate that a new search request 132 should be initiated.
Namespace management 103 can follow instructions from namespace management 102 contained within the entrusted message.
As an alternative, namespace management 102 can reroute the search request 133 itself by calling RouteProximally (new ID H, search request 133, proximity criterion P) on its own. For example, a new ID H hashes the migrated namespace branch of the entire component, as opposed to the original hash value, which was generated only by hashing the schema part and the first part of the path component. By doing so, it can be generated. Calling RouterProximally allows you to route search request 133 to another namespace management for delivery to namespace management 101 (indicated by the dashed arrow, including search request 133).
FIG. 8C illustrates a flowchart of an embodiment of a method for processing a namespace search request. Method 830 describes the federation infrastructure of the namespace in Figure 1 and the namespace in Figure 5.
Method 830 involves receiving an action to receive a namespace search request, including a namespace identifier that identifies a branch of the namespace that belongs to the namespace (action 831). For example, namespace management 102 can receive namespace search request 133, including namespace ID 143. Namespace ID143 can identify a namespace branch of namespace infrastructure 500.
Method 830 includes an action that identifies a namespace search request type for a namespace search request (action 832). For example, namespace management 102 identifies the search request type for the namespace of search request 133. In some embodiments, the namespace search request type is a generic request type (for example, for a branch in one of the namespaces) or a targeted request type (for example, for a branch in a particular namespace). Can be.
Method 830 includes an action that detects that one or more providers are registering for a portion of the namespace associated with a namespace branch (behavior 833). For example, namespace management 102 may detect that one or more providers are registering for the portion of the namespace associated with the namespace branch represented by namespace ID143. it can. At this time, referring to FIG. 5, if the ID 143 of the namespace is Location: / Corporate Buildings / Bldg 50 / Floor 1, the providers 501, 502 and 503 can be identified. Provider 501 is registered for Room 1304 (below Floor 1 in namespace tree 500), provider 502 is registered for Bldg 50 (above floor 1 in namespace tree 500), and provider 503 is named. Registered for Floor 1 in the spatial tree 500.
Method 830 can also include forwarding a namespace search request to at least one provider based on the identified namespace search request type. For example, namespace management 102 can forward search request 133 to one or more of providers 501, 502 and 503.
For generic requests, namespace management 102 forwards the request to all providers whose registration namespace branch is either a prefix or suffix of what is specified in the search request. For example, namespace management 102 can forward namespace search requests 133 to providers 501, 502, and 503 if namespace ID 143 is Location: / Corporate Buildings / Bldg 50 / Floor 1. For targeted requests, namespace management forwards the request only to the provider, whose registration namespace branch is the largest prefix of what is specified in the search request. However, for both generic and targeted types, if multiple copies of a given provider are available, such as 501, namespace management 102 makes a request under the selected proximity metric. Forward to the provider closer to the source of the search request (namespace management 103 in this case).
Namespace management 103 can create a connection between the namespace branch represented by namespace ID 143 and namespace management 102 (for example, store it in the namespace database). ). Such a binding is such that a namespace search request that specifies a namespace branch (eg Location: / Corporate Buildings / Bldg 50 / Floor 1) directly below what is specified in the binding is routed to namespace management 102. Make it easier to be transferred rather than being done. If a failure in managing the target namespace is detected, or if a delegation to the management of a different namespace is obtained, the bond is broken. In the former case, subsequent requests are routed until new bindings can be formed.
FIG. 9 illustrates a flowchart of an embodiment of a method for a resource to participate in multiple namespaces. Method 900 is described for the namespace tree in Figure 6.
Method 900 includes the action of establishing a unique resource identifier for a resource (action 901). Action 901 can include establishing the path portion of the URI corresponding to the resource. For example, the identifier of "printer 603" can be established for the printer.
Method 900 includes an action that issues resource usefulness in the first namespace (action 902). For example, printer 603 can publish its usefulness within tree 601 in the namespace. Method 900 links a unique resource identifier to a node resource in the first namespace within the first namespace so that the first namespace can be traversed to identify the resource. Includes (operation 903). For example, namespace segment 631 can be established to link printer 603 to a node resource in the "Dev Team" namespace. Therefore, the namespace tree 601 (and the node resource in the "Dev Team" namespace) can be traversed to identify the printer 603.
Method 900 includes an action that issues resource usefulness in a second namespace (action 904). For example, printer 603 can publish its usefulness within tree 602 in the namespace. Method 900 links a unique resource identifier to a node resource in the second namespace within the second namespace so that the second namespace can be traversed to identify the resource. Includes (operation 905). For example, namespace segment 632 can be established to link printer 603 to a node resource in the "Room 1226" namespace. Therefore, the namespace tree 602 (and the node resource in the "Room 1226" namespace) can also be traversed to identify the printer 603.
FIG. 10 illustrates a flowchart of an embodiment of a method for identifying a subset of resources within a namespace federation infrastructure. Method 1000 will be described for the namespace tree in Figure 6.
Method 1000 includes the operation of receiving a query from the device (operation 1001). For example, a provider for namespace tree 602 can receive queries from devices that are networks that can connect to that provider. The query contains a first query part that identifies the first part of a resource that meets the first query criteria at the first level in the namespace hierarchy. For example, the first query part can identify the first part of a resource that meets the first query criteria after traversing the namespace segment "Floor 2" (in the namespace tree 602). The first part of the resource can be, for example, an employee, and the first criterion can also include, for example, being assigned to a "Messaging Team". In this way, the first query part can identify all employees assigned to the "Messaging Team" working on Floor 2 (of Bldg 42). In some embodiments, the first query criterion is utilized to navigate through the properties of the resource that reference the first part of the resource.
The query includes a second query part that identifies the second part of the selected resource from the resources contained in the first part of the resource. For example, the second query part can identify the second part of a resource that meets the second query criteria after traversing the namespace segment "Room 2005" (in the namespace tree 602). The second part of the resource can be, for example, an administrator, and the second criterion can be, for example, a device. Thus, the second query part can identify the printer administrator with the office cubicle in Room 2005. In some embodiments, a second query criterion is utilized to navigate through the properties of the first part of the resource that references the second part of the resource.
Therefore, if you provide the resource identified from the first query part as input to the second query part, the result of the received query (depending on the field definition in the resource schema) will be upstairs, Room 2005. Can identify printer administrators who have offices within and are assigned to the Messaging Team.
Method 1000 involves returning the identity of the second part of the resource back to the device (action 1002). For example, a provider for namespace tree 602 can revert the identity of the device administrator in Room 2005, owned by a Messaging Team employee on Floor 2, to a networkable device.
FIG. 12 illustrates a flowchart of an embodiment of a method for organizing a plurality of resources. Method 1200 is described for the namespace infrastructure of Figure 6.
Method 1200 includes the action of determining that a new resource should be contained within one or more namespaces, so that each of one or more namespaces organizes one or more resources. It is configured in (operation 1201). For example, it can be determined that the printer 603 should be contained within namespace 601 and / or namespace 602. Method 1200 includes the action of identifying the first resource in the first namespace of one or more namespaces that should be associated with the new resource (action 1202). For example, it can be identified that room 1226 in namespace 602 should be associated with printer 603. Similarly, it can be identified that the Dev Team in namespace 601 should be associated with printer 603.
Method 1200 uses a segment of the first namespace to link a new resource to the first resource, traversing the segment of the namespace and navigating from an existing resource to a new resource in the namespace. Includes actions that allow you to (action 1203). For example, namespace segment 632 can be used to link printer 603 to Room 1226 so that namespace segment 632 can be traversed to navigate from Room 1226 to printer 603. Similarly, namespace segment 631 can be used to link printer 603 to the Dev Team so that namespace segment 631 can be traversed to navigate from Dev Team to printer 603.
FIG. 11 and the following discussion are intended to provide a brief overall description of a suitable computing environment of embodiments in which the present invention can be practiced. Although not required (eg, when implemented in hardware), the present invention will generally be described in relation to computer executable instructions executed by a computer system, such as program modules. Program modules typically include routines, programs, objects, components, data structures, etc., which either perform a particular task or implement a particular abstract data type. Computer executable instructions, associated data structures, and program modules represent examples of program code means for performing the operations of the methods disclosed herein.
Referring to FIG. 11, the system of embodiments for carrying out the present invention includes a general purpose computing system in the form of computer system 1120, which includes processing apparatus 1121, system memory 1122, and Includes system bus 1123, which connects various system components, including system memory 1122, to processor 1121. The processor 1121 is capable of executing computer executable instructions designed to implement the features of the computer system 1120, including the features of the present invention. The system bus 1123 can be in any of several types of bus structures, which use any of the various bus architectures, memory bus or memory controller, peripheral bus, and local. Bus is included. System memory includes read-only memory (ROM) 1124 and random access memory (RAM) 1125. The basic I / O system (BIOS) 1126 contains basic routines that help transfer information between multiple elements within the computer system 1120, such as during boot, and can be stored in ROM 1124.
Computer systems 1120 also include magnetic hard disk drives 1127 for reading and writing to magnetic hard disks 1139, magnetic disk drives 1128 for reading and writing to removable magnetic disks 1129, and, for example, CD-ROMs or other optical storage media. It may also include an optical disk drive 1130 for reading and writing to the removable optical disk 1131. The magnetic hard disk drive 1127, magnetic disk drive 1128, and optical disk drive 1130 are connected to system bus 1123 by hard disk drive interface 1132, magnetic disk drive interface 1133, and optical drive interface 1134, respectively. The drives and their associated computer readable media provide a non-volatile storage of computer executable instructions, data structures, program modules and other data for computer system 1120. The environment of the examples described herein uses a magnetic hard disk 1139. Removable magnetic disk 1129 and removable optical disk 1131, but other types of computer-readable media for storing data can be used. , These computer-readable media include magnetic cassettes, flash memory cards, digital versatile disks, Bernoulli cartridges, RAM, ROM, and the like.
Program code means with one or more program modules can be stored on hard disk 1139, magnetic disk 1129, optical disk 1131, ROM 1124 or RAM 1125, and these program modules include operating system 1135, one or more. Includes application program 1136, other program modules 1137, and program data 1138. The user can enter commands and information into the computer system 1120 through the keyboard 1140, pointing device 1142, or other input device (not shown), such as a microphone, joystick, gamepad, scanner. These and other input devices can be connected to processing device 1121 through the I / O interface 1146 coupled to system bus 1123. The input / output interface 1146 may be, for example, a serial port interface, a PS / 2 interface, a parallel port interface, a universal serial bus (USB) interface, or an American Institute of Electrical and Electronic Engineers (IEEE) 1394 interface (ie, a FireWire interface). It may logically represent one of a wide variety of different interfaces, or a combination of different interfaces.
Monitor 1147 or other display device can also be connected to system bus 1123 via video interface 1148. Speakers 1169 or other audio output devices are also connected to system bus 1123 via audio interface 1149. Other peripheral output devices (not shown), such as printers, can also be connected to computing system 1120.
The computer system 1120 can be connected to a network such as an office-wide or enterprise-wide computer network, a home network, an intranet and / or the Internet. Computer system 1120 can exchange data with external resources, such as remote computer systems, remote applications, and / or remote databases, over such networks.
The computer system 1120 includes a network interface 1153, through which the computer system 1120 receives data from an external source and / or sends data to an external source. As shown in FIG. 11, network interface 1153 facilitates the exchange of data with remote computer system 1183 over link 1151. Network Interface 1153 can logically represent one or more software and / or hardware modules, such as a network interface card and a corresponding Network Driver Interface Specification (NDIS) stack. Link 1151 represents a portion of the network (eg, an Ethernet® segment) and remote computer system 1183 represents the computer system of the network.
Similarly, the computer system 1120 includes an input / output interface 1146, through which the computer system 1120 receives data from an external source and / or sends data to an external source. The input / output interface 1146 is coupled to a modem 1154 (eg, a standard modem, cable modem, or digital subscriber line (DSL) modem) over link 1159, through which the computer system 1120 receives data from an external source through modem 1154. Receive and / or send data to an external source. As shown in FIG. 11, the I / O interface 1146 and modem 1154 facilitate the exchange of data with the remote computer system 1193 via link 1152. Link 1152 represents a portion of the network and remote computer system 1193 represents the computer system of the network.
FIG. 11 represents a suitable operating environment for the present invention, but the principles of the present invention may be used in any system in which the principles of the present invention can be implemented with appropriate modifications, if necessary. You can also. The environment illustrated in FIG. 11 is only exemplary and by no means represents even a small portion of the wide range of environments in which the principles of the invention can be practiced.
According to the present invention, namespace management, providers and resources, and related data including namespace databases, namespace identifiers and strings, hashes, resource identifiers, routing tables and namespace trees are stored. It can be accessed from any of the computer-readable media associated with the computer system 1120. For example, some of such modules and some of the associated program data are contained within the operating system 1135, application program 1136, program module 1137 and / or program data 1138 for storage in system memory 1122. there is a possibility.
When a mass storage device, such as a magnetic hard disk 1139, is coupled to the computer system 1120, such modules and associated program data can also be stored within the mass storage device. In a networked environment, the program modules shown in relation to computer system 1120 or parts thereof can be stored in remote memory storage, which can be stored in remote computer system 1183 and / or remote computer system 1193. For example, associated system memory and / or mass storage. Execution of such a module can be executed in the distributed environment as described above.
The present invention can be practiced in other particular embodiments without departing from its spiritual or essential properties. The embodiments described are exemplary in all respects and should be considered non-limiting. The scope of the invention is therefore indicated by the appended claims, not by the aforementioned description. The meaning of the equivalents of the claims and all changes that fall within those scopes should be included within those scopes.
<figref num="1">It is a figure which illustrates the embodiment of the federation infrastructure of a namespace.</figref><figref num="2">FIG. 5 illustrates an embodiment of a computer architecture that facilitates the indirect routing of requests to partners.</figref><figref num="3">It is a diagram illustrating an embodiment of a binary relation between the management of a plurality of namespaces in a namespace federation infrastructure.</figref><figref num="4">FIG. 5 illustrates an architectural embodiment that facilitates the integration of namespace federation infrastructure with other protocols.</figref><figref num="5">FIG. 5 illustrates an embodiment of a namespace federation infrastructure and a namespace collection view from a provider.</figref><figref num="6">FIG. 5 illustrates an embodiment of a namespace federation infrastructure with resources made available within a plurality of namespaces.</figref><figref num="7A">It is a figure which illustrates the flowchart of embodiment of the method for routing a namespace registration request.</figref><figref num="7B">It is a figure which illustrates the flowchart of the embodiment of the method for migrating the namespace registration request.</figref><figref num="7C">It is a figure which illustrates the flowchart of embodiment of the method for processing a namespace registration request.</figref><figref num="8A">It is a figure which illustrates the flowchart of embodiment of the method for routing a namespace search request.</figref><figref num="8B">It is a figure which illustrates the flowchart of the embodiment of the method for migrating the search request of a namespace.</figref><figref num="8C">It is a figure which illustrates the flowchart of embodiment of the method for processing a search request of a namespace.</figref><figref num="9">It is a figure which illustrates the flowchart of the embodiment of the method for a resource to participate in a plurality of namespaces.</figref><figref num="10">FIG. 5 illustrates a flowchart of an embodiment of a method for identifying a subset of resources within a namespace federation infrastructure.</figref><figref num="11">It is a figure which illustrates the suitable operating environment for the principle of this invention.</figref><figref num="12">It is a figure which illustrates the flowchart of embodiment of the method for organizing a plurality of resources.</figref><figref num="13">It is a figure which illustrates the embodiment of the schema classification method which can be used to describe a resource.</figref>
17 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2003316636A | Cites | Japan |
| JP2004110624A | Cites | Japan |
| WO03058537A1 | Cites | World Intellectual Property Organization (WIPO) |
| JP2005515526A | Cites | Japan |
| JP2001005758A | Cites | Japan |
172 members in 16 offices
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 10956472 | United States of America | – | |
| 95647204 | United States of America | A | |
| 95647204 | United States of America | A | |
| 2004956472 | – | – | – |
| US20040956472 | – | – | – |
Members172
| Document | Office | Kind | |
|---|---|---|---|
| CA2517538A1 | Canada | A1 | |
| CA2833834A1 | Canada | A1 | |
| CN1755694A | China | A | |
| EP1643730A2 | European Patent Office (EPO) | A2 | |
| MXPA05009679A | Mexico | A | |
| US2006074876A1 | United States of America | A1 | |
| AU2005203695A1 | Australia | A1 | |
| JP2006107501A | Japan | A | |
| CA2523897A1 | Canada | A1 | |
| CN1764171A | China | A | |
| EP1650911A2 | European Patent Office (EPO) | A2 | |
| MXPA05011314A | Mexico | A | |
| MXPA05011314A | Mexico | A | |
| US2006087985A1 | United States of America | A1 | |
| US2006087990A1 | United States of America | A1 | |
| US2006088015A1 | United States of America | A1 | |
| US2006088039A1 | United States of America | A1 | |
| US2006090003A1 | United States of America | A1 | |
| BRPI0504205A | Brazil | A | |
| AU2005220253A1 | Australia | A1 | |
| KR20060049121A | Republic of Korea | A | |
| KR20060050878A | Republic of Korea | A | |
| KR20060050878A | Republic of Korea | A | |
| EP1650911A3 | European Patent Office (EPO) | A3 | |
| US2006117024A1 | United States of America | A1 | |
| US2006117025A1 | United States of America | A1 | |
| US2006117026A1 | United States of America | A1 | |
| BRPI0504513A | Brazil | A | |
| BRPI0504513A | Brazil | A | |
| JP2006174417A | Japan | A | |
| US2006282505A1 | United States of America | A1 | |
| US2006282547A1 | United States of America | A1 | |
| US2007002774A1 | United States of America | A1 | |
| RU2005130350A | Russian Federation | A | |
| RU2005130350A | Russian Federation | A | |
| RU2005132569A | Russian Federation | A | |
| US2007133520A1 | United States of America | A1 | |
| AU2006335155A1 | Australia | A1 | |
| CA2629230A1 | Canada | A1 | |
| WO2007081523A2 | World Intellectual Property Organization (WIPO) | A2 | |
| TW200733679A | Taiwan Province of China | A | |
| WO2007081523A3 | World Intellectual Property Organization (WIPO) | A3 | |
| TW200803303A | Taiwan Province of China | A | |
| US2008005624A1 | United States of America | A1 | |
| AU2007270008A1 | Australia | A1 | |
| AU2007270060A1 | Australia | A1 | |
| CA2652917A1 | Canada | A1 | |
| CA2652921A1 | Canada | A1 | |
| WO2008005078A1 | World Intellectual Property Organization (WIPO) | A1 | |
| WO2008005086A1 | World Intellectual Property Organization (WIPO) | A1 | |
| CL2007001394A1 | Chile | A1 | |
| CL2007001453A1 | Chile | A1 | |
| US2008031246A1 | United States of America | A1 | |
| TW200818811A | Taiwan Province of China | A | |
| US7362718B2 | United States of America | B2 | |
| WO2008060938A2 | World Intellectual Property Organization (WIPO) | A2 | |
| NO20082600L | Norway | L | |
| WO2008060938A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1974500A2 | European Patent Office (EPO) | A2 | |
| KR20080089382A | Republic of Korea | A | |
| US2008288646A1 | United States of America | A1 | |
| US2008288659A1 | United States of America | A1 | |
| US7466662B2 | United States of America | B2 | |
| MX2008015966A | Mexico | A | |
| MX2008015966A | Mexico | A | |
| MX2008015984A | Mexico | A | |
| MX2008015984A | Mexico | A | |
| NO20085027L | Norway | L | |
| CN101352002A | China | A | |
| US7496602B2 | United States of America | B2 | |
| EP2036255A1 | European Patent Office (EPO) | A1 | |
| EP2036256A1 | European Patent Office (EPO) | A1 | |
| KR20090034322A | Republic of Korea | A | |
| KR20090034829A | Republic of Korea | A | |
| JP2009522690A | Japan | A | |
| CN101485149A | China | A | |
| CN101491006A | China | A | |
| IL191877A0 | Israel | A0 | |
| IL191877D0 | Israel | D0 | |
| IL195188A0 | Israel | A0 | |
| IL195189A0 | Israel | A0 | |
| EP2095248A2 | European Patent Office (EPO) | A2 | |
| CN101535977A | China | A | |
| KR20090098791A | Republic of Korea | A | |
| US7613703B2 | United States of America | B2 | |
| US7624194B2 | United States of America | B2 | |
| JP2009543188A | Japan | A | |
| JP2009543447A | Japan | A | |
| US2009319684A1 | United States of America | A1 | |
| US7640299B2 | United States of America | B2 | |
| US2009327312A1 | United States of America | A1 | |
| CN100578494C | China | C | |
| US2010005071A1 | United States of America | A1 | |
| RU2008127075A | Russian Federation | A | |
| US2010046399A1 | United States of America | A1 | |
| JP2010509871A | Japan | A | |
| US7694167B2 | United States of America | B2 | |
| US7730220B2 | United States of America | B2 | |
| AU2005220253B2 | Australia | B2 | |
| RU2008152420A | Russian Federation | A |
16 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313113S111 | S111 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 4879547
- Publication, DOCDB
- 4879547
- Publication, EPODOC
- JP4879547B
- Application
- 287843
- Application, DOCDB
- 2005287843
- Application, EPODOC
- JP20050287843
Titles2
- Japanese
- より効率的なおよび確かなリソースアクセスを容易にするコレクションへのリソースの編成
- English
- Organize resources into collections for more efficient and reliable resource access
Classification
- CPC, 11
- H04L61/3015
- G06F15/16
- G06F16/10
- H04L61/4552
- H04L61/30
- Y10S707/99931
- Y10S707/99943
- Y10S707/99945
- Y10S707/99942
- Y10S707/99944
- Y10S707/99948
- IPC, 2
- G06F13 00
- G06F12 00
