Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
The preliminary amendment filed 02/26/2024 has been entered. Claims 1-18 and 21-22 are pending. Claims 1, 17, 21 and 22 are independent. Claims 2-16 and 18 are dependent. Claims 21 and 22 have been amended. Claims 19 and 20 are cancelled.
Information Disclosure Statement
The information disclosure statements (IDSs) submitted on 02/26/2024 and 02/04/2025 were in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-18 and 21-22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Kakivaya et al. (US 20120331122) hereinafter Kakivaya in view of O'Connor et al. (US 20150222589) hereinafter O'Connor.
Regarding claim 1, Kakivaya teaches a routing (i.e. message routing, [0061]) method, comprising: acquiring predetermined information carried in a received application data packet (i.e. receive requests for streaming applications and/or services from clients, [0032]), wherein the predetermined information comprises a cloud resource identifier for processing a cloud resource of application data in the application data packet (i.e. a unique resource identifier for a resource, [0173] and a cloud into which resources, such as, files and event sources are registered. Applications can issue find requests against the cloud to discover registered resources, [0101]); determining, according to a cloud resource identifier routing table, information about a cloud node corresponding to the predetermined information (i.e. resource identifiers, routing tables, and namespace trees, may be stored, [0193] and resources selected from among the resources included in the first portion of resources, [0052]), wherein the cloud resource identifier routing table uses the cloud resource identifier as an index to record the information for providing the cloud node and/or cloud resource instance of the cloud resource identified by the cloud resource identifier (i.e. Each namespace manager on ring 306 can include a routing table that facilitates routing namespace information (e.g. registration and lookup requests) to other namespace managers. An example routing table for the namespace manager having ID 64 is depicted in FIG. 3. The routing table indicates that the successor to ID 64 is ID 76, [0094], a resource can be assigned one or more URIs that can be used to access the resource. One URI, the Resource ID, assigned to a resource can be, at a minimum, unique across all namespaces implemented by a given namespace federation infrastructure such that the resource can be singularly referenced, [0066] and unique resource identifier to a first namespace node resource in the first namespace such that the first namespace can be traversed to identify the resource, [0174], and if the namespace identifier is a URI string, it is stored in the namespace registration database index in alphabetical order with longer strings ranked higher, [0149]); and routing and forwarding the application data packet according to the determined information about the cloud node and/or cloud resource instance (i.e. The routing table indicates that ID 64 can route directly to IDs 200, 2, 30, 46, 50, 64, 76, 83, 98, and 135. Thus, when namespace manager having ID 64 receives a request, the namespace manager can route the requests to the namespace manager having an ID in the routing table that is closer to the namespace manager ID in the request, [0097] and Once a group of resources have been identified, many operations can be performed on them such as selecting resources that satisfy some criteria, sending (and potentially routing) a given message to only those in a group, [0064]).
However, Kakivaya does not explicitly disclose determining, according to a cloud resource identifier routing table, information about a cloud resource instance corresponding to the predetermined information.
However, O'Connor teaches determining, according to a cloud resource identifier routing table, information about a cloud resource instance corresponding to the predetermined information (i.e. for cloud resource identifier routing table, see e.g. table 130 which stores the URL ( the cloud resource identifier) together with the IP address of the cloud server (i.e. the information for providing the cloud instance) for the purpose of routing client requests to the cloud server based on the mapping of the URL to the IP address of the cloud server; Fig. 4; [0054], [0055], [0035], [0031]).
Based on Kakivaya in view of O'Connor, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of O'Connor to the system of Kakivaya in order to utilize higher network speeds and experience less latency, (O'Connor, [0003]).
Regarding claim 2, Kakivaya teaches wherein the cloud resource identifier is configured for globally and uniquely identifying a class of cloud resources, and is independent of the attributions and/or positions of the cloud resources (i.e. Universal Resource Names ("URNs") refer to a subset of URIs that are required to remain globally unique and persist even when a corresponding resource ceases to exist, [0011], The unique resource identifier is linked to an existing namespace node resource in the first namespace such that the first namespace can be traversed to identify the resource,[0023], [0051], [0102], and [0103]).
Regarding claim 3, Kakivaya teaches wherein the class of the cloud resources is divided based on a cloud resource attribute; and the cloud resource attribute comprises at least one of the following: service categories of the cloud resources, service identifiers of the cloud resources, computing resources comprised in the cloud resources, storage resources comprised in the cloud resources, or interface parameters of the cloud resources (i.e. Various types of resources can be published in Namespaces, including services, devices, files, hosts, components, items in a database, metadata about metadata (schemas), and so on. A resource can have a service component hosting/backing it. For example, a file resource can have a file server as the service component for accessing the file, [0102] and in the form of a URI segment parameter, for the fields/attributes defined on a namespace node resource for selection and traversal, [0118]).
Regarding claim 4, Kakivaya teaches wherein the predetermined information further comprises at least one of the following: an aggregation category, support resource attribute, and service parameter of the cloud resource (i.e. in the form of a URI segment parameter, for the fields/attributes defined on a namespace node resource for selection and traversal, [0118] and [0102]).
Regarding claim 5, Kakivaya teaches wherein the information about the cloud node comprises at least one of the following: a gateway address of the cloud node (i.e. A URI can include a network address or alphabetic string identifying a computing device as well as an addition alpha-numeric string identifying a specific resource at the computing device, [0011]), and cloud resource state data of the cloud node (i.e. a resource-specific schema instance containing semi-static metadata about the resource. This metadata is useful for resource selection, [0107])
Regarding claim 6, Kakivaya teaches wherein the information about the cloud resource instance comprises at least one of the following: an address of the cloud resource instance, a state of the cloud resource instance, and information of the cloud node to which the cloud resource instance belongs (i.e. a URI segment parameter, for the fields/attributes defined on a namespace node resource for selection and traversal, identifying a first portion of resources) and would select namespace node resource, [0118]).
Regarding claim 7, Kakivaya does not explicitly disclose wherein the application data packet carries the predetermined information in at least one of the following manners: encapsulating the predetermined information in a cloud resource identifier sub-layer packet header above a network layer of the application data packet; encapsulating the predetermined information in an Internet Protocol version 6 (IPv6) extension packet header of the application data packet; encapsulating the predetermined information by extending an IPv6-based Destination Option Header (DOH) packet header of the application data packet; programmatically encapsulating the predetermined information by extending an IPv6-based Segment Routing version 6 (SRv6) function of the application data packet; encapsulating the predetermined information in a tunnel protocol Overlay extension packet header of the application data packet; encapsulating the predetermined information in a Multi-Protocol Label Switching (MPLS) extension header of the application data packet; or carrying an anycast address corresponding to the cloud resource identifier in a destination address field of a packet header of the application data packet, wherein the prefix of the anycast address is defined as the cloud resource identifier, or the anycast address corresponds to a unique cloud resource identifier, and a mapping relationship between the anycast address and the cloud resource identifier is globally consistent.
However, O'Connor teaches wherein the application data packet carries the predetermined information in at least one of the following manners: encapsulating the predetermined information in a cloud resource identifier sub-layer packet header above a network layer of the application data packet; encapsulating the predetermined information in an Internet Protocol version 6 (IPv6) extension packet header of the application data packet; encapsulating the predetermined information by extending an IPv6-based Destination Option Header (DOH) packet header of the application data packet; programmatically encapsulating the predetermined information by extending an IPv6-based Segment Routing version 6 (SRv6) function of the application data packet; encapsulating the predetermined information in a tunnel protocol Overlay extension packet header of the application data packet; encapsulating the predetermined information in a Multi-Protocol Label Switching (MPLS) extension header of the application data packet; or carrying an anycast address corresponding to the cloud resource identifier in a destination address field of a packet header of the application data packet (i.e. a unique address associated with the uniform resource locator and the local information handling system responsive to determining that the uniform resource locator includes the local domain name of the local information handling system, [0007]), wherein the prefix of the anycast address is defined as the cloud resource identifier, or the anycast address corresponds to a unique cloud resource identifier, and a mapping relationship between the anycast address and the cloud resource identifier is globally consistent (i.e. Table 130 may comprise a list, map, array, database, or other data structure which associates domain names of information handling systems of the local network of router 122 into IP addresses. Accordingly, router 122 may, by performing a look-up into table 130, resolve URLs for information handling systems of its local network without relying on DNS, [0035] and [0054]). Therefore, the limitations of claim 10 are rejected in the analysis of claim 1 above, and the claim is rejected on that basis.
Regarding claim 8, Kakivaya teaches wherein determining, according to the cloud resource identifier routing table, the information about the cloud node and/or cloud resource instance corresponding to the predetermined information comprises: at a cloud resource identifier routing sub-layer, determining, according to the cloud resource identifier routing table, the information about the cloud node and/or cloud resource instance corresponding to the predetermined information (i.e. resource identifiers, routing tables, and namespace trees, may be stored, [0193] and resources selected from among the resources included in the first portion of resources, [0052], and [0011]).
Regarding claim 9, Kakivaya teaches wherein routing and forwarding the application data packet according to the determined information about the cloud node and/or cloud resource instance comprises: at an address routing sub-layer, routing and forwarding the application data packet according to the determined information about the cloud node and/or cloud resource instance (i.e. the routing table indicates that ID 64 can route directly to IDs 200, 2, 30, 46, 50, 64, 76, 83, 98, and 135. Thus, when namespace manager having ID 64 receives a request, the namespace manager can route the requests to the namespace manager having an ID in the routing table that is closer to the namespace manager ID in the request, [0097], once a group of resources have been identified, many operations can be performed on them such as selecting resources that satisfy some criteria, sending (and potentially routing) a given message to only those in a group, [0064], Uniform Resource Locators ("URLs") refer to a subset of URIs that identify resources via representation of their primary access mechanics (e.g., their network location). Universal Resource Names ("URNs") refer to a subset of URIs that are required to remain globally unique and persist even when a corresponding resource ceases to exist, [0011]).
Regarding claim 10, Kakivaya teaches wherein acquiring the predetermined information carried in the received application data packet comprises: acquiring, by a network entry node, the predetermined information carried in the received application data packet (i.e. a unique resource identifier for a resource, [0173] and a cloud into which resources, such as, files and event sources are registered. Applications can issue find requests against the cloud to discover registered resources, [0101]); determining, according to the cloud resource identifier routing table, the information about the cloud node corresponding to the predetermined information comprises: according to the cloud resource identifier routing table, determining, by the network entry node, the information about the cloud node corresponding to the predetermined information (i.e. resource identifiers, routing tables, and namespace trees, may be stored, [0193] and resources selected from among the resources included in the first portion of resources, [0052]); and routing and forwarding the application data packet according to the determined information about the cloud node and/or cloud resource instance comprises: according to the determined information about the cloud node and/or cloud resource instance, determining, by the network entry node, a network edge node corresponding to the cloud node and/or cloud resource instance as a network exit node (i.e. Edge Descriptor Schema: specifies a locally-scoped edge name, the edge type, and target resources, [0114], routing and forwarding the application data packet to the network exit node (i.e. Routing via the namespace manager closest to the namespace manager originating the lookup request results in improved network throughput and dynamic load balancing, since lookup requests get automatically and efficiently partitioned across the neighborhood namespace managers from the lookup request satisfaction perspective, [0154]), and forwarding the application data packet to the cloud node and/or cloud resource instance by the network exit node (i.e. The routing table indicates that ID 64 can route directly to IDs 200, 2, 30, 46, 50, 64, 76, 83, 98, and 135. Thus, when namespace manager having ID 64 receives a request, the namespace manager can route the requests to the namespace manager having an ID in the routing table that is closer to the namespace manager ID in the request, [0097] and Once a group of resources have been identified, many operations can be performed on them such as selecting resources that satisfy some criteria, sending (and potentially routing) a given message to only those in a group, [0064]).
However, Kakivaya does not explicitly disclose determining, according to a cloud resource identifier routing table, information about a cloud resource instance corresponding to the predetermined information.
However, O'Connor teaches determining, according to a cloud resource identifier routing table, information about a cloud resource instance corresponding to the predetermined information (i.e. for cloud resource identifier routing table, see e.g. table 130 which stores the URL ( the cloud resource identifier) together with the IP address of the cloud server (i.e. the information for providing the cloud instance) for the purpose of routing client requests to the cloud server based on the mapping of the URL to the IP address of the cloud server; Fig. 4; [0054], [0055], [0035], [0031])). Therefore, the limitations of claim 10 are rejected in the analysis of claim 1 above, and the claim is rejected on that basis.
Regarding claim 11, Kakivaya teaches wherein acquiring, by the network entry node, the predetermined information carried in the received application data packet comprises at least one of the following: analyzing, by the network entry node, a packet header to acquire the predetermined information when the predetermined information is encapsulated, at a terminal sending the application data packet, in a network layer packet header of the application data packet or a cloud resource identifier sub-layer packet header above a network layer (i.e. To obtain access to resources, the consumers may issue lookup requests to attempt to identify resources. Lookup requests can be received at namespace mangers and delivered to one or more appropriate providers. Generally, when a namespace manager receives a lookup request, it routes that lookup request to the partner namespace manager closest to it (as determined by some predefined proximity metric) and toward the neighborhood of the namespace manager responsible for the namespace branch specified in the request, [0153], Lookup request 133 can specify namespace ID 143 that identifies a branch of namespace tree, [0156]); and deeply detecting, by the network entry node, the application data packet to acquire the predetermined information when the predetermined information is encapsulated, at the terminal sending the application data packet, in a transmission layer under the network layer of the application data packet or an application layer packet header (i.e. a resource can be assigned one or more URIs that can be used to access the resource. One URI, the Resource ID, assigned to a resource can be, at a minimum, unique across all namespaces implemented by a given namespace federation infrastructure such that the resource can be singularly referenced. Other, potentially non-unique, URIs can also be assigned to resources. These other, potentially non-unique, URIs provide access to the resource via additional locations within namespaces implemented by a given namespace federation infrastructure, [0066]), and encapsulating the predetermined information in the network layer packet header of the application data packet or the cloud resource identifier sub-layer packet header above the network layer (i.e. namespace manager 102 can generate a hash 152 based on the scheme portion of namespace ID 142 along with at least part of the path portion of namespace ID 142. Any of a variety of different hashing functions, such as, for example, SHA, can be used to generate a hash value from portions of a namespace string, [0133] and namespace manager 103 can hash the scheme portion of the namespace ID 143 along with at least part of the path portion of the namespace ID 143 to produce hash 153, [0157]).
Regarding claim 12, Kakivaya teaches wherein acquiring the predetermined information carried in the received application data packet comprises: acquiring, by a network exit node, the predetermined information carried in the received application data packet (i.e. a unique resource identifier for a resource, [0173] and a cloud into which resources, such as, files and event sources are registered. Applications can issue find requests against the cloud to discover registered resources, [0101]), determining, according to the cloud resource identifier routing table, the information about the cloud node corresponding to the predetermined information comprises (i.e. (i.e. resource identifiers, routing tables, and namespace trees, may be stored, [0193] and resources selected from among the resources included in the first portion of resources, [0052]).
However, Kakivaya does not explicitly disclose according to the cloud resource identifier routing table, determining, by the network exit node, the information about the cloud resource instance corresponding to the predetermined information; and routing and forwarding the application data packet according to the determined information about the cloud node and/or cloud resource instance comprises: forwarding, by the network exit node, the application data packet to the cloud resource instance according to the determined information about the cloud resource instance.
However, O'Connor teaches according to the cloud resource identifier routing table, determining, by the network exit node, the information about the cloud resource instance corresponding to the predetermined information (i.e. for cloud resource identifier routing table, see e.g. table 130 which stores the URL ( the cloud resource identifier) together with the IP address of the cloud server (i.e. the information for providing the cloud instance) for the purpose of routing client requests to the cloud server based on the mapping of the URL to the IP address of the cloud server; Fig. 4; [0054], [0055], [0035], [0031]); and routing and forwarding the application data packet according to the determined information about the cloud node and/or cloud resource instance comprises: forwarding, by the network exit node, the application data packet to the cloud resource instance according to the determined information about the cloud resource instance (i.e. cloud server 112 may start up and execute host application 118. At step 304, cloud server 112 may attempt to register or confirm registration of an associated local domain name with router, [0044] and host application 118 may comprise a web server application configured to receive requests for streaming applications and/or services from clients, [0032]). Therefore, the limitations of claim 12 are rejected in the analysis of claim 1 above, and the claim is rejected on that basis.
Regarding claim 13, Kakivaya teaches wherein acquiring, by the network exit node, the predetermined information carried in the received application data packet comprises: analyzing, by the network exit node, the network layer packet header of the application data packet or the cloud resource identifier sub-layer packet header above the network layer to acquire the predetermined information (i.e. To obtain access to resources, the consumers may issue lookup requests to attempt to identify resources. Lookup requests can be received at namespace mangers and delivered to one or more appropriate providers. Generally, when a namespace manager receives a lookup request, it routes that lookup request to the partner namespace manager closest to it (as determined by some predefined proximity metric) and toward the neighborhood of the namespace manager responsible for the namespace branch specified in the request, [0153], Lookup request 133 can specify namespace ID 143 that identifies a branch of namespace tree, [0156]).
Regarding claim 14, Kakivaya teaches wherein, when the received application data packet is the first application data packet in an application data stream to which the application data packet belongs (i.e. a subset of resources in namespace federation infrastructure is identified. A query is received from an originator. The query includes a first query portion identifying a first portion of resources that satisfies first query criteria at a first level in a namespace hierarchy, [0024]), after determining, according to the cloud resource identifier routing table, the information about the cloud node and/or cloud resource instance corresponding to the predetermined information, the method further comprises: recording the determined information about the cloud node and/or cloud resource instance to a traffic affinity forwarding table (i.e. a namespace registration request is transferred in a namespace federation infrastructure. A namespace registration request to register a namespace branch is received, the namespace registration request including a namespace string that identifies the namespace branch, [0017] and when a provider/subscriber registers at namespace branch with a namespace manager, the registration request is sent (and potentially routed) to a partner namespace manager responsible for maintaining registration information for the namespace tree specified in the registration request, [0131]).
Regarding claim 15, Kakivaya teaches wherein, when the received application data packet is not the first application data packet in the application data stream to which the application data packet belongs (i.e. The query includes a second query portion identifying a second portion of resources selected from among the resources included in the first portion of resources. For example, a second query portion can identify a second portion of resources that satisfies second query criteria, [0178]), the method further comprises: determining, according to the traffic affinity forwarding table, the information about the cloud node and/or cloud resource instance corresponding to the application data stream (i.e. resource identifiers, routing tables, and namespace trees, may be stored, [0193] and resources selected from among the resources included in the first portion of resources, [0052]); and routing and forwarding the application data packet according to the determined information about the cloud node and/or cloud resource instance (i.e. The routing table indicates that ID 64 can route directly to IDs 200, 2, 30, 46, 50, 64, 76, 83, 98, and 135. Thus, when namespace manager having ID 64 receives a request, the namespace manager can route the requests to the namespace manager having an ID in the routing table that is closer to the namespace manager ID in the request, [0097] and Once a group of resources have been identified, many operations can be performed on them such as selecting resources that satisfy some criteria, sending (and potentially routing) a given message to only those in a group, [0064]).
Regarding claim 16, Kakivaya teaches further comprising at least one of the following: maintaining the cloud resource identifier routing table at a network routing and forwarding node, wherein the network routing and forwarding node comprises a network entry node and/or network exit node of the application data packet; or maintaining the cloud resource identifier routing table at a network centralized control unit, and synchronizing to the network routing and forwarding node regularly or based on a request, wherein the network routing and forwarding node comprises the network entry node and/or network exit node of the application data packet (i.e. namespace manager 103 can determine that the amount of namespace information (related to federation namespace infrastructure 100) being processed at namespace manager 103 has exceeded a configured threshold. A configured threshold can be, for example, a total number of registrations maintained at a namespace manager or a total number of lookup requests being serviced at a namespace manager, [0140] and Each of the namespace managers 101, 102, 103, 111, and 112 can maintain a database of namespace information, such as, for example, what namespace managers or providers are interested in which namespace branches, [0076]).
Regarding claim 17, Kakivaya teaches a cloud resource registering (i.e. a namespace federation infrastructure as a cloud into which resources, such as, files and event sources are registered, [0101]) method, comprising: receiving cloud resource information reported by a cloud resource providing end (i.e. Applications can also request the cloud to subscribe on their behalf to both current and future event sources registering with the cloud. Further, applications can subscribe to pub-sub topics maintained in the cloud. Anyone can publish a notification message and the cloud takes care of forwarding the message to the subscribers of the event topic into which that message was published, [0101]), wherein the cloud resource information comprises: a cloud resource identifier of a cloud resource provided, and information for providing a cloud node and/or cloud resource instance of the cloud resource (i.e. resources can be defined to have the following properties: [0106] Resource ID: a URI that can optionally be augmented with a set of reference properties and can be stable in space and time. It can be represented as an instance of a resource reference schema, [0105]); and generating or updating a cloud resource identifier routing table according to the cloud resource information (i.e. The routing table indicates that the predecessor to ID 64 is ID 50. The predecessor can be the immediate adjacent namespace manager in a counterclockwise direction from ID 64 on ring 306. The predecessor can change, for example, when a new namespace manager (e.g., with an ID of 59) joins or an existing namespace manager (e.g., ID 50) leaves the namespace federation infrastructure, [0095]).
However, Kakivaya does not explicitly disclose wherein the cloud resource identifier routing table uses the cloud resource identifier as an index to record the information for providing the cloud node and/or cloud resource instance of the cloud resource identified by the cloud resource identifier.
However, O'Connor teaches wherein the cloud resource identifier routing table uses the cloud resource identifier as an index to record the information for providing the cloud node and/or cloud resource instance of the cloud resource identified by the cloud resource identifier (i.e. Each namespace manager on ring 306 can include a routing table that facilitates routing namespace information (e.g. registration and lookup requests) to other namespace managers. An example routing table for the namespace manager having ID 64 is depicted in FIG. 3. The routing table indicates that the successor to ID 64 is ID 76, [0094], a resource can be assigned one or more URIs that can be used to access the resource. One URI, the Resource ID, assigned to a resource can be, at a minimum, unique across all namespaces implemented by a given namespace federation infrastructure such that the resource can be singularly referenced, [0066] and unique resource identifier to a first namespace node resource in the first namespace such that the first namespace can be traversed to identify the resource, [0174], and if the namespace identifier is a URI string, it is stored in the namespace registration database index in alphabetical order with longer strings ranked higher, [0149]).
Based on Kakivaya in view of O'Connor, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of O'Connor to the system of Kakivaya in order to utilize higher network speeds and experience less latency, (O'Connor, [0003]).
Regarding claim 18, Kakivaya teaches further comprising at least one of the following: reporting the cloud resource identifier routing table to a network centralized control unit; or flooding the cloud resource identifier routing table between network routing and forwarding nodes (i.e. A configured threshold can be, for example, a total number of registrations maintained at a namespace manager or a total number of lookup requests being serviced at a namespace manager, [0140] and Each of the namespace managers 101, 102, 103, 111, and 112 can maintain a database of namespace information, such as, for example, what namespace managers or providers are interested in which namespace branches, [0076]).
Regarding claims 21 and 22, the limitations of claims 21 and 22 are similar to the limitations of claim 1. Kakivaya further teaches a non-transitory computer readable storage medium, wherein a computer program is stored in the computer readable storage medium (i.e. computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media may be any available media, which is accessible by a general-purpose or special-purpose computer system. By way of example, and not limitation, such computer-readable media can comprise physical storage media such as RAM, ROM, EPROM, CD-ROM or other optical disk storage, [0054]), an electronic apparatus, comprising a memory, a processor, and a computer program that is stored in the memory and executable on the processor (i.e. a computer system can include a single physical device (such as a mobile phone or Personal Digital Assistant "PDA") where internal modules (such as a memory and processor) work together to perform operations on electronic data, [0056]). Therefore, the limitations of claims 21 and 22 are rejected in the analysis of claim 1 above, and the claims are rejected on that basis.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Zhang (US 20210136653 A1), A mapping relationship between a service feature and a network slice is established on an IoT platform, or a routing policy for determining a network slice based on a service feature is established on an IoT platform.
Kim et al. (US 20190289648 A1), the router gateway may then access information in a routing table or routing policy, and may direct the packet to the next network or device in the transmission path of the packet.
Keller et al. (US 20190028431 A1), the systems and methods identify each of a service name and a controller name embedded in the URI, and identify a controller service instance using the service name and controller name from the URI, from a mapping of a plurality of controller server instances to respective service names and controller names.
Wan et al. (US 20180041428 A1), receiving a data packet that comprises a destination address, a source address, and a payload, determining a plurality of next-hops along a service chain path between the source address and the destination address.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYELE F WOLDEMARIAM whose telephone number is (571)270-5196. The examiner can normally be reached M_F 8:30AM-5:00PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Joon H Hwang can be reached at 571-272-4036. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/AW/
AYELE F. WOLDEMARIAM
Examiner
Art Unit 2447
10/28/2025
/SURAJ M JOSHI/Primary Examiner, Art Unit 2447