DETAILED ACTION
This Office Action is in response to claims filed on 07/13/2026.
Claims 1-20 are pending.
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 .
Response to Arguments
Applicant’s arguments with respect to claims 1, 8, 9, and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claims 1-2, 4, 6-10, 12-16, and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sun et al. Patent No. US 8,001,422 B1 (hereinafter Sun) in view of Gai et al. Patent No. US 10,607,228 B1 (hereinafter Gai) in view of Burris et al. Patent No. US 8,965,827 B2 (hereinafter Burris).
With regard to claim 1, Sun teaches a system (Col. 2, Systems and methods in accordance with various embodiments of the present disclosure may overcome one or more the aforementioned and other deficiencies experienced in conventional approaches to testing developing and managing services and other such functionalities in an electronic environment), comprising:
a non-transitory memory (Col. 14, Such a system may also include one or more storage devices, such as disk drives, optical storage devices, and solid-state storage devices such as random-access memory ("RAM") or read-only memory ("ROM"), as well as removable media devices, memory cards, flash cards, etc.); and
one or more hardware processors coupled with the non-transitory memory and configured to read instructions from the non-transitory memory to cause the system to perform operations (Col. 4, Each server typically will include an operating system that provides executable program instructions for the general administration and operation of that server, and typically will include a computer-readable medium storing instructions that, when executed by a processor of the server, allow the server to perform its intended functions; Col. 13, As discussed above, the various embodiments can be implemented in a wide variety of operating environments, which in some cases can include one or more … processing devices) comprising:
receiving, at a unified strategy evaluation pool, a request associated with a first service (Col. 7, FIG. 4 illustrates components of a system 400 that can be used to provide shadow service functionality in accordance with one embodiment. In this example, two different production groups 404, 406, (Examiner notes: Service pool) or groups offering the production service, are able to receive requests from various customers 402, process those requests, and send the appropriate responses back to the customers. The production services for both groups also are able to send copies of the requests … to a shadow group 410 that is operating the shadow service 412 (Examiner notes: Evaluation pool)) of a plurality of different types of services associated with a decision service pool, wherein the request comprises a context identifier associated with the first service (Col. 6, In other embodiments, the production service might send a new request to the shadow service that includes at least a portion of the information of the initial request, and may include additional information in a header or body of the request that is useful for testing purposes, such as an identifier of the instance of the service generating the new request.), and wherein the unified strategy evaluation pool evaluates the request (Col. 8, the shadow interceptor can call a comparison element such as a comparison engine 418. The comparison engine can be part of the interceptor, part of the shadow service, or external to both. The interceptor also can call a reporting element 420, which can be registered with the comparison engine.) independently from the decision service pool (FIG. 4, Production Group A and B 404, 406 independent from Shadow Group 410; Col. 7, FIG. 4 illustrates components of a system that can be used to provide shadow service functionality in accordance with one embodiment … The production services for both groups also are able to send copies of the requests received from the customers, as well as copies of the responses sent back to those customers, to a shadow group 410 that is operating the shadow service 412; As used herein, the term "group" can refer to any appropriate association, such as a farm of servers, a set of modules owned by a specific group or division within an organization, etc.);
retrieving, by the unified strategy evaluation pool from a database that stores a plurality of sets of rules each associated with a respective service of the plurality of different types of services, a first set of rules of the plurality of sets of rules associated with the first service;
However, Sun does not explicitly teach strategy evaluation, generation, and outputting of a strategy associated with a request for a service.
Gai teaches evaluating, at the unified strategy evaluation pool, a strategy associated with the first service for processing the request (Col. 2-Col. 3, FIG. 1 is a block diagram illustrating an operating environment for a dynamic rule strategy fraud detection system 60 in accordance with an embodiment of the invention. Col. 1, The displayed embodiment has particular applicability to payment card transactions. However, it should be understood that the operating environment can be configured to facilitate fraud detection and prevention for any type of transaction. Card transactions using cards 30a, 30b are processed by a computing device 20 and transmitted over a network 10. Card processing systems 50 are connected over the network 10 to process the card transactions (Examiner notes: request processing).) based on data associated with the context identifier and data associated with the strategy (Col. 4, During execution, the dynamic rule strategy pulls recent, transactional data and performs fraud rule development. Col. 5, The automated trigger identification engine 210 pulls all approved transactions and analyzes them to identify), wherein the strategy enables the request to be evaluated based on the retrieved first set of rules (Col. 4, The dynamic rule strategy provides an automatic framework to develop fraud rules.);
generating, at the unified strategy evaluation pool, an evaluation result of the strategy based on the evaluating (Col. 6, Once the dynamic rule strategy is implemented in the server, the fraud rules generated can be implemented by business and incorporated in production systems, and fraud rule implementation can be accomplished … The model output database 250 stores outputs of the dynamic rule strategy fraud detection system 200. The outputs include a score and rules associated with the score. The score represents the probability (between 0.0 and 1.0) that a POS transaction is fraudulent); and
outputting, at the unified strategy evaluation pool, the evaluation result of the strategy for a determination of whether to send the strategy from the unified strategy evaluation pool to the decision service pool (Col. 8, If a rule or several rules are generated in block 436, it is sent to the control engine for validation in block 440. If the validation fails with unreasonable results, the rule is sent to block 480. If the validation occurs with reasonable results, the rule is then sent for business review in block 442 and fraud rule implementation testing in block 447 … Once implementation test is successful, business may implement select rules in the production system. Finally, the rule is implemented in the production system in block 448).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Gai with the teachings of Sun in order to provide a system that teaches evaluation, generation, and implementation of a strategy in association with a particular request for a service. The motivation for applying Gai teaching with Sun teaching is to provide a system that allows for identification of service patterns that enables a system to ingest service data and dynamically generate rule strategies in alignment with a particular interest, such as combatting fraud (Gai, Col. 4). Sun and Gai are analogous art directed towards service computing arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Gai with Sun to teach the claimed invention in order to provide strategy evaluation in association with a request for a service.
Sun reasonably teaches receiving and processing request directed towards a number of different services (Sun, Col. 5). Gai reasonably teaches a data warehouse storing information related to dynamic rule strategies for a fraud detection service (Gai, Col. 4). However, the combination does not explicitly teach a plurality of different types of services associated with a decision service pool and a database that stores a plurality of sets of rules each associated with a respective service of the plurality of different types of services, a first set of rules of the plurality of sets of rules associated with the first service.
Burris teaches receiving, at a unified strategy evaluation pool, a request associated with a first service of a plurality of different types of services associated with a decision service pool (Col. 11-Col. 12, An organization may perform distinct functions or services, for example underwriting, finance, billing, or production, and one or more respective applications may be used in performing a given such function. Each function may be considered as encompassing an environment, and as used herein the term refers to the application and computer and communication systems dedicated to the performance of such function within an organization, and/or the operation designation, and/or classification thereof; Col. 22, At step 310, an application, such as application 104, 106, or 108 sends a request to execute a rule to rules execution platform 102 … The request to execute the rule includes an identification of the rule along with any input or identification of the input required by the rule.) …;
retrieving, by the unified strategy evaluation pool from a database that stores a plurality of sets of rules (Col. 6, System 100 further comprises at least one shared rules repository 128 that includes a database 130 for storing rules, as described in more detail below. Desing tool 132 is configured to facilitate the creation of rules, as explained below, and is operatively connect to repository to store such rules once created) each associated with a respective service of the plurality of different types of services (Col. 12, Referring first to rules repository 128, database 130 may be configured to store rules according to the predetermined hierarchy … the business rule domain may refer to functional division within the life insurance organization, e.g., administrator, underwriter, customer representative, actuary, finance, accounting, human resources, or legal.), a first set of rules of the plurality of sets of rules associated with the first service (Col. 7, When one of the applications 104, 106, or 108 thereafter requires he rule to be executed … the application requests rules execution platform 102 to execute the rule and return the result to the requesting application … In response, rules execution platform 102 selects the translated rule it associated with the requested rule according to the platform protocol; Col. 22, Based on the identifier, rules execution platform 102 retrieves the metadata associated with the stored translated rule at step 320 and identifies the rules engine associated with the rule at step 330.);
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Burris with the teachings of Sun and Gai in order to provide a system that teaches storage of a plurality of distinct rulesets associated with distinct services. The motivation for applying Burris teaching with Sun and Gai teaching is to provide a system that allows for a central platform to serve requests with respect to a plurality of distinct services, such that enables the benefit of service strategy of Sun and Gai are realized across the wide business domain functions range of Burris. That is, one of ordinary skill in the art would have recognized that applying Burris’s known technique of multi-service rule processing platform to the strategy evaluation system of Sun and Gai predictably extends the combination’s system to multi-service platforms. Sun, Gai, and Burris are analogous art directed towards rule-based knowledge engineering and service computing arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Burris with Sun and Gai to teach the claimed invention in order to provide multi-service ruleset database.
With regard to claim 2, Sun teaches wherein the request is duplicated from a parent request received at the decision service pool (Col. 5, In addition sending the response back to the user, application, or other source of the request 314, the production service can forward a copy of the initial request (Examiner notes: Parent request) and a copy of the response, generated by the production service for the initial request, to the shadow service 312), the request further comprising a request identifier and a parent request identifier (Col. 6, the production service might send a new request to the shadow service that includes at least a portion of the information of the initial request, and may include additional information in a header or body of the request that is useful for testing purposes, such as an identifier of the instance of the service generating the new request.).
With regard to claim 4, Gai teaches wherein the operations comprise:
in response to the evaluating, retrieving additional data associated with the strategy (Col. 7, FIG. 4 is a flow chart illustrating operation of the dynamic rule strategy fraud detection system by component in accordance with an embodiment of the invention. A data mart 401 includes historical transaction data 402 and data warehouse data 404. The data from the data mart 401 is pulled by the dynamic rule strategy system 400 for analysis at 408. With respect to data collection, all daily approved transactions are pulled from data warehouse 404 for further segmentation to perform fraud trend reporting at block 410 and trigger event detection at block 420.); and
further re-evaluating the strategy based on the additional data associated with the strategy (Col. 7, The result of trigger event detection 420 including high fraud concentration segments and the user-defined segments 405 is determined to help fraud concentration be identified at a more granular level to prepare for rule induction (decision tree development). Given the nature of fraud prevention, the list of segments and associated segmentation definitions are expected to be dynamic and evolving.).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Gai with the teachings of Sun in order to provide a system that teaches strategy modification in view of selected data segments. The motivation for applying Gai teaching with Sun teaching is to provide a system that allows for strategy evaluation to be repeated within a specified time period using newly collected data in order to enhance rule development efficiency that automates the short-term combat with fraudsters (Gai, Col. 1). Sun and Gai are analogous art directed towards service computing arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Gai with Sun to teach the claimed invention in order to provide dynamic re-evaluation of a strategy in association with newly collected additional data.
With regard to claim 6, Sun teaches wherein the operations further comprise:
utilizing a part of traffic for processing the request, wherein the part of traffic is divided from a main traffic for processing the parent request (Col. 6, In some embodiments, the production service might have a parameter stored locally that causes the production service to only forward a percentage or other number of production requests to the shadow service (Examiner notes: Such that a volume of traffic directed for a production service is diverted to the shadow service).).
With regard to claim 7, Sun teaches wherein the data associated with the context identifier comprises metadata associated with the first service (Col. 6, the production service might send a new request to the shadow service that includes at least of portion of the information of the initial request, and may include additional information in a header or body of the request (Examiner notes: Service metadata) that is useful for testing purposes, such as an identifier of the instance of the service).
With regard to claim 8, Sun teaches a method (Col. 2, Systems and methods in accordance with various embodiments of the present disclosure may overcome one or more the aforementioned and other deficiencies experienced in conventional approaches to testing developing and managing services and other such functionalities in an electronic environment)
Claim 8 is a method claim having similar limitations to claim 1. Thus, claim 8 is rejected for the same rationale as applied to claim 1.
With regard to claim 9, Sun teaches receiving, from the decision service pool, a second request associated with a second service (FIG. 4, Production Group B 406; Col. 7, FIG. 4 illustrates components of a system 400 that can be used to provide shadow service functionality in accordance with one embodiment. In this example, two different production groups 404, 406, or groups offering the production service, are able to receive requests from various customers 402, process those requests, and send the appropriate responses back to the customers.) of the plurality of different types of services, wherein the second request comprises a second context identifier associated with the second service (Col. 6, In other embodiments, the production service might send a new request to the shadow service that includes at least a portion of the information of the initial request, and may include additional information in a header or body of the request that is useful for testing purposes, such as an identifier of the instance of the service generating the new request.);
However, Sun does not explicitly teach strategy evaluation and implementation of a second strategy associated with a request for a service.
Gai teaches evaluating, based on a second set of rules of the plurality of sets of rules that are associated with the second service, a second strategy associated with the second service for processing the second request (Col. 2-Col. 3, FIG. 1 is a block diagram illustrating an operating environment for a dynamic rule strategy fraud detection system 60 in accordance with an embodiment of the invention. Col. 1, The displayed embodiment has particular applicability to payment card transactions. However, it should be understood that the operating environment can be configured to facilitate fraud detection and prevention for any type of transaction. Card transactions using cards 30a, 30b are processed by a computing device 20 and transmitted over a network 10. Card processing systems 50 are connected over the network 10 to process the card transactions (Examiner notes: request processing).) based on third data associated with the second context identifier and fourth data associated with the second strategy (Col. 4, During execution, the dynamic rule strategy pulls recent, transactional data and performs fraud rule development. Col. 5, The automated trigger identification engine 210 pulls all approved transactions and analyzes them to identify) wherein the second set of rules comprises one or more second criteria for evaluating the second strategy (Col. 8, if a rule or several rules are generated in block 436, it is sent to the control engine for validation in block 440 … Business computing systems may take all the rules from the ARIE in 442, look at results of out of time validation and review and select rules. Selection may be based on combination of individual rule performance (False Positive Rate, rule benefit in dollar amount) and operation capacity (# of expected out sorts).), wherein the evaluating the second strategy and the evaluating the first strategy are performed asynchronously (Col. 4, The automated trigger identification engine 210 achieves identification through segmentation. Segmentation is intended to capture potential concentrations of ongoing fraud attacks at a relatively granular level. There are multiple ways to segment the portfolio of transactions. … For each dynamic rule strategy execution, a period of transactional data is used in automated trigger identification … The metrics of the target period may be used for high risk segment detection based on trigger criteria, and the metrics of a historical transaction window will be used for comparison with the target period to monitor fraud trend changes over time.);
providing, at the unified strategy evaluation result of the second strategy based on the evaluating the second strategy (Col. 8, If a rule or several rules are generated in block 436, it is sent to the control engine for validation in block 440. If the validation fails with unreasonable results, the rule is sent to block 480. If the validation occurs with reasonable results, the rule is then sent for business review in block 442 and fraud rule implementation testing in block 447); and
sending, to the decision service pool, the second strategy based on the evaluation result of the second strategy (Col. 8, Once implementation test is successful, business may implement select rules in the production system. Finally, the rule is implemented in the production system in block 448).
Rationale to claim 8 applied here.
Examiner notes: It would have been obvious for one of ordinary skill in the art to recognize that the method of claim 8, once performed for a first request associated with a first service to evaluate a first strategy, would be performed again for a second request for a second service (See at least Sun, FIG. 4) repeated using the method set forth by Gai to implement a second strategy (See at least Gai, FIG. 3, S341 repeats to S301; Col. 7, lines 35-47) with similar motivation and which would have yielded predictable results.
However, Sun and Gai do not explicitly teach that the second service is of a different service types, a second set of rules of the plurality of sets of rules, and wherein the second set of rules comprises one or more second criteria.
Burris teaches the plurality of different types of services (Col. 11-Col. 12, An organization may perform distinct functions or services, for example underwriting, finance, billing, or production, and one or more respective applications may be used in performing a given such function. Each function may be considered as encompassing an environment, and as used herein the term refers to the application and computer and communication systems dedicated to the performance of such function within an organization, and/or the operation designation, and/or classification thereof) …
a second set of rules of the plurality of sets of rules (Col. 22, At step 310, an application, such as application 104, 106, or 108 sends a request to execute a rule to rules execution platform 102 … The request to execute the rule includes an identification of the rule along with any input or identification of the input required by the rule.)
wherein the second set of rules comprises one or more second criteria (Col. 3, As should be understood, different rules engines may have different functions and/or organizations that may make the respective engines more suitable or efficient for use with respective different types of rules. Thus, for example, a given rules engine might be better suited for “if/then” type rules, whereas another rules engine might be more suitable for mathematical-based rules … The association between the rule and the rule engine occurs within the system according to a predetermined criteria, without the application user or rule-creator needing to know which rule engine is or will be used.)
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Burris with the teachings of Sun and Gai in order to provide a method that teaches a plurality of distinct rulesets associated with distinct services comprising distinct criteria. The motivation for applying Burris teaching with Sun and Gai teaching is to provide a method that allows for applying Burris’s known technique of multi-service rule processing platform to the rule strategy evaluation system of Sun and Gai predictably extends the combination’s method to multi-service platforms. Sun, Gai, and Burris are analogous art directed towards rule-based knowledge engineering and service computing arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Burris with Sun and Gai to teach the claimed invention in order to provide multi-service ruleset evaluation.
With regard to claim 10, it is a method of claim having similar limitations to claim 2. Thus, claim 10 is rejected for the same rationale as applied to claim 2.
With regard to claim 12, it is a method of claim having similar limitations to claim 4. Thus, claim 12 is rejected for the same rationale as applied to claim 4.
With regard to claim 13, it is a method of claim having similar limitations to claim 6. Thus, claim 13 is rejected for the same rationale as applied to claim 6.
With regard to claim 14, it is a method of claim having similar limitations to claim 7. Thus, claim 14 is rejected for the same rationale as applied to claim 7.
With regard to claim 15, Sun teaches a non-transitory machine-readable medium having stored thereon machine-readable instructions executable to cause a machine to perform operations (Col. 4, Each server typically will include an operating system that provides executable program instructions for the general administration and operation of that server, and typically will include a computer-readable medium storing instructions that, when executed by a processor of the server, allow the server to perform its intended functions)
Claim 15 is a non-transitory machine-readable medium claim having similar limitations to claim 1. Thus, claim 15 is rejected for the same rationale as applied to claim 1.
With regard to claim 16, it is a non-transitory machine-readable medium claim having similar limitations to claim 2. Thus, claim 16 is rejected for the same rationale as applied to claim 2.
With regard to claim 18, it is a non-transitory machine-readable medium claim having similar limitations to claim 4. Thus, claim 18 is rejected for the same rationale as applied to claim 4.
With regard to claim 19, it is a non-transitory machine-readable medium claim having similar limitations to claim 6. Thus, claim 19 is rejected for the same rationale as applied to claim 6.
With regard to claim 20, it is a non-transitory machine-readable medium claim having similar limitations to claim 7. Thus, claim 20 is rejected for the same rationale as applied to claim 7.
Claims 3, 11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Sun in view of Gai in view of Burris as applied to claims 1, 8, and 15 above, and further in view of Ciszewski et al. Pub. No. US 2017/0031804 A1 (hereinafter Ciszewski).
With regard to claim 3, Ciszewski teaches wherein the operations further comprise:
determining whether the request identifier matches the parent request identifier ([0022], Service 113 may be considered a new version of a service, while service 103 may be considered the previous version of the service, although other distinctions are possible so long as the services are different versions relative to each other. For example, service 113 could be an older version of service 103, not a new version. Service 103 and service 113 process the traffic in parallel relative to each other and generate responses that are directed to validation service 107; [0024], Validation service 107 receives the responses from both service 103 and service 113 (step 205) and evaluates the responses to determine whether or not to validate service 113 (step 207).); and
in response to determining that the request identifier matches the parent request identifier, validating that the request is associated with the service ([0024], For instance, if the responses match, then it that portion of the new version of the service may be considered valid or ready.).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Ciszewski with the teachings of Sun in view of Gai in order to provide a system that teaches request validation. The motivation for applying Ciszewski teaching with Sun in view of Gai teaching is to provide a system that allows for synchronization of data between a live service and its corresponding shadow service, such that enables corrections to the shadow service’s state without disruption against the live service (Ciszewski, [0002]-[0003]). Sun in view of Gai and Ciszewski are analogous art directed towards service computing arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Ciszewski with Sun in view of Gai to teach the claimed invention in order to provide request identifier matching and service request validation.
With regard to claim 11, it is a method of claim having similar limitations to claim 3. Thus, claim 11 is rejected for the same rationale as applied to claim 3.
With regard to claim 17, it is a non-transitory machine-readable medium claim having similar limitations to claim 3. Thus, claim 17 is rejected for the same rationale as applied to claim 3.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Sun in view of Gai in view of Burris as applied to claim 1 above, and further in view of Kirshenbaum Pub. No. US 2010/0083004 A1 (hereinafter Kirshenbaum).
With regard to claim 5, Kirshenbaum teaches wherein the operations further comprise:
generating a key and a value based on a hash for the data associated with the context identifier ([0027] In order to address the foregoing problems, the present invention provides systems that include request-management processes and techniques, as well as storage data structures. With regard to storage, as shown in FIG. 2, the preferred embodiments of the present invention employ a structure utilizing two kinds of storage nodes: entry nodes 42 that store associations that are requested (by authorized entities) to be made between keys and data values and value list nodes 43 that store the data values pertaining to a common key; [0039], References to the value list nodes 43 that are stored in the entry nodes 42 preferably are generated by using a unique hashing technique), wherein the key comprises a context associated with the parent request ([0031], In one exemplary embodiment, the key corresponds to a particular user who is being granted access (i.e., the grantee) and also corresponds to a particular file, folder or other data object for which access is being granted (but instead could correspond to either one alone), and the data value corresponds to a decryption key that is used to decrypt the data object (or any other metadata pertaining to the data object).) and the value comprises the parent request identifier ([0033], In this regard, the term “data value” as used herein can comprise a single value (e.g., a decryption key as described in the “Key Management” application) or an array or set of component values of the same or different types (e.g., an entire set of values for entry into the fields of a pre-defined form). Generally speaking, the request 45 can involve any kind of data value; [0040], The association stored in the entry node 42 preferably includes the key, together with certain additional information. In the present embodiment, such additional information includes: (1) a data value (which, as noted previously, can include multiple different components or values) designated by the requester with which the key is to be associated (Examiner notes: The request being a data object key and the value being an associated identifier).); and
retrieving the context associated with the parent request based on the key and the value (FIG. 3, step 77 Data value request? and step 78 Retrieve/generate and provide any relevant data values; [0066], in step 77 a determination is made as to whether any data value request 360 (as shown in FIG. 8) has been made; [0068], In step 78, any data value (or portion thereof) that is relevant to the received request 360 is retrieved and/or generated on-the-fly and then provided to the request 350. As indicated above, the request 360 preferably includes a key 362 that is derived from the data object to which the desired data values apply or, more generally, from an identification for the desired data value).
It would have been obvious to one of ordinary skill in the art at the time the invention was filed to apply the teachings of Kirshenbaum with the teachings of Sun, Gai, and Burris in order to provide a system that teaches key and value association with the context and identifier of a parent request and retrieving information of such request based on the key-value pair. The motivation for applying Kirshenbaum teaching with Sun, Gai, and Burris teaching is to provide a system that allows for a storage and retrieval of key-value pairs such that enables associations between keys and values to be used in mapping data object metadata with information associated with such metadata that may be efficiently retrieved (Kirshenbaum, [0036]). Sun, Gai, Burris, and Kirshenbaum are analogous art directed towards service computing arrangements. Therefore, it would have been obvious for one of ordinary skill in the art to combine Kirshenbaum with Sun, Gai, and Burris to teach the claimed invention in order to provide a key-value data structure configured to store and retrieve data associated with a particular request.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 9,798,973 B2
teaches
A method, system, and/or computer program product performs rule execution in decision services. One or more specialized ruleset classified by decision partitions are based on defined clustering predicates of decision services signatures for business rules.
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 IVAN A CASTANEDA whose telephone number is (571)272-0465. The examiner can normally be reached Monday-Friday 9:30AM-5:30PM EST.
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, Aimee Li can be reached at (571) 272-4169. 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.
/I.A.C./Examiner, Art Unit 2195
/Aimee Li/Supervisory Patent Examiner, Art Unit 2195
Prosecution Insights