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 .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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-7, 9-12, 16, 18, 19, 21, 22, 24-26 and 31-34 are rejected under 35 U.S.C. 103 as being unpatentable over US 20200162619 A1 (Zevallos) in view of ERICSSON: "pCR to TR 32.291 Update of Service Operations", 3GPP TSG SA WG5 (Telecom Management) Meeting#120; Belgrade (Serbia); S5-185321, 20-24 August 2018 (hereinafter Ericsson).
In re claims 1 and 31, Zevallos discloses a charging function entity, comprising: a processor (Fig. 8:800); and a memory (Fig. 8:802) coupled to the processor, said memory containing instructions executable by said processor ([0004], “According to an aspect of the present invention, there is provided an apparatus in a communication system, comprising: at least one processor and at least one memory including a computer program code, wherein the at least one memory and the computer program code are configured, with the at least one processor, to cause the apparatus to perform operations”) and a method performed by a charging function entity, comprising: sending a charging notify request ([0005], “a method in an apparatus of a communication system, comprising: creating a bearer for user terminal communication; transmitting a credit control request message to Online Charging System”) comprising at least one information element to a network function entity, wherein the at least one information element is used for determining which quota and/or usage reporting is required to be updated to the charging function entity ([0026], “Credit Control Request CCR is sent from the PGW (acting as a Credit Control Client) to the OCS (acting as a Credit Control Server). There are three types of CCR messages: [0027] “Initial” (or CCR-I, or CCR-Init) which is sent from the PGW to the OCS to create the DCCA session. This message marks the start of a credit control session (DCCA session). [0028] “Update” (or CCR-U, or CCR-Update) which is sent from the PGW to the OCS several times during the DCCA session. It is used to request quota (such as to request X Mbytes of Skype traffic), to report the consumed quota, or to inform changes on the network, like subscriber's location changing from LTE to 3G)”); and receiving a charging notify response from the network function entity ([0005], “receiving a credit control answer message as a reply to the request message”. [0030], “Credit Control Answer CCA is sent from the OCS to the PGW. There are three types of CCA messages: [0031] “Initial” (or CCA-I, or CCA-Init. This is the reply to the CCR-I). Sent from OCS to PGW to authorize the DCCA session to be created… [0032] “Update” (or CCA-U, or CCA-Update. This is the reply to the CCR-U). Sent from OCS to PGW. It is used to grant quota (e.g. 1 MB of Skype traffic) or to deny further traffic, or to command the PGW to take certain actions (for example to redirect the subscriber's traffic to an operator's webpage where the subscriber can purchase more credit)”), wherein when validation of a part of the at least one information element is failed, the charging notify response comprises a first status code and error information related to the part of the at least one information element ([0035], “The OCS sends a reply CCA-U 208 to PGW with an error code”).
Zevallos does not explicitly disclose wherein when validation of a part of the at least one information element is failed, the charging notify response comprises a first status code and error information related to the part of the at least one information element.
Ericsson discloses wherein when validation of a part of the at least one information element is failed, the charging notify response comprises a first status code and error information related to the part of the at least one information element (Page 2, Figure 4.1A.2.1: step 2b, lines 8-10, “On failure or redirection, one of the HTTP status codes listed in Table xxxx shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the “cause” attribute set to one of the application errors listed in Table…” (response includes a HTTP status code from the Table and an error code with cause)). Examiner’s Note: Table xxxx refers to Table 6.1.3.2.3.1-3 of TR 32.291 update of service operations (page 4, section 4, “The following changes are proposed to be incorporated into TR 32.291).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Zevallos with Ericsson to provide a method of charging client server applications from a mobile terminal and analyzing various messages related to the service requests and updates online or offline, processing and notifying the results to the charging function entity by the network function entity. Existing charging is primarily based on volume of data traffic. The advantage of doing so is that it makes service pricing understandable and transparent to an end user, and better reflects the perceived value of the service to the end user such as prepaid customers.
In re claim 2, the combination discloses the method according to claim 1, wherein Zevallos discloses wherein the at least one information element comprises at least one of: service identifier, rating group, or quota management indicator ([0026], “It is used to request quota (such as to request X Mbytes of Skype traffic), to report the consumed quota, or to inform changes on the network, like subscriber's location changing from LTE to 3G)”).
In re claim 3, the combination discloses the method according to claim 1, wherein Ericsson discloses wherein the charging notify request comprises a type of notification indicating re-authorization, and wherein the error information related to the at least one information element comprises re-authorization is failed (section 4.1.4.3, page 2, “The following procedures using the Nchf_Convergcd_Charging_Update Service Operation are supported: receiving re-authorization notification from CHF”. Figure 4.1A.2.1: step 2b, page 2, lines 8-10, “On failure or redirection, one of the HTTP status codes listed in Table xxxx shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the “cause” attribute set to one of the application errors listed in Table…” (notifying that the supported IE of reauthorization has failed through error codes)).
In re claims 4 and 32, the combination discloses the method according to claim 1 and the charging function entity according to claim 31, wherein Ericsson discloses wherein the first status code comprises a status code indicating that the charging notify request is at least partly acknowledged (Figure 4.1.4.3.1: Step 2a, section 4.1.4.3, “At successful operation, "200 OK" response is returned. The CHF includes the granted service unit in the “200 OK” response” (request is acknowledged)).
In re claim 5, the combination discloses the method according to claim 1, wherein Ericsson discloses wherein the error information related to the part of the at least one information element comprises a failure reason (Page 4, lines 5-7, “On failure, one of the HTTP status codes listed in Table xxxx shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the “cause” attribute set to one of the application errors listed in Table…”).
In re claim 6, the combination discloses the method according to claim 1, wherein Ericsson discloses wherein when validation of each of the at least one information element is failed, the charging notify response comprises a second status code and error information related to the at least one information element (Page 2, Figure 4.1.4.2.1: step 2b, lines 8-10, “On failure or redirection, one of the HTTP status codes listed in Table xxxx shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the “cause” attribute set to one of the application errors listed in Table…”).
In re claim 7, the combination discloses the method according to claim 6, wherein Ericsson discloses wherein the second status code comprises a HTTP 404 Not Found or 400 Bad Request status code (Page 2, Figure 4.1A.2.1: step 2b, line 8, “On failure or redirection, one of the HTTP status codes listed in Table xxxx shall be returned”).
In re claim 9, the combination discloses the method according to claim 1, wherein Ericson discloses the method further comprising: sending a first message comprising information for indicating at least one supported feature of the charging function entity to the network function entity (Page 1, section 4.1.4.2, lines 1-2, “The Nchf_ConvergedCharging_Create service operation provides means for NF {CTF) to request quota for service, delivery or initial report of service usage”); and receiving a second message comprising information for indicating at least one supported feature of the network function entity from the network function entity (Page 2, section 4.1.4.3, lines 1-6, Supporting charging events that may affect the ratings of the charging service for one rating group such as cost, validity, quota etc. such as a voice call of a group of subscribers)).
In re claim 10, the combination discloses the method according claim 9, wherein Ericsson discloses wherein the at least one supported feature comprises supporting for notification response in a network function consumer (Page 2, section 4.1.4.3, lines 1-6, “the granted service unit for one rating group are spent is supported” (notification response supports consumer related functions such as cost, validity of granted services such as call service for one rating group)).
In re claim 11, the combination discloses the method according to claim 10, wherein Ericsson discloses wherein the supporting for notification response in the network function consumer indicates that the notification response supports the first status code, the second status code and the error information (Figure 4.1A.2.1: step 2b, page 2, lines 8-10, “On failure or redirection, one of the HTTP status codes listed in Table xxxx shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the “cause” attribute set to one of the application errors listed in Table…”).
In re claim 12, the combination discloses the method according to claim 9, wherein Ericsson discloses wherein the first message comprises the charging notify request and the second message comprises the charging notify response (Page 1, section 4.1.4.2, lines 1-2, “The Nchf_ConvcrgedCharging_Create service operation provides means for NF (CTF) to request quotas for service delivery or initial report of service usage”. Figure 4.1 .4.4. 1: steps 2a, 2b are the second message comprising charging notify response, section 4.1.4.4, step 2a, “At successful operation, “204 No Content response is retuned”).
In re claims 16 and 33, Zevallos discloses a network function entity ([0094], “In some embodiments, the apparatus may be another network element of a communication system”), comprising: a processor (Fig. 8:800); and a memory (Fig. 8:802) coupled to the processor, said memory containing instructions executable by said processor ([0102], “As a further example, as used in this application, the term ‘circuitry’ would also cover an implementation of merely a processor (or multiple processors) or a portion of a processor and its (or their) accompanying software and/or firmware. The term ‘circuitry’ would also cover, for example and if applicable to the particular element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or another network device”) and a method performed by a network function entity ([0023], “Offline charging utilizes Charging Collection Function (CCF) and it is managed by Offline Charging System 112 OFCS. One module related to charging is Charging Data Function CDF, which may be implemented in SGW, PGW or in OCS. The mechanism used may depend on the service. Offline changing and online charging typically operate independently. Both OCS 110 and Offline Charging System 112 are connected to a Billing Domain (not shown) which is responsible for actual billing and statistics. In offline charging mechanism, charging information for traffic or using network resources is collected concurrently when resources are used. At the end of the usage, Charging Data Record CDR files are generated by the network, and transmitted to the Billing Domain”), comprising: receiving a charging notify request comprising at least one information element from a charging function entity ([0005], “a method in an apparatus of a communication system, comprising: creating a bearer for user terminal communication; transmitting a credit control request message to Online Charging System”), wherein the at least one information element is used for determining which quota and/or usage reporting is required to be updated to the charging function entity ([0026], “Credit Control Request CCR is sent from the PGW (acting as a Credit Control Client) to the OCS (acting as a Credit Control Server). There are three types of CCR messages: [0027] “Initial” (or CCR-I, or CCR-Init) which is sent from the PGW to the OCS to create the DCCA session. This message marks the start of a credit control session (DCCA session). [0028] “Update” (or CCR-U, or CCR-Update) which is sent from the PGW to the OCS several times during the DCCA session. It is used to request quota (such as to request X Mbytes of Skype traffic), to report the consumed quota, or to inform changes on the network, like subscriber's location changing from LTE to 3G)”); and validating the at least one information element; and sending a charging notify response to the charging function entity ([0005], “receiving a credit control answer message as a reply to the request message”. [0030], “Credit Control Answer CCA is sent from the OCS to the PGW. There are three types of CCA messages: [0031] “Initial” (or CCA-I, or CCA-Init. This is the reply to the CCR-I). Sent from OCS to PGW to authorize the DCCA session to be created… [0032] “Update” (or CCA-U, or CCA-Update. This is the reply to the CCR-U). Sent from OCS to PGW. It is used to grant quota (e.g. 1 MB of Skype traffic) or to deny further traffic, or to command the PGW to take certain actions (for example to redirect the subscriber's traffic to an operator's webpage where the subscriber can purchase more credit)”, wherein when validation of a part of the at least one information element is failed, the charging notify response comprises a first status code and error information related to the part of the at least one information element ([0035], “The OCS sends a reply CCA-U 208 to PGW with an error code”).
Zevallos does not explicitly disclose validating the at least one information element, wherein when validation of a part of the at least one information element is failed, the charging notify response comprises a first status code and error information related to the part of the at least one information element.
Ericsson discloses validating the at least one information element (Page 2, second change, section 4.1.4.3, lines 1-6, “The following procedures using the Nchf_Convergcd_Charging_Update Service Operation are supported: expiry of granted service units validity time…receiving re-authorization notification from CHF”), wherein when validation of a part of the at least one information element is failed, the charging notify response comprises a first status code and error information related to the part of the at least one information element (Page 2, Figure 4.1A.2.1: step 2b, lines 8-10, “On failure or redirection, one of the HTTP status codes listed in Table xxxx shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the “cause” attribute set to one of the application errors listed in Table…” (response includes a HTTP status code from the Table and an error code with cause)). Examiner’s Note: Table xxxx refers to Table 6.1.3.2.3.1-3 of TR 32.291 update of service operations (page 4, section 4, “The following changes are proposed to be incorporated into TR 32.291).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Zevallos with Ericsson to provide a method of charging client server applications from a mobile terminal and analyzing various messages related to the service requests and updates offline and online, processing and notifying the results to the charging function entity by the network function entity. Existing charging is primarily based on volume of data traffic. The advantage of doing so is that it makes service pricing understandable and transparent to an end user, and better reflects the perceived value of the service to the end user such as prepaid customers.
In re claim 18, the combination discloses the method according to claim 16, wherein Ericsson discloses wherein the charging notify request comprises a type of notification indicating re-authorization, and wherein the error information related to the at least one information element comprises re-authorization is failed (section 4.1.4.3, page 2, “The following procedures using the Nchf_Convergcd_Charging_Update Service Operation are supported: receiving re-authorization notification from CHF”. Figure 4.1A.2.1: step 2b, page 2, lines 8-10, “On failure or redirection, one of the HTTP status codes listed in Table xxxx shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the “cause” attribute set to one of the application errors listed in Table…”).
In re claims 19 and 34, the combination discloses the method according to claim 16 and the network function entity according to claim 33, wherein Ericsson discloses wherein the first status code comprises a status code indicating that the charging notify request is at least partly acknowledged (Figure 4.1.4.3.1: Step 2a, section 4.1.4.3, “At successful operation, "200 OK" response is returned. The CHF includes the granted service unit in the “200 OK” response” (request is acknowledged)).
In re claim 21, the combination discloses the method according to claim 16, wherein Ericsson discloses wherein when validation of each of the at least one information element is failed, the charging notify response comprises a second status code and error information related to the at least one information element (Page 2, Figure 4.1.4.2.1: step 2b, lines 8-10, “On failure or redirection, one of the HTTP status codes listed in Table xxxx shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the “cause” attribute set to one of the application errors listed in Table…”).
In re claim 22, the combination discloses the method according to claim 21, wherein Ericsson discloses wherein the second status code comprises a HTTP 404 Not Found or 400 Bad Request status code (Page 2, Figure 4.1A.2.1: step 2b, line 8, “On failure or redirection, one of the HTTP status codes listed in Table xxxx shall be returned”).
In re claim 24, the combination discloses the method according to claim 16, wherein Ericsson discloses the method further comprising: receiving a first message comprising information for indicating at least one supported feature of the charging function entity from the charging function entity (Page 1, section 4.1.4.2, lines 1-2, “The Nchf_ConvergedCharging_Create service operation provides means for NF {CTF) to request quota for service, delivery or initial report of service usage”); and sending a second message comprising information for indicating at least one supported feature of the network function entity to the charging function entity (Page 2, section 4.1.4.3, lines 1-6, Supporting charging events that may affect the ratings of the charging service for one rating group such as cost, validity, quota etc. such as a voice call of a group of subscribers); wherein the first message comprises the charging notify request and the second message comprises the charging notify response (Page 1, section 4.1.4.2, lines 1-2, “The Nchf_ConvcrgedCharging_Create service operation provides means for NF (CTF) to request quotas for service delivery or initial report of service usage”. Figure 4.1 .4.4. 1: steps 2a, 2b are the second message comprising charging notify response, section 4.1.4.4, step 2a, “At successful operation, “204 No Content response is retuned”).
In re claim 25, the combination discloses the method according claim 24, wherein Ericsson discloses wherein the at least one supported feature comprises supporting for notification response in a network function consumer. (Page 2, section 4.1.4.3, lines 1-6, “the granted service unit for one rating group are spent is supported” (notification response supports consumer related functions such as cost, validity of granted services such as call service for one rating group)).
In re claim 26, the combination discloses the method according to claim 25, wherein Ericsson discloses wherein the supporting for notification response in the network function consumer indicates that the notification response supports the first status code, the second status code and the error information. (Figure 4.1A.2.1: step 2b, page 2, lines 8-10, “On failure or redirection, one of the HTTP status codes listed in Table xxxx shall be returned. For a 4xx/5xx response, the message body shall contain a ProblemDetails structure with the “cause” attribute set to one of the application errors listed in Table…”).
Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SWATI JAIN whose telephone number is (571)270-0699. The examiner can normally be reached Mon - Fri (830 am - 530 pm).
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, Pan Yuwen can be reached on 571-272-7855. 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.
/SWATI JAIN/Examiner, Art Unit 2649 /YUWEN PAN/Supervisory Patent Examiner, Art Unit 2649