DETAILED ACTION
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 .
General Remarks
This communication is considered fully responsive to Applicant’s application filed 08/06/2025.
Application filed: 03/15/2024
Claims:
Claims 1-9, 11-16 and 18-22 are pending.
Claims 1, 11, 18 and 20 are independent.
Claims 1, 3-5, 11, 18 and 20 are amended.
Claims 10 and 17 are canceled.
Claims 21 and 22 are new.
IDS:
Previous IDS:
IDS filed 09/13/2024 has been considered.
Continuity/Priority Data:
This Application claims priority Chinese Application No. CN202111080886.1 filed 09/15/2021.
This Application is a Continuation of International Application No. PCT/CN2022/118231 filed 09/09/2022.
Response to Arguments
Applicant's arguments filed 02/09/2026 have been fully considered but they are not persuasive.
Applicant argues the cited prior art does not teach the newly amended claim language, in particular, Applicant argues the Plunk teachings are significantly different from the technology described in Applicant’s specification. See page 4 of the Applicant’s response.
Examiner respectfully disagrees with Applicant’s specification.
Applicant argues that the specification describes handling API version mismatches by altering the version identifier to one supported by the service providing network element (SPNE) and the content of the service request is unchanged. Applicant further argues that Plunk handles mismatches of the APIs by preserving the version identifier and instead altering the data to match what is expected by the receiving service providing network element.
Examiner is unpersuaded by Applicant’s arguments in light of the newly amended claim language. Applicant argues that the actual request remains unchanged while the version identifier used with the URI of the request is changed. However, the claim language does not reflect the arguments presented by the Applicant or at the very least, the claim language presented is unclear if they represent the arguments presented by Applicant.
For example, Applicant has amended the claims to state in part:
determining, by the service communication proxy, a version of the service-based interface identified in the uniform resource identifier (URI) of the service request message is inconsistent with a version of the service-based interface selected by the service communication proxy;changing, by the service communication proxy, the version of the service-based interface identified in the URI of the service request message to the version of the service-based interface supported by the service providing element selected by the service communication proxy;
Applicant argues the above limitations are meant to be interpreted as the version of the URI being updated and then used to make the service request. Meaning, the version ID within the URI itself is updated and the underlining data within the request remains unchanged. However, the current state of the claim limitations do not reflect this. The above limitations only state that the interface version is identified in the URI and then changing the version that is identified in the URI. It is not clear that the URI itself is changed, but only that the version of the interface that is identified in the URI is changed. If Applicant wants to have that specific interpretation of the claims, the claim language needs to be more explicit in the language used within the claims.
As such, the interpretation of a version of an interface being updated using the version identifier of the URI request is still warranted and reasonable. Therefore, the teachings of the prior art still teaches the claim limitations as they are currently stated.
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 may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 1-9, 11-16 and 18-22 are rejected under 35 U.S.C. 103 as being unpatentable over International Application No. WO 2021/083926 A1 to Yang et al. (“Yang”) in view of U.S. Patent No. 10,769,000 B1 to Plunk et al. (“Plunk”).
As to claim 1, Yang discloses:
a communication method, comprising:
wherein the service request message is used to request to invoke a service at a service providing network element (¶0028, ¶0037, ¶0047 – Yang teaches sending a service discovery request and service requests),
wherein the service request message includes version information of a service-based interface for the requested service (¶0022 – Yang teaches determining if the search identifies a service producer capable of providing a service having a same major API version as the preferred API version; ¶0059 – Yang teaches discovery by SCP, the NF consumer may indicate a preferred API version in HTTP header), and
wherein the service-based interface is supported by the service invoking network element (¶0037, ¶0046-¶0048 – Yang teaches support of multiple API versions of the same service and lists of candidate NF service producers of supported service API versions and service discovery request includes filed and/or parameter specifying the preferred API version), and
selecting, by the service communication proxy, a first service providing network element based on the service request message (¶0049 – Yang teaches use of criteria to select a desired API version (i.e., preferred API version),
wherein the selected service providing network element and the service invoking network element are able to support a same version of the first service-based interface (¶0022 – Yang teaches determining if the search identifies a service producer capable of providing a service having a same major API version as the preferred API version; ¶0059 – Yang teaches discovery by SCP, the NF consumer may indicate a preferred API version in HTTP header).
Plunk discloses what Yang does not expressly disclose.
Plunk discloses:
receiving, by a service communication proxy, a service request message sent by a service invoking network element (Fig. 1 of Plunk),
determining, by the service communication proxy, a version of the service-based interface identified in the uniform resource identifier (URI) of the service request message is inconsistent with a version of the service-based interface selected by the service communication proxy (Fig. 2A, First API Response; col. 15 ll. 9-26 – Plunk teaches receiving a GET/v1 (i.e., api version) response from the server (240) (i.e., service providing network element)); and
changing, by the service communication proxy, the version of the service-based interface identified in the URI of the service request message to the version of the service-based interface supported by the service providing element selected by the service communication proxy (Fig. 2A, Second API Response; col. 15 ll. 9-26– Plunk teaches receiving a GET/v2 (i.e., api version) response from the compute server (120) (i.e., proxy)).
sending, by the service communication proxy, the updated service request message to the selected service providing network element (Fig. 2A, Fig. 2B of Plunk);
receiving, by the service communication proxy, a service response message sent by the selected service providing network element (Fig. 2A, First API Response; col. 15 ll. 9-26 – Plunk teaches receiving a GET/v1 (i.e., api version) response from the server (240) (i.e., service providing network element));
updating, by the service communication proxy, the service response message by adding to the service response message the version of the service-based interface supported by the service providing network element (col. 11 ll. 10-38 – Plunk teaches this can be performed by determining a version identifier of the API included in an HTTP header of the API request. In some embodiments, the gateway module 210 includes an API version determiner that is operative to determine whether the request triggers execution of the API compatibility enabler 155A.; col. 16 ll. 1-18 – Plunk teaches the API request is an HTTP GET method for “api.example.com,” with an HTTP Header including a version identifier of a first version of the API, where the version identifier does not match any version identifiers stored at the origin server triggers execution of an API compatibility enabler to convert the HTTP GET request into an HTTP GET request in a second version of the API.); and
sending, by the service communication proxy, the updated service response message to the service invoking network element (Fig. 2A, Second API Response; col. 15 ll. 9-26– Plunk teaches receiving a GET/v2 (i.e., api version) response from the compute server (120) (i.e., proxy)),
Yang and Plunk are analogous arts because they are from the same field of endeavor with respect to API versions.
Before the effective filing date, it would have been obvious to a person of ordinary skill in the art to incorporate API versions as discussed in Plunk with the communication method as discussed in Yang by adding the functionality of Plunk to the system/method of Yang in order to transparently enable compatibility between multiple versions of an application programming interface (API). (Plunk, col. 1 ll. 9-14).
As to claim 2, Yang and Plunk discloses:
method according to claim 1, and
Yang discloses:
wherein before the selecting the first service providing network element based on the service request message, the method further comprises:
obtaining, by the service communication proxy, registration information of a service providing network elements from a network repository function network element (Fig. 3, ¶0013 – Yang teaches requesting profile information and included in a JSON response (i.e, obtain registration information),
wherein the one or more service providing network element is configured to provide the requested service (¶0013 – Yang teaches names of supported service(s), Endpoint information of instance(s) of each supported service and possibly other service parameter. In action 300b the NRF stores the NF profile of the registering NF and preferably marks the NF instance (i.e., NF2 in this example) as available. The NRF may then send a Registration Response to NF2 in action 300c, which response may include the registered NF profile as a confirmation of the registration made by the NRF.),
wherein the registration information comprises a version list of the first service-based interface supported by the one or more service providing network elements (¶0037 – Yang teaches an NF producer may support multiple application programming interface (API) versions of the same service. In that case, the NF producer may register all supported API versions in its NF Profile.), and
wherein the version list comprises one or more versions (¶0037 – Yang teaches an NF producer may support multiple application programming interface (API) versions of the same service. In that case, the NF producer may register all supported API versions in its NF Profile.).
As to claim 3, Yang and Plunk discloses:
method according to claim 2, and
Yang discloses:
wherein the service request message comprises a version of the first service-based interface that is preferentially selected by the service invoking network element (¶0020 – Yang teaches receiving a service discovery request from a network entity, wherein the service discovery request comprises a set of query parameters, the set of query parameters including a preferred application programming interface (API) version), and
wherein the selecting, by the service communication proxy, a first service providing network element based on the service request message (¶0038 – Yang teaches the NF consumer selects an NF instance to send the service request to the service access point registered in the NF profile) comprises
determining, by the service communication proxy based on the registration information, that the selected service providing network element supporting the preferentially selected version (¶0038 – Yang teaches the NF producer may register all supported API versions in its NF Profile; ¶0086 – Yang teaches NRE 502 transmits to the NE 504 the discovery response 503, which is responsive to discovery request 501 (i.e., discovery response 503 includes an array of profiles that match the preferred API version and/or otherwise satisfy the filter criteria included in request 501)).
As to claim 4, Yang and Plunk discloses:
method according to claim 3, and
Yang discloses:
wherein the selecting the first service providing network element based on the service request message comprises:
determining, by the service communication proxy, that the service providing network element does not support the version of the first service-based interface that is preferentially selected by the service invoking network element in the service request message (col. 9 ll. 27-63 of Plunk); and
determining, by the service communication proxy, the first service providing network element according to a local configuration rule (Fig. 2A, Fig. 2B of Plunk),
wherein the first service providing network element supports at least one version in the version list (¶0047 – Yang teaches enabling a service consumer to request, in a service discovery query, that the NRF return a list of candidate NF service producers, of which the supported service API version(s) matches a predetermined criterion specified in the service discovery query; ¶0086 – Yang teaches NRE 502 transmits to the NE 504 the discovery response 503, which is responsive to discovery request 501 (i.e., discovery response 503 includes an array of profiles that match the preferred API version and/or otherwise satisfy the filter criteria included in request 501)).
As to claim 5, Yang and Plunk discloses:
method according to claim 2, and
Yang discloses:
wherein the service request message comprises the version list of the first service-based interface supported by the service invoking network element (¶0022 – Yang teaches determining if the search identifies a service producer capable of providing a service having a same major API version as the preferred API version; ¶0059 – Yang teaches discovery by SCP, the NF consumer may indicate a preferred API version in HTTP header), and
wherein the selecting the first service providing network element based on the service request message comprises:
based on the version list of the first service-based interface supported by the service invoking network element comprising one version, determining, by the service communication proxy, that a service providing network element that is in the one or more service providing network elements and that supports the one version is the first service providing network element (¶0047 – Yang teaches enabling a service consumer to request, in a service discovery query, that the NRF return a list of candidate NF service producers, of which the supported service API version(s) matches a predetermined criterion specified in the service discovery query; ¶0086 – Yang teaches NRE 502 transmits to the NE 504 the discovery response 503, which is responsive to discovery request 501 (i.e., discovery response 503 includes an array of profiles that match the preferred API version and/or otherwise satisfy the filter criteria included in request 501)); or
based on the version list of the first service-based interface supported by the service invoking network element comprising a plurality of versions, determining, by the service communication proxy, the first service providing network element according to a local configuration rule, wherein the first service providing network element supports at least one of the plurality of versions.
As to claim 6, Yang and Plunk discloses:
method according to claim 2, and
Yang discloses:
wherein the list is carried in a user-defined hypertext transfer protocol (HTTP) header of the service request message (¶0059 – Yang teaches discovery by SCP, the NF consumer may indicate a preferred API version in HTTP header), and the version preferentially selected by the service invoking network element is carried in the URI of the service request message (¶0063, Table 1 – Yang provides descriptions for some query parameters that may be included in request 501. These various query parameters are URI query parameters supported by the GET method on this resource.).
As to claim 7, Yang and Plunk discloses:
method according to claim 2, and
Yang discloses:
wherein the selecting, by the service communication proxy, a first service providing network element based on the service request message comprises:
based on the URI comprising version information indicating a version of the first service-based interface supported by the service invoking network element, determining, by the service communication proxy, the selected service providing network element from the one or more service providing network elements (¶0063, Table 1 – Yang provides descriptions for some query parameters that may be included in request 501. These various query parameters are URI query parameters supported by the GET method on this resource.); or
based on the URI not comprising version information, and the URI of the service request message indicating the service invoking network element supports all versions of the service-based interface, determining, by the service communication proxy, the selected service providing network element according to a local configuration rule.
As to claim 8, Yang and Plunk discloses:
method according to claim 4, and
Yang discloses:
wherein the local configuration rule comprises at least one of the following rules:
preferentially selecting a network element that support a higher version (¶0021 – Yang teaches the search identifies a service producer capable of providing a service having an API version higher than the preferred API version. In response to determining that the search identifies a service producer capable of providing a service having an API version higher than the preferred API version, the method returns an identifier of the service producer capable of providing a service having an API version higher than the preferred API version.) or
a lower version, preferentially selecting a network element with a higher priority, and preferentially selecting a lower-load network element.
As to claim 11, Yang discloses:
a communication method comprising:
sending, by a service invoking network element, a service request message to a service communication proxy (¶0028, ¶0037, ¶0047 – Yang teaches sending a service discovery request and service requests),
wherein the service request message is used to request to invoke a service at a service providing network element (¶0037, ¶0046-¶0048 – Yang teaches support of multiple API versions of the same service and lists of candidate NF service producers of supported service API versions and service discovery request includes filed and/or parameter specifying the preferred API version),
wherein the service request message includes version information of a service-based interface for the requested service, wherein the service-based interface is supported by the service invoking network element (¶0037 – Yang teaches an NF producer may support multiple application programming interface (API) versions of the same service. In that case, the NF producer may register all supported API versions in its NF Profile.), and
wherein the version information is identified in a uniform resource identifier (URI) of the service request message (¶0022 – Yang teaches determining if the search identifies a service producer capable of providing a service having a same major API version as the preferred API version; ¶0059 – Yang teaches discovery by SCP, the NF consumer may indicate a preferred API version in HTTP header).
wherein the service providing network element is determined by the first service communication proxy based on the service request message (¶0022 – Yang teaches determining if the search identifies a service producer capable of providing a service having a same major API version as the preferred API version; ¶0059 – Yang teaches discovery by SCP, the NF consumer may indicate a preferred API version in HTTP header),
Plunk discloses what Yang does not expressly disclose.
Plunk discloses:
receiving, by the service invoking network element, a service response message sent by the service communication proxy (Fig. 2A, Second API Response; col. 15 ll. 9-26– Plunk teaches receiving a GET/v2 (i.e., api version) response from the compute server (120) (i.e., proxy)),
wherein the service response message is from the first service providing network element (Fig. 2A, First API Response; col. 15 ll. 9-26– Plunk teaches receiving a GET/v1 (i.e., api version) response from the compute server (240) (i.e., service providing network element)),
wherein the service providing network element and the service invoking network element are able to support a same version of the service-based interface (Fig. 2A, Client Device, 110B; Server, 240, Second API Version), and
wherein the service response message comprises the version of the first service based interface supported by the service providing network element which is selected by the service communication proxy, and the version in the service response message is different from the version in the service request message (Fig. 2A, Second API Response; col. 15 ll. 9-26– Plunk teaches receiving a GET/v2 (i.e., api version) response from the compute server (120) (i.e., proxy)).
The suggestion/motivation and obviousness rejection is the same as in claim 1.
As to claim 12, Yang discloses:
method according to claim 11, and
wherein the service request message includes a version of the first service-based interface that is preferentially selected by the service invoking network element (¶0020 – Yang teaches receiving a service discovery request from a network entity, wherein the service discovery request comprises a set of query parameters, the set of query parameters including a preferred application programming interface (API) version), and
wherein the version of the first service-based interface that is preferentially selected by the service invoking network element is used by the service communication proxy to select the service providing network element (¶0038 – Yang teaches the NF producer may register all supported API versions in its NF Profile; ¶0086 – Yang teaches NRE 502 transmits to the NE 504 the discovery response 503, which is responsive to discovery request 501 (i.e., discovery response 503 includes an array of profiles that match the preferred API version and/or otherwise satisfy the filter criteria included in request 501)).
The suggestion/motivation and obviousness rejection is the same as in claim 1.
As to claim 13, Yang discloses:
method according to claim 12, and
wherein the service request message further comprises a version list of the service-based interface supported by the service invoking network element (col. 9 ll. 27-63 of Plunk),
wherein the version list comprises one or more versions, the version list is used by the service communication proxy to select the first service providing network element (col. 9 ll. 27-63 of Plunk), and
wherein the service providing network element supports at least one version in the version list (¶0037 – Yang teaches an NF producer may support multiple application programming interface (API) versions of the same service. In that case, the NF producer may register all supported API versions in its NF Profile.).
As to claim 14, Yang discloses:
method according to claim 11, and
wherein the service request message comprises a version list of the first service-based interface supported by the service invoking network element, the version list comprises one or more versions (col. 9 ll. 27-63 of Plunk),
wherein the version list is used by the service communication proxy to select a first service providing network element (col. 9 ll. 27-63 of Plunk), and
wherein the service providing network element supports one or more versions in the version list (¶0037 – Yang teaches an NF producer may support multiple application programming interface (API) versions of the same service. In that case, the NF producer may register all supported API versions in its NF Profile.).
As to claim 15, Yang discloses:
method according to claim 13, and
wherein the version list is carried in a user-defined hypertext transfer protocol (HTTP) header of the service request message, and
wherein the version preferentially selected by the service invoking network element is carried in the URI of the service request message (¶0059 – Yang teaches discovery by SCP, the NF consumer may indicate a preferred API version in HTTP header; ¶0063, Table 1 – Yang provides descriptions for some query parameters that may be included in request 501. These various query parameters are URI query parameters supported by the GET method on this resource.).
As to claim 16, Yang discloses:
method according to claim 11, and
wherein the URI comprises a version of the service-based interface supported by the service invoking network element (¶0063, Table 1 – Yang provides descriptions for some query parameters that may be included in request 501. These various query parameters are URI query parameters supported by the GET method on this resource.); or
the URI of the service request message indicates that the service invoking network element supports all versions of the first service-based interface.
As to claim 18, similar rejection as to claim 1.
As to claim 19, similar rejection as to claim 2.
As to claim 20, similar rejection as to claim 11.
As to claim 21, similar rejection as to claim 12.
As to claim 22, similar rejection as to claim 13.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TAYLOR A ELFERVIG whose telephone number is (571)270-5687. The examiner can normally be reached Monday (10:00 AM CST) - Friday (4:00 PM CST).
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, Oscar Louie can be reached at (571) 270-1684. 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.
/TAYLOR A ELFERVIG/Primary Examiner, Art Unit 2445