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
Applicant’s PgPUB: 2024/0224171
Claims:
Claims 1-8, 11-16 and 18-22 are pending.
Claims 1, 11, 18 and 20 are independent.
Claims 1, 11, 18 and 20 are amended.
Claims 9, 10 and 17 are canceled.
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, see Applicant’s response, filed 05/26/2026, with respect to the rejection(s) of claim(s) 1-8, 11-16 and 18-22 under 35 U.S.C. 103 have been fully considered and are persuasive to overcome the prior rejection. However, upon further consideration, a new ground(s) of rejection is made in view of U.S. Patent No. 10,521,195 B1 to Swope et al. (“Swope”).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 11, 18 and 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by U.S. Patent No. 10,521,195 B1 to Swope et al. (“Swope”).
As to claim 1, Swope discloses:
a communication method comprising:
receiving, by a service communication proxy, a service request message sent by a service invoking network element (Fig. 4 of Swope),
wherein the service request message is used to request to invoke a service at a service providing network element (col. 30 ll. 6-29 – Swope teaches users requests for resources (i.e., services)), and
wherein the service request message includes version information identified in a uniform resource identifier (URI) of the service request message (col. 13 ll. 3-16 – Swope teaches users requesting virtual resources; col. 25 ll. 7-30 – Swope teaches URLs with GETs to retrieve (i.e., request) services or resources);
selecting, by the service communication proxy, a 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),
determining, by the service communication proxy, a version identifier in the URI of the service request message is inconsistent with a version supported by the selected service providing network element (Abstract – Swope teaches The software application determines a first mapping between the input variable and a URL parameter of the API and a second mapping between the output variable and a response from the API. The first and second mappings are stored in in the persistent storage to define the action.);
changing, by the service communication proxy, the URI of the service request message by replacing the version identifier in the URI with the version supported by the selected service providing network element (col. 3 ll. 4-32 – Swope teaches generating a modified version of the URL that includes therein a value of the input variable according to the first mapping and invokes the function by transmitting a request to the modified version of the URL),
wherein changing the version comprises modifying the URI without modifying other content of the service request message (col. 3 ll. 4-32 – Swope teaches generating a modified version of the URL that includes therein a value of the input variable according to the first mapping and invokes the function by transmitting a request to the modified version of the URL); and
sending, by the service communication proxy, the service request message including the replaced URI to the selected service providing network element (col. 1 ll. 37-52 – Swope teaches generate and transmit, to the API, a request that includes therein the input values,).
As to claim 11, Swope discloses:
A communication method comprising:
sending, by a service invoking network element, a service request message to a service communication proxy (Fig. 4 of Swope),
wherein the service request message is used to request to invoke a service at a service providing network element (col. 30 ll. 6-29 – Swope teaches users requests for resources (i.e., services)), and
wherein the service request message includes version information identified in a uniform resource identifier (URI) of the service request message (col. 13 ll. 3-16 – Swope teaches users requesting virtual resources; col. 25 ll. 7-30 – Swope teaches URLs with GETs to retrieve (i.e., request) services or resources),
receiving, by the service invoking network element, a service response message sent by the service communication proxy (Abstract – Swope teaches The software application determines a first mapping between the input variable and a URL parameter of the API and a second mapping between the output variable and a response from the API.),
wherein the service response message is from the service providing network element (Fig. 4, col. 1 ll. 37-52 – Swope teaches Namely, an action may be configured to receive input values for a function of the API, generate and transmit, to the API, a request that includes therein the input values, receive a response from the API, identify output values of the function in the response, and expose the output values to other actions via output variables),
wherein the service response message comprises a version of the service-based interface supported by the service providing network element that is different from a version identifier in the URI of the service request message (Abstract – Swope teaches The software application determines a first mapping between the input variable and a URL parameter of the API and a second mapping between the output variable and a response from the API. The first and second mappings are stored in in the persistent storage to define the action.).
As to claim 18, similar rejection as to claim 1.
As to claim 20, similar rejection as to claim 11.
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 2, 3, 5-7, 12, 16, 19 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 10,521,195 B1 to Swope et al. (“Swope”) in view of International Application No. WO 2021/083926 A1 to Yang et al. (“Yang”).
As to claim 2, Swope discloses:
method according to claim 1, and
Yang discloses what Swope does not expressly discloses.
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.).
Swope and Yang 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 version transformation as discussed in Yang with the communication method as discussed in Swope by adding the functionality of Yang to the system/method of Swope in order to request a service discovery request based on API versioning (Yang, ¶0020).
As to claim 3, Swope and Yang 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)).
The suggestion/motivation and obviousness rejection is the same as in claim 2.
As to claim 5, Swope and Yang 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.
The suggestion/motivation and obviousness rejection is the same as in claim 2.
As to claim 6, Swope and Yang 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.).
The suggestion/motivation and obviousness rejection is the same as in claim 2.
As to claim 7, Swope and Yang 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 12, Swope discloses:
method according to claim 11, and
Yang discloses what Swope does not expressly disclose.
Yang discloses:
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 2.
As to claim 16, Swope discloses:
method according to claim 11, and
Yang discloses what Swope does not expressly disclose.
Yang discloses:
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 19, similar rejection as to claim 2.
As to claim 21, similar rejection as to claim 12.
Claims 4, 8, 13-15 and 22 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent No. 10,521,195 B1 to Swope et al. (“Swope”) in view of International Application No. WO 2021/083926 A1 to Yang et al. (“Yang”) in further view of U.S. Patent No. 10,769,000 B1 to Plunk et al. (“Plunk”).
As to claim 4, Swope and Yang discloses:
method according to claim 3, and
Yang discloses:
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)).
Plunk discloses what Swope and Yang do not expressly discloses.
Plunk 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),
Swope, 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 API version transformation as discussed in Yang with the communication method as discussed in Swope by adding the functionality of Yang to the system/method of Swope in order to transparently enable compatibility between multiple versions of an application programming interface (API). (Plunk, col. 1 ll. 9-14).
As to claim 8, Swope, 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 13, Swope and Yang discloses:
method according to claim 12, and
Yang discloses:
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.).
Plunk discloses what Swope and Yang do not expressly discloses.
Plunk discloses:
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),
The suggestion/motivation and obviousness rejection is the same as in claim 4.
As to claim 14, Swope discloses:
method according to claim 11, and
Yang discloses what Swope do not expressly discloses.
Yang discloses:
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.).
Plunk discloses what Swope and Yang do not expressly discloses.
Plunk discloses:
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),
The suggestion/motivation and obviousness rejection is the same as in claim 4.
As to claim 15, Swope, Yang and Plunk discloses:
method according to claim 13, and
Plunk discloses:
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.).
The suggestion/motivation and obviousness rejection is the same as in claim 4.
As to claim 22, similar rejection as to claim 13.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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
Prosecution Insights