DETAILED ACTION
This Office Action is in response to claims filed on 11/20/2023.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
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).
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, from a decision service pool at a unified strategy evaluation pool, a request associated with a 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)), wherein the request comprises a context identifier associated with the 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.) which is performed 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.);
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 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 comprises a set of rules for evaluating the request (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.
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 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 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 a second 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.), 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 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 second data associated with the second context identifier and second 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 identifying the second strategy and the identifying the 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.);
retrieving a second set of rules associated with the second strategy (Col. 7, If trigger event detection detects segments in block 420, the segments are forwarded to block 422 for construction of development and validation data for the targeted segments. If event detection is triggered in block 420, data collection continues in block 408. In addition to segments identified through automated trigger identification at 422, the ARIE may operate on user defined segments 405, as described above, and pull additional data with attributes at 406.), wherein the retrieving the second set of rules and the retrieving the set of rules are performed synchronously (Col. 8, Entry of the data to the ARIE occurs in block 508. The data is processed in block 510, 512, 514, and 516 through reading of the csv (comma separated values) header, encoding of categorical levels, imputation of missing values and memory mapping.);
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.
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 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 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 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 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 and Gai 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 and Gai 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 and Gai and Kirshenbaum are analogous art directed towards . Therefore, it would have been obvious for one of ordinary skill in the art to combine Kirshenbaum with Sun and Gai 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
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